数年ぶりに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はとても快適

もうだいぶ前の話になってしまうのだが、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>

2023

2021

2020

2019