要約

要約

昨日、新しいTrueOSインスタンス(FreeBSDバリアント)をインストールし、USBキーボード(Logitech G510)を接続しました。インストール環境、最初の起動設定中、新しいインスタンスが再起動されるまで正常に動作します。この時点では、ブート時にBSDのモジュールロードフェーズから始まり、入力転送を完全に停止するようです。なぜなら、この時点でScroll Lockが動作を停止するからです。ただし、LCD画面とバックライトが点灯していて他のキーボードを接続すると、ステータスの変更(Caps / NumLockなど)を追跡し、Windows / Linuxおよびラップトップでうまく機能します。

BIOSでLegacy USBとHand-offをオン/オフするだけでなく、さまざまなポートを使用するさまざまな組み合わせを試しましたが、役に立ちませんでした。他のUSBキーボード(以下のログの「サプライヤー0x1241 USBキーボード」)はどちらもうまく機能します。 USBマウスは常に動作します。 PS/2ポートがありません。

ここで何が起こっていて、どのように解決するのかご存知ですか?ありがとうございます!

% dmesg | grep kb
kbd1 at kbdmux0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
ukbd0 on uhub5
ukbd0: <vendor 0x1241 USB Keyboard, class 0/0, rev 1.10/2.80, addr 2> on usbus6
kbd2 at ukbd0
ukbd1 on uhub0
ukbd1: <Logitech G510 Gaming Keyboard, class 0/0, rev 2.00/1.65, addr 2> on usbus0
kbd3 at ukbd1

% ll /dev/*kb*
crw-------  1 root  wheel  0x47 Oct 31 10:46 /dev/atkbd0
lrwxr-xr-x  1 root  wheel     6 Oct 31 10:46 /dev/kbd0 -> atkbd0
lrwxr-xr-x  1 root  wheel     7 Oct 31 10:46 /dev/kbd1 -> kbdmux0
lrwxr-xr-x  1 root  wheel     5 Oct 31 10:46 /dev/kbd2 -> ukbd0
lrwxr-xr-x  1 root  wheel     5 Oct 31 10:46 /dev/kbd3 -> ukbd1
crw-------  1 root  wheel  0x25 Oct 31 10:46 /dev/kbdmux0
crw-------  1 root  wheel  0x62 Oct 31 10:46 /dev/ukbd0
crw-------  1 root  wheel  0x6a Oct 31 10:46 /dev/ukbd1

ベストアンサー1

要約

実際に起こったことはとても簡単でした。追加のゲームやその他のキーを押すための真のNキーロールオーバーを提供するために、Logitechはキーボード入力イベントがUSB経由で報告される方法を調整しました。 FreeBSDカーネルに組み込まれているUSB入力レポート解析ライブラリはこの機能をサポートしていません。カーネルメッセージ出力をフィルタリングしないと、次のメッセージが表示されます。

hid_get_item:アイテム数(991)が255に切り捨てられました
hid_get_item:アイテム数(257)が255に切り捨てられました
または

hid_get_item:364: 255 で切り捨てられた項目数

詳細

USB入力レポートプロトコルを使用すると、USB HIDはそれぞれ最大65531のキーで構成される2つのグループを持つことができます。現在のUSB規格は、A a最初のグループのキー4()から231()までのコードを定義しています。⌘ Right GUI「ゲーム用キーボード」にはこれ以上のキーがあり、ほとんどは標準化されたキーコードと一致せず、とにかく実際に2番目のグループに属することができます。

USBHID概念的にキーボードアクティビティをキーごとに1ビットの巨大なビットマップとして報告し、キーボード上のすべてのキーの現在の動作/動作状態を説明します。これは実際には8つの修飾子キー(コード224〜231)の場合に当てはまりますが、通常他のキーは逆配列として報告されます。デバイスからUSBホストに回線を介して送信されるキーボード入力レポートには、次のものが含まれます。索引ビットマップのビット数1に設定されています

この逆配列形式はスペースを節約します。現在、126キーのマルチメディアキーボードでこの回答を入力しており、各入力レポートにはキーボード全体をビットマップ形式で報告するために16バイトが必要です。ただし、反転配列の場合は8バイトのみを使用し、そのうち6バイトは変更されていないキーの配列インデックスです。

この逆配列形式の問題は、何も得られないことです。

  • 反転を制限します。 完全なビットマップを使用すると、真のNキーロールオーバーが可能になります(キーボードマトリックス自体のハードウェア制限によって異なります)。逆配列型の場合、配列インデックスの数によって反転回数が制限されます。通常、USB HIDキーボードはレポートに6つの配列インデックスを提供し、最大6つの(修飾子ではない)キーを同時に押すことができます。これは、USB HID規格が実際に付録でこの「ブート」レポート形式を説明しているためです。
  • 重要なコードを制限します。 配列インデックスは通常8ビット整数です。 256以上のキーコードを収容できるように広くし、6つの同時に押された(非修飾子)キーを報告するために8バイト以上が必要であるか、またはレポートできる同時に押したキーの数を次より少なくします。 6.

    残念ながら、ゲームキーボードは256よりもはるかに多くのキーコードを報告できるはずです。上記のログの抜粋を見るとわかるように、ロジクールゲーミングキーボードのキーコードは1つのケースでは最大257、もう1つの場合は991です。それは257と991のキーがあるという意味ではありません。これは意味するキーコード値の範囲そんなに広いですか?

FreeBSDカーネルの制限事項、特にFreeBSDカーネルに接続されているlibusbライトバージョンの制限は、やや微妙です。よく報告されるように、ビットマップサイズに制限はありません。これはUSB用語の制限です。報告件数の一つ入力。 FreeBSDはレポート数を255個に制限し、実際のレポート数が255個を超えると上記のメッセージを印刷します。

これにより、次のような結果が得られます。両方キーボード入力のビットマップ形式と逆配列形式。

  • ストレートビットマップ形式の場合、255より大きいビットマップは255番目のキーコードで切り捨てられます。つまり、ビットマップの最初の64バイトのみが考慮されます。これは認識されるキーコードの範囲を制限します。
  • 逆配列型の場合、これは最初の255個の配列インデックスのみが使用されることを意味します。もちろん、最初の255個の配列インデックスには任意のキーコードを含めることができます。これにより、有効なロールオーバー量が制限されます。

これは後者より前者の問題が大きい。賢明な人なら、重要な状況ではビットマップ形式ではなく逆配列形式を使用しません。 255個の配列インデックスを持つ逆配列はたくさんあります。少ない同じサイズのビットマップは、真のNキーロールオーバーを介して8倍のキーコードを表すことができるため、同等のビットマップ形式よりもスペース効率が高くなります。

したがって、Logitechは、257または991キーコードの範囲内のすべてのキーコードを報告し、すべての追加キーが正しく機能できるようにします。 (このように分割される理由は、さまざまな種類のキーを押すためのコードが異なる「ページ」にグループ化される方法と、アイテムが複数の「ページ」にまたがることができない方法に関連しています。これはUSBミステリーであり、この記事の範囲から外れます。)答え。 )そして人々に単純な6キーロールフリー機能以上の機能を提供したいと思います。

これを行うにはUSBに切り替えます。レポート記述子の形式を入力してください。ビットマップと広範なレポートを使用します。 (USBを使用すると、HIDに複数の入力レポート形式があり、フォーマット間で切り替えることができます。)FreeBSDカーネルはそれを気に入らず、問題が発生します。

デフォルトの修正は、Logitechキーボードが6キーロールオーバーを提供する「ブート」入力レポート記述子形式を引き続き使用し、「デフォルト」レポートではなくキーボードの追加キーのコードを送信できないようにすることです。記述子形式。これは、各システムブートローダでこのコマンドを使用し、それにusbconfigサブadd_quirk UQ_KBD_BOOTPROTOコマンドを提供することによって実行できます。

重要なのは、この異常な点をFreeBSDカーネルに組み込まれている事前定義された既存の特異点のリストに入れ、カーネルがそれを一致するUSB​​デバイスに魔法のように適用することです。

サービスの修正は、報告回数が255に制限されないようにカーネル内のlibusbカットを修正することです。 FreeBSDメーリングリストの1つで、これについて簡単で表面的な議論がありましたが、誰もこれを行いませんでした。

おすすめ記事