SlackwareでThinkPadの液晶の明るさを変える

Slackware + i3 + ThinkPadな環境において、液晶の明るさを変更するための仕組みを考えました。

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 で実行できるようにしています。

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

Slackware -currentでHEIC対応のdigiKamを動かす

写真管理のソフトウェアを、macOSの写真アプリから、KDEのdigiKamに移行しました。その際に、HEIC画像を扱うことができなかったので対処をした際のログです。

Linux

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)の4K出力が安定しない件を解決する

Debian GNU/Linux 13 (trixie)とThinkPad E14 (Gen 3)で、外部モニター(JapanNext)への4K出力が安定しなかったので対処しました。

Linux

私は普段、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 が悪さをする可能性があるので、消しておきます。

Debian GNU/Linux 13 (trixie)でSwiftを動かす

Debian GNU/LinuxでSwiftを動かしてみようという試みをしました。

Linux

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秒の処理時間が掛っていました。

Git Submoduleを使っている環境で、 upload-pack: not our refエラーが発生した場合の修復方法

Git Submoduleを使っている環境で、Submoduleのcommitを忘れてしまったのでその対処方法を調べました。

Debian

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

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

SAMを使ってみる

AWSのこと

SAMのハンズオンをやってみた。

SAMとは、Serverless Application Modelの接頭辞で、サーバレスアプリケーションを素早く開発するためのツールセットです。CloudFormationにより、必要なリソースのデプロイが行われます。今回は、Cloud9環境を用いてハンズオンを行いました。

SAMの使い方

大きな流れは以下の通りです。

  1. サーバレスアプリケーションの雛形作成（sam init）
  2. コーディング
  3. ビルド（sam build）
  4. ローカル環境でのテスト（sam local start-api）
  5. デプロイ（sam deploy）

サーバレスアプリケーションの雛形作成

sam init

今回は、以下のような構成を取りました。

  • テンプレートの種類: AWS Quick Start Templates
  • 使用するテンプレート: Serverless API
  • ランタイム: Node.js 16.x
  • X-Rayの使用有無: No X-Ray
  • アプリケーション名: sam-app
sam init

以下のとおり選択していきます。

You can preselect a particular runtime or package type when using the `sam init` experience.
Call `sam init --help` to learn more.

Which template source would you like to use?
        1 - AWS Quick Start Templates
        2 - Custom Template Location
Choice: 1

Choose an AWS Quick Start application template
        1 - Hello World Example
        2 - Multi-step workflow
        3 - Serverless API
        4 - Scheduled task
        5 - Standalone function
        6 - Data processing
        7 - Infrastructure event management
        8 - Lambda EFS example
        9 - Machine Learning
Template: 3

Which runtime would you like to use?
        1 - dotnet6
        2 - dotnetcore3.1
        3 - nodejs16.x
        4 - nodejs14.x
        5 - nodejs12.x
Runtime: 3

Based on your selections, the only Package type available is Zip.
We will proceed to selecting the Package type as Zip.

Based on your selections, the only dependency manager available is npm.
We will proceed copying the template using npm.

Would you like to enable X-Ray tracing on the function(s) in your application?  [y/N]: N

Project name [sam-app]: sam-app

Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)

    -----------------------
    Generating application:
    -----------------------
    Name: sam-app
    Runtime: nodejs16.x
    Architectures: x86_64
    Dependency Manager: npm
    Application Template: quick-start-web
    Output Directory: .
    
    Next steps can be found in the README file at ./sam-app/README.md
        

    Commands you can use next
    =========================
    [*] Create pipeline: cd sam-app && sam pipeline init --bootstrap
    [*] Validate SAM template: sam validate
    [*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch
    

SAM CLI update available (1.70.0); (1.57.0 installed)
To download: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html

コーディング

ディレクトリ構成を確認しておきます。