左手デバイス、Linuxで設定してみた
マイナー左手デバイスの混乱した状況
左手デバイスには、わりと高価で付属ソフトもしっかりした製品がいくつかある。多くのクリエイターがそれを重宝しているようですし、最近になってmacOS対応になったと話題になったデバイスがあったりもしました。
たいして、マイナー左手デバイスは簡素で大幅に安価で、ちゃんと使えるのであれば、気軽に買えると考える人も多いはずです。
しかし、実際には数多ある廉価のマイナー左手デバイスには、ブランドネームや名称,型番などすらもあやふやなものがほとんどで、それがどういう製品であるか把握することも難しかったりします。
こういった問題の一因は、最大の購買者であるWindowsユーザーが、PCIやUSBのVender IDやPoroduct IDについて無頓着、もしくはそもそも知識を持っていないため、情報共有が成り立っていないためです。
結果的に、通販サイトなどで売られているマイナー左手デバイスは、売り手自体が商品を理解しておらず
「Windows Vista移行なら動くらしい」
「Linuxでも動くらしい」
「Macで動くのかはわからない」
みたいなあやふやな情報から、Vista,Linux対応みたいな表記で売っていたりするようです。
そういった混乱の中、大手のメジャーな左手デバイスでもLinux対応を謳うものは乏しく、謳いつつ設定ソフトの用意が無く、設定にはWindows環境が必須となっていたりするのが実情です。
左手デバイスの本質は、カスタマイズ可能で、特化されたHIDデバイスです。
ですから、カスタマイズが行われていれば、USB HIDクラスドライバーやBluetooth HIDプロファイルに対応しているOSであれば、それなりにつかえるわけです。
しかし、実際にはWindows環境が無ければ設定することができないのが普通で、たとえばChromebookだけ持っているキッズや、Windowsを見限ってWindows XP,Vista,7,8.1あるいは10を捨ててLinux系OSを選んだ人にしてみれば、いざ使ってみたいと思ってから、はしごを落とされた気分になった人もいるんじゃないかと思います。
Linuxで使える左手デバイス
前述したように、設定済みならOSの制限はほとんど無かったりします。
標準キーボード自体が違うmacOSでは勝手がかなり違うことになりますが、Linux系OSでは普通Windowsと同じIBM PC/ATの106keyや109keyを使いますし、ラズパイなどでもそれは変わりません。
しかし狭義にはLinux系OSだけでカスタマイズ作業もできるデバイスだけが、Linuxでも使える左手デバイスと言えるはずです。
その上で、高価なアイテムは試しに買うことができるのはWindowsやmacOSを使う人だけで、そういうの使わない人は手を出すことが困難です。
結果的に、気軽に試してみることができるのは安価なデバイスで、実際私が試しに買ってみたものは、USBのProduct IDなどでググれば容易に見つかるch57x-keyboard-toolで対処できるようです。
記事には対応可能な類似デバイスの情報も掲載されています。
ch57x-keyboard-toolが対応しているデバイスとはch57xが表す、CH573,CH571をコントローラーとして採用したデバイスということになります。
Windows界隈では、コントローラーチップに着目しない人が多いため、音が出ないという質問に対して「試しにRTLのドライバーを試してみよう」みたいなアドバイスをする人がいたりしますし、ネットワークデバイスでも似たような状況があったりします。
それは非常に不合理な考え方で、問題を起こしたり徒労に終わったりするはずです。
対してLinux系OSでは、もともとデバイスのメーカーがLinux対応ソフトを用意しないため、ユーザー側ではデバイスメーカーをあてにすることができません。
故に、採用されているコントローラーチップに着眼して情報を集めます。
そういう考え方をすると、パソコンや電子工作の周辺機器や部品に対しての解像度が高くなります。
ただ、ch57x-keyboard-toolが対応できるデバイスがどれかは、網羅的な情報源がありませんし、私が購入したものが対応していたのは、単に幸運のパターンだったのかもしれません。
実際のCH57xデバイスの利用
私が購入したものは↓これです。
見ての通り、ユニークな商品名や型番というものがありません。
メインPCで使っているOSはKubuntu 22.04LTSですが「たぶんイケる」という曖昧な情報で、ダメ元で購入しましたｗ
昨年は臨時収入があって、Wacom One 13とか3Dプリンターとか、ラズパイ4から5へのアップグレードなど盛大に散財して、それぞれから左手デバイスを入手し運用性を高めようかという機運が生まれました。
購入後、接続して最初に試したのは、Ubuntuのリポジトリーにもあるinput-remapperでしたが、これで露呈したのが、このデバイスは出荷時の状態で、すべてのキーに同じcのkeycodeが設定されているという現実でした。
xevでも確認しましたが、結局は汎用のキーカスタマイズソフトでは、手に負えないということがわかりました。
すべてのキーとダイヤルに、たった一つの同じ機能を割り当てることしかできません。
それでlsusbで確認し、Vender ID 1189,Product ID 8890
Acer Communications & Multimedia CH57xということがわかり
ぐぐってみるとch57x-keyboard-toolが見つかったわけです。
将来的には、それのGUIフロントエンドが作られれば、より手軽になるのでしょうが、現状では手作業でやるしか無いようです。
yaml書式の設定ファイルが公開されていますから、これをヒントに設定することになりますが、まとまった詳細な情報が揃っていないようで、試行錯誤することにもなるようです。
このソフトを導入することも、設定ファイルをリダイレクトで取り入れて、左手デバイス側に登録といった操作も、ググればすぐわかるものなので割愛します。
苦労したのは、書式の読解と実際の記述、それに他のカスタマイズとの干渉による問題回避などでした。
一旦中断して、甘いもの食べて再起し一日かかりました。
写真をこの向きで載せますが、これはch57x-keyboard-toolの設定ファイルが、この配置で記述するようになっているからです。
キーはCherryの特許が切れたため、雨後の筍のごとく広まった互換品のようです。赤軸風のもので、本体を落下したりするとバラバラになります。
キータッチが違うものに交換したり交換修理できる見込みがあります。
ゲームパッド的に連打する酷使にも適している可能性があります。
(耐久性がどうかは使ってみないとわかりませんが)
Cherryのものや互換品から、たぶんキートップの流用ができますし、3Dプリンターで自分でキートップを作る手もあると思っています。
この2x3にダイヤル1のタイプは、ch57x-keyboard-toolでは、設定ファイルで
rows: 2
columns: 3
knobs: 1
と指定するようになっています。
次いでlayers:の項目は、1つ目は番号なしで、複数のlayerを使う場合は2,3と続くようです。
(この機種は、側面のスイッチで三つのレイヤーに切り替えて使えます)
ROWSなどの数字は、設定ファイルの書式としての整合性のチェックが行われます。デバイスと設定ファイルの間の整合性のチェックは無いようで、注意が必要です。
食い違いによる意図しない挙動が起きるかもしれませんが、検証していません。
buttons:については、暫定的に
- [f5, f11]
- ["ctrl-z", PrintScreen]
- ["ctrl-v", "ctrl-c"]
と指定しています。
私は、利用時の設置向きは写真とは逆にしていますから、一番先にダイヤル(ノブ)があり、左上にコピー右上にペースト
左側真ん中にスクショ、右側真ん中にCTRL+Zとしています。
F5とF11は、普通常用する必要は無いんですが、ラズパイを艦これ専用端末として運用すると、普通のキーボードは繋いでおかなくても、スクショボタンは欲しいのと…
液晶モニターだけ電源を切った場合、全画面表示していたものが、ウィンドウ表示になるという挙動が出て、F11が必要になるため設定してみたものです。
それがあればラズパイのそれ以外の管理は、メインPCからsshなどを介してやれば良いと考えています。
最終的には、左手デバイスを2,3機用意して、複数の端末で専用化して運用するとなると、設定する機能も見直すことになると思います。
左手デバイスを設定した上で、OS側にinput-remapperなどでのカスタマイズを被せて、より複雑なカスタマイズを手軽に行える場合もあると思います。
(その場合、別端末に繋ぎ変えると、その分は使えなくなるわけですが)
ほかのカスタマイズとの干渉
設定に1日かかった原因は、OSに通常行なっているキーカスタマイズとの干渉で、意図した挙動が起きて、それで混乱したためです。
具体的に言うと、Kubuntuが採用しているKDE Plasmaには標準機能としてCTRLとCAPSLOCKを入れ替えるといった設定が可能ですが、それをやると左手デバイスにも影響が及ぶという挙動でした。
つまり入れ替えられたctrl+cが、capslock+cとして扱われてしまいます。
連打するとcCcCみたいになってしまいます。
だからといって、設定ファイルにcapslock+cと書いたらctrl+cとして扱われるかというと、そうなりませんでした。
修飾キーであるCTRLと、トグル動作するCAPSLOCKは左手デバイス側では等価に扱われないということなんだと思います。
それで、一旦KDE Plasmaでのキーカスタマイズをオフにして、左手デバイス側の設定を終わらせたんですが、その間の設定ファイルの書き換えなどにキーカスタマイズ無しでやるの…ちょっとしんどかったです(苦笑)
最終的に、KDE Plasmaの機能ではなく、Linux系の汎用のコマンドでsetxkbmap -device "devicenumber" -option ctrl:swapcapsといった書式で、対象デバイスを指定したswapcapsを行えば、左手デバイスへの設定との干渉が避けられました。
この辺の挙動は充分な検証を行なっていません。
KDE Plasma環境の設定機能での設定は、接続されていなかったデバイスにも影響するのに対して、setxkbmapによる設定は、発行時に接続されているデバイスだけに適用され、また対象の制限が可能で、かつ一旦外して繋ぎ直すと無効になっているという違いがあります。
ですからデバイス指定の手間をかけなくても、再接続で回避できるといえばできます。
混乱しやすいので、改めて書きますが
左手デバイスへのch57x-keyboard-toolでの設定は左手デバイスの中に記録されるのに対して
KDE Plasmaでの設定はOS環境自体に対して設定され
setxkbmapでは(デバイス指定を行えば)特定のキーボードだけに指定可能で、かつOS環境自体ではなく、発行時接続されているキーボードなどだけに限定され、また一旦OS環境から切り離されれば無効になるという違いがあります。
キーコードとキーシム関連の話を理解していれば、何が起きているのか理解できるんじゃないかという気もしますが、実は私はよくわかっていません。
xevとかで観測してみたりするとわかることもあると思います。
あと、ch57x-keyboard-toolでの設定を書き込んだ際、なぜかlayer 3に切り替わるという挙動があります。バグなんじゃないかと思っていますが、未確認ですし、開発元にも問い合わせていません。
ググればわかるかもしれませんが、現状やっていません。
設定さえできれば、対応する対象は広い
こういった製品は、IBM PC/ATのキーボード規格を背景としているため、対象はIBM PC/AT互換機で動くOSを前提としているようです。
ですからUSB 2.0が普及した時代のWindows Vista以降やXP以降という記述やLinux系OS対応といった記述が行われているようです。
厳密に言えばmacOSでも設定次第で使えるはずですし、PC/AT互換機でのLinux系OSで構築した設定をそのまま、MacでのLinux系OSに接続しても、設定が食い違って使い物にならなかったりするはずです。
しかし、そういったことを前提とせず商品紹介が行われているのが現実です。
逆に、IBM PC/AT用のキーボードの流用が大前提となっているRaspberry Piでも設定済みであれば、普通に使えます。
Android端末も、PC/ATそのままでは無いようですが、同じキーが使われる部分があるため、わりと普通に使えたりします。
前述の設定で、Androidタブレットにアダプターを介して繋いでみましたが
(当然そういう機能があるアプリ上で)コピペ,スクショ,CTRL+Zが普通に機能しましたし、上記に紹介していない別layerでのボリューム操作設定も機能しました。
Chromebookなどでも使えるだろうと思います。
特に、ラズパイでの工作では、専用ボタンを用意して、独自スクリプトで操作することがよくありますが、そういうスクリプトを作るスキルが無くても、比較的手軽にラズパイ用に小さい物理スイッチを用意できるという利点があります。
私も、Z80のハンドアセンブルまで行って、プログラマーにはなれないと思ったので、こういうので済ませたいと長らく思っていました。
極論すれば、キースイッチ部分を延長して、平面的なキーボード然とした配置を、立体的な手ににじむ配置に改めることもできる気がしますし、簡易な工作の幅が広がると思います。
配線延長分の不安定やノイズ問題が起きないとは限りませんが…
ぼく機械科卒だから、電気,電子もプログラミングもよくわかんないんだよね…