Hi Serge, On Mon, Aug 1, 2016 at 7:12 PM, Serge van den Boom <serge@xxxxxxxxxx> wrote: > Hi Luiz, > > Thanks for the reply. > > On Mon, 1 Aug 2016, Luiz Augusto von Dentz wrote: >> This is a classical problem of using hci* tools along with bluetoothd, >> they both are trying to control the same thing and then you got a >> conflict, it shall be one or the other but not both. If you are >> curious to look at the bluetoothd source code you will see that the we >> derive the class of the device from the registered services so there >> is no point in doing anything with hcitool. > > That is interesting, because if I don't set the class explicitly, it > always shows up as 0x100000 when I inspect it. And more relevantly, > if I don't explicitly set the class, the (HID) device that I am > implementing won't be discovered. > > I haven't been able to find the part of the bluetoothd code that you are > referring to, so far. I would appreciate it if you could point me in the > right direction. https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/adapter.c (get_uuid_mask) For more about registering profiles see: https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/profile-api.txt You may not be able to register HID as an external profile if the input plugin is active because afaik both roles have to listen to certain fixed PSMs, I wouldn't oppose to have this functionally in the input plugin itself though since we can make it generic enough to use with HoG implementation. -- Luiz Augusto von Dentz -- 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
