数年ぶりにPebbleアプリを書いている。公式のsdk(というかpebbleコマンド)は、使ってるサーバがもう動いていないので動かない。
<a href="https://rebble.io/">Rebble</a>の有志がforkして運用してくれてる <a href="https://github.com/pebble/pebble-tool">https://github.com/pebble/pebble-tool</a> を使えば良い。
ArchLinuxだとaurにパッケージがあるので、
<pre><code class="sh">yay -S pebble-tool-git python2-virtualenv</code></pre>

とするだけで昔とおなじように開発できるようになる。<a class="footref" href="#fn1" id="r1">[1]</a> ありがたい。
今はlanguage serverとかエディタ側が進化しているので、補完や定義ジャンプをばりばり使って書けるようになっていて、sdkが当時のままでもなかなか新鮮な感じでプログラミングできて面白いし、快適だ。
language serverの使い方は普通のCプロジェクトとおなじ。
自分は定義作るのに<a href="https://github.com/rizsotto/Bear">bear</a>、language serverには<a href="https://github.com/MaskRay/ccls">ccls</a>を使っている。
<pre><code class="sh">bear pebble build</code></pre>

としてbuild時にbearをかませばcclsに渡せる定義ファイル(compile_commands.json)ができるので、それをcclsから使えば良い。
<aside class="footdef">
<a href="#r1">[1]</a> virtualenvはsdkのダウンロードに必要
</aside>

2019年にPebbleアプリを作る

結論から書くと、<a href="https://unknownplace.org/blog/2019/10/23/v4l2loopback/">前回</a>書いたv4l2loopbackと<a href="https://play.google.com/store/apps/details?id=com.pas.webcam&amp;hl=en_US">IP Webcam</a>というAndroidアプリを組みあわせればいける。
<a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/48953456078/in/datetaken/" title="2019-10-24-114609_683x549_scrot"><img src="https://live.staticflickr.com/65535/48953456078_1314c4ab25_z.jpg" width="640" height="514" alt="2019-10-24-114609_683x549_scrot"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>

IP Webcamの使い方はいまのところまだよくわかってないが、Start serverすると、 <code>http://ip:8080/video</code> <a class="footref" href="#fn1" id="r1">[1]</a> で、mjpegストリームが取れるっぽいので、
<pre><code class="sh">ffmpeg -i http://ip:8080/video -f v4l2 -pix_fmt yuv420p /dev/video0</code></pre>

とかで流しこんでやればokぽい。 <code>-pix_fmt</code> はないとエラーが出たので適当に付けて回避したものなのでもっと良い指定があるやもしれず。
日本で使っていたカメラや、ノートPCのそれより全然良いので、もはやこれで良いなぁ。
あと、この方法だと、静止画流しこんだり、デスクトップキャプチャを流しこんだり、本来カメラしか使えないところでもいろいろ応用ができるのもよさそう。
<aside class="footdef">
<a href="#r1">[1]</a> ipって書いてるところはスマホのIP。念のため。
</aside>

Pixel3をwebcamとして使う

日本で使っていたWebカメラは処分してしまったので、デスクトップPCでビデオ会議するためには、また新しく買わないとなぁと思っていたのだが、
画質良いやつを買おうとすると、結構高いし悩む。(会議に画質をもとめなくてもいいとは思うが…w
スマホをWebcamとして使える方法ないのかな？ と検索してみると、Androidだと <a href="https://www.dev47apps.com">DroidCam</a> というアプリでまさにそういうことが出来そう。
ただ、専用のソフトウェア(Linuxの場合kernel module)をインストールする必要があって、あんまりやりたくない感じがする。
用途的におそらくカーネルモジュールは入れる必要はあるとは思うが、もう少しオープンなものor汎用的なものはないのかと探して見つけたのが、 <a href="https://github.com/umlaeute/v4l2loopback">v4l2loopback</a> というプロジェクト。
これはv4l2の仮想入出力デバイスを作ってくれるもので、v4l2に対応してるアプリならなんでもつかえそうなのでなかなか良さそう。
とりあえず、
<pre><code class="sh">sudo modprobe v4l2loopback exclusive_caps=1
ffmpeg -re -i foo.mp4 -f v4l2 /dev/video0</code></pre>

として、適当な動画をChromeからwebcamとして使えるところまでは確認した。<a class="footref" href="#fn1" id="r1">[1]</a>
あとはffmpegに何らかの方法でスマホのカメラ画像を渡せばやりたいことはできそう。
<aside class="footdef">
<a href="#r1">[1]</a> <code>exclusive_caps=1</code> を付けないとChromeが認識してくれない ref: <a href="https://github.com/umlaeute/v4l2loopback/issues/78">https://github.com/umlaeute/v4l2loopback/issues/78</a>
</aside>

v4l2loopbackで仮想videoデバイスを作る

LinuxのGUIアプリの起動は基本的には WM (awesomewm) のコマンド実行機能(<code>super-r</code>)でやっている。
この方法だと実行する名前を少なくとも頭文字くらいは覚えておかないといけない。
たまにしかつかわないようなアプリはけっこうなんだっけ？ってなることが多くてつらい
<ul>
<li><code>zeal</code> ドキュメントビューワ</li>
<li><code>evince</code> PDFリーダー</li>
<li><code>scrot</code> スクショ取り</li>
<li><code>peek</code> gif動画取り</li>
</ul>

などなど…。
awesomewmにもmenubarというWindowsでいうところのスタートメニューみたいな機能があるので、そういうのをもっと活用すべきなんだろうな〜とおもいつつ。

Linuxのアプリの名前を覚えるのが難しい

TL;DR: <code>hexedit --color</code> 良い。
バイナリーファイルを編集するというような機会は、いままでそんなになかった。
表示して確認したいということはそこそこあったが、編集するということはあってもせいぜい1byte書き換えるとかその程度。
なのでだいたい、 <code>hexdump</code> か Emacs の <code>hexl-mode</code> でことたりてた。
ただ最近わりとがっつりバイナリーを編集する必要があって、いままでのようにhexl-modeを使っていたのだが、
ガーっと入力できるのはasciiだけで、hex値での入力は毎回 <code>C-M-x</code> をおして1byteずつやらなければいけない。
めちゃくちゃ不便。
そもそもhexl-modeはそのようにがっつりバイナリーをいじる用途向けではなさそうだ。
適当に検索すると
<ul>
<li><a href="https://qiita.com/hachisukansw/items/7f0219d17707e149f389">Linuxで大きめのファイルの扱えるバイナリエディタ - Qiita</a></li>
<li><a href="https://www.tecmint.com/best-hex-editors-for-linux/">Top Hex Editors for Linux</a></li>
</ul>

とかがひっかかる。CUI、GUIけっこういろいろある。
いろいろ試して決めようとおもうが、
<ul>
<li>なるべくArchLinuxのデフォルトでパッケージがあるやつ<a class="footref" href="#fn1" id="r1">[1]</a></li>
<li>どこでもつかえるからCUIのやつ</li>
</ul>

という条件で検索すると
<ul>
<li>hexedit</li>
<li>dhex</li>
</ul>

のどっちかかなと。dhexは上の記事によるとキーバインドが独特っぽかったのでとりあえずhexeditを試す
<pre><code class="sh">yay -S hexedit</code></pre>

とりあえず軽く使ってみた感じでは
<ul>
<li>変なキーをおすとダイアログみたいなやつが出て親切</li>
<li>F1でmanがひらける(↑のダイアログにでる)</li>
<li>カーソル移動はEmacsキーバインドが使える</li>
<li>hex領域とascii領域の行き来はtab</li>
<li><code>--color</code> で起動すれば色つきになる<a class="footref" href="#fn2" id="r2">[2]</a></li>
</ul>

という感じでもうこれでいいじゃん、というかかなり気にいってしまった。こまったらF1おせばシンプルに使い方がわかるし、Emacsバインドがつかえるのも個人的には最高。
もはや表示だけでも <code>hexedit --color</code> をつかうレベル。
もっとはやくさがしておけばよかったな〜
<aside class="footdef">
<a href="#r1">[1]</a> AURはあまり増やすとアップデート時に時間かかるから最小限にしたい 
<a href="#r2">[2]</a> ちゃんとカーソル位置がhexのところとasciiのところの色が連動するので見易い
</aside>

バイナリエディターを探す旅

howmメモ、orgファイル、skkの個人辞書などをいままではDropboxにいれてsyncしていたが、Google Driveに変更した。
syncツールには <a href="https://github.com/vitalif/grive2">grive2</a> というのを採用。Arch Linuxだとaurにあるので、
<pre><code class="sh">yay -S grive-git</code></pre>

でokだった。<a class="footref" href="#fn1" id="r1">[1]</a>
全部syncしてほしくはないので <code>~/drive/.griveignore</code> として以下のようなファイルを作る:
<pre><code class="text">*
!howm
!org
!skk</code></pre>

それを作ったあとで、
<pre><code class="sh">cd ~/drive
grive -a</code></pre>

とすると、OAuth認証のプロセスになって、それが通ると初回同期が走る。認証だけじゃなくて、ファイルもおとしてきてしまうので、ignoreファイルを最初に作っておかないと悲しいことになる(なった…w)
あとはこれを自動で動かすために、
<pre><code class="sh">systemctl --user enable grive-timer@drive.timer
systemctl --user start grive-timer@drive.timer
systemctl --user enable grive-changes@drive.service
systemctl --user start grive-changes@drive.service</code></pre>

をやっておけば勝手に同期してくれるっぽい。<a class="footref" href="#fn2" id="r2">[2]</a>
<aside class="footdef">
<a href="#r1">[1]</a> gitのほうを使わないと .griveignore が使えない 
<a href="#r2">[2]</a> inotify-toolsのインストールが必要 
</aside>

Google Driveを使う

サブPCとしてSurface Goを使っていることもあって、やっぱりメイン環境がHiDPIじゃないのがきになってきていたので、
<a href="https://www.eizo.com/products/flexscan/ev2785/">4Kモニタ</a>を導入してみたのだが、Linuxで使おうとするといろいろ問題がでてきた。
まず、LinuxでのHiDPI設定というのはいまだにこなれてなくて、アプリごとにいろいろな設定をする必要がある。詳しくは<a href="https://wiki.archlinux.org/index.php/HiDPI">ArchWikiの該当ページ</a>とかを参照。
まぁまだそれは良いとして、いまの自分の環境のように、HiDPIなモニタとそうじゃないモニタが混在しているマルチモニタ環境だと、HiDPI設定をしたアプリを普通のモニタで表示するとめっちゃでっかく表示されてしまったりと、かなりツラいことになる。
HiDPIなモニタで環境を統一してしまえばいいのかもしれないが、個人的にはHiDPIなモニタと、144Hzなど高リフレッシュレートのモニタの組み合せが現状ゲーマーエンジニア的にはベストなデュアルモニタ構成であると思っているので、しばらくはこの構成を維持しそうな気がしている。<a class="footref" href="#fn1" id="r1">[1]</a>
そんなわけでLinuxでこのディスプレイ構成は痛みしかなさそうなので、ダメ元でWindowsをメイン環境として試してみることにした。<a class="footref" href="#fn2" id="r2">[2]</a>
Surface Goで開発環境は一応整えていて、開発環境として使えはする、というところまでは分かっているのだが、快適な作業環境という意味でかなり重要なのがタイル型のウィンドウマネージャ的なウィンドウ操作ができるかどうか、ということがある。
素のWindowsで開発していてやはり気になるのが、各ウィンドウ位置を調整するのに手間どる、というところだ。
Linuxでは<a href="https://awesomewm.org/">awesome</a>というタイル型WMを愛用していて、これを使うとEmacsをフルスクリーンで使っているところに、シュッとChromeをside-by-side表示したりまたEmacsにもどしたり、ChromeにかわりにTerminalを出したり、ドキュメントビューワをだしたり、といったことが瞬時に行える。
この快適さに慣れてしまうと、マウスでちまちまウィンドウの位置を変える、とかはめんどくさくてやってられない。
Windows 10にはビルドインでWinキーとの組み合せで画面分割ができる仕組みがあってがんばって使ってみたものの、やはりタイル型WMにはほど遠い使い勝手。
Windowsで動くタイル型WMはないものか、と探すとすぐに見つかるのが<a href="https://github.com/fuhsjr00/bug.n">bug.n</a>というWM。AutoHotKeyでうごいてるらしいことにも驚く。
さっそく少し触ってみると、tagの概念がawesomeと違い(awesome流のほうが好み)、ワークフローを考えなおさないといけないが、なんとかなりそう。
というわけで本導入してみたら、ハマるわハマるわ…。bug.n自体もDPI違いのマルチディスプレイだとすんなりとは動いてくれないのであった………。本末転倒とはまさにこのこと😢
いろいろやってなんとか動かすことができたのが以下の環境:
<ul>
<li>8.4.0という古いバージョンを使う</li>
<li><code>Config_verticalBarPos=tray</code> は使わない</li>
</ul>

です。 <code>Config_verticalBarPos=tray</code> はbug.nのステータスバーをWindowsのタスクバーの上に表示してくれてカッコ良いし、違和感がないので、ほんとうは使いたかったが、どうしてもこれを有効にしたまま上手く動かすことができなかった。
とりあえずこの環境ならなんとかうまくうごいてくれて、ギリギリメイン環境としていけるかなぁ、という感じ。ちょっとbug.nが不安定すぎるのが気になる。とにかくしばらくこの状態で使ってみることにする。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50280877171/in/datetaken-public/" title="trying bug.n"><img src="https://live.staticflickr.com/65535/50280877171_6afefb0cf6_b.jpg" width="1024" height="575" alt="trying bug.n"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

こんな感じ。(これはあんまりタイル型っぽくないが…)
bug.nにしろ、WSLにしろ、なんとなく使えてはいるが、そこはかとなく本物じゃない感というか、不安定感があって、使っていて不安になる。
とはいえこのディスプレイ環境のままLinuxを使い続けるのはもっとつらそうだしな、とう感じで消去法で環境をきめていて、なんだかなーという感じだ。せっかく使うからにはもうちょいがんばってWindowsを使いやすくしていきていとは思っているが、いまのところ最低限使える程度、という感じ。
<aside class="footdef">
<a href="#r1">[1]</a> 4K+144Hzでゲームをうごかすスペックがまだまだ現実的ではないため
<a href="#r2">[2]</a> ちょうど新しくPCを組んだところだったというのも理由の一つ 
</aside>

Windowsをメイン開発環境として使ってみる試みでbug.nを導入

Linuxデスクトップ環境では<a href="https://awesomewm.org/">awesome</a>というウィンドウマネージャを愛用している。
かなり前の話なのだが、このWMがフォントのレンダリングにつかっているpangoというライブラリがビットマップフォントのサポートをドロップしてしまった。
以下の画像のようにTamsynというビットマップフォントを使用してUIを作っているだが、あるときupdateしたらぜんぶ豆腐になってしまって大変困り、とりあえずpangoは1.43でバージョン固定して、更新しない、という方針でながらくしのいでいた。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/50035187302/in/datetaken-public/" title="tamsym-font-otb x awesomewm"><img src="https://live.staticflickr.com/65535/50035187302_5110b5cc22_o.png" width="547" height="63" alt="tamsym-font-otb x awesomewm"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

今日別件で<a href="https://wiki.archlinux.org/index.php/fonts">ArchWikiのFontのページ</a>を見ていたら、OpenType Bitmap (otb) という種類のビットマップフォントならpango 1.44以降でも使えるというのを見て、さっそく、 <code>tamsym-font-otb</code> を入れたら、あっさり最新のpangoでもそのまま(configもそのままで)同じ見た目になって、なんだそれだけのことか…となっている。
しかし、tamsymはotb版はaurにしかないのがちょっとめんどくさいくらい。もっとはやくしらべておけばよかった案件。

pango 1.44以降でのbitmapフォント

E
この1年ほどメイン開発環境をWindowsにしてみる、というのをやってみていたが、1年たってもしっくりこないままなので、結局Linuxに戻してしまった。
ただ、Windowsの良かった点もいくつかあって、一番はリモートデスクトップがとても良くできているところ。
自分の普段使いのマシン構成は、高スペックデスクトップPC + Surface Go 2 で、Surface Goはかなり非力なのでそれ単体で仕事をしたりするのはかなり厳しい。 しかし、Windowsのリモートデスクトップを使えば、Surface Goから違和感なくデスクトップPCを操作することができ、安定したネット環境さえあればどこでもそれで十分作業ができる。これはなかなか良い体験だった。
リモートデスクトップが実用的に使えると、Surface Goはサブマシンとしてかなり良い。iPadの代わりのタブレットとしての用途だけでなく、やろうとおもえばガッツリ仕事にも使える。持ちはこぶのも楽々だし。
その体験がとても良かったので、Linuxホスト(Windowsクライアント)でもおなじような環境が作れないものかといろいろ試行錯誤した。結果、Chrome Remote Desktopがいまのところ一番満足度が高いという結果になった。
CRDの良いところは、
<ol>
<li>クライアントのスクリーン解像度にあわせてリモート側の解像度も変わる</li>
<li>音も出る</li>
<li>低遅延<a class="footref" href="#fn1" id="r1">[1]</a></li>
<li>4K(+ HiDPI)でも実用に耐える</li>
</ol>

という感じ。他にもそれ単体でNAT越え機能がついてるというのも人によっては嬉しいだろう。僕の場合はVPN経由でもアクセスできるようにしているのでこれはどうでもよいのだが。
1,2ができることで、Windowsのリモートデスクトップと使用感がかなり似ている。ただし、Windowsのそれは本体側のスクリーンをそのまま操作するようになっているのに対し、LinuxホストのCRDは本体側で別途リモート専用のXセッションを立ち上げる形で実装されているので、重複起動ができないアプリを本体側で起動していたりするとめんどうなことになる。あと開発系のツールでport空けるやつとかが使おうとしてる環境とは別側で動いてたりとかも。
4K HiDPIな環境で使うには少しトリッキーなことをする必要がある。WindowsでHiDPIにしていると、(例えば3840x2160のディスプレイを200%にスケールさせて使っていると、)Linux側では1920x1080のデスクトップとして扱われてしまうので、全体的にぼんやりとして表示になってしまう。 めんどうだが、まずWindows側のディスプレイ設定を100%にした上でリモート接続する。その上でLinux側で普通にHiDPIの設定をするとすべて上手く行く。 ただ、3840x2160のディスプレイ解像度で接続しつつ通信量を見てみたのだが、瞬間的に20Mbps近くいくこともあるっぽいので、テザリングでこれやるのは慎重に。
Linux側の設定は、xinitでXを起動している僕のようなユーザーにとってはかなりとっつきやすいものになっている。 <code>~/.xinitrc</code> の代わりにCRDでは <code>~/.chrome-remote-desktop-session</code> が使われるのでそこに同じようなことを書けば良い。
HiDPIの設定は <code>.Xresources.remote</code> に書いている<a class="footref" href="#fn2" id="r2">[2]</a>。ここがいま一番悩ましいところで、使うディスプレイによって200%が良いときと150%が良いときがあるし、他にも出先でLTE回線で使う時は100%で使いたい、とかクライアントの事情によってフレキシブルに変更したいことがあるのでこの仕様は不便だ。
自分がリモートデスクトップを良く使う環境はまずSurface Goでこれは150%表示で使いたい。次にがっつり作業したい時などはSurface Goにポータブルモニタを繋げてそちらにリモートデスクトップをわりあてている。この時はできれば200%表示が良い…、みたいな感じ。倍率変えて起動しなおすのもそこまで手間ではないが、リモートデスクトップを使う時の手順がまずWindowsのほうで使うディスプレイを倍率100%にするところから始める必要があるので、リモートの倍率設定までしているとかなり手順が多くなってしまう。
他の悩ましい点としては、Win-LキーがWindows側にどうしてもとられてしまって、リモートでは使えないところ。awesome wmでwindowのサイズ変更に使用しているので、ちょっと困る。他のキーに割り当てを追加したが、慣れるまでは大変そうだ。
などなど微妙な点もそれなりにあるものの、トータルではこの環境にかなり満足している。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/51413138381" title="My mobile workstation 2021"><img src="https://live.staticflickr.com/65535/51413138381_35903df32f_h.jpg" width="1600" height="900" alt="My mobile workstation 2021"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

ガチで作業するときの図。右がLinux、左に普段はMacをそれぞれリモート接続している。Surface GoのようなタブレットPCは単体で使うと本体なのにサブディスプレイ的なポジションにもなれるのも良い。
<aside class="footdef">
<a href="#r1">[1]</a> VNC、xrdp、X forwarding via sshと試した中で一番良かった
<a href="#r2">[2]</a> これを前述のinitファイルから xrdb -merge してる
</aside>

LinuxホストでのChrome Remote Desktopはとても快適

Diablo4、発売してから二ヶ月弱、ちょこちょこプレイしてるけどやっぱり楽しい。
初期にありがちなちょっとした問題はいろいろあるものの、それ問題を加味してもだいぶ楽しい。
自分は最初はネクロマンサーで始めたものの、ナイトメアに昇格するダンジョンのボスが消えてしまうバグにひっかかってナイトメアにあがることができず、
その修正待ちのあいだしょうがなくローグをやっていたら、ローグだとそのバグがおきずにナイトメアにいけてしまい、結果レベルが逆転してしまったので、そのままローグをプレイしている。
このローグはなかなか面白いキャラで、剣やナイフをつかう近接ビルドも弓を使う遠距離ビルドもいけるハイブリッドなキャラで、しかもどっちが強いということはなく、また死にスキルがないといっても良いほどの調整になっているので、めちゃめちゃビルドの幅が広くむちゃくちゃ面白い。自分はいろいろ試した結果、遠距離の速射というスキルをメインにしたビルドが好みだったのでそのような感じに育てている。
と言っても、高レベルダンジョン用とかレベル上げ用とかでいろいろビルドを変えている。いまの問題点のひとつとしてはこうしたビルドの切り替えがめーーーーーっちゃくちゃめんどいこと。なんとかしてくれ。

<h3>シーズンスタート</h3>
まちにまったシーズン1が明日から始まるのだけど、正直ローグのやり残した感が半端ないので複雑な気持ち。
レベルも98までしか上げられなかったし、装備も全然そろってないし、、、
ただ、シーズンはもう少し期間がながいので、自分のペースでもけっこうエンドゲームを楽しめそうだと思われるので、なかなか楽しみ。
ローグやりのこした感あるとはいえ、今後のシーズンではやったことないキャラがいなくなるまであたらしいキャラを試していきたいのでまた別キャラで始める予定〜。

<h3>LinuxでDiablo</h3>
いままでの自分のゲーミング環境は、Linuxホスト上でWindowsをKVMでうごかし、そのVMに対してGPUをPassthroughしてあげるというゲーミングWM環境がメインだった。
しかし、Steam Deckを買って、LinuxでWindowsゲームが普通に遊べることを知ってしまったので、わざわざVMを起動するのが馬鹿らしくなり、それ以降はメインPCでもSteam DeckのようにWineベースの環境でプレイするようになった。Diablo4もそのように動かしているが全然普通に遊べる。
ただ、キーボード周りにちょっと問題があり、IMEを有効にしているとキーボード操作ができない。<a class="footref" href="#fn1" id="r1">[1]</a>
コントローラプレイもできるけど、遠距離職だとどうしてもピンポイントでターゲットを指定したほうが強いので、マウスキーボードでプレイしたいのよね。
そんなわけでIMEを無効にした状態で起動させると、キーボードプレイはできるようになるが、今度はゲーム内チャットで日本語がうてなくなるという問題がでてくる😇
なので、雑な解決法として、<a href="https://github.com/typester/text-copy-widget">シンプルなテキストフィールドのみのアプリで、それは入力された文字を標準出力に投げて終了する</a>、みたいなのを作ってそれをWMの設定で
<pre><code class="lua">awful.key({ mod }, 'Return', function() awful.spawn.with_shell('text-copy-widget | xsel -bi') end),</code></pre>

みたいな感じで設定することで、Win-Enterで起動し、なんか書いてEnterおすと書いた内容がクリップボードに入るので、それをゲーム内ではりつければ日本語で発言が可能！ みたいなローテクな解決法で対処している。慣れればそんなに不便じゃないよ。ちなみにこの設定はAwesome WMの例ね。


<h3>Steam Deck</h3>
空き時間にPCゲーができてしまう神デバイスなSteam Deckだけど、Diablo4も普通に快適にプレイできる。
のだが、やはりPCとくらべるとロード時間に差があり、友達とプレイしている時はそれによって友達を待たせてしまう、というような状況が発生するので、結局スマホでPCのゲームをストリーミングプレイしたほうが良いということになってしまっている。とりあえずDiabloに関しては。
Diablo4はコントローラにも正式に対応しているので、スマホでのリモートプレイがめちゃくちゃ快適で、ソファにすわってだらだらレベル上げや低難度ダンジョン周回ができるのも神。
そんなこんなで、まったりとシーズン1も楽しんでいこうとおもっていますが、一緒にやってる友人らがガチ勢しかいなくて追いていかれ気味なので、まったりフレを募集しています…！
<aside class="footdef">
<a href="#r1">[1]</a> これはDiabloの仕様とおもわれ、Windows上でもおそらく日本語のIMEとかにしていると操作ができないものと思われる。Windows上ではEnglighと日本語のIMEを切り替えることができるので問題にはならない
</aside>

Diablo4とLinuxゲーミング

もうだいぶ前の話になってしまうのだが、3月くらいに<a href="https://store.steampowered.com/steamdeck">Steam Deck</a>がセールされていて、もともと興味もあったのでついつい購入してしまった。
Steam Deckの話はまた別に投稿するかもしれないけど、これはめちゃめちゃおすすめなデバイスである。$350の価値はありすぎる。
このSteam DeckにはSteam OSというArch LinuxベースのOSが搭載されていて、このOSには、ゲームモードとデスクトップモードの二種類のモードがある。
通常立ち上がるのはゲームモードで、これはSteamのBig PictureモードのUIがそのままOSになったみたいな感じのものだ。
デスクトップモードは普通のLinuxデスクトップで、デフォルトだとKDE Plasmaの環境が立ち上がる。デスクトップモードはいったんゲームモードで立ち上げたあと、電源メニューからデスクトップに切り替える必要がある。実際このへんは<a href="https://wiki.archlinux.org/title/SDDM">SDDM</a>を使ってやっているっぽく<a class="footref" href="#fn1" id="r1">[1]</a>、好きに変更することも不可能ではなさそうだが、OSアップデートのたびにホームディレクトリ以外の場所は初期化されてしまうようなのであまりそういうことはしないほうがよさそう。
そんな感じでデスクトップモードはいろいろ制約がおおいのだが、<a href="https://www.reddit.com/r/SteamDeck/comments/10toj3c/linux_handheld_desktop_gaming_pc_feat/">Waylandベースのデスクトップ環境をゲームモードで立ち上げる</a>、という猛者がいるのを発見した。
この方法だと、ゲームモードのまま、ゲームを起動する感覚でデスクトップ環境を立ち上げられるのでめちゃくちゃ便利。外部ディスプレイで稼動させるのもいろいろ制約はあるもののちゃんと動く。以下は4Kのモバイルモニタを使っている様子↓
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/52807289765/in/datetaken-public/" title="4K Linux desktop on Steam Deck"><img src="https://live.staticflickr.com/65535/52807289765_9e1c31dd63_b.jpg" width="1024" height="771" alt="4K Linux desktop on Steam Deck"/></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

おなじような方法でXorgベースなWMを起動するのもトライしてみたが、いちおう起動はできたものの解像度の設定がどうやってやるのかわからず…。
ゲームモード上ではX Windowのアプリはgamescopeというアプリにトラップされて全画面表示になってしまうのだが、このように起動したWMもおなじgamescopeの中に入ってしまう。
ちなみにWayland WMの中でも従来のXを使うアプリはgamescopeに囚われてしまうので、基本このゲームモード上のデスクトップ環境では純粋なWaylandアプリのみを使えるということになる。
それでも自分の普段使っているアプリでWaylandに完全に対応していないのはAndroid Studioくらいなので、わりといろんなことができる。

<h3>ゲーム機としては？</h3>
Linuxマシンとしてはかなり遊べるデバイスだが、ゲーム機としてはどうか？ 自分はもともとゲーミングPCを持っているということもあり、最初はまったく期待していなかったのだが、いまではゲーム機としてもかなり気にいっている。
まず、一番おどろいたのは自分のSteamライブラリーのゲームのほとんどが問題なくうごいてしまうところ。モンハンなんてめちゃくちゃサクサクでビックリする。
720pという解像度だからというのもあるだろうが、このパフォーマンスのよさには正直おどろいた。また、画面自体も小さいからか、解像度の低さもあんまり気にならない。むしろどこでも好きなときにPCゲーが遊べる、というのがとてもよい。
あとはコントローラの質がめちゃくちゃ良い。過去に発売されていたSteam Controllerもすごく評判がよかったけど、こういうことかと。若干レイアウトがくるしいところはあるものの、手持ちのコントローラの中では断トツに良いのでSteam Deckの重さなんかを加味してもトータルのプレイ体験が良い。
あと、普通の携帯ゲーム機のような感覚でいつでも電源ボタンをおしてゲームを中断・再開できるのもよい<a class="footref" href="#fn2" id="r2">[2]</a>
そんなわけで、積みゲー消化マシンとしてはとても良く、Life Is Strange2 と Star Wars Fallen Order をたてつづけにクリアした。あ、そうそう、Diablo4 のベータも快適にプレイできましたよ。

<h3>Wayland</h3>
という感じでSteam Deck契機でWayland環境をためすことになったのだが、その後はメインPCのほうでもWaylandを試している。
メインのデスクトップ環境はマルチモニタで、それぞれのスケール設定が異なる。Xorgではそのような設定はできないため解像度が低いほうは無理矢理scaleさせて縮小表示するようになっていて、ただでさえHiDPIとくらべて画質がわるいのにさらに悪くなってしまうのが気になっていた。
Waylandだとそのへんはモニタ毎に自由にscale設定できるし、runtimeでscaleを変えたりもできるし、かつそのへんの動作がかなりサクサクなので、その時点でけっこう惹かれてしまった。
ただ問題は自分が<a href="https://awesomewm.org/">awesomewm</a>ライクなワークスペース操作になれてしまっているので、<a href="https://swaywm.org/">Sway</a>や<a href="https://hyprland.org/">Hyprland</a>にどうしてもなじめなかった。
そんな中発見した<a href="https://github.com/riverwm/river">river</a>というWMがawesomeとおなじtagベースなワークスペース管理があり、設定方法なんかも好みで、最高やん！と思ってしばらく使っていたのだが、どうしても画面共有がうまく動かせないのと、IMEが動かないアプリがあるのが残念で、現時点では常用はむずかしそうということに。惜しい。ただとても気にいっているのでriverは今後もwatchしたい。
いま試しているのは、<a href="https://github.com/typester/hyprtag/">Hyprlandにタグベースのワークスペース機能をあとづけする</a>、というものだ。
最初はネタのつもりでサクっと必要最小限の機能を作ってみたら、一気にHyprlandが便利になってしまい、これは完成すれば普通にHyprlandに移行できるかも？ という感じになってしまったので、それ以降空き時間にちょこちょこ開発している。まだ使えないユースケースがおおいので他の人が使うことは想定していない(のでREADMEも書いていない)段階だが、そのうちちゃんとととのえていきたい。
先週末にマルチモニタにも対応したので自分用としては最小限の機能は一通りおわった感じがある<a class="footref" href="#fn3" id="r3">[3]</a>。あとは、
<ul>
<li>runtimeでのモニタの増減に対応</li>
<li>各種statusを通知するAPI (ステータスバーとかWidget用</li>
<li>条件にマッチしたclientにfocusする機能</li>
</ul>

くらいでとりあえず十分なものになるきがする。
<aside class="footdef">
<a href="#r1">[1]</a> ゲームモードにauotloginする設定があるのは確認した
<a href="#r2">[2]</a> たまにバグるけどw
<a href="#r3">[3]</a> 先週まではawesomeと併用してたけど今週からHyprlandオンリーの生活をおくっています 
</aside>

Steam Deck, Waylandお試し中

TLDR: <a href="https://unknownplace.org/blog/2019/01/24/grive/">Google Drive経由で同期していた</a>orgファイルなどの同期を<a href="https://syncthing.net/">Syncthing</a>を使うように変更したら劇的に便利になった、という話。
最近はorg-modeを使いたおしている<a class="footref" href="#fn1" id="r1">[1]</a>のだが、いままではorgファイルの同期をGoogle Drive経由でやっていた。
これにいろいろ不満あった:
<ol>
<li>grive2がちょいちょい動かなくなる</li>
<li>grive2がちょくちょくビルドできなくなる or OAuth認証ができなくなる</li>
<li>Androidとの同期が微妙</li>
</ol>

1は、Google Driveへの同期ツールとしてgrive2というのを使っているのだが、このgrive2がたまーにうごかなくなることがある。
これはほとんどの場合、ArchLinuxでgrive2は公式パッケージには入っておらずAURになっているがboostに依存している、というのが原因。boostが更新されてもAURであるgrive2はそのまま再ビルドされないままになってしまい、結果libraryが読めなくなってうごかなくなる。
2は、ビルドできなくなるのはArchLinuxが新しすぎるパッケージを採用しすぎるのが原因なきがするが、最近も<a href="https://github.com/vitalif/grive2/issues/370">最新のgrepが入ってるとビルドできない</a>、みたいなのがあってこまった。OAuthのほうはよくわからないが(Googleのポリシー周り？)、しばらく新規認証できなくて新しいPCを同期対象にできなかったりもあった。
3はAndroidはGoogleケータイだしネイティブでGoogle Drive同期できるのでは？ みたいに思うかもしれませんが、実際のファイルとして同期しようとするとサードパーティツールをつかわないとできないのですね。<a href="https://play.google.com/store/apps/details?id=com.ttxapps.drivesync">Autosync for Google Drive</a>というのを使っていたが、これは無料だと1時間に1回しか同期してくれないのであった。
有料でもそんなに高くないのだけど、1,2の理由からGoogle Driveでのファイル同期は微妙だなという思いがあって購入しないままいまにいたる。
Androidでのorgの編集は
<ul>
<li>出先でなにかおもいついたことをinboxにメモ(あとでPC上でグルーミング)</li>
<li>習慣をやったよ、とマークする</li>
</ul>

だけなので、基本的に1時間syncでも問題がないというのもあった。
そんな感じでgriveをちょいちょい直して使う、みたいなことをしていたのだが、grepが原因でビルドできなくなったのをきっかけにもうこんなんやってられーん、という感じになってしまい重い腰をあげてなんとかしようとしてみた。
日常使っている端末(PC, Mac, Android)でいいかんじでファイル同期ができるものを探したところ、Syncthingがよさそうに思ったのでとりあえず評価してみた。<a class="footref" href="#fn2" id="r2">[2]</a>
結果、問題もなくはないが、同期の速度は爆速だし、Androidのバッテリー消費もそんなにわるくなってないように見えるし、体感としてはとてもよい。なにより、ふと気付いたらうごかなくなってる、みたいなgriveにあった不安さもないのが最高。
というわけでorgファイル以外もSyncthingをつかって同期するようになって、いまではこんな感じに。
<div class="image">
 <a data-flickr-embed="true" href="https://www.flickr.com/photos/typester/52658627437/in/datetaken-public/" title="My Syncthing sync flow"><img src="https://live.staticflickr.com/65535/52658627437_8133943baf_k.jpg" width="2048" height="901" alt="My Syncthing sync flow"></a><script async src="//embedr.flickr.com/assets/client-code.js" charset="utf-8"></script>
</div>

<ul>
<li>orgファイル同期</li>
<li>Pixel 7とPixel 3の写真同期</li>
<li>一部ソースコードをLinuxとMacで同期</li>
</ul>

orgファイルの同期、PC/Mac間ではそこまで使い勝手に差はないが、やはりモバイルでした変更が即座にPCに反映されるのはあたりまえだけど便利だった。キッチンでコーヒーいれているときに思いついたことをinboxにいれて仕事部屋にもどってきても、その変更はまだきてない、みたいなことがなくなった。
Pixel 7と3の写真同期はまぁ単純にGoogle Photosの容量をケチってPixel 3経由でアップするようにする用。
ソースコード同期がやってみたら意外にも便利で手放せなくなった。
具体的には <code>~/dev/src/sync</code> 以下が自動で同期されるようにした。基本的に進行中のprojectのソースコードを置いておく。 同期しないディレクトリも指定できるので、RustのtargetディレクトリとかNodeのnode_modulesディレクトリとかはsyncしないようにもできる。便利!
これによってキリの悪いところで作業が中断してレポジトリにpushできていなくても、そのままの状態を他の端末で再開できるようになってかなり快適になった。
ただ、問題がないわけではなくて、以下のような問題があった:
<ol>
<li>Google Driveとはちがってバックアップがない</li>
<li>Hyper-VのNATを超えられない</li>
<li>Androidアプリが止まってることがある</li>
</ol>

1は上の図にもあるように、Windowsにもorgファイルをread onlyでコピーされるようにして、そこをGoogle Driveでバックアップする、というような運用にした。Windowsでやるのはgriveをつかいたくなかったからです。
このようにread onlyかread/writeかというような同期方法を選べるのも良いポイント。Pixel間の写真同期はあえてread/writeにしていて、こうするとPixel 3のほうのPhotoアプリでCleanup spacesするとPixel 7のほうも消えてくれて楽。
2は、自分のHyper-V VMのネットワークはNATを使って外に出ているのだが、このNATをSyncthingがうまくあつかえない模様。
Sync対象が外からみて同じグローバルIPを持っているとおなじLANにいる想定でうごいてしまうのか(?)、うまくおたがいをさがせなくなってしまう。
これは常時VPNを張っておくことで解決できた。PC/Macはもともと<a href="https://www.zerotier.com/">zerotier</a>を使ってつながっていたので、そこにAndroidも追加する形。
3は、めったにないのだが、ごくまれにAndroidアプリが止まっていることがある。再起動したタイミングとかなのかな？
まぁとにかく動作中は通知領域にアイコンがでるので、止まってる場合そのアイコンが消えているのでわりとすぐに気が付けるので良いのだけど、
ほんとはつねに通知領域にでているのはウザいので消してしまいたいのだが、そうすると止まっていることに気が付けないので消すに消せなくなっている…。これはちょっと残念ポイント。
そんなわけで良い点ばかりではないものの、トータルではとても良いものです。おすすめ。
<aside class="footdef">
<a href="#r1">[1]</a> <a href="https://unknownplace.org/blog/2021/05/06/org-protocol-wsl-subsystemd/">ここ</a>で書いた家族との共有以外はすべてorg-modeでやるように戻ってしまっている 
<a href="#r2">[2]</a> Syncthingは公式にはiOSに対応していないので、iOSで使いたい人は注意されたし。サードパーティ製はいくつかある模様 
</aside>

Syncthing便利

普段はLinuxをメイン環境として使っているが、会社支給のコンピューターはMacで、そのMacからしかアクセスできない情報がある。
LinuxからMacを操作することができるといろいろ楽なので、リモートデスクトップをつかってLinuxからMacを操作している。
いままではChrome Remote Desktopを使っていて、そこそこ満足していた。
けれどなにか最近のアップデートでキーボード入力がまったく効かなくなるようになってしまい、Macの中でしかうごかないものの一つにSlackがあるため、入力ができないというのは致命的。
そもそも、使っている<a href="https://codeberg.org/river/river">Window Manager</a>がwaylandのtext-input-v1プロトコルをサポートしていない<a class="footref" href="#fn1" id="r1">[1]</a>ので、Chrome自体の日本語入力にも問題があったりして、そのへんはずっと微妙な感じではある。
ただ今回のChrome Remote Desktopはなにも入力ができないので、なにか根本的におかしいきがするが。
いろいろためした結果、いまのところ<a href="https://rustdesk.com/">RustDesk</a>というリモートデスクトップソフトウェアで落ち着いた。
Chrome Remote Desktopと比較したpros and consはこんなかんじ:
<ul>
<li>Pros
<ul>
<li>安定してる</li>
<li>ファイル転送専用UIが良い</li>
</ul></li>
<li>Cons
<ul>
<li>キーリマップ機能がない</li>
<li>若干遅延を感じる</li>
</ul></li>
</ul>
<h3>安定してる</h3>
Chrome Remote Desktopのときは、なんか気付くとMacがオフラインになってしまっていたり、使いたいのに繋げない、みたいなのがたまーにあった。
Rustdeskだとそれがまったくない。ものすごく安定している。
<h3>ファイル転送UI</h3>
なんか昔のFTPクライアントみたいなファイル転送機能がついてるのも良い。Chrome Remote DesktopのときはなんかメニューからUploadとかDownloadとか選んでやるかんじだったので。
<h3>キーリマップ機能がない</h3>
これは人によってはかなりのダウンサイドになるとおもう。具体的に言うと、cmdキーのマッピング。Chrome Remote Desktopでは左のAltキーをCmdになるようにマッピングしていた。
これがRustDeskではできないので、そのままWindowsキーがCmdとしておくられる。しかしWindowsキーはWindow Managerの機能でいろいろ割り振っているので、そちらが優先され、リモートデスクトップ側では使えないコンビネーションがでてくる。
自分の場合ほぼコピペさえできればよく、Win-C, Win-VはどちらもWMの機能をわりあててないのでそのままリモートサイドで使えるのでなんとか許容できる。
<h3>遅延</h3>
RustDeskはChrome Remote Desktopとくらべすと、びみょーーーにだけど遅延を感じる。
あとキー入力とかのバッファがたまりすぎて、それがはけるまでは操作ができなくなってしまうこともある。とはいえそこまで顕著にかわるわけではないので、しばらく使っているうちに慣れた。
Relayサーバーになっちゃってるのかな？と思いRelayを使わないように設定しても同じだったので仕様っぽい。
<h3>まとめ</h3>
キーリマップ機能さえあれば個人的には完璧な感じがするのが惜しい。
でも前述の通りめちゃくちゃ安定してつかえるのがとてもよい。
<aside class="footdef">
<a href="#r1">[1]</a> v3をサポートしているんだからv1などサポートする必要はないっていう硬派なスタイルなんだよね。riverの作者は他にも全体的に思想がつよい感じ。嫌いじゃないけど。 
</aside>

リモートデスクトップをChrome Remote DesktopからRustDeskに乗り換え

Waylandでアプリケーション毎にキー配列を変えられるようなリマッパーを探していたのだが、なかなか良いものが見つけられずにいた。
最近ふとしたことで、<a href="https://github.com/xremap/xremap">Xremap</a>を目にすることがあり、READMEをあらためて読んでみた。
このツール自体は昔から知っているのだが、当時はPython製で、Waylandはサポートされていなかったと記憶している。
しかしいまはRustで書かれていて、Waylandにも対応していた。そしてわたしのやりたいことはすべてサポートされているように見えた。すごい進化だ…！
というわけで試してみることにした。

<h3>インストール</h3>
自分の環境はArch Linuxで、<a href="https://isaacfreund.com/software/river/">river</a>を使っている。
riverはwlroots系なので以下をインストール
<pre><code class="sh">&#10095; paru -S xremap-wlroots-bin</code></pre>

<h3>設定</h3>
ユーザーをinputグループにいれて、udevのルールを追加。
<pre><code class="sh">&#10095; sudo usermod -a -G input $USER
&#10095; echo 'KERNEL=="uinput", GROUP="input", TAG+="uaccess"' | sudo tee /etc/udev/rules.d/99-input.rules</code></pre>

で、再起動。

<h3>リマップ設定</h3>
それでこれらのツールで実現したいことの基本的なことは以下の通り:
<ul>
<li>SpaceキーをShiftとして利用。しかし単独で押したときはSpaceとして機能する
<ul>
<li>特定のアプリケーション(主にゲーム)ではこの機能は無効にしたい</li>
</ul></li>
<li>キーボードハードウェア毎の配列の調整</li>
</ul>

Xremapでこれらをみたす設定はこんなかんじになった。
<pre><code class="yaml">shared:
 games: &amp;games
 - steam_app_default # DiabloIV
 - steam_app_2694490 # POE2

modmap:
 - name: SandS
 application:
 not: *games
 remap:
 Space:
 held: Shift_L
 alone: Space
 alone_timeout_millis: 999999999

 - name: HHKB
 device:
 only: "Topre Corporation HHKB Professional"
 remap:
 KEY_GRAVE: KEY_ESC
 KEY_ESC: KEY_GRAVE
 KEY_BACKSLASH: KEY_BACKSPACE
 KEY_BACKSPACE: KEY_BACKSLASH</code></pre>

起動はriverの設定から
<pre><code class="sh">xremap ~/.config/xremap/config.yaml --watch=config,device &amp;</code></pre>

こんな感じで起動すればokそう。

<h4>よくわからなかったところ</h4>
<ol>
<li>alone_timeout_millisの設定</li>
<li>アプリケーションの指定方法</li>
<li>watchコマンドラインオプション</li>
</ol>

<h5>alone_timeout_millisの設定</h5>
このタイムアウトを無効にしたかったので、最初は0を指定してみた。そうするとSpace単独でおしてもSpaceとして機能しなくなってしまったw
その挙動を望む人はいないとおもうのでよくわからないのだが、とりあえず十分大きい値を設定することにした。

<h5>アプリケーションの指定方法</h5>
ドキュメントにはswayの例はあるものの、一般的なwlroots系WMで通用するアプリケーションの指定方法の記載がないため、最初はなにを指定したらいいのかわからなかった。
いろいろやってみたところ、どうやら <code>lswt</code> で取得できる <code>app_id</code> を指定すればよいみたいだ。

<h5>watchコマンドラインオプション</h5>
さいしょ単純に <code>--watch</code> としか指定しなかったら、configの自動リロードなどが動作しないように思えた。 <code>--watch=config</code> などと具体的に指定しないとうごかないっぽい？

<h3>まとめ</h3>
とまぁ、よくわからない点はあったものの、ひとまず満足。Xremapにはほかにも興味深い機能がいろいろあるので、それらもそのうち見てみたい。

2025

2023

2021

2020

2019