HPノートブックファンクションキーは、Arch Linuxのスリープモードで起動した後の動作を変更します。

HPノートブックファンクションキーは、Arch Linuxのスリープモードで起動した後の動作を変更します。

HPノートブックにArch Linuxシステムを設定していますが、キーボードは奇妙な方法で配置されているので(小さいまたは大きいキーで示されたキーはスキャンコード105を送信し、これは正しいコントロールXと解釈されます)、設定を試みる必要があります。私のキーボード設定。問題は、どのキーがどのスキャンコードを送信するかを確認するためにxevを使用したときにファンクションキーに奇妙なことがあることです。正確さのために、私はフランス語AZERTYレイアウトを使用しており、私が報告する動作は、私がロードするすべてのフランス語レイアウトsetxkbmapfrレイアウト、モデルevdev、AZERTYで始まるすべてのレイアウトhp)で発生します。

  • まず、F1の行動は本当に一貫していません。システムを起動してログインした後に修飾子を適用せずにF1キーを押すと、一般的に役立つようにマッピングされたスキャンコード146が送信されます。ただし、下に戻ると、それ自体を押すと、これを実行せずに、代わりにスキャンコード133(Super_Lにマッピングされている)と67(F1にマッピングされています)を継続的に送信し、これがトリガーされるものがわかりません。変化。再起動すると、常に予想される動作にキーが復元されます。

  • 第二に、F4キーはほぼ同じように動作します。再起動後、単独で押すと164(XF86Favorites)を送信しますが、ある時点では133(Super_L)と33(p)を送信することに変更されます。この変更はF1キーの動作変更と同時に発生するようです。 ~によるとこれページ、HPノートブックでは、F4キーはノートブックディスプレイと外部モニターを切り替えるために使用されます。

  • 最後に奇妙なことは、通常、修飾キーとファンクションキーをすばやく連続して押すと、各ファンクションキーと各修飾子を体系的に試みるときに送信されると予期しないいくつかのスキャンコードが送信されることです(XF86Sleepなど)。キャラクター実行時にスキャンコードが出てこないので何を意味するのか分からないですね… こんな現象は時々発生し、再現条件が何なのかよく分からないので再現が難しいです。

何が起こっているのか知っている人はいますか?私はLinuxlandに初めて触れ、Xがキーボード構成をどのようにしているかを理解しようとしましたが、まだ混乱しています。したがって、私が間違って理解している、または愚かなことをしている場合は、教えてください。また、どのような情報が役に立つのかわからないので、この問題を解決するのに役立つ追加情報が必要な場合はお知らせください。

ちなみに、Fnキーも押して離したら、次にファンクションキーを押すときにFnキーを押しているのと同じという点でデッドキーのように見えます。これがちょっと迷惑な部分がありますが、fnキーはOSではなくキーボードで直接処理するからといって、どうすればいいのかわかりませんね。

編集1:そこでこの質問を上げた直後、続けてキーボードに触れながら考えました。いくつかの手がかりを提供しますが、答えはあまりありません。 F1とF4が行動を変える原因は、Xがスリープ状態になるからです。再起動後、ラップトップを閉じるか、F5(Xにスリープモードに切り替えるように指示する信号を送信)を押してXをスリープモードに切り替えます。以前はF1とF4が予想通りに行っていましたが、目が覚めて混乱しました。実際、F5キーもこれによって変更されました。 xevによると、目覚めた後にそれ自体を押してもスキャンコードが研磨されないからです。これはまた、私が認識していないキーコードが時折表示される理由も説明します。

しかし、今これを知ったので、Fキーに他の奇妙な点も発見しました。 xevによると、変更の前後にそのキーを押したときに影響を受けるすべてのキーの動作の概要は次のとおりです。

  • F1:前 = 146(ヘルプ)。以降 = 133 + 67(Super_L + F1)。
  • F4: 前 = 164(XF86 お気に入り)。以降 = 133 + 33(Super_L + p)。
  • F5: 前 = 150(XF86Sleep)。以降 = 何も
  • F11: 前 = 136 + 171 (キャンセル + XF86AudioNext)。以降 = 171(XF86AudioNext)。
  • F12: 以前 = 255 + 171(XF86RFKill + XF86AudioNext) または 171 + 255(XF86AudioNext + XF86RFKill)、識別できるパターンはありません。毎回= 255(XF86RFKill)以降。

だから寝て起きて壊れる人もいて、起きてすぐに滅びる人もいて、寝てから解決した人もいて…混乱します。

ベストアンサー1

おすすめ記事