Bluetoothキーボードをコンソール入力用の実際のキーボードではなく、リモコン（電気ロックを開くためのPIN入力パッド）として使用したいと思います。以下のudevルールを使用してBluetoothキーボードに正しくアクセスできます。
ENV{ID_BUS}=="bluetooth", ATTRS{phys}=="00:1a:7d:e3:76:60", ENV{ID_INPUT_KEYBOARD}=="?*", GROUP="uucp", SYMLINK+="btremote"
これにより、デバイスノードがグループuucp（キーイベントへのアクセスを必要とするグループ）に入り、適切なデバイスとのシンボリックリンクも作成されます/dev/btremote（/dev/input12数値が異なるため）。今まではそんなに良くなった。
残念ながら、キーボードと内蔵ポインティングデバイス返品私のXセッションに接続して実行すると表示されますloginctl seat-status seat0。私はリモコンを自分のコンソールより安全性の低い場所に配置する予定であり、人々が自分のコンソールに入力したくないので（またはそのキーボードに組み込まれているポインティングデバイスを使用すること）、迷惑で危険です。
私はいくつかのバリエーションを試しました。
ATTRS{phys}=="00:1a:7d:e3:76:60", TAG-="seat", ENV{ID_AUTOSEAT}=""
私はXセッション接続からデバイスを除外しようとしましたが、udevは機能しません。解決策として、偽の座席とloginctl attachキーボードを作成できることを知っていますが、seat1これはセキュリティ上の問題なので、そのMACアドレスに一致するすべてのBluetoothデバイスを完全に除外する単純なudevルールを使用することをお勧めします。信頼できず、自動ではないからです。起こることができる
私の質問は、この座席割り当てメカニズムがどのように機能するのか、そしてデバイスグループを安全に除外する方法です（キーボードは実際には4つの入力デバイスとして表示されるので）。関連している場合は、systemd-242.32でArch Linuxを使用しています。
修正するとの間で実行される/etc/udev/rules.d/72-btremote.rulesというファイルにルールを追加しました。前者はラベルが追加される場所のようで、後者は座席番号が割り当てられているようですが、これがどのように機能するかを理解していないことを認めます。/usr/lib/udev/rules.d/71-seat.rules/usr/lib/udev/rules.d/73-seat-late.rulesseat
アップデート2数回の努力の終わりに、私が欲しいものを手に入れました。
ATTRS{phys}=="00:1a:7d:e3:76:60", ENV{ID_SEAT}="none"
シートラベルを無効にする代わりに（または少なくとも他のデバイスに対応するラベルがmaster-of-seatある場合）、「なし」というシートを作成すると思うので、これはまだ醜い感じです。私はまだ何が起こっているのか、なぜTAG-="seat"動作しないのか理解していないので、まだ質問に答えていないので、他の人が説明できることを願っています。