Hi Chen, > Do we really need this kind of functionality? Firstly you should realize that this is not about functionality exposed to the user or applications, but functionality exposed to bluetoothd. The fact that we have something in the mgmt interface doesn't mean that it'll automatically be exposed in the D-Bus interface or bluetoothd internal APIs. As for this particular case (allowing bluetoothd to restrict device discovery to LE or BR/EDR) the reason is the concern that when doing discovery for a specific profile which is only applicable for BR/EDR or LE, you really don't want to waste the users time doing the "other" discovery which will not yield any valuable results. Examples of this could be discovering devices to send a file over Object Push (BR/EDR only) or when running a application for a LE profile which utilizes features only available though an LE radio. I'm not completely sure the need for this will be strong enough for exposing it in the D-Bus API, but not having it in the kernel interface (mgmt) from the start makes it a lot harder to fix if we do end up needing it later (as opposed to the D-Bus interface which would "only" mean doing a new major BlueZ version). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
