マルチディスプレイ環境での液晶タブの調整

 デスクトップのDebianをStretchに上げたら、Xの液晶タブの設定がおかしくなったという。原因は単純だったけど、設定方法を備忘のためメモ。

 私の環境は同じ大きさのディスプレイをDVIポートとアナログVGAにそれぞれつないでいて、上下に並べてる。xrandr的には、こんな感じ。

% xrandr --output DVI-0 --below VGA-0

ここで、DVI-0はWacom DTU710(液晶タブレット)で、VGA-0はMITSUBISHI RDT173LM。液晶タブレットが下。ディスプレイの名前はOSやドライバーにより異なるので、引数なしでxrandrを実行して確認。

 このような場合で、DTU710の画面とスタイラスの座標を合わせるのは、今はxinput。3×3の変換行列で座標系を割り当て。かつてはxorg.confとかhalで??-wacom.confをいじくっていました。

% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1 0 0 0 0.5 0.5 0 0 1

 ここで「Wacom DTU710 Pen stylus」はXに認識されているデバイス名(スタイラスとか消しゴムとか)。名前は引数なしでxinputを実行すると出てきます。結論から言うと、Xのバージョンが上がった際にこの名前が「Wacom DTU710 stylus」から「Wacom DTU710 Pen stylus」に変更されたために、動かなくなったということでした。

 ちなみに元に戻す場合は、以下の通り。

% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1

 さて、この手のフロート型のポインティングデバイスでは、座標があっていればそれに越したことはないものの、大抵ズレているので座標合わせが必要となります。こういう場合は、xinput_calibratorで座標のズレがどれくらいか測定します。

 まずは両方の画面を同じ表示にして、一旦元に戻します。

% xrandr --output DVI-0 --same-as VGA-0
% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1

その後にxinput_calibrator。

% xinput_calibrator --output-type xorg.conf.d

Warning: multiple calibratable devices found, calibrating last one (Wacom DTU710 Pen eraser)
         use --device to select another one.
Calibrating standard Xorg driver "Wacom DTU710 Pen eraser"
        current calibration values: min_x=0, max_x=34080 and min_y=0, max_y=27660
        If these values are estimated wrong, either supply it manually with the --precalib option, or run the 'get_precalib.sh' script to automatically get it (through HAL).
        --> Making the calibration permanent <--
  copy the snippet below into '/etc/X11/xorg.conf.d/99-calibration.conf' (/usr/share/X11/xorg.conf.d/ in some distro's)
Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "!!Name_Of_TouchScreen!!"
        Option  "MinX"  "20"
        Option  "MaxX"  "33687"
        Option  "MinY"  "221"
        Option  "MaxY"  "27196"
        Option  "SwapXY"        "0" # unless it was already set to 1
        Option  "InvertX"       "0"  # unless it was already set
        Option  "InvertY"       "0"  # unless it was already set
EndSection

Change '!!Name_Of_TouchScreen!!' to your device's name in the config above.

 xinput_calibratorの出力形式にはxinputもあるのですが、私の環境ではうまく動かないので、xorg.conf.d形式で出力しています。

 ここで重要なのは、

current calibration values: min_x=0, max_x=34080 and min_y=0, max_y=27660

        Option  "MinX"  "20"
        Option  "MaxX"  "33687"
        Option  "MinY"  "221"
        Option  "MaxY"  "27196"

の部分。この値を元に変換行列を作成します。

x_1=(max_x-min_x)/(MaxX-MinX)=1.0122672052752
x_2=0
x_3=MinX/MaxX=0.00059370083415
y_1=0
y_2=0.5*(max_y-min_y)/(MaxY-MinY)=0.512696941612604
y_3=0.5*(1-MinY)/MaxY=0.49593690248566
z_1=0
z_2=0
z_3=1

 この値をxinputの引数にして、テスト。x_1とy_2の値が幅と高さ、x_3とy_3の値が原点(左上)からのオフセット量になります。で調整するとこんな感じ。

% xinput set-prop "Wacom DTU710 Pen stylus" --type=float "Coordinate Transformation Matrix" 1.011 0 0.0006 0 0.513 0.495 0 0 1
% xinput set-prop "Wacom DTU710 Pen eraser" --type=float "Coordinate Transformation Matrix" 1.011 0 0.0006 0 0.513 0.495 0 0 1

Debian Stretchと日本語入力

Debian Stretchがリリースされたので、まずはVAIO Pを更新。さすがにデスクトップは一部変なハードがあるので、後から。

 ……思ったよりすんなり入りました。外部リポジトリーが入っていないせいか。

 まあ、ソフトウェア構成としても、

くらいなので、変なものはそうないわけで。GNUstep環境という時点で標準からは外れますけど、慣れだし。

 各種IMのJISキーボード環境での親指シフト(nicola)環境は相変わらず。

  • scim/ibus/fcitx-anthy: 問題なし。
  • ibus/fcitx-skk: 以前書いたとおり。「fj(変換開始)」「a(=う)」「s+親指右(=じ)」「d+親指左(=な)」→まず「▽う」が表示された後「▽じ」、「▽な」と表示され、変換バッファに複数の仮名が入らない。正しい動きなら「▽うじな」。
  • ibus-kkc: 「fj」を抜いて上と同じ入力をすると、「aう」が表示されたあと、「as雨」(変換キーが親指右でなく変換キーとして働いているらしく「う」が変換されて「雨」になったり、「asうし」になったりする)、「as雨dな」となる。叩いているキーとかなが両方入力される上に、ibus-skkibus-anthyで働いていた変換キーの親指右が働かない。
  • fcitx-kkc: ibus-kkcにほぼ同じ。
  • mozc: oyainput使用のこと。

ibus/fcitx-skkibus/fcitx-kkcは同じロジックを遣っているので、同じような動きをしています。どこに投げたらよいのやら。

 まあ、この機械自体、文字入力はほとんどEmacsとddskk+skk-nicolaだけで完結しているけれど、Firefoxなどでibus/fcitx-skkskk-nicola感覚で入力しようとすると、本当に困ってしまうわけで。現在実用なのはscim/ibus/fcitx-anthyしかない、というのはどうにかなりませんかね。

辞書形式の話。

 電子辞書(ICじゃなくてCD-ROMとかで供給される方)について、書いてみる。

 日本語環境において辞書ソフトウェアはMacを除いてあまり普及していないのが現状。Macの辞書.appはNeXTからの伝統ですな。一応EPWING/JIS X 4081という規格があることはあるけれど、字種がJIS X 0208(技術的に言えばJIS X 0213の第1面)の枠内だけという欠点があって、日本語(の一部)と、英語くらいしかまともに扱えない。

 外字地獄とか何らかの代用表記を我慢すればそれ以外もできないことはないけれど、外字の文字数が94×94×2(half/wide width)しかないので、私の扱う言語、具体的には中国語(繁体字簡体字)、広東語(繁体字)の世界だとGB 2312は何とかなるとしても、CNS 16443やBig5には文字が足りない。まあ、小学館日中・中日辞典のように、JIS X 0208にある字種以外を外字にするやり方ならBig5は何とか入るけど、CNS 16443は合計8面もあるのでどうしようもないわけで。ましてやUnicodeのCJKV統合漢字なんぞ無理。

 しっかし、外字地獄なんて遣う側からはやってられないのですわ。

 そもそも外字をUnicodeに変換する機能があるソフトウェアなんてEBWin/EBMac/EBPocketとかEmacs+Lookupくらいでして、遣う側も面倒、辞書を作る・変換する側も大変という。

 じゃあ、EPWING/JIS X 4081をUnicode化すれば良いというかも知れないけれど、確かに

というものが存在しているものの、ONESWINGはメーカー囲い込み、FreeUWingは公開されている辞書が存在せず、かつEmacs+Lookupでしか扱えない。

 これ以外で、データを作成できる辞書形式となると、

  • PDICU
  • StarDictとXDXF
  • MDict
  • LeXML

といったものがあるけれど、PDICUは実質Windows用でテキストデータのみ(Wineで頑張る?)、StarDictはテキストデータのみ、MDictは画像や音声データも扱えるけれど、日本語圏では作成方法が知られていない、LeXMLは中間形式という問題があるわけで。

 独自形式でない、汎用な辞書形式が欲しい。……Macの辞書.app形式? いやはや。

市販Nicola(親指シフト)キーボード

 市販されている・いた専用のNicolaキーボードとしては、いずれもPS/2接続で、

  • FMV-KB211
  • FMV-KB611 / OAKB-193 / FMVTW-KBS / FMV-KB613
  • FMV-KB661
  • Rboard

があります(とりあえずFMR/FM-TOWNS/OASYS/FACOMとか、かつてのSONY NEWSとかは考えない)。これらは後述する106キーボードNicolaの刻印をしたものと異なり、内部的にキーコードを変換する機能を持っています。ただ、FMV-KB611/613/661は特殊で、611モードと211モードの両方を持っています。

 これらをBSD/Linuxで使用する場合、(FMV-KB611/613/331ではFMV-KB211モードにして、)JIS仮名入力できるIMでモードずれを手動で修正しながら入力することになります。

 一方、JISキーボードにNicolaを刻印したキーボードは意外とあり、

  • FMV-KB231
  • FMV-KB232
  • FKB-8579USB
  • FKB-7628-801 (Thumb Touch)
  • ライフラボ社製親指シフト表記付きUSBライトタッチキーボード
  • FMVのノートPCのNicolaモデル

などがあります。これらは内部的には106/109キーボードですので、通常のJISキーボードと同様に、BSD/Linuxだとキーボードエミュレーション機能付きのIM(例えばscim/ibus/fcitx-anthyなど)やキーボードエミュレーター(oyainput、かつてはQ's Nicolatter for X)、Emacs内限定でskk-nicolaを使うことになります。

 FMV-KB231なんて見た目FMV-KB211とそっくりですが、親指シフトキーを押しても変換や無変換キーのコードが出力されます……。

BSD/LinuxにおけるNicola(親指シフト)入力の現状

 私はNicola親指シフト)入力なのでそのつもりで。

 PC-UNIX環境でNicola入力する場合、以下の方法があります。

a. JISキーボード(後述のThumb Touchなども同様): キーボードエミュレーション機能付きのIM(例えばscim/ibus/fcitx-anthyなど)やキーボードエミュレーター(oyainput、かつてはQ's Nicolatter for X)、Emacs内限定でskk-nicolaを使う
b. FMV-KB211系: IMをJIS仮名入力に設定して、手動でモードずれを直して使う
c. FMV-KB611/613/661系: FMV-KB211と同様にする(Windowsであれば専用モードを扱えるのだけど)

 まず、普通はPS/2接続のNicolaキーボードなんて持ってないでしょうから、a.となるでしょうか。

 私はa.とb.の両方です。デスクトップではFMV-KB211をuim-anthyで使っていますし、ノートではscim-anthyEmacs上でskk-nicolaを使用しています。多言語環境が必要だと、Emacsで暮らす時間が長くなる……(でもFMV-KB211でEmacsを使うとそれはそれで厄介)。

 ちなみに、libkkc系だとfcitx-kkcとibus-kkc、libskk系だとscim-skkとfcity-skkibus-skkNicola機能が付いていますが、現状まともに動きません。scim-anthyibus-anthy、fcitx-anthyを使いましょう(ただ、Debian Jessieのi386版でscimを使用すると、WindowMakerの右クリックメニューが動かなくなる)。

ibus-skkの例: 「f+j(変換開始)」「a(=う)」「s+親指右(=じ)」「d+親指左(=な)」→まず「▽う」が表示されたあと「▽じ」、「▽な」と表示され、変換バッファに複数の仮名が入らない。

理想的な環境

 自分にとって必要な環境は

といったことだろうか。まあ、wmakerとかGNUstepはNeXT(というかOPENSTEP for Mach、私はUNIXはこっちから入った)の名残みたいなものであるし、親指シフトFM-TOWNSをつかっていたから。

 こいつらを全部成り立たせようとすると大変で、実質的にはFreeBSDかDragonflyBSD、NetBSDLinux(私の場合はDebian)になってしまう。

  • FreeBSDはほぼほぼ満足といえ、usb4bsdのおかげでWACOMタブレットがつかえなくなってしまった。後、古い機械でACPIまわりでPANICになるのと、インストーラーCDを途中で認識しなくなる類のバグはなんとかしてほしい。IPX/SPXサポートの中止のときもひどいことになったり……。
  • DragonflyBSDはFreeBSDと同様。しかしi386で動かないのが辛い。
  • OpenBSDは国際化まわりが劣る。一例を挙げると、GNUstepの国際化機能が働かない。後はPackageが少なく、EBViewとか、日本語IMとか。
  • NetBSDは良いのだけど、pkgsrcの整備状況か。pkgsrcは良い仕組みといえ、バイナリーパッケージが整備されていない。皆pkgsrcしているの?
  • Debianは一度環境を作ってしまえば楽で、パッケージも充実している。とはいえ、私自身BSDの方が好き・しっくり来るので、こいつでないと動かない機種(例: VAIO P)とか周辺機器(例: 液晶タブレット)、ソフトウェア(例: mars_nwe)という事情がないと入れない。

 正直、FreeBSDがまともならそれに越したことはないのですが……。Darwin? 人柱確定だし、そんなの入れるくらいならMacOSにしますって。