IntelおよびBroadcomの一部の最新のBluetoothチップセットでは、btattachBluetoothを正しく有効にするためにユーザースペースでこのコマンドを実行する必要があります（BTチップセットを「接続」し、必要に応じて必要なファームウェア負荷をトリガーします）。
この例は、次のコマンドを必要とするLenovo ThinkPad 8タブレットのBroadcom BCM43241 rev B5チップセットですが、# btattach --bredr /dev/ttyS1 -P bcmこれはUARTコントローラに接続されている他の多くのBluetoothチップセットに適用されます。
btattachQ：起動中にBluetoothを自動的に有効にするために必要なコマンドを実行する最も推奨される方法は何ですか？？
PS最近、多くの最新のデバイスには基本的にBluetooth機能がまったくないため、コマンドのパッケージ化を開始したLinuxディストリビューション（Debianなど）btattachにこれらの修正を提供することがアイデアです。これは、フルサイズのUSBポートがほとんどないかまったくないタブレットに特に便利です。
答え1
linux-bluetoothメーリングリストに関するディスカッションでは、対応するメーリングリストを作成することを提案しましたudev rule。を参照してください。このメッセージ。
質問に記載されている特定のチップセットの場合、単純なudevルールは次のとおりです。
$ cat /etc/udev/rules.d/98-bluetooth-attach-broadcom.rule KERNEL=="BCM2E55:00", RUN+="/usr/bin/btattach --bredr /dev/ttyS1 -P bcm"
そしてBCM2E55:00対応するBluetoothチップセットのハードウェアACPI識別子で、次のように表示されます。ターミナルS1デバイスノード（のsysfsで表示されます/sys/devices/platform/80860F0A:00/tty/ttyS1/device/BCM2E55:00$）各ACPI識別子をルールファイルに追加し、対応する/ dev / ttyS *を各チップセットバリアントに合わせて調整する必要があります。
しかし、この単純なアプローチの既知の制限は、上記のように短時間だけ動作することです。ここ。実際、btattachコマンドは数秒/分後に終了します。これは次の動作の記録ですudev。
デーモンや他の長期実行プロセスを開始することは、分離の有無にかかわらずudevには適していません。死イベント処理が完了した後。 `
btattachしたがって、他のオプションでは終了しないようにするために、たとえばsystemdサービスを介してルール自体から直接コマンドを実行するのではなく、間接的なトリガが必要です。udevbtattach
この簡単な答えは、予備テストを実行するとき、特に正しいudevルール条件を見つけるときにまだ役に立ちます。
答え2
より洗練されたアプローチは、udev正しいハードウェアがある場合にのみトリガーされるルールをbtattach作成することですsystemd service。これは、前の2つの答えを組み合わせた概念です。
質問に記載されている特定のチップセットの場合、udevルールは簡単に見えます。
$ cat /etc/udev/rules.d/99-bluetooth-btattach.rules KERNEL=="BCM2E55:00", RUN+="/bin/systemctl --no-block start btattach-broadcom-ttyS1.service"
そしてBCM2E55:00対応するBluetoothチップセットのハードウェアACPI識別子。
systemdサービス、子として表示されるチップセットとのみ互換性ターミナルS1デバイスノード（のsysfsによって表示されます/sys/devices/platform/80860F0A:00/tty/ttyS1/device/BCM2E55:00$）は、次のように非常に簡単に維持できます。
$ 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
これは、サブキー（およびパラメータ）として表示される他のBroadcomチップセットとsystemd service同じように機能します。-P bcmttys1（したがって/dev/ttyS1）udev他のチップセットバリアントのACPI識別子を含めるようにルールを完成させてください。
他のttyS *ノードに接続されているBroadcomチップセットの場合、このsystemd serviceケースを処理するために別の同様のチップセットを作成できます（またはudevルールでsystemdサービスと正しいパラメータを共有できます）。
タブレットを再起動すると、btattach起動時にコマンドが正しく実行されたことがわかりました。
$ 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
そして、Bluetoothが実際に有効になって動作しています！ Gnome Bluetoothの設定には、接続および検出されたデバイスが一覧表示され、コマンドライン$ bluetoothctlから実行するとコントローラが正しく表示されます。
驚くべきことに、単に実際のコマンドを遅らせるために使用される最初の1秒のスリープコマンドを削除すると、Bluetoothはまったく機能せず、正しくアクティブになりません。それにもかかわらず、btattachバックグラウンドプロセスのリストではまだ正しく実行されているようです。
正確に何が起こっているのかはまだわかりません。 btattachが起動する前にタイミングの問題があり、必要な依存関係を待つ必要があることは確かです。
答え3
1つの可能なアプローチは、次のようにハードコーディングされたsystemdサービスを作成することです。
$ 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`
この新しいサービスを有効にするには、次のコマンドを実行します。
# systemctl --system enable btattach
タブレットを再起動すると、起動時にbtattachコマンドが正しく実行されることがわかります。
$ 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
そして、Bluetoothが実際に有効になって動作しています！ Gnome Bluetoothの設定には、接続および検出されたデバイスが一覧表示され、コマンドライン$ bluetoothctlから実行するとコントローラが正しく表示されます。
驚くべきことに、実際のコマンドを単純に遅らせる初期コマンドを1s sleep削除すると、Bluetoothはまったく機能せず、正しくアクティブになりませんが、btattachバックグラウンドプロセスリストではまだ正しく実行されているようです。
正確に何が起こっているのかはまだわかりません。始める前にタイミングの問題があり、必要な依存関係を待つ必要があることは確実ですbtattach。