コグノスケ

Ubuntu 22.04のxrdpに接続できない病

目次: Linux

WindowsからUbuntu 22.04 LTSのxrdpに接続すると真っ黒な画面しか出ず、すぐに接続が切断されてしまう問題に遭遇しました。どこでクラッシュしているか調べるため、xrdpがGNOMEを起動するところまでを追いかけると下記のようになっていました。

/etc/xrdp/startwm.sh
  exec /bin/sh /etc/X11/Xsession
    /etc/X11/Xsession.d/99x11-common_start
      /usr/bin/ssh-agent /usr/bin/im-launch x-session-manager
        /usr/bin/x-session-manager
          /usr/libexec/gnome-session-binary

スクリプトx-session-managerを書き換えてgnome-session-binaryの引数に--debugを足すと、GNOMEはより詳細なメッセージを出力します。メッセージはホームディレクトリの.xsession-errorsに記録されます。GNOMEのエラーメッセージは下記です。

** (gnome-session-check-accelerated-gles-helper:3301100): WARNING **: 13:50:04.884: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[3300977]: DEBUG(+): hardware acceleration check failed: Child process exited with code 1
gnome-session-binary[3300977]: GLib-DEBUG(+): setenv()/putenv() are not thread-safe and should not be used after threads are created
gnome-session-binary[3300977]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256    ★★ここでエラーが発生している
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:3301174): WARNING **: 13:50:09.927: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[3300977]: WARNING: software acceleration check failed: Child process exited with code 1
gnome-session-binary[3300977]: CRITICAL: We failed, but the fail whale is dead. Sorry....

エラーメッセージ曰くamdgpu_get_auth()が失敗しています。関数名から推測するにAMDのGPUが装着されているマシンでしか発生しないエラーなのかもしれません。この関数は何者なのかDRMのソースコード（Mesa/libdrmのソースコードリポジトリへのリンク）を見ると、

// drm/amdgpu/amdgpu_device.c

/**
* Get the authenticated form fd,
*
* \param   fd   - \c [in]  File descriptor for AMD GPU device
* \param   auth - \c [out] Pointer to output the fd is authenticated or not
*                          A render node fd, output auth = 0
*                          A legacy fd, get the authenticated for compatibility root
*
* \return   0 on success\n
*          >0 - AMD specific error code\n
*          <0 - Negative POSIX Error code
*/
static int amdgpu_get_auth(int fd, int *auth)
{
	int r = 0;
	drm_client_t client = {};

	if (drmGetNodeTypeFromFd(fd) == DRM_NODE_RENDER)
		*auth = 0;
	else {
		client.idx = 0;
		r = drmIoctl(fd, DRM_IOCTL_GET_CLIENT, &client);    //★★エラーを返すのはこの関数だけ★★
		if (!r)
			*auth = client.auth;
	}
	return r;
}


// drm/xf86drm.c

/**
 * Call ioctl, restarting if it is interrupted
 */
drm_public int
drmIoctl(int fd, unsigned long request, void *arg)
{
    int ret;

    do {
        ret = ioctl(fd, request, arg);    //★★drmIoctl()はioctl()が返すエラーをそのまま返す★★
    } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
    return ret;
}

ソースコードから推測するにグラフィクス系のデバイスファイルにioctl()しようとして失敗しているものと思われます。

XのグラフィックスはDRI（Direct Rendering Infrastructure）と呼ばれるインタフェースを経由してGPUを使用します。Xとカーネルの間にはlibDRMがおり、libDRMはLinuxカーネルのDRM（Direct Rendering Manager）を使用してGPUにアクセスします。DRMのデバイスファイルは/dev/driディレクトリの下にありますが、名前がDRIだったりDRMだったりして謎ですね。グラフィクス周りはあまり詳しくなくて理由はわかりません……。

# ls /dev/dri/* -la

crw-rw-rw-+ 1 root video  226,   0  4月 30 15:00 /dev/dri/card0
crw-rw-rw-+ 1 root render 226, 128  4月 30 15:00 /dev/dri/renderD128

上記のようにキャラクタデバイス/dev/dri/card0と/dev/dri/renderD128のパーミッションを0666にしたところエラーが出なくなりました。今回はこの2つのデバイスファイルで解決しましたが、他のデバイスファイルにもアクセスしていた場合はさらに調査が必要かもしれません。グラフィクス系のエラーは簡単に調べる方法がないのが辛いですね。

ちなみにこの症状はQEMUだと再現しません。card0のパーミッションを0000にするとlibEGLがエラーになるのですが、なぜかGNOMEはエラーを無視して起動してしまいます。AMDのときだけなんで止まるんでしょうか。いまいち釈然としません……。

VirtualBoxでxrdpのエラーを再現できるか挑戦

目次: Linux

昨日（2024年10月1日の日記参照）のUbuntu 22とxrdpの組み合わせで起きるエラーですが、VirtualBox 7.0.18で再現できるかやってみました。グラフィクスはVMSVGAを選択しています。VMSVGAは/dev/driの下にcard0とrenderD128が生成されるようです。ちなみにgdm3は終了させてxrdpのみ起動しています。

ちなみに結論から言っておくと再現しません。以下が通常時のログです。正常に画面が表示されます。

gnome-session-binary[2774]: DEBUG(+): Enabling debugging
gnome-session-binary[2774]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’

ログにはデバッグ有効であることと、libEGLが何かしら見つけて反応しています。それ以外は特に何も出ません。

次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。しかし正常に画面が表示されます。えぇー？ログは下記のようになりました。

gnome-session-binary[4319]: DEBUG(+): Enabling debugging
gnome-session-check-accelerated: GL Helper exited with code 512
libEGL warning: DRI2: failed to authenticate
gnome-session-check-accelerated: GLES Helper exited with code 512
gnome-session-binary[4319]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’

AMDのGPUでも見かけたfailed to authenticateが出ています。が、エラーは無視されるんでしょうか？謎の動きですね。

Ubuntu 20.04 LTSでxrdpのエラーを再現できるか挑戦

目次: Linux

先日（2024年10月1日の日記参照）のUbuntu 22とxrdpの組み合わせで起きるエラーですが、Ubuntu 20で再現できるかやってみました。グラフィクスは種類が違いますがAMDのGPU（Radeon RX 6900 XT）です。条件は同様でgdm3は終了させてxrdpのみ起動しています。

結論から言うと再現しました。以下が通常時のログです。正常に画面が表示されます。

gnome-session-binary[2712263]: DEBUG(+): Enabling debugging
gnome-session-binary[2712263]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-binary[2712263]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
gnome-session-binary[2712263]: WARNING: Error creating FIFO: File exists

ログにはデバッグ有効であること以外は特に何も出ません。FIFOが作れない警告が出ます、これは何だろう？まあいいか。

次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。画面は真っ黒になってすぐに切断されます。Ubuntu 20.04 LTSでも再現するんですね。ログは下記のようになりました。

gnome-session-binary[2712010]: DEBUG(+): Enabling debugging
gnome-session-binary[2712010]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:2712146): WARNING **: 14:44:50.573: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[2712010]: DEBUG(+): hardware acceleration check failed: Child process exited with code 1
gnome-session-binary[2712010]: GLib-DEBUG(+): setenv()/putenv() are not thread-safe and should not be used after threads are created
gnome-session-binary[2712010]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:2712203): WARNING **: 14:44:55.610: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[2712010]: WARNING: software acceleration check failed: Child process exited with code 1
gnome-session-binary[2712010]: CRITICAL: We failed, but the fail whale is dead. Sorry....

前回も見かけたamdgpu_get_auth()のエラーが出て止まりました。AMDのGPUの場合、エラーが起きると止まってしまう疑いが強まりました。本当はエラーが起きたらソフトウェアレンダリングにフォールバックしてほしいんですけど、そうならないようです……。

デバイスファイルが/dev/driに全く存在しなくてもamdgpu_get_auth()が怒ってくるところを見ると、X.orgはPCのグラフィクスの種類（VirtualBoxなのかAMDのGPUなのか）を最初から決め打ちにしているんですね。

OpenPilot - まとめリンク

目次: OpenPilot

一覧が欲しくなったので作りました。

• OpenPilotを調べる - ビルドと実行
• OpenPilotを調べる - プロセス間通信msgqの仕組み

目次: 一覧の一覧

OpenPilotを調べる - ビルドと実行

目次: OpenPilot

最近はOSSの運転支援ソフトウェアOpenPilotのコードを見ています。今日はOpenPilotのビルドと実行方法について調べます。ソースコードはGitHubから入手できます（リンク）。

OpenPilotは全自動運転とはいかないまでもADAS＋αの機能を実現するシステムです。OpenPilot用のデバイスが市販されており、既存のADASシステム搭載車のCAN通信回線に割り込ませる形で後付します。自動運転レベルでいえばレベル2（常に人間が見ている前提）だと思います。突然止まっても害はありませんし、OpenPilotがおかしな制御信号を出しても既存ADASシステムが受け付けないはずです。たぶん……。

ビルド

ソースコードの他にUbuntuの環境、Pythonの環境のセットアップが必要です。私はDebian Testingで試しましたが、特にこだわりがなければUbuntu 24.04 LTSを使うと良いと思います。

$ cd openpilot
$ git submodule update --init --recursive
$ ./tools/install_ubuntu_dependencies.sh

$ python3 -m venv .venv
$ source .venv/bin/activate
$ ./tools/install_python_dependencies.sh

$ scons -j8

主にPythonとC++で実装されています。車用と銘打ったソフトウェアがPythonを使っているのは割と驚きでした……。

実行

ビルドできましたが我が家には専用デバイスもありませんし、車も古いのでADAS付きではありません。そんな私はどうしたら良いのでしょうか？大丈夫、デモモードがあります。デモモードを動作させるには端末を2つ使います。

#### 1つ目の端末

$ ./tools/replay/replay

#### 2つ目の端末

$ ./selfdrive/ui/ui

なぜかreplayはCUIで、uiはGUIです。まあそれはどうでも良いとして、replay側はこのような表示になるはずです。

OpenPilotのreplay（デモモード）

デモモードではあるもののデータ自体は実際の車で走行したデータを再現しているはずです（たぶん）。しばらくするとCar Fingerprint: TOYOTA COROLLA TSS2 2019と出ますから、カローラと接続してこのデータを作ったのでしょう。もう一方のui側はこのような表示になるはずです。

OpenPilotのui（デモモード）

アメリカのどこかのハイウェイ？でしょうか。しばらく見ていると車線変更を行ったりする様子が見えると思います。

デモモードでは全ての機能が動作する訳ではありませんが、特殊な機器なしでもある程度動作させることができるため、内部を解析する際の手助けになるでしょう。なかなか便利ですね。

Microsoft Office 2024を購入

Microsoft Office 2016のまま8年間ほったらかしにしてきましたが、ついにMicrosoft Office 2024に買い替えました。Amazonで31,000円くらいでした。うーん、高い。Office 2024もきっと8年くらい使うでしょう。買い替えるモチベーションがほとんどないし……。

買い替えのきっかけはOffice 2024 Homeです。今年からMicrosoftが改心してOffice 2024 Home（かつてのPersonal相当と思われる）からOutlookを消してPowerPointを入れてくれました。私が欲しいのはPowerPointとExcel（Wordはあってもなくても良い）だったので、これはありがたい変更でした。

• 2021 Personal: Word, Excel, Outlook
• 2024 Home: Word, Excel, PowerPoint, OneNote

従来のOffice 2021はPowerPointとExcelが安価に購入できるパッケージが存在しないことが悩みどころで、前回は仕方なくOffice Personal 2016とPowerPoint 2016の2つを買いました。ただでさえ高いのにバラバラに買うと余計高いし、Outlookも無用の長物で非常に嫌な構成でした。

不思議現象

Office 2024をインストールした直後、謎のディレクトリ「Microsoft OneNote Namespace Extension for Windows Desktop Search」がデスクトップに生成されました。しかも誰かが使っているのか移動もできません。

謎のディレクトリがデスクトップに生成

しかも調べているうちにディレクトリごと消滅しました。謎ですね。一体なんだったんでしょうか……。

Microsoft 365を使わないのか？

Officeが全部使えるMicrosoft 365ならばPowerPointのあるなしに悩むことはなくなりますが、問題点は異常に高いことです。サブスクリプション契約1年で15,000円もします、2年で永続パッケージが買えてしまいます。

Office製品は家庭でヘビーユースしませんし、年15,000円払うほどの価値を感じません。月500円（年6,000円）くらいなら良かったんですけどね……。

shapezレベル100達成

目次: ゲーム

書くの忘れてました。放置してたshapezを夏ごろにレベル100まで進めました。レベル27から納品物がランダムになるので「何でも作れる機構」を構築しないとレベル100達成はしんどいです。

実績は41/45まで取りました。取り逃しは、取る気が元々ないスピードラン系3つ＋操作ミスで取り逃した「King of Inefficiency」です。

shapezの実績

レベル100程度ならさほど納品速度は要求されませんが、高レベルになると作成したShapeを納品する場所（ハブ）に超高速で納品しなければならないです。何でも作れる機構＋倉庫に大量のShapeをためて、たまったら一気に流し込む機構が必要です。

レベル100までやってみた感想ですけど、総合的には面白かったです。効率的な機構を考え付いたときが爽快です。個人的な面白さのピークは「何でも作れる機構」を作りレベル30くらいを突破する辺りでした。そのあとはコピペ感が強くなってやや盛り下がるのはシステム上仕方ないですね。

近々shapez2がリリースされる（今はearly access版）みたいですが、さらに複雑になっているようで買うかどうか微妙です。やると疲れるんで……息抜きには向いてないです。

メモ: 技術系の話はFacebookから転記しておくことにした。

企業のドメイン

今の企業は公式サイトを持っていなほうが珍しいと思いますが、ドメイン名の使い方は各社でバラバラで面白いです。特にグローバル企業は日本だけでなく世界各国向けに公式サイトを構築する必要があるため、迂闊に「会社名.co.jp」みたいなドメインを使うと海外展開時に困ってしまいます。

解決方法はいくつかパターンがあるみたいです。

• gTLD（.com）ドメイン
• gTLD（.com）ドメイン＆ドメイン先頭（www部分）が地域名
• ccTLD（汎用JPなど）ドメイン
• 日本だけ属性型JP（.co.jp）ドメイン、他国はccTLD（汎用JPなど）ドメイン
• 企業名ドメイン

一番良く見かけるタイプでオーソドックスな解決方法だと思われます。gTLD（generic Top Level Domain）である.comドメインのあとに地域名や国名を表すパスが続きます。ドメインを増やさずに各国地域対応が可能で、スマートですね。

• アイシン: https://www.aisin.com/jp/, https://www.aisin.com/en/
• デンソー: https://www.denso.com/jp/ja/, https://www.denso.com/fr/fr/
• 電通: https://www.dentsu.com/jp/jp, https://www.dentsu.com/fr/fr
• 三菱商事: https://www.mitsubishicorp.com/jp/ja/index.html, https://www.mitsubishicorp.com/fr/en/
• Panasonic: https://www.panasonic.com/jp/about.html, https://www.panasonic.com/fr/
• PlayStation: https://www.playstation.com/ja-jp/, https://www.playstation.com/fr-fr/
• 住友商事: https://www.sumitomocorp.com/ja/global/, https://www.sumitomocorp.com/zhcn/easia/

亜流としてNECのように、.comドメイン＆ドメイン先頭（www部分）が地域名になる会社もありました。.comドメインだけどパス名の代わりにドメインの先頭を使うんですね。これはこれでスマートです。

• NEC: https://www.nec.com/, https://jpn.nec.com/, https://fr.nec.com/

もう一つはccTLD（country code Top Level Domain、つまり汎用JPドメインなど）を使う会社です。一貫性がありますね。

• トヨタ: https://toyota.jp/, https://www.toyota.fr/

亜流として日本だけ属性JPドメイン（.co.jp）、他国はccTLDドメインを使う会社もあります。日本だけ違うのは過去の互換性のためでしょうか？

• ホンダ: https://www.honda.co.jp/, https://www.honda.fr/
• 日産: https://www.nissan.co.jp/, https://www.nissan.fr/
• ソニー: https://www.sony.co.jp/, https://www.sony.fr/

珍しいパターンとしては企業名ドメインもありました。このタイプのドメインの名称が良くわからないんですが、企業名がトップレベルドメインになっています。でも他国向けはccTLDでした。謎の作りですね。

• SHARP: https://global.sharp/, https://jp.sharp/, https://www.sharp.fr/
• 東芝: https://www.global.toshiba/jp/top.html, https://www.toshiba.fr/pages/fr/

日本だけ特別扱い系の謎

日産やホンダは.co.jpを使っていますが、.jpはアドレス解決ができないところから使っていないように見えます。.jpドメインはどうなっているんでしょうか？Whois情報を見ると、

$ whois nissan.jp

Domain Information: [ドメイン情報]
[Domain Name]                   NISSAN.JP

[登録者名]                      日産自動車株式会社
[Registrant]                    Nissan Motor Co., Ltd.

[Name Server]
[Signing Key]

[登録年月日]                    2001/03/26
[有効期限]                      2025/03/31
[状態]                          Active
[ロック状態]                    DomainTransferLocked
[ロック状態]                    AgentChangeLocked
[最終更新]                      2024/08/06 16:25:46 (JST)

見慣れない"DomainTransferLocked"と"AgentChangeLocked"が設定されています。これはドメイン名移転申請ロック、指定事業者変更ロックのことだそうでJPRSのサイト（指定事業者変更ロック - JPドメイン名のルール - JPドメイン名について - JPRS）に解説があります。

企業と関係のない登録者に勝手に使われないように申請を弾いてくれる仕組みですね。こんな機能があるとは知らなかったです、なるほど便利だ。

JTSA Limited練習記録2024

目次: 射的

スピードシューティングを始めてから2年半が経ちました。11月には3回目の参加を予定しているJTSA Limited（リミティッド - 一般社団法人日本トイガン射撃協会JTSA）が開催されます。

以前と変わらず、基本的に練習は週1回のみです。たまに練習以外のシューティング系イベントにも行きますが、記録を見る限りタイム上達とは関係なさそうです。2023年の結果はこんな感じでした。

JTSA Limited 2023年の記録

記録は横ばいで80秒台からタイムが早くなる様子がなく、週1回の練習ならこんなもんか？と諦めていました。ところが2024年の夏から70秒台のタイムが出るようになりました。何が起きたのかわかりません。謎です。

JTSA Limited 2024年の記録

今日は初の69秒台のタイムが出ました。とはいえ各ステージのタイムのゆらぎを見る限り、全ステージが偶然早いタイム側に寄っただけの偶然の産物です。実力は75秒くらいでしょうか。

ここ1か月は最近は1発目を早く撃てるように頑張りましたが、その前からなぜか早くなっていたし、何が良くなったのかイマイチわからないです。この後良くなるのか悪くなるのかわからないですね……。

ゲームを買ったら遊びましょう2

目次: ゲーム

前回の振り返り（2022年5月13日の日記参照）から2年半経ちました。所持しているゲームのリストを見るとほとんど変わっていなくて、最近ゲームしてないことが良く表れてます。特に続編系は情熱をもって遊べていないですね。小規模ゲームはいくつかクリアしました。

Skylines 2

順当な続編である印象を受けますね、システムは大体一緒です。リリース直後はゲームバランスが変で遊ばなくなりました。そのうち改善されるでしょう。

スプラ3

初めから超絶ボコボコにされてやる気ゼロになりました。下手くそには辛い。

Wizardry外伝

初期のWizardry目指して作った感じですかね？昔のWiz好きなら面白いと思います。追加シナリオ1個（戦闘の監獄、Prisoners of the Battles）をクリアしましたが、基本シナリオ5個全部クリアする元気はありませんでした。

熱血硬派くにおくん外伝

くにおくんシリーズを裏切らない、たくさん出てくる敵をボコボコにしていくシステムで面白いです。が、私はアクションが基本的に好きではなくて、あまり続きませんでした。

8番出口

地下鉄の通路を思わせる道に起きた異変を察知しながら脱出を試みるゲームです。短いながら面白かったです。アイデアの勝利ですね。

振り返り結果

クリアした（実績90〜100％、シナリオコンプなど）。

• 332.9: Steam: Cities: Skylines
• 192.8: Steam: STATIONflow
• 180.3: Steam: Transport Fever 2
• 68.5: Steam: Mad Tower Tycoon
• 59.2: Steam: shapez.io
• 35.0: Switch: DUNGEON ENCOUNTERS
• 23.3: Steam: ぶきあつめ (The World is Your Wepon)
• 10.0: Switch: Return of the Obra Dinn
• 1.0: Switch: ごめんね、NPCです
• 1.0: Steam: 8番出口

たくさん遊んだ（クリア条件がないor困難すぎて挑む気なし）。

• 413.3: Steam: Dyson Sphere Program
• 170.0: Steam: the Hunter: Call of the Wild
• 95.0: Switch: スプラトゥーン2

未クリア（実績、シナリオクリア率が50％以下）。

• 71.5: Steam: Surviving Mars
• 63.9: Steam: Tropico 6
• 55.0: Switch: Fire Emblem風花雪月
• 44.4: Steam: Wizardry外伝 五つの試練
• 39.4: Steam: Timberborn
• 28.9: Steam: Cities: Skylines II
• 28.9: Steam: Turing Complete
• 21.5: Epic: DAEMON X MACHINA
• 20.0: Switch: ザ・コロニスト
• 15.0: Switch: マリオカート8デラックス
• 15.0: Switch: A列車で行こう はじまる観光計画
• 9.0: Steam: Freeways

ほぼ遊んでいない。

• 12.3: Steam: Asset Corsa
• 10.0: Switch: スイカゲーム
• 9.0: Steam: Captain of Industry
• 5.0: Switch: スプラトゥーン3
• 4.8: Steam: OpenTTD
• 4.0: Steam: Battlefield V
• 3.9: Steam: Kerbal Space Program
• 2.0: Switch: 熱血硬派くにおくん外伝 River City Girls 2
• 1.0: Steam: Plate Up!

メモ: 技術系の話はFacebookから転記しておくことにした。

OpenPilotを調べる - プロセス間通信msgqの仕組み

目次: OpenPilot

最近はOSSの運転支援ソフトウェアOpenPilotのコードを見ています。今日はOpenPilotのプロセス間通信について調べます。

OpenPilotは複数のプロセスが共有メモリを通じてデータを送受信しています。データ送受信のモデルはPublisher/Subscriberモデルを採用していて、1つの通信チャネルについて1つだけPublisherがいてデータ送信役を担い、複数のSubscriberがいてデータ受信役を担います。Client/Serverモデルとは異なりデータはPublisherからSubscriberへの一方通行で、SubscriberからPublisherに送ることはできません。

Publisher/Subscriberの仕組みの名前が見当たらなかったので、関連するコードのディレクトリ（openpilot/cereal）からcerealと呼びます。画像用のPublisher/Subscriberの仕組みだけ特別にVisionIpc（openpilot/msgq/msgq/visionipc）と名前が付いていてcerealと実装が異なりますが、背後にあるデータ送受信の仕組みmsgq（openpilot/msgq）は共通です。

実装箇所

今回の着目点はmsgqですから、cerealとVisionIpcの違いは扱いません。簡単に双方ともmsgqを使う経路がある説明だけに留めます。

まずcerealです。cerealはPython用およびC++用のクラス定義を行っています。Publisher用がPubMaster、Subscriber用がSubMasterです。PythonもC++も同じクラス名で、クラス定義、実装箇所は下記のとおりです。

• Python用: openpilot/cereal/messaging/__init__.py
• C++用: openpilot/cereal/messaging/socketmaster.cc

背後のデータ送受信の仕組みはopenpilot/msgq/msgq/msgq.ccにあります。関数がプレフィクスmsgq_から始まるので見分けやすいです。cerealのPubMaster/SubMasterからmsgqのコードに至る経路は下記のとおりです。

PubMaster::PubMaster()
  PubSocket::create()
    MSGQPubSocket::connect()
      msgq_new_queue()

SubMaster::SubMaster()
  SubSocket::create()
    MSGQSubSocket::connect()
      msgq_new_queue()

次にVisionIpcのServer/Clientからmsgqのコードに至る経路は下記のとおりです。コンポーネントによって呼び出し元は違うので、例としてPublisher側はreplayのCameraServer、Subscriber側はuiのCameraWidgetからの経路を挙げます。

CameraServer::startVipcServer()
  VisionIpcServer::create_buffers_with_sizes()
    PubSocket::create()
      MSGQPubSocket::connect()
        msgq_new_queue()

CameraWidget::vipcThread()
  VisionIpcClient::VisionIpcClient()
    SubSocket::create()
      MSGQSubSocket::connect()
        msgq_new_queue()

経路は多少違うもののcerealもVisionIpcも両方ともmsgqに行き着きます。ただしcerealはmsgq以外の経路（ZMQ）が選択可能で、ZMQを選択した場合は上記と異なる実行経路となります。

msgqのデータ共有方法

ファイルの共有メモリマップをお互いのプロセスから読み書きしてデータ共有します。msgq_new_queue()にて/dev/shmにあるtmpfsファイルシステム（メモリ上にファイルシステムを作る仕組み）上に1つの通信チャネルごとに1つファイルを作成します。1つのファイルをPublisherとSubscriberが共有メモリマッピングするので、お互いに同じファイルのデータが見えます。Publisherがメモリマップ経由でファイルを書き換えたらSubscriber全員に変更が見える仕組みです。

通常、ファイルの共有メモリマップに書き込んだ内容を他のプロセスに可視化するときはmsync()を呼ぶ必要があります。しかしmsgqの実装はtmpfs決め打ちというか、msync()の手間を惜しんだのか、atomicアクセスもしくはメモリバリア__sync_synchronize()だけで済ませています。うーん？これでも動くんだ……？

// openpilot/msgq_repo/msgq/msgq.cc

int msgq_msg_send(msgq_msg_t * msg, msgq_queue_t *q){
  //...

  //★★q->dataは共有メモリマップへのポインタ★★
  char *p = q->data + write_pointer; // add base offset

  //...

  // Write size tag
  //★★atomicアクセス★★
  std::atomic<int64_t> *size_p = reinterpret_cast<std::atomic<int64_t>*>(p);
  *size_p = msg->size;

  // Copy data
  //★★memcpy + メモリバリア★★
  memcpy(p + sizeof(int64_t), msg->data, msg->size);
  __sync_synchronize();

ファイル内のデータは下記のようにヘッダ領域とデータ領域の2領域からなります。各プロセスにはmsgq_queue_t構造体が確保され、ヘッダ領域とデータ領域へのポインタを保持します。

msgqのデータ共有用ファイルの構造

データ領域のサイズはDEFAULT_SEGMENT_SIZE（10MiB）固定です。Subscriber数の最大数はread_pointers[]などの配列長で決まります、現状だとNUM_READERS（15）固定です。なぜ16じゃなくて15なのか？理由が良くわかりません。特に理由は書いていませんでした。

// openpilot/msgq_repo/msgq/msgq.h

#define DEFAULT_SEGMENT_SIZE (10 * 1024 * 1024)
#define NUM_READERS 15
#define ALIGN(n) ((n + (8 - 1)) & -8)

struct  msgq_header_t {
  uint64_t num_readers;
  uint64_t write_pointer;
  uint64_t write_uid;
  uint64_t read_pointers[NUM_READERS];
  uint64_t read_valids[NUM_READERS];
  uint64_t read_uids[NUM_READERS];
};

struct msgq_queue_t {
  std::atomic<uint64_t> *num_readers;
  std::atomic<uint64_t> *write_pointer;
  std::atomic<uint64_t> *write_uid;
  std::atomic<uint64_t> *read_pointers[NUM_READERS];
  std::atomic<uint64_t> *read_valids[NUM_READERS];
  std::atomic<uint64_t> *read_uids[NUM_READERS];
  char * mmap_p;
  char * data;
  size_t size;
  int reader_id;
  uint64_t read_uid_local;
  uint64_t write_uid_local;

  bool read_conflate;
  std::string endpoint;
};

PublisherとSubscriberが1プロセスずついるときはこんな感じです。msgq_header_tの実体は1つで、各プロセスのmsgq_queue_tがmsgq_header_tとデータ領域へのポインタを保持します。

PublisherとSubscriber間のtmpファイル共有

データ領域はPublisherが書き手、Subscriberが読み手のリングバッファとして機能します。つまりPublisherはデータ領域に送信したいデータを書いてwrite_pointerを進め、Subscriberはデータ領域からデータを読み取ってread_pointerを進めます。

ONKYOからM-AUDIOのUSB DACへ

目次: PC

かれこれ10年以上（2013年3月16日の日記参照）活躍してくれたONKYO SE-U33GXV2ですが、いよいよ調子が悪くなってきたようです。しばらく放っておくと音が出なくなってしまいます。

Windows 11のアップデート直後から発生するようになったので、Windows 11のせいである可能性もゼロではありません。が、同様の不具合に言及している人が見当たらないところを見ると、USB DACが故障した可能性の方が高いでしょう。

次のUSB DACはM-AUDIO M-Track Solo（メーカーのサイト）にしました。実はしばらく前に購入していたのに使わずに積んだままでした。活躍の場ができて良かったです。

M-Track Solo

入力が2系統（XLR/6.3mmステレオコンボプラグ: マイク/Line、6.3mmステレオプラグ: ギターなど/Line）、出力が2系統（RCAプラグ: スピーカー、3.5mmミニプラグ: ヘッドフォン）あります。ありがたいですね。

ボリュームつまみは大きくて見やすく、筐体の上部に付いています。私のように目線より下（机やPC筐体の上など）に置く人には、操作しやすくて良いです。一方でラックに入れて使う人にはやや使いづらいかもしれません。

動作も問題ないですね、変なノイズやおかしな音はしません。音質は良いんじゃないでしょうか、私の耳では細かいことは良くわかりませんけども……。

Linuxからリモートデスクトップ

目次: Linux

開発用のLinuxマシンの画面を見るにはいろいろな手段がありますが、最近はxrdpを使っています。WindowsからもLinuxからもリモートデスクトップで接続できて、同じ画面を拝めるので便利です。以前はTigerVNCを使っていましたが、Windows版のクライアントはVNC系よりリモートデスクトップが一番出来が良いです。

Linuxからリモートデスクトップ接続するときはxfreerdpを使います。便利なんですけど、オプションが独特すぎていつも書き方を忘れます。バージョン2系とバージョン3系で若干オプションが違いますが、今回は3系を紹介します。

$ xfreerdp3 \
  /d: \
  /v:remotehost:3389 \
  /size:1920x1080 \
  /kbd:layout:0x411 \
  /clipboard:direction-to:all \
  /auto-reconnect-max-retries:5

### キーボードレイアウトの一覧を確認するには

$ xfreerdp3 /list:kbd

いつも使っているオプションです。意味は下記のとおりです。

• /d:domain: 大抵はドメインを入れる必要がないので空白でOK
• /v:host:port: ホスト名、ポート番号（省略すると3389）
• /size:WxH: 画面サイズ
• /kbd:layout:0x411: 日本語配列キーレイアウト、これを忘れると英語配列になってしまう（一覧を見るなら/list:kbdオプション）
• /clipboard:direction-to:all: クリップボードを双方向（リモート←→ローカルどちら向きにも転送する）有効にする
• /auto-reconnect-max-retries:N: 切断されたときにリトライする回数

確か音声も転送できたはずですが、私はLinux側の音声は無視しているので音声関係のオプションは書いていません。こんなオプションが便利だよ、と教えていただけると喜びます。

マンガ紹介

目次: マンガ紹介

お気に入りのマンガ紹介シリーズ。最近完結した短めの作品を紹介します。

マイナススキル持ち四人が集まったら、なんかシナジー発揮して最強パーティーができた件（全4巻、2022年〜2024年）

RPG的ファンタジー世界が舞台です。主人公達4人が致命的に悪い効果を持つ「マイナススキル」を消せると噂のダンジョンに偶然集まります。マイナススキルの悪い効果を打ち消しあう出会いの順、奇跡の組み合わせに気づくパズルのような展開が面白かったです。世界観の説明をほぼ省略し「なんかしらんがそうなる」の一点張りで通す点も個人的には好きです。読みやすくてテンポが良いです。

ゴリせん〜パニックもので真っ先に死ぬタイプの体育教師〜（全7巻、2021年〜2024年）

あるあるなシチュエーションを逆手に取ったギャグ漫画です。主人公は体育教師のゴリせんで、なぜか学校に次々と押し寄せる強そうor悪そうな奴らに必ず襲われます。襲う側はやる気満々なものの、ゴリせん側は圧倒的に強いうえに本人は無自覚で、全てノーダメージ＆いつのまにか勝っています。アリとゾウの戦いですね。襲う側の空回りやボコられた後のギャップが面白いです。

DENSOの最終勤務日

最終勤務日でした、入門カードや会社のPCを返却してきました。在籍期間はNSITEXE（品川のオフィス）が約5年、DENSOが約1年（新橋のオフィス）でした。

やってたこと

DENSOは主に自動車メーカー直請け（俗に言うTier 1）で部品、電装品を作っている会社です。私はNSITEXEに入社したこともあり、DENSOとの合併後も半導体のIPを開発する部署に所属していました。正確にはハードウェアに付随するソフトウェア開発を行っていました。いわゆるBSPとかファームウェアと呼ばれる部分になるかと思います。

会社全体を見渡せばソフトだけでなく、ハード、機械設計、プラントのようなものまであって、自動車産業の裾野の広さを感じます。自分の仕事が好きに選べるかどうかは正直言って配属次第ですが、全員のワガママは叶えられません。Panasonicも同じでした、これは大企業の仕方ない一面でしょう。どうしても気に入らないなら別の部署に移籍する制度もあるみたいです。使ったことないので詳細は知らない。

企業風土は紙文化の残るやや古い日本の大企業ですが、時代の流れに乗るべく刷新を頑張っていました。やや大企業病（実務を下請けに丸投げで、社員は納期の管理しかしない）に掛かりかけている部分もありそうですが、エンジニア目線としてはものづくり会社の気風が強く、技術的にはさっき言ったとおりで幅広くて面白いと思います。あと大企業の割に経営陣との距離が近いというか、偉い人たちのフットワークが軽い感じがします。

辞めた理由

実は辞める気はあまりなくて管理職の昇格試験も受けてました。そんななかで突然辞めたので非常に迷惑を掛けてしまいました、申し訳ない。辞める理由を聞かれましたが、嫌なことがあったわけじゃないです。むしろDENSO良い会社ですよ、転職考えている方なら受けてみてはいかがでしょう。

理由は月並みですけど年齢です。40歳過ぎてこのまま管理職になるのも良かったですし、最後にもう一回くらい何かにチャレンジするも良かったですし、とぼんやり思っていたところに、運良くチャレンジできそうなチャンスが訪れたので乗りました。一度しかない人生なのでやりたいことをやれるときにやってみようと思いました。

年齢的に数年先の保証もないベンチャー企業に行くのは迷うところでしょうけど、NSITEXE時代を思い出してベンチャーの雰囲気は結構好きだったなー、と一歩前に踏み出せました。もちろん会社が急に消滅して40半ばで無職として放り出されるリスクはあります。とはいえ最近の動向を見ていると、

• 大企業は傾けば40〜50代をリストラするし、その後の面倒も見ない（Panasonicで何度も見た風景）
• 人手不足の影響か40歳以上は取りません！みたいな足切りする企業が減った

労働者側から見たらリストラも会社がなくなるのも職を失うという意味では一緒です。昔と違って40半ばで無職となっても詰みではなさそうですし、その時はその時でなんとかするしかない、そのために腕を磨いておくしかないだろう……と思える環境に変わってきたことも要因の一つです。