Como ativar o Bluetooth * automaticamente na inicialização * para os chipsets Intel e Broadcom recentes que dependem de btattach?

Question

Alguns chipsets Bluetooth recentes da Intel e Broadcom precisam executar o comando btattach no espaço do usuário para que o Bluetooth seja habilitado corretamente (ele "conecta" o chipset BT e aciona o carregamento do firmware necessário, se necessário). / p>

Esse exemplo é o chipset Broadcom BCM43241 rev B5 encontrado em tablets Lenovo ThinkPad 8 que precisam do seguinte comando # btattach --bredr /dev/ttyS1 -P bcm , mas isso é aplicável a muitos outros chipsets Bluetooth conectados a um controlador UART.

P: Qual é a melhor maneira recomendada de acionar o comando btattach exigido durante a inicialização para que o Bluetooth seja ativado automaticamente ?

P.S. A idéia seria contribuir com tal modificação para as distribuições Linux começando a empacotar o comando btattach (como o Debian), já que agora muitos dispositivos recentes simplesmente não têm o Bluetooth pronto para uso. Isso seria especialmente útil para tablets que não possuem ou têm algumas portas USB de tamanho normal.

    

Answer 1

Uma abordagem mais refinada consiste em criar uma regra udev , acionada apenas quando o hardware correto estiver presente, para iniciar o comando btattach necessário de um systemd service . Isso está mesclando os conceitos das duas respostas anteriores.

Para o chipset específico mencionado na pergunta, a regra udev é simplesmente assim:

$ cat /etc/udev/rules.d/99-bluetooth-btattach.rules KERNEL=="BCM2E55:00", RUN+="/bin/systemctl --no-block start btattach-broadcom-ttyS1.service"

com BCM2E55: 00 sendo o identificador de hardware ACPI do chipset Bluetooth correspondente.

O serviço systemd, compatível apenas com chipsets que aparecem como filhos do nó do dispositivo ttyS1 (visível via sysfs em /sys/devices/platform/80860F0A:00/tty/ttyS1/device/BCM2E55:00$ ), pode permanecer muito simples assim:

$ cat /etc/systemd/system/btattach-broadcom-ttyS1.service [Unit] Description=Start btattach, needed to enable Bluetooth for some UART-based Bluetooth Broadcom chipsets [Service] Type=simple # A delay is needed, 1s seems enough ExecStartPre=/bin/sleep 1s ExecStart=/usr/bin/btattach --bredr /dev/ttyS1 -P bcm

Esse systemd service funcionará como está para outros chipsets da Broadcom (daí o parâmetro -P bcm ) aparecendo como um filho de ttys1 (daí o /dev/ttyS1 ); apenas a regra udev precisa ser preenchida para incluir os identificadores ACPI de outras variantes do chipset.

Para os chipsets Broadcom que se conectam a um nó ttyS * diferente, outro systemd service semelhante pode ser criado para cobrir este caso (ou talvez os parâmetros corretos possam ser compartilhados da regra do udev para o serviço systemd).

A reinicialização da mesa mostra que o comando btattach foi executado corretamente na inicialização:

$ ps auxw | grep btattach root 2059 0.0 0.0 6372 720 ? Ss 23:17 0:00 /usr/bin/btattach --bredr /dev/ttyS1 -P bcm

e o Bluetooth está realmente ativado e funcionando! As configurações do Gnome Bluetooth listam dispositivos conectados e varridos e a execução de $ bluetoothctl a partir de uma linha de comando mostra corretamente o controlador.

Surpreendentemente, ao remover o comando sleep 1s inicial usado para simplesmente atrasar o comando real, o Bluetooth não está funcionando e não está habilitado corretamente, apesar de btattach ainda parecer estar sendo executado corretamente na lista de processos em segundo plano.

Não tenho certeza de entender exatamente o que está acontecendo: há uma questão de tempo em jogo e, certamente, uma dependência necessária para esperar, antes de ser lançado o btattach ...

    

Answer 2

Discussões na lista de discussão linux-bluetooth sugeriram criar um udev rule correspondente, cf. esta mensagem .

Para o chipset específico mencionado na pergunta, uma regra do udev simples é assim:

$ cat /etc/udev/rules.d/98-bluetooth-attach-broadcom.rule KERNEL=="BCM2E55:00", RUN+="/usr/bin/btattach --bredr /dev/ttyS1 -P bcm"

com BCM2E55: 00 sendo o identificador de hardware ACPI do chipset Bluetooth correspondente, aparecendo como um filho do nó de dispositivo ttyS1 (visível via sysfs em /sys/devices/platform/80860F0A:00/tty/ttyS1/device/BCM2E55:00$ ) . Cada identificador ACPI precisaria ser adicionado no arquivo de regras com o / dev / ttyS * correspondente adaptado para cada variante de chipset.

No entanto, uma limitação conhecida desta abordagem simples é que ela funciona apenas por um curto período de tempo, conforme descrito aqui . De fato, o comando btattach é morto alguns segundos / minutos depois. Este é um comportamento documentado de udev :

Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.'

Portanto, em vez de ativar o comando btattach diretamente da regra udev , outras opções precisarão acionar btattach indiretamente para garantir que ele não seja eliminado, por exemplo, por meio de um serviço systemd.

Essa resposta simples ainda pode ser útil enquanto você faz alguns primeiros testes, especialmente para encontrar a (s) condição (ões) da regra do udev.

    

Answer 3

Uma abordagem de trabalho é criar um serviço systemd hardcoded com esta aparência:

$ cat /etc/systemd/system/btattach.service 
[Unit]
Description=Start btattach, needed to enable Bluetooth for some UART-based Bluetooth chipsets
[Service]
Type=simple
\# A delay is needed though, 1s seems enough on my system
ExecStartPre=/bin/sleep 1s
ExecStart=/usr/bin/btattach --bredr /dev/ttyS1 -P bcm
[Install]
WantedBy=multi-user.target'

Para ativar este novo serviço, execute o seguinte comando:

# systemctl --system enable btattach

A reinicialização do tablet mostra que o comando btattach agora é executado corretamente na inicialização:

$ ps auxw | grep btattach
root      2059  0.0  0.0   6372   720 ?        Ss   23:17   0:00 /usr/bin/btattach --bredr /dev/ttyS1 -P bcm

e o Bluetooth está realmente ativado e funcionando! As configurações do Gnome Bluetooth listam dispositivos conectados e varridos e a execução de $ bluetoothctl a partir de uma linha de comando mostra corretamente o controlador.

Surpreendentemente, ao remover o comando 1s sleep inicial usado para simplesmente atrasar o comando real, o Bluetooth não está funcionando e não está habilitado corretamente, apesar de btattach ainda parecer estar sendo executado corretamente na lista de processos em segundo plano. / p>

Não sei ao certo o que está acontecendo exatamente ainda: há uma questão de tempo em jogo e, certamente, uma dependência necessária para esperar, antes de começar a lançar btattach ...