テクニカルプア

備忘録と若干の補足

2022年に GPD Pocket をメインマシンにする為の備忘録

注:後述するように11年前のノート PC で充分な程度の使い方しかしない人間からみた「メインマシン」の記録です。


ということがあり、

となった。Twitter が死んだ時の為にちゃんと言葉にしておくと、

  1. だいぶ前 に入手し それなりに前 に手直しをし使い続けていた ThinkPad X201s が 2100 エラー*1で起動しなくなった
  2. 動態保存してた SSD があったのでそちらを使って再度セットアップすれば X201s は復活する
  3. しかし X201s をふたたび使い続ける状況が突然億劫になった
  4. ずいぶん前 に入手した GPD Pocket を X201s の代わりに使うことにした
    • ちょっと前 に入手した MacBook Pro もあるのだがやっぱり JIS 配列のマシンは常用できずお蔵入りになっている

という次第。

いままで GPD Pocket はオモチャ扱いというか、X201s を持ち歩くのは厳しいがパソコンを使いたくなるような時の供え(例:遠出する時にカバンに忍ばせておく等)といった用途で使用しており、あまり長時間酷使するといった用途では使っていなかった。

このため

や前述のようなグラフィックスまわりの問題を何度も踏むということがあるという事実を今回初めて知るに至り、中々ストレスフルな時間を過ごす羽目になった。

X201s の起動ディスクが物理的に死んだりそのセットアップが億劫になるということは、GPD Pocket でも同じような状況になり得るということである。その時にまた同じ轍を踏んで更にウンザリすることにならないよう、GPD Pocket をなんとかメインマシンにでっちあげる為にやったことを記録しておく。

普段の使い方

  • USB-A:トラックボール / キーボード / Web カメラ を使う為の USB ハブを繋いでいる
  • USB-C:給電用の USB-A to USB-C ケーブルでほぼ常時 AC アダプタに繋いでいる
  • microHDMI:microHDMI -> HDMI な変換アダプタを噛ませた上で HDMI にて このモニタ を繋いでいる
    • 4K 対応のモニタではあるが使い手の目とモニタの大きさの都合で WQHD 程度に落として使っている

やったこと

セットアップ

Arch Wiki には GPD Pocket - ArchWiki という専用の項目があるが、ここで案内されている独自リポジトリは現在不要。公式リポジトリからふつうにインストールできる ALSALinux カーネルで十分に動作する。

前述の使い方においてはモニタ側のオーディオ関連を HDMI 機器として認識してしまうようだが、この場合 PulseAudio を使う場合に

といった事象を踏む。これには以下で案内されている snd_hdmi_lpe_audio を blacklist にいれる方法が効く。

具体的にはこんなかんじ:

 $ ls -lah /etc/modprobe.d/blacklist-snd-hdmi-lpe-audio.conf 
-rw-r--r-- 1 root 29 Apr 22 01:33 /etc/modprobe.d/blacklist-snd-hdmi-lpe-audio.conf

$ cat /etc/modprobe.d/blacklist-snd-hdmi-lpe-audio.conf 
blacklist snd_hdmi_lpe_audio

グラフィックス

Intel graphics - ArchWiki では xf86-video-intel およびこれを使う X 向け設定は不要な 場合がある という注釈があるが、GPD Pocket においては modesetting ではなく素直に xf86-video-intelを使ったほうが安定している感覚がある(私見であり定量的な評価ではない)。

これに加えて同じ項目の以下をやってあげれば大分安定してきた感がある:

あと一応 Backlight_and_KMS(GPD Pocket な ArchWiki 内の項目にあり)もやっておく。

解決できてない問題

いくつかある:

  • 時々 GPD Pocket 本体側のモニタが突然グリッチした感じになり極彩色になる
    • 放っておくとだいたい直る
  • 内蔵 Wi-Fi チップ + iwd + systemd-networkd で 802.11 ac な 5GHz 帯の Wi-Fi アクセスポイントに接続できない
    • iwctl で見ると SSID が見えないのでアクセスポイントを拾えていない感じがする

ところで

上記の問題以外についてはあまり GPD Pocket を使う上で困ることは無い。少なくともわたしのユースケースにおいては。

X201s で頑張ってきた結果、貧相なコンピューティングしかできなくなっていたという事実を突き付けられた気がした。

*1:起動ディスク検出不可;つまり本体ではなく OS 起動ディスクが死んだというもの。参考

systemd-nspawn コンテナの中の web ブラウザからホストに繋いだ web カメラを使う

人生とは不思議なもので、掲題のようなことをしたくなることがある。

より具体的には意地でも専用のクライアントをインストールしない(できない)という決意の下で Zoom や Meet を使わざるを得なくなることがあり、Zoom や Meet を web ブラウザで使うには Chrome 系のそれを使うのが確実である*1。しかし依存関係で GTK が入る為 Chromium を入れたくないという事情がある。

システムに直接いれたくないアプリケーションを誤魔化し使うにはコンテナにして使うのがそれなりにラクなので、必然的に nspawn コンテナへ Chromium をインストールして Zoom や Meet を使うということになる。そしてこれらを使う事情というのは web カメラで映像を写し、マイクに音を拾わせる、といったことになる。

そういったことをやる為に四苦八苦し、結果としてなんとかなったので記録しておく。

前提

たぶんデバイスに依存しない内容にはなっていると思うが一応記載しておく。使っている web カメラはこれ:

準備

web カメラがどのようなデバイスとして認識されているかを確認しておく:

$ v4l2-ctl --list-devices
HD Pro Webcam C920 (usb-0000:00:1a.0-1.5.3):
        /dev/video0
        /dev/video1
        /dev/media0

この場合は以下が設定対象のデバイスとなる:

  • /dev/video0
  • /dev/video1
  • /dev/media0

以下、本項では上記3デバイスを設定対象としてゆく。

設定

nspawn コンテナ側と systemd-nspawn サービス側の各設定を修正する必要がある。 以下では nspawn コンテナの名前を CONTAINER とする。

nspawn コンテナ側

/etc/systemd/nspawn/ 下に存在するはずの CONTAINER.nspawn 設定内 [Files] 下に以下を追加する:

Bind=/dev/video0
Bind=/dev/video1
Bind=/dev/media0

これでひとまず対象のデバイスが nspawn コンテナ側からも見れるようになる。設定の意味合いは systemd-nspawn のドキュメント が詳しい。

systemd-nspawn サービス側

/etc/systemd/system/systemd-nspawn@CONTAINER.service.d/ 下に override.conf を以下のように用意する:

[Service]
DeviceAllow=/dev/video0 rwm
DeviceAllow=/dev/video1 rwm
DeviceAllow=/dev/media0 rwm

これも詳細は systemd のドキュメント が詳しい。要するに当該デバイス名で参照されるデバイスを適切に使えるよう設定をいれるといったもの。

nspawn コンテナ準備

CONTAINER なコンテナが既に起動していれば再起動する。止まっていれば起動する。

もちろん CONTAINER なコンテナで web カメラを使いたい X アプリケーションが動くようになっている必要もある。このあたりは以下の拙稿が参考になるかもしれない:

Chromium を起動

nspawn コンテナ内に Chromium を何らかの方法で入れ、ホスト側から起動する。そのあたりも前掲の拙稿を参考のこと。

おわり

Chromium も専用クライアントもインストールしたくないが Linux 上で Zoom や Meet を使わなければならなくなった方のお役に立てれば幸い。


参考

*1:別のネタになるかもしれなかったので Qt5 を使うブラウザで検証した:
qutebrowser:遅いがなんとか使える。
Falkon:一見使えそうだがマイクが音をうまく拾えない。
Konqueror:マイクもカメラも認識しない。

ただし検証に使用した機械は ThinkPad X201s などという12年前の代物であり、パフォーマンスの問題は機械の影響である可能性が非常に高い。

DS61 V1.1 を買った + xrdp で RDP と仲良くなるまでのメモ

通して読んでみると別に RDP と仲良くなれてないな。まあいいか。そんなかんじの内容です。

前フリ

掲題のパソコンを友人から購入した。以下で紹介されているものを手頃な金額で譲ってもらえた。 hanjuku-am2.hatenablog.com

とくに目的のない買い物ではあった。悩む理由が金なら買え、という古からの金言に従ったかたちとなる。

手にいれてからしばらく放置していたのだが、宅内サーバ的な用途で動かしたり動かさなかったりしている ThinkPad X61 & X201s をこいつで置き換えてしまおうと思い立ち、いつもどおり Arch をいれて動かせるようにしてみた。

ちなみに後者はこれで入手したものである。もう3年もまえになるのだな……。

で、作業している間にこいつを Blu-ray 再生専用機に仕立て上げ、手元の PC(これも今だにこの X201s。もう6年も前か……)に負荷をかけることなく映画を観ようと思い至った。 xrdp あたりをいれて手元 PC へ RDP で映像と音を飛ばしてもらうおうという魂胆である。

で、やってみたのだが割と苦戦した。DS61 V1.1 の中の SSD が吹き飛んで再びセットアップしなくてはならなくなった時に泣かないよう、今回泣いた内容を記録しておこうと思う。ということで私的な備忘録であり体系立ってはいないメモをかく。

初期設定

Installation guide - ArchWiki に従い素直にやる。

とりあえずちゃんと動くようになったら yay とかをいれて AUR も使えるようにしておく。

sudo の設定をした上で必要そうなグループにもユーザをいれておく:

$ sudo gpasswd -a $USER users

X をうごかす

まずはお約束のやつをいれる:

# pacman -S xorg-server
# pacman -S xf86-video-intel xf86-video-fbdev xf86-video-vesa

/etc/mkinitcpio.confMODULESi915 をいれてカーネルイメージを作りなおすやつもやる:

# grep 'MODULES=' /etc/mkinitcpio.conf | grep -v '#'
MODULES=(i915)
# mkinitcpio -P

おわったら再起動をする。

こんかい当初はデスクトップ環境という大物をいれるのはやめて i3 + ly でシンプルにやろうとした。が、挫折した。諦めて馴れ親しんだ KDE をうごかすことにした:

# pacman -S plasma

当初は SDDM もいれたが、xrdp でリモートデスクトップをやる場合はディスプレイマネージャが不要なので SDDM は不要であった。ゆえに消してある。これに気付くまでかなり時間がかかった。 要するに startx みたいな感じで X が起動されるため .xinitrc$HOME 下に置かねばならぬということで以下のようにする:

(注:ここの '#' はプロンプトではなくコメントの意)
# cat ~/.xinitrc
export DESKTOP_SESSION=plasma
exec dbus-run-session startplasma-x11

ディスプレイマネージャは不要ということがわかったので、次回おなじ作業をやるときは i3 でリベンジできるかもしれない。

PulseAudio でいいので以下のようにする:

# pacman -S pulseaudio pulseaudio-alsa

一応この時点で必要そうなグループにユーザをいれておく:

$ sudo gpasswd -a $USER audio

xrdp をうごかす

素直に以下のようにする:

$ yay -S xrdp xordxrdp pulseaudio-module-xrdp

今回バックエンドを xorgxrdp にしたので Xrdp - ArchWiki に従い /etc/X11/XWrapper.config をつくる:

(注:ここの '#' はプロンプトではなくコメントの意)
# cat /etc/X11/Xwrapper.config
allowed_users=anybody

わたしの環境だと xrdp.service が吊るしのままだとうまく起動しなかった。 どうもネットワーク系サービスの起動中にこいつが起きてしまうせいでコケるようだったので、こいつが依存している xrdp-sesman.servicenetwork-online.target の後で起動させるようにしてみた:

(注:ここの '#' はプロンプトではなくコメントの意)
# cat /etc/systemd/system/xrdp-sesman.service.d/override.conf
[Unit]
After=network-online.target

ここまでやったら以下のようにして xrdp が起動してくるようにしてやる:

# systemctl enable xrdp.service
# systemctl enable xrdp-sesman.service

必要そうなグループにユーザをいれるやつもやる:

$ sudo gpasswd -a $USER video

Blu-ray を再生できるようにする

いつも mpv を使用しているのでそんな感じにやる:

$ sudo pacman -S mpv libbluray
$ yay -S makemkv-cli
$ yay -S makemkv-libaacs

makemkv-cli の作業中に教えてもらえる以下もやる:

# echo sg > /etc/modules-load.d/sg.conf

必要なグループにユーザをいれる。これをしないと RDP セッション内で Blu-ray ドライブにアクセスできなかった:

$ sudo gpasswd -a $USER lp
$ sudo gpasswd -a $USER optical

あとはよしなに mpv の設定をする。個人の好みがあると思われるので内容は省略。 カーネルモジュールを読み込む設定をやっているので作業のキリがよいところでマシンを再起動してやる。

RDP でつなぐ

KDE ユーザなので KRDC で繋ぐようにしてみた。適当に設定をして繋ぐ。ただしSoundOn This ComputerPulseAudio を選択してやる必要がある。

xrdp.service がうごいていれば問題なく接続できるはず。 ただしこれだと pulseaudio-module-xrdp をいれているにもかかわらず RDP セッション内からサウンドバイスがみえない。どうしたものか。

RDP セッション内で音を出せるようにする

2日くらい難儀した結果、以下の情報をみつけた:

github.com

これに従い設定をしてみる。まずは以下をやる:

$ systemctl --user mask pulseaudio.service
$ systemctl --user mask pulseaudio.socket

このとき RDP セッション内のターミナルから作業すると Failed to get properties: Process org.freedesktop.systemd1 exited with status といわれて詰むので SSH などの別セッションから作業するとよい。

次にデスクトップ環境側から PulseAudio を起動させるようにする。KDE の場合は以下のようにする:

  1. System Settings を開く
  2. Startup and Shutdown -> Autostart
  3. Add から Add Application を選択
  4. /usr/bin/pulseaudio を実行するよう色々設定する
    • 画面内でコマンドを指定する箇所があるので絶対パスを入れてやればよい
    • Teminal options はとくにいじらなくてよい

ここまでやって RDP セッションを一度落として(単にログアウトすればよい)再度立ち上げると無事に KMix あたりから xrdp sinkxrdp source が見えるようになる。これで RDP を経由して手元の PC から音が出るようになる。

やってみて

X201s に WQHD な解像度に設定したモニタを接続し、全画面で RDP して Blu-ray を再生してみた。

X201s で Blu-ray を再生した場合はほとんど全てのコマが落ちて観れたものではないのだが、RDP 経由だとガクつきがするがまあ我慢すれば観れるかな程度までなんとかなることがわかった。

モニタ解像度を Full HD 程度まで落とせば現実的な快適さで観れるようになるだろう。LAN 的な影響は考慮していない。

リモートデスクトップというものをやってみたい気持ちがずっとあったが、その気持ちをようやく消化できて有意義だった、というところでオチとしておく。

参考

パスワード認証しないで machinectl から nspawn コンテナを操作する

掲題のような事をしたい気持ちになることが時々ある。というよりずっとあっていつか調べようと思って放置していた。

やっと調べる気になった結果以下のような Polkit ルールを /etc/polkit/rules.d/ 下に適当な名前(10-nopassword-machinectl.rules など)で配置して systemctl restart polkit してあげればよい:

このルールの場合全てのユーザでパスワード認証を迂回するわけではなく wheel なグループにいるユーザのみに限定される。 わたしの場合 sudo の許可でこのグループにユーザをいれているので特に不都合はない。不要な場合は subject.isInGroup("wheel") の行を消してやればよい。

これで少しは machinectl で nspawn コンテナを使って潰してというやつがやりやすくなると思う。とても嬉しい。

参考

MacBook Pro (Late 2012) 買った

f:id:aaodsn:20200726212438j:plain
画面は Arch 側で起動させたもの

掲題の買い物をした。友人から3万円也。

JIS 配列のキーボードがついたパソコンを買うのは ThinkPad X40 を買った頃以来なので10年ぶりくらいのはず。

当初はこれも US 配列なキーボードに入れ替えるつもりだったが小手調べのつもりで裏蓋をあけた瞬間に ThinkPad いじりの常識やノウハウが一切活かせないシビアな光景が目に入ったので諦めた。つくりをみれば当然なのだがキーボードだけではなくガワも交換せねばならず、ガワを交換するにもキーボードへアクセスするにもあらゆる部品をひっぺがえさねばらなず、これは壊すな、と感じたのだった。

JIS 配列の違和感も最初の1時間くらいでなくなった。実用上はおそらく SSH で入って操作するのであまり困らないなと思っている。

とりあえず macOS と Arch Linuxデュアルブートにした。Arch 側はいつもどおり KDE(Plasma + SDDM)にした。 景気よく OSX をフッ飛ばして Arch だけにしようと当初は思っていたのだが、https://wiki.archlinux.org/index.php/Mac#Firmware_updates を読んで OSX は残したほうがよいとのことだったのでこれも止した。

GPD Pocket の次に新しい年代のパソコンがこれになり、それがもう8年前の機械か、なんならまだ現役の ThinkPad X201s は2011年製だから9年前か、という状態。隔世の念がある。

ちなみに写真で本体左側についている黒いのは Elecom WDC-433SU2Mで802.11acな通信を実現したかった - テクニカルプアElecom WDC-433SU2Mで802.11acな通信を実現したのかわからないけどとりあえず動いた - テクニカルプア で苦しんだ Elecom の WiFi アダプタ。当該2記事ではドライバ入手やらコンパイルやらでゴタゴタやっているが、2020年現在は Linux カーネル本体に(おそらく互換のきく)ドライバがとりこまれたようで、挿したら何もせず認識してくれた 1。ただし ac ではなく n くらいの速度しかでていない。これも隔世の念がある。


  1. カーネル 5.7.10 で確認

AUR のパッケージ更新を日次で勝手にやるようにして楽をしている話

半年くらい放置しているので意図しないものが出るようになっている。出さなくさせる為に書く。

いろんなところで散々言及しているがわたしは AUR でいくらかの PKGBUILD を公開している: AUR (en) - Search Criteria: nosada

PKGBUILD を公開といってもやることは開発元のコードを落としてきて pacman が解釈できるパッケージに落とすというだけなので大した内容ではない。 ただ開発元が新しいバージョンをリリースする度に PKGBUILD 側でもバージョンを更新してメタデータも書き換えて AUR に反映させてとそれなりに作業が発生するので、手間がかかる作業ではある。

去年末から今年の始めにかけて https://github.com/x-motemen/ghq が、そしてほぼ恒常的に https://github.com/digitalocean/doctl が、それぞれ結構な頻度で新しいバージョンをリリースしており、その度に PKGBUILD を更新して……という作業をするのが面倒になってきた。無論新しいバージョンがリリースされること自体はとても喜ばしいのだが、普通に作業量が多くてしんどくなってしまったのは事実である。

どうにかしたいな、バージョンが更新されたらそいつを PKGBUILD に落として AUR への反映までやってくれるようなやつ欲しいな、としばらく考えていた。 で、作った。今確認したら最後に更新したの1月下旬だった:

github.com

やることは単純で、

  1. AUR ユーザがもってる PKGBUILD を総浚いする
  2. 総浚いした中で GitHub 上で開発されているものの最新バージョンをチェックする
  3. 2. で確認した最新バージョンが PKGBUILD 上のそれと異なる場合に新バージョンと見做して更新
    • PKGBUILD 更新
    • .SRCINFO(パッケージのメタデータ)更新
    • makepkg -sfmL --noconfirm してちゃんと新バージョンでパッケージが作れるか確認
  4. 3. できちんとパッケージが作れることが確認できたら AUR 更新分を反映

ということを https://hub.docker.com/r/archlinux/base/ を基にした Docker コンテナ内でやる。 この Docker コンテナを systemd-timer を使って一日一回起動してくるようにし、開発元で更新があればこのタイミングで PKGBUILD の更新が発生するようにしてある。

既にこいつを使用しはじめて2ヶ月程度経つが、わたしが管理している AUR の PKGBUILD で目立った問題は発生していない。はず。

README.md に拙く書いた通りビルドの進捗や更新の成否を通知する都合上 Slack に依存していたり、作業内容の性格上既に AUR にユーザアカウントが存在している必要があったりと制約が多い内容ではあるが、AUR で公開している PKGBUILD を更新し続けるのが面倒になってきた人にとっては便利なものになっていると思っている。

現時点では GitHub 上で開発されているものしかバージョン更新の検知に対応していないので、他の環境上で開発されているものもきちんと更新を検知できるようにしていきたい。

doctl にプルリク投げたら DigitalOcean からノベルティを貰った話

f:id:aaodsn:20191022141203j:plain
DigitalOcean ロゴの向き間違ってた(すみません)

わたしは AUR にいくらか PKGBUILD を公開しており、その中に DigitalOcean (https://www.digitalocean.com/) の CLI ツールである https://aur.archlinux.org/packages/doctl/ というものがある。 upstream はこれ:

ある日こいつが makepkg -sri でビルドするとコケるようになり、doctl 側をみてみたところビルドスクリプトに難があるようだった。 ビルドが通らないと困るので直すことにした。それが以下のプルリク:

中身をみてもらえればわかる通り大した内容ではない。

で、このプルリクのコメント最下にあるように DigitalOcean の中の人から連絡くれというメッセージがきていたのでやりとりをし、いろいろあってノベルティを貰えることになった。

貰ったノベルティが本項目冒頭の写真になる。シャツ1枚にステッカー3枚、握ってストレスをどうこうするやつひとつ。ドイツから遠路はるばる今日到着した。

https://sngsk.infohttps://mastodon.sngsk.info を動かしているサーバは DigitalOcean の一番安い VPS を使っている。今後もお世話になります。

ちなみにすぐ直したわけではなくしばらく様子をみてはいた。その間 AUR に投稿した内容にパッチを含めて誤魔化したりしていた。