Re: Registering profile or making discoverable resets adapter class

[Serge van den Boom <serge@vdboom.org>]

Hi Luiz,

On Mon, 1 Aug 2016, Luiz Augusto von Dentz wrote:

> On Mon, Aug 1, 2016 at 7:12 PM, Serge van den Boom <serge@vdboom.org> wrote:
> > 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)

I see. So this only affects the major service class part of the
CoD field, and not the (major or minor) device class parts.
And as there is no case for HID_SVCLASS_ID, the CoD is not affected by
an HID service.

> 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.

I had my service working already, but it involved setting the class id
in the /etc/bluetooth/main.conf file. I disliked this, as it involved
making a system-wide modification to run my service.

After a conversation on the #bluez IRC channel, it appears that this
however is the correct way. Apparently, a bluetooth device is not
expected to change what it is.

I did indeed have to disable the input plugin.


Thanks,

Serge