ArchLinux

Emacs + DDSKK on kittyな環境で日本語変換がバグる

tmuxでemacs -nwを実行し、その上でddskkによって日本語入力をすると、ゴミデータもあわせて入力されることがあり、どうしたものかと思っていたところ、kittyとemacsの起動方法を工夫することで、ある程度は軽減できることが分かった。

環境

  • Arch Linux
  • tmux 3.6
  • GNU Emacs 30.2 + DDSKK
  • kitty 0.44.0

事象

以下のように入力すると、不正な文字列が入力される。

KiGasuru -> 気gがする

解消方法

以下のようにすることで、完全な解消は難しいものの軽減はできた。

~/.config/kitty/kitty.conf

kitty_keyboard_protocol no

~/.local/bin/emacs-noime

#!/bin/sh -e

unset GTK_IM_MODULE
unset QT_IM_MODULE
unset XMODIFIERS
unset DefaultImModule
unset GLFW_IM_MODULE

export NO_AT_BRIDGE=1

exec emacs -nw "$@"

今後は、 ~/.local/bin/emacs-noimekitty から呼びだすことで、不正な文字が極力残らないようにして作業を実施できるものと思われる(完全解消するためには、 emacs -nw を止めるしかない)。

その後の検証の結果

結局、上記は効果がなかったとは言えないが、もっとも効果がありそうなのは以下の対策であった。

~/.config/kitty/kitty.conf

programs.kitty.keybindings = {
  "ctrl+j" = "discard_event";
}

その後の検証の結果(2)

結局、劇的な効果が見込まれず emacs -nw をtmuxの中で動かすことは止めにした。

qutebrowserがウェブサイトを描画しない

Arch Linuxにインストールしたqutebrowserがウェブサイトを描画せず困り果てていたところ、Xorgのドライバをきちんとインストールしていなかったことが原因でした...。

かつてよりLinux環境ではFirefoxを愛用していたのですが、最近ではもっぱらqutebrowserを愛用しています。vimの操作方法を使えるのが便利で、マウスを使わずともほとんどの操作をキーボード主体でできることから、i3-wmとも非常に相性が良いです。

しかし、そのqutebrowserをArchLinuxにインストールしたところ、どうにもまともに動かない状況で、2-3日ハマりました。結論は、Xorgのドライバーをきちんとインストールしていなかったことでした。解決に至るまでの状況と教訓をまとめておきます。

起こっていたこと

  • スタートアップに指定しているDuckDuckGoのページが表示されない。ロードが終わっていることはステータスバーから分かるものの、画面は真っ白の状態。まれに画面がちらつき、アヒルのロゴが表示される状況。
  • 操作がまともに出来ない。コマンドを受け付けない。

調査(1) qutebrowser/qtwebkitのバージョンによる不具合の有無

まず最初に疑ったのが、ArchLinuxにインストールされている qutebrowser と、それが利用している QtWebEngine のバージョンによる不具合の有無です。私の環境では、2025年11月21日現在で以下のバージョンがインストールされていました。

  • qutebrowser v3.6.1
  • PyQt 6.10.0
  • PyQt6.QtWebEngineCore 6.10.0

これらのバージョンは、正常に動作しているSlackware -current on ThinkPadと同じであったので、インストールされているバージョンに不具合があるというわけではなさそうだ、という結論に到達しました。(一応、ChatGPTにも調査させ、不具合がでていないことは調べました。)

調査(2) ドライバの問題

次に疑ったのがグラフィックドライバの問題です。疑った根拠は以下の2つです。

  • Xorgの設定をまともにしていなかったと思い出したこと
  • qutebrowser --version の出力結果を眺めていたところ、qutebrowserの内部ではChromiumをベースとしたQtWebEngineが動作していることに気が付いたこと

利用している端末はHP EliteBook 630 (G9)で、これには12世代のIntel CPU(12th Gen Intel(R) Core(TM) i5-1235U)が搭載されています。使用しているグラフィックボードはオンボード(統合チップセット)で、Intel Iris Xe Graphicsです。Xorg - ArchWikiによると、この世代のチップには xf86-video-intel を使うのではなく、代わりに mesa を使うように記載があります。

なるほどと思い /var/log/pacman.log を調べると、 extra/mesa がインストールされていないことが判明しました。 extra/x86-video-intel を削除したのち、 extra/mesa をインストールして端末を再起動したころ、qutebrowserが正常に動作するようになりました。

教訓

当たり前のことですが、ソフトウェアの動作環境はきちんと確認するようにすべきでした。今回の場合、 qutebrowser --verion を実行すれば、どのバージョンのソフトウェアが動作しており、かつqutebrowserに認識されているのかを確認することができます。その中で、OpenGLがどのドライバーによって動作するのかも知ることができるので、最初から丹念に確認しておけば今回の調査期間を短縮できたはずです。今回気が付いたのは3日目でした。

また、Slackwareでqutebrowserを特に何も気にすることなく使えていたのは、あらかじめ必要なドライバーがインストールされており、それが自動検出によって使われていたお陰であろうと思います。ArchLinuxはカスタマイズ性が高いのですが、それはすなわち全てを自分で管理しなければいけないということにあるので、まずはきちんと設定をする、というところを怠るべきではありませんでした。(最近のLinuxの自動検出/自動設定に甘えていました)

今回のこの件を機に、自分のスキルはまだまだだなと思いつつ、利用者の目線からするとある意味ではシンプルに動作している点がさすがLinuxだと思ったので、今後も精進していこうと思います。