Thread (13 messages) 13 messages, 2 authors, 2016-09-14

Re: btattach: auto triggering at boot time by Linux distributions

flat view

From: Marcel Holtmann <marcel@holtmann.org>
Date: 2016-09-04 19:30:59

Hi Jerome,
From a Linux distribution point of view, what part of the stack is
expected (or would you recommend) to trigger the user-space btattach
command, to have Bluetooth enabled automatically at boot?

On an older computer, hot-plugging a Bluetooth USB adapter starts
Bluetooth automatically. On a ThinkPad 8 tablet, a manual btattach
command is currently needed to attach the hardware and load the
firmware for its Broadcom chip.

What do distro maintainers need to adapt to achieve the equivalent of
the USB auto-loading case for btattach-based chipsets, now that
btattach is starting to be included in some Linux distributions (such
as in Debian following this report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816865 even if only
in experimental right now)?

Is it an already planned evolution on BlueZ side? Reading through the
mailing list, it doesn't seem to be the case but I may have missed a
discussion.

If not, any hints would be really appreciated, and especially your
view on which SW component would be a good candidate to take care of
this initialization task. Thanks a lot.
the real evolution would be that we get a serial bus (as discussed a few weeks ago) which then the UART kernel drivers can enumerate its devices on.

Until then, you need an userspace part that triggers btattach with the right hardware id on the right /dev/ttySx device node as soon as it becomes available. So that means udev rules. However the problem is and always has been to figure out what hardware is behind what /dev/ttySx. If you are lucky it is part of ACPI tables or DT. If you are unlucky you need a DT overlay or hardcode it.

The pain point is really that the kernel has all the information we need. Except people kept insisting on creating /dev/ttySx devices and let someone else deal with the fact that it is an actual Bluetooth chip behind it.

That said, it has gotten better when we moved power control into the Intel and Broadcom drivers. Which means you no longer need to fiddle with RFKILL to get your GPIOs set up. That was a huge mess as well when people though we just expose the power control of the TTY as RFKILL switches and leave userspace totally in the dark and jump through 10 hoops before getting things working.

Regards

Marcel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help