環境

• 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-noime を kitty から呼びだすことで、不正な文字が極力残らないようにして作業を実施できるものと思われる(完全解消するためには、 emacs -nw を止めるしかない)。

その後の検証の結果

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

~/.config/kitty/kitty.conf

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

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

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

かつてより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だと思ったので、今後も精進していこうと思います。

X.comでもいくつかポストしていますが、先日からSlackwareでi3を使用しています。環境構築作業のなかで最も優先度が低かったのが液晶の明るさを変更するための仕組みであったのですが、今日、ようやく実装しました。

何かツールを入れるのもなぁと思っていたところ、 /sys/class/backlight/amdgpu_bl0/brightness を書き換えればよいということがわかり、以下のようなスクリプトを作っておきました。

#!/bin/sh -e

#
# Usage:
# brightness.sh 1000 (for Brighter)
# brightness.sh -1000 (for Darker)
#

FILE=/sys/class/backlight/amdgpu_bl0/brightness
CURRENT_BRIGHTNESS=`cat $FILE`

TARGET_BRIGHTNESS=$(( $CURRENT_BRIGHTNESS + $1 ))
echo $TARGET_BRIGHTNESS > $FILE

これを、以下のように設定することでキーボードから呼び出すようにしました。

bindsym XF86MonBrightnessUp exec --no-startup-id sudo ~/.local/bin/brightness.sh 4000
bindsym XF86MonBrightnessDown exec --no-startup-id sudo ~/.local/bin/brightness.sh -4000

私だけしか使っていないシステムなので、 sudo は NOPASSWD で実行できるようにしています。

これで、設定を再読み込みすれば、キーボードから液晶の明るさを調整することができるようになります。

TL;DR

Slackware -currentのImageMagick (7.1.2-7)は --with-heic=yes でコンパイルされていないため、それを使っているdigiKamでもHEIC/HEIFフォーマットの画像を扱うことができない。同じ理由で、Gwenviewでも扱うことができない。

そもそもの発端

つい最近までDebian GNU/Linuxを使っていたのですが、思うところがありここ数日でSlackware -currentに環境を移行しました。kernel/gcc/emacsを自前でコンパイルし、色々な試行錯誤を繰り返しながら、なんとか必要な作業ができるようになってきたことから、本格的にデータを移行することにしました。

これといった理由は特に無いのですが、趣味の写真をさっさと再開できるようにということで、まずは写真のデータをSlackwareに移行することにしました。

HEICフォーマットの画像がdigiKamに表示されない

HEICフォーマットはiPhone等で使われる形式で、同程度の視覚品質を得るためにはJPEGの50-60%程度のファイルサイズで済むといわれています。つまり、容量に制約のあるスマートフォンや、クラウドサービスの容量を節約したい場合にHEICを使うことが良いのではないかと思われます。私も、iPhoneでHEICが使われるようになってからというもの、iPhoneで撮る写真はすべてHEIC形式になりました。

それらの写真をdigiKamに取り込もうとした時に、サムネイルもプレビューも表示されないので「どうなってんだ？」と思い調査したところ、まず判ったのは libheif がシステムにインストールされていないことでした。

libheif をインストールする

libheif は libaom と libde265 に依存している。まずはそれらをシステムにインストールする必要があるので、準備する。 libaom はdarkskygit / libaomから入手することができる。また libde265 はstructurag / libde265から入手できるので、それぞれREADMEを参考にコンパイルしてパッケージを作り installpkg でインストールしておく。

次に libheif をインストールする。 libheif はstructurag / libheifから入手できるので、こちらもREADMEを参考にコンパイルしてパッケージを作り installpkg でインストールしておく。途中 /usr/lib64/libaom.a が見付からないというエラーが出るので ln -s /usr/lib64/libaom.a /usr/local/lib64/libaom.a としてsymlinkを張っておく。

ここまで実施してdigiKamを起動しても状況は変わらなかった。なぜだと考え、調べているうちに、どうやらdigiKamはバックエンドにImageMagickを使っていそうだということがわかり、では、ImageMagickでHEIC/HEIFは有効になっているのだろうかと調べたところ有効になっていなかったのであった。

$ magick -list format | grep HEIC    # 結果は何も表示されなかった => 無効
$ magick -list format | grep HEIF    # 結果は何も表示されなかった => 無効

ImageMagickを --with-heic=yes つきでインストールする

ImageMagicは、currentのソースコードをもとにコンパイルする。 imagemagic.SlackBuild の中に記載されている ./configure に対し --with-heic=yes を指定したうえでパッケージを作成し、インストールする。

私は普段、Debian GNU/Linux 13 (trixie)をThinkPad E14 (Gen 3)で運用しており、外付けモニターとしてJapanNextの4Kモニターを使用しています。4K出力に対応しておりながら安価である点が気に入っています。

さて、その環境も、HDMI出力が安定せず、画面が表示されたりされなかったりで作業にならない状況が続いていました。どうもXがEDIDをモニターから取得するまでのタイムラグが原因のように思えましたので、環境決め打ちになってしまうのが気にはなりますが、以下のように対処をしました。

ここに記述している内容はX向けの設定ですが、結果的にXWayland経由で設定が反映されていることになります。

問題の切り分け

まずは物理的な問題を除外しました。

モニター自体は正常か？

手元にあるMacBookを使ったところ正常に4K出力できたので、問題は無いと判断した。

HDMIケーブル自体は正常か？

手元にあるMacBookに接続してみたところ正常に4K出力できたので、問題は無いと判断した。

ThinkPadのHDMIポートに問題は無いか？

手元にある他のモニター(FullHD)に接続してみたところ正常に出力できたので、問題は無いと判断した。

この結果、物理的なハードウェアの問題ではなく、モニターとThinkPadの間の通信(ネゴシエーション)がうまくいかない場合がある、という仮説にいたりました。

ネゴシエーションの肝となる EDID (Extended Display Identification Data: 拡張ディスプレイ識別データ)

EDIDは、モニターが自分自身の仕様をコンピュータに伝えるデータです。具体的には以下の情報を含みます。

• 対応解像度(例：1920x1080、3840x2160)
• リフレッシュレート(例：60hz)
• 色深度やカラーフォーマット
• 製造情報
• タイミング情報(垂直/水平同期)

通常、コンピュータはEDIDを参照して自動的に最適な解像度やリフレッシュレートを設定します。EDIDのやり取りが失敗すると、画面が表示されなかったり、 xrandr が BadMatch エラーを返したりします(追記：これは、Waylandで実行すると出るエラーです)。

モニターから取得したEDID情報をXWayland経由で読み込む

つまり、モニターとやり取りをして解像度等を決定するのではなく、あらかじめEDIDを取得しておき、それをXから読み取るようにしておけば、ネゴシエーションに失敗する可能性は低いわけです。ただ問題は、EDIDを取得するためにはきちんと画面出力されている必要があるということで、そこまではなんとかする必要があるということです。全く表示されない場合には、この手段は使えないと思います。

EDIDを取得する

/sys/class/drm/card0-HDMI-A-1/edid からダンプしておきます。ここは環境に依存しますので、どのパスからダンプすればよいのかは xrandr の情報を参考にして決めてください。

$ sudo mkdir -p /etc/X11/edid/
$ sudo cat /sys/class/drm/card0-HDMI-A-1/edid > /etc/X11/edid/JAPANNEXT_JN-280IPS4KR.bin

Xの設定

/etc/X11/xorg.conf.d/10-monitor.conf を編集します。

Section "Monitor"
   Identifier "HDMI-1"
   Option "CustomEDID" "HDMI-1:/etc/X11/edid/JAPANNEXT_JN-280IPS4KR.bin"
EndSection

ゴミデータの削除

~/.config/monitors.xml が悪さをする可能性があるので、消しておきます。

Swift は、Apple社が開発をしているプログラミング言語で、主にApple製品で動作させるソフトウェアを開発するために使用されるものですが、オープンソース化されてからというもの、Linuxなどサーバサイドで動作するソフトウェアの開発にも使われているようです。

今回は、たまたま目新しいということで、インストールしてみました。

Swiftをインストールする

Install Swiftを参考にすればインストール自体は簡単にできます。

$ cd
$ mkdir swiftly
$ cd swiftly
$ curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz
$ tar xvzf swiftly-$(uname -m).tar.gz
$ sudo ./swiftly init --quiet-shell-followup
$ sudo apt install libstdc++-12-dev     # Swiftlyからインストールを求められた場合のみ
$ . "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh"
$ hash -r

~/.bashrc にも、以下を追記しておきます。

# Swift
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh"
hash -r

Hello World してみる

swift にパスが通っていることを前提に、以下のコマンドを実行します。

$ mkdir helloworld
$ cd helloworld
$ swift package init --name HelloWorld --type executable
$ swift run HelloWorld

すると、以下のように実行されます。初回はとにかく遅く、Hello Worldだけにも関わらず約5秒の処理時間が掛っていました。

Debian GNU/Linux 13が公開されたのを機に、このブログのメンテナンスを進めようと思い、GitHubのリポジトリをローカルにクローンさせ、サブモジュールの中身を引っ張ってこようとしたところ、以下の様なエラーに遭遇してしまった。

$ git submodule update

出力されたエラーは以下の通り。

Cloning into '/home/sonohen/work/blog/blog/public'...
fatal: remote error: upload-pack: not our ref 35b4c8b0165369c2f92485e2b384bfc78827c75f
fatal: Fetched in submodule path './', but it did not contain 35b4c8b0165369c2f92485e2b384bfc78827c75f. Direct fetching of that commit failed.

これは前回、 public というサブモジュールを git commit しなかったことが原因であり、既に当時のマシンは手元にない。サブモジュールの commit hash をGitHub側と合わせる必要があるので、以下のような手当をした。

$ cd public
$ git fetch
$ git checkout <valid_commit_hash>

$ cd ../
$ git add public
$ git commit -m "Update submodule ref to valid commit"
$ git push

これで、事象自体は解決したはずである。

思うところがあって、2022年度末にGrand Seikoを購入した。

AWS Certified Developer - Associate (DVA-C01)に合格しましたので、その記録を書いておきます。