手を入れてから使用するのが面倒くさいので報告した事を報告 8/22追記
先週あたりに、毎回fcitx5の再起動も面倒くさいので報告してしまおうとfictx5のGithubにissueとして報告しました。
[Wayland] Key input freezes after sleep/idle until Fcitx5 is restarted or unblocked #1642
すると、Fcitx5の開発者からコメントがあり、コンポジター側じゃね？という返答とそのログのとり方を教えてもらいました。
その後、DMS側にも同じ事を報告してみました。
Key input / focus gets stuck after sleep when running DMS #3073
するとDMS側は、「仮想キーボードを常駐させているわけではなく、クリップボードから貼り付ける際に明示的に接続を開き終了時に切断する仕組みになっているので、クリップボードの関係は低いと思う」とコメントをもらいました。
- clipboard: release virtual keyboard keys on paste error paths ef05dbe
- displays: apply refresh rate changes without compositor config reload fdf0d73
と2点の修正が入りました。fcitx5の開発者がアタリをつけたあたりに何かしら問題があったようです。下の修正はクリップボードとは関係ないのですが、何かしら手が入ったという感じです。
これら修正版は2026/8/22の早朝ではまだリリースされていないので、これらで直るかどうかはリリース後にテストしてみてからでしかわかりません。
長時間のスリープ後に発症したり、fcitx5のデフォルト設定ではトレイアイコンの「再起動」では直らず、←矢印押しっぱで直し、以下の記事のWayland寄りの設定にしてからはトレイアイコンの「再起動で」直るようにはなったが、Hyprlandのバインドは効くけどもキーボードから入力できないと理由のわからない挙動を見せていたわけです。
これはfcitx5の設定でどうにかなるものではないと思ったので報告したわけですが、以下の記事に書いたWayland寄りの設定は、少なからず有効だと思います。
まずは現在の進捗を報告した次第です。
これら設定を行っても完全に直るわけではありません。症状が出にくくなるか、出てもすぐに収まるそう言う類のものです。
どんな環境でも必ず起こるものでもないと思いますが
Plasma環境、あるいはGNOME環境が現在のWayland対応になる前までは問題なく、Dank Material Shellがv1.5(The Wolverine)になる前はそう言うことは特に起こりませんでしたが、SUPER(Windowsキー/⌘キー)、←矢印、BackSpace、ファンクションキーなどが長時間のスリープから復帰した時に一時的に効かなくなるということがありました。
これらは例えばテキストエディターであればカーソルがある位置で←矢印を押しっぱにすればその内に動いて、動けばその後は問題なく使用できる感じでした。←矢印が効かないと入力を間違った時に戻ることができず、タッチパッドやマウスでカーソルを動かしてdelキーを使用する必要があったり、同様にBackSpaceも入力間違いの時に戻れないことになりますから、いずれにしても面倒くさい状態でした。
ワークスペースの切り替えもSUPERが効かないことから行えず、ウィンドウの切り替えもできないと全てにおいて面倒くさい状態でした。
案外早い段階でfcitx5を終了すれば機能するというのはわかっていた
しばらくはずっと、テキストエディターのカーソル、あるいはファイルマネージャーで何かしらファイルを選んでおいて←矢印を押しっぱにするとその内にそれらが動いて直るというのは気づいていて、原因としてはfcitx5臭いと思ってはいました。
fcitx5を終了させて試すと動作する───。ということはHyprland環境には問題なく、コンポジターをNiriやMango WMに変更すると同様の症状が出るがfcitx5を終了するとやはり動く。
まだPlasma環境のアプリ(プロセス)が動作しているというのはあると言えばありますが、2日に渡ってスリープの状態を続け、時折スリープから復帰をしてみて試して現在の状態で問題ないだろうと思ったのでその状態をここに書いておく次第です。
何が起こっていたか
おそらくPlasmaやGNOMEが現状のWayland対応になる前、またDMSが1.5になる前というのはおそらく(想像ですが)、XWaylandを通じて単一のルートで通信していたものが、Waylandへの対応が進んだことによりinput-method-v2などへの対応が進み、fcitx5にはどのディストリビューションでも対応できるようにX11/XWayland/waylandなどのルートがあり、内部的には正しく動作していても設定でX11を使用するものがあれば通信に混乱が起こったのではなかろうかと。←矢印押しっぱで、その内に直るということもこれら通信が、ある時を境に正常に繋がって正しく動作していたと言うことなんだろうと思うわけです。
起動している間はHyprlandで正しく動作していたのに、スリープから復帰という状態を挟むとまた通信に混乱が起こる → fcitx5を終了させ再起動すると直る と言うのがここからもそうであったのではないかという説明が高い確率でできるようになったと思うのです。
どういう対処をすればよいか
X11の設定が邪魔なので、これらが機能しないようにする設定をして、またデフォルトでSUPERを使用するようなfcitx5のキーバインドを空欄か他のものに変えるようにすればキーの奪い合いがなくなり、正しくHyprlandのキーバインドが通るようになる、つまりはfcitx5がキーの横取りをしなくなると言うことになると考えます。
おそらく今後、ディストリビューションもDMSもfcitx5もバージョンアップをしていくでしょうから、スリープから復帰後にfcitx5を終了させて再起動させると言うことを別途設定する事で対処はできるにしても、修正された時に元に戻す方法を忘れたりと言う事があったりでそれらはできるだけしたくなかったのです。
hyprland.luaの設定
hl.env("XMODIFIERS", "@im=fcitx")
hl.on("hyprland.start", function()
-- default exec_once conf
hl.exec_cmd("fcitx5 -d")
end)念のため環境変数にXMODIFIERSは設定しておきます。これは私がファイルマネージャーにThunarを使用しているからで、設定しなくても動作はするはずですがあくまでも念のためにというものです。fcitx5をシステム起動時にデーモン起動させるだけと言う設定にしてあります。
使用途中でキー不能が起こった
この記事に書いてある設定の最中、スリープからの復帰時でもないのにキー不能になることがありました。以前のように押しっぱでも直らず(もしかしたらもう少し続ければ直っていたかも知れない)で、その時に使用していたのがファイルマネージャーのThunar、ファイルを転送するためのLocalSend、そしてテキストエディター(gnome-text-editor)でした。
ここから考えるに、全部GTKやん!と思ったのでDMS自体はQTを使用したものが多いわけですが、起動させているDMS以外のものはGTKばっかりということで、現在GTKの環境変数を追加して動作が安定するかをテストしています。
hl.env("GTK_IM_MODULE", "fcitx")
hl.env("XMODIFIERS", "@im=fcitx")
hl.on("hyprland.start", function()
-- default exec_once conf
hl.exec_cmd("fcitx5 -d")
end)つまりこういう感じです。
おおよそ12時間ぐらい放置して試してみました。hl.env("GTK_IM_MODULE", "fcitx")を入れておくと、システムの起動時などに「GTK_IM_MODULEを検出した→環境変数を使用せずにWaylandでどうぞ」みたいな通知がおそらく来ます。hl.env("GTK_IM_MODULE", "fcitx")を入れておく方が安定していると言えると思います。
このことから問題が解決するかは不明ながら次回アップデートまでは最低hl.env("GTK_IM_MODULE", "fcitx")を入れておく方が良いと思います。通知が出るだけなので。
同様にQTのアプリを多用される方で似通った症状が出ている場合は、
hl.env("QT_IM_MODULE", "fcitx")を試してみる価値はあると思います。DMS自体もQt/QMLベースのコンポーネントが動作していますが、GTKのテキストエディターほど頻繁に通信を行っているということではないと思うので問題が露出していないだけともとれます。なのでランチャーで文字が入力できないとか、Plasma由来のアプリを使用していた時にキーが一時的に不能になるなどが起こったら、上記Qtの環境変数も試してください。
Qtでは、
hl.env("QT_IM_MODULE", "wayland;fcitx")と言う書き方もできると思います。しかし、問題を確実に切り分けるためにもhl.env("QT_IM_MODULE", "fcitx")の書き方が望ましいと思います。フォールバック指定では「Waylandモジュールが正常に読み込めたか(初期化できたか)どうか」だけを判定するため、その後で起こる問題をフォールバックできるわけではありません。
これら環境変数を書くと現在、スリープからの復帰時に「キーの入力ができない」という問題にもなるかも知れません。しかしそれは上部バーのfcitx5アイコンを右クリック(だったと思いますが)から出るメニューの再起動で直ります。
グローバルオプション・アドオン設定
fcitx5の設定自体はこんな感じで、上部タブにある「グローバルオプション」と「アドオン」の設定を変えていきます。
グローバルオプション
グローバルオプションでやったことはSUPER + ※と何かしらSUPERが使用されているものを空欄にしたことです。
アドオン
モジュール項目
Module(モジュール)と言う項目の「Wayland」にある項目で、「システムXKB設定の上書きを許可する(PlasmaとGNOMEのみサポート)」のチェックを外します。
Waylandの標準プロトコル(共通規格)では、セキュリティと設計の観点から「外部のアプリ(IMEなど)がデスクトップのキーボードレイアウトを勝手に書き換えてはならない」という強い制限があります。しかし、それでは利便性が落ちるため、独自にIME連携機能を拡張しているのが Plasma(KWin)とGNOME(Mutter)です。
これら理由からチェックを外します。
同じくモジュールの項目のXCBの設定ですが、「システムXKBの設定のオーバーライドを許可する」では、XCB(X C Binding)は、fcitx5が X11(およびWayland上で動くXWayland)のディスプレイサーバーと通信するためのモジュールとなっています。つまりX11(XWayland)でキーボードマップの定義自体を直接書き換える命令をしているということです。
つまりfcitx5が制御するのではなく、Hyprland等がfcitx5を動作させるという仕組みにしたいため、チェックを外します。
クイックフレーズとクリップボード
クイックフレーズとクリップボードの項目ですが、これらはグローバルオプションであったようにSUPERを使用するキーバインドが使用されていたので空欄に設定しました。
フロントエンド
Waylandインプットメソッドでは、「現在実行中のアプリケーションを検出する」のみにチェックを入れてあります。
「キーイベント処理がされない場合はテキストを確定せずにキーイベントを転送する」は、キーボードのキーが押された際、fcitx5側でそのキー操作をハンドリング(IMEの処理として利用)しなかった場合、そのキーイベントをどう扱うかを規定する設定です。
「V2プロトコルの仮想キーボードオブジェクトを維持する(再起動が必要)」は、Wayland のinput-method-v2プロトコルにおいて、fcitx5はシステム上に「仮想キーボード(Virtual Keyboard)」という通信オブジェクトを生成してアプリに文字を送信します。
XIM(X Input Method)は、X11時代の非常に古い入力プロトコルです。現在のWaylandやGTK/Qtアプリは新しい通信規格(Wayland共通プロトコルやDBus)を使うので出番はありませんが、一部の古いX11アプリやJavaアプリ(XWayland 経由)などで互換性のために利用されます。
現代のWayland/XWayland環境において、XIMの「On The Spot」を有効(ON)にすると、
- XWayland 経由で動く古いアプリやツールキットは、XIM の「On The Spot」コールバック命令を正しく処理できないことが多く、変換中の文字が消えたり、全く関係ない画面の隅に候補ウィンドウが飛んでしまう現象が多発します。
- アプリ側に文字を描画させる通信のやり取り(イベントルーティング)が増えるため、キー入力の反映が一瞬遅延したり、変換中のキーイベントがスタックする原因になります。
これら問題があるとされるので、これら設定はチェックを外しています。
まとめ
これらの設定で2日間、「シャットダウン」や「ログアウト」せずスリープしたままで必要なときにだけスリープから復帰させて試してみました。SUPERの反応が遅れるとウィンドウやワークスペースの切り替えができなかった時もありましたが、余裕を持って再度SUPERを押しつつ操作したら機能しており、1秒で、ワークスペース1～3を数回切り替えるような操作でも問題なく応答するようになりました。
他の環境に変える時、例えばログアウトしてからMango WMや、あるいはPlasma/Gnomeなどをログイン画面で選んで、そのセッションで始めたらどうなるかはわかりませんが、そもそもの話、X11かWaylandかどちらかに絞って使えば正しく機能すると言う結果でもあると思うので、Hyprlandで動作しているなら他のコンポジター(NiriやMango WM)でも機能するはずですし、PlasmaやGNOMEでも動作するだろうと思っています。
ただX11が絡んでくるとわかりません。そう言う時は環境変数を追加すればたいてい解決するだろうと思います。
今後どのようになるかは予想でしか無いですが、ほとんどのディストリビューション及びアプリがWaylandに対応してきている中で、未来的にはこれら設定をせずともデフォルトでWaylandに完全対応となるだろうと思います。「X11のアプリを使用する時のみ設定する」と言うこれまでと設定が逆転する事になっていくでしょう。
Waylandへの過渡期にあると、ほぼWaylandとなった今でもどうしてもX11の名残でそれが問題になることもあるわけですから、その道中にいる私たちにとっては、生まれた時にはPS5と言う現代の若者のような便利さはありませんし、むしろ面倒くさいことが多いわけです。
前に何処かでも書きましたが、自動運転はまだかと未来に期待する若者を横目に、タクシーに乗ればいいやんと、何が違うんだと口を紡いで思うだけで、若者に忖度するような大人にはなりたくないなとも思うわけです。
Waylandに移っていく過程は面倒くさいことも多く、これら設定も同様の面倒臭さを含んでいますがこれらを体験できることは、それらをすっ飛ばした未来にいる人よりも絶対に意味があるはずです。過渡期の面倒を乗り越える経験は、決して無駄にはならないと思うのです。