Ryzen 5 2400Gでの環境構築

Debian ハードウェア

　相当放置していた環境構築について、ケースを買ったことからようやく重い腰を上げる。

　まず、不本意なことにOSがUbuntu 18.04LTE。後述するドライバーまわりの都合でLinuxのカーネルバージョン4.15以上かつメジャーなディストリビューションとなってしまうため。

　ちなみにハードウェア構成はこんな感じ。

  • APU: AMD Ryzen 5 2400G
  • RAM: 32GB
  • M/B: ASRock AB350 Pro4
  • HDD: SAMSUNG HD204UI（転がっていたのを流用。かなり古い）
  • Optical: HL-DT-ST DVDRAM GH20NS10（上に同じ）
  • Tuner: PLEX PX-Q3U4
  • 接触式ICカードリーダー

　結論から言うと地雷だらけ。もうちょっと枯れたハードを遣いましょう。（追記）おまけにメモリーが一枚ぶっ壊れてた。いやはや。

インストール

まず、起動に一苦労

　まず、内蔵DVDドライブから起動させようとするも、つなぐポートがASRockで追加したSATAポートだったので起動せず。

　付け替えるのも面倒なので外付けDVDドライブから起動させてみるも、途中で止まる。

画面がまともに映らず

　今度はUSBメモリーにUbuntu日本語remixを入れて起動するも……画面の1/4程度しか映らず。構わずインストールを続けるも、途中でカーネルイメージのバージョンが違うと宣い止まる。

　本家のイメージにして起動するも、インストーラーの途中で刺さる。調べると、同じところのよう……。

別機体・エミュレーターでインストール

　仕方ないので、別機体にUSB経由で接続して、VirtualBoxの中でインストールする。物理HDDを認識させるため、

# VBoxManage internalcommands createrawvmdk -filename sdg.vmdk -rawdisk /dev/sdg

という具合にVMDKファイルを作成してSATA1にしておき、光学ドライブにUbuntu本家のインストールイメージを指定してインストールする。

表示問題

　先にBIOSのアップデートをかける。SSDは遣わない構成だけど、気休め。

　実機にHDDを移して起動させる。今度は画面がまともに映った……と思いきや、今度は画面の左右端が映り、真ん中が間延び。まともに映るときとそうでないときがあり、まともに映らないことの方が多い。

　仕方ないので、プロプライエタリーなドライバーを導入。方法は下記を参照した。

gihyo.jp

　相変わらず同じところで刺さって、ソフトウェア的に再起動やシャットダウンができない状態なものの、まあまあ動く状態にはなった。

　あと、GNOMEなんて遣ってられないのでWindowMaker+WDM、GNUStepにする。これでほぼDebianと同様の環境になった。

PX-Q3U4ドライバー導入

　最近、公式ドライバーが公開されたことから、それを導入してみるも、vermagicで撥ねられる。こいつはバイナリーを編集して何とかした。

　非公式ドライバーはPX-Q3PE4まで対応が進んでいるみたいだけど、PX-Q3U4はまだ（追記: ハード的に同じだからいけた）。待ちですな。

github.com

BDAVの作り方

動画関係 Debian FreeBSD

　地球の裏側から弾丸で行って帰ってきてクラクラしていたり。

　最近ようやくFreeBSD/LinuxでBDAVを焼けるようになったのでメモ。といいつつも、まあ、DLNA経由でPS3なりBDP-150から鑑賞できるのだけど。しかもほとんどwine上での作業。何というべきか。

　wineでの作業になったのは、

  1. chotBDAV
  2. ImgBurn

といったツールがWindows用のため。前者はBDAV化するのに必要、後者はUDF 2.5/2.6のディスクイメージ作成に必要。今のところDebianだとUDF 2.5/2.6の作成ができず、一方でプレーヤーの中にはUDFバージョンを決め打ちしている代物もあるので、ImgBurnでイメージを作成してgrowisofsで書き込む。

　それ以外のバケットサイズの変更（BD2FWなど）くらいならFreeBSD/Linuxでもできるし、タイトルを変更しないならrplsTOOLSとかも遣わずとも良いものの、まあ手抜き・不便極まりないのでやはりwineから動かす。

　動作はPS3で確認。

XPSの表示・変換。

PDF

　今や廃れた感のあるMicrosoftのXPS。今のWindows 10には標準でPDF仮想プリンターがついているので遣う機会が少なくなってきているものの、Windows 7だと標準でPDFを作れないので、PDF代わりとなっていることがある。

　PSファイルで配布？　WindowsではAcrobatだのGhostscriptなどのソフトウェアRIPなんて入っていることがそもそも珍しい（せいぜい仕事の都合でとかTeXしているとか）し、今時PSプリンターなんて組版屋くらいしか持っていない。

　閑話休題。

　BSD（Mac含む）とかLinuxとかでは、XPSなんて渡されても扱いに困ってしまうわけだけど、MuPDFはXPSに対応していたりする。mupdfをライブラリーとして遣っているソフトウェアでも同様に表示できる。

% mupdf in.xps

　また、mutoolの1.10以降を遣えばPDFに変換することもできる。

% mutool convert -F pdf -o output.pdf input.xps

　ただしDebian 9だと1.9なので、libgxps-utilsの中のxpstopdfを用いる。

# apt-get install libgxps-utils
% xpstopdf input.xps output.pdf

　この手のファイルで表示できなくて困るファイル形式は、あとはMDIくらいだけど、WindowsのMODIで開くかサードバーティーの市販ソフトくらいしか方法がない。

仕方ないのでiBus化。

Debian 日本語入力 広東語入力

　我が携帯用VAIO P(Debian 9 Stretch, i386)は主にEmacsとAtril（PDFリーダー）くらいしか動いていない。Emacsの中でskk-nicolaで暮らしているので、XIMとかIMMODULEの必要は薄いものの、まれにEmacs以外のアプリケーションでの入力が必要になるので、IMにSCIM、変換エンジンとしてAnthyを入れている（以前書いた通り、FMV-KB211の場合はuimが扱いやすく、thumb-touchのような刻印だけ親指シフトなキーボードだとSCIM+scim-anthyのようなエミュレーションできるIMとエンジンの方が扱いやすい）。

　近頃は変換エンジンはmozcとかlibkkcとかが流行っているものの、親指シフトの対応の関係から変換エンジンにはAnthyを使用している。変換効率は良くないものの、まあ、いつもskkなので、比較してはいけない。

　一方で、私は広東語（粤語）話者でもあるので、中文の入力というのも必要だったりする。

　SCIMは特に広東語で入力しようとすると、文字テーブル、要は単漢字変換しかない。昔ながらの漢字部品入力とか北方方言な拼音、注音ならエンジンがあるので効率良く入力できるものの、はっきり言って覚えるのが大変。（香港では従来は漢字部品による入力、具体的には倉頡が一般的だったものの、最近は粤拼(Jyutping)が普及してきている）

　ということで、広東語、粤拼(Jyutping)で連文節入力するためにRIMEを導入。ちなみにWindowsでもこのソフトが動くので、CPIMEのほぼ単漢字入力っぷりに辟易している人やAndroidでのGoogle Cantonese Inputのような快適さを求めるならおすすめ。

　まず、最近流行りのfcitx。日本語の方はAnthy。

# apt-get install fcitx-rime librime-data-jyutping fcitx-anthy

　この上で~/.config/fcitx/rime/default.custom.yamlを作成する。

patch:
  schema_list:
    - schema: jyutping

　im-configでIMを切り替えてからログインし直し、fcitx-config-gtkなりで設定……すぐ落ちる。

　仕方ないのでiBusにする。この時点でlibrime-data-jyutpingは入っているので省略。

# apt-get install ibus-rime ibus-anthy

　fcitx-rimeと同様に~/.config/ibus/rime/default.custom.yamlを作成する。

patch:
  schema_list:
    - schema: jyutping

　同じようにIMの切り替えとibus-setupで変換エンジンにAnthyとRIMEを追加。今度は落ちづらくなりましたとさ。

　……iBusは大嫌いですけど、まあ、仕方なし。

Ryzen 5 2400Gに更新。

Debian ハードウェア

　PCの中身を組み替えて電源を入れたら、しゅ〜んと音がして動かなくなってしまったという。電源から香ばしい香りがしていたので、電源がダメになってしまったらしい。

　この機械は2012年くらい（だったと思う）から遣ってきたので、併せてAPUとマザーボードを更新。いままでがA8だったのがRyzen 5 2400Gに更新、メモリーは16 GBから32 GBに倍増。

　……しかしDebian上で内臓グラフィックスの認識がうまくいっていないですなぁ。DVI-Dに映像が出ない。

zfsをマウントできず仮想機械で読み込む

FreeBSD Debian

　FreeBSDで使用していたHDDからデータを移すために、仮想機械を遣うハメになったという。

　Linuxの今のカーネルはFUSEで読み書きする方法があり、それで読もうとしたところ、zfsのバージョン違いで読めず。 さすがにバージョンを落とすわけにも行かず、幸いzrootなディスクだったので仮想機械からブート……今度はmountrootで止まる。

　結局、インストールCDを遣ってLive CDから読み込み、ただいまmount_smbfs経由でサーバーにコピーしてるとさ。

BDXLドライブを購入。

ハードウェア

　今までジャンクのスリムBDドライブを BufferloのDVSM-PCS58U2の中身と交換して遣っていたけれど、DVDドライブとしてしか認識されず。……いや、ついこの間までBD-REなりを焼こうとしなかったので。

　ごく最近録画をするようになったので、バックアップが必要になり、BD-REを買って試したらあれ？　となってしまったという。

　……そういや、CD-RWがまだ大量にあるけど、どうしますかね？　まあ、CD-RとDVD-Rだったらまだ配布用途があるし、DVD-RWはデータやりとりでまだ需要がある。でもCD-RWはCD-Rで毎回焼くと無駄になるインストールメディア用くらいかなと……。

　仕方ないので、BaffaloのBRXL-PT6U2V-BKDを購入。人によっては再生ソフト付きだろうけど、BSDとLinuxな上に外部ディスプレイはRGBとDVIだったりする。そもそもBDMV再生ならBDプレーヤーがあるし。一応、BDXL対応だけど、私の使用メディアは二層まで。

　ということでxfburnとかK3Bで焼いてみたものの、手元のBDP-150ではUnknown disk扱い……何故？

32 bitアプリを入れていた

Debian

　Debianは一度環境を整えてしまえば、後は非常に安定する。例えば、WindowMaker環境をUbuntuなどで構築・維持するというのは非常に苦労するわけで、あの手のディストリビューションはお仕着せの環境を遣うものだ、と思うべきだろう。ただ、DebianとかFreeBSDは環境を整えるまでが少々手間なわけで、何を遣いたいか明確な人以外にはお勧めできないものになってしまっている。

　Debianにおいては、Ubuntuなどと違ってマルチメディア関係のソフトウェアに様々な制限がある。一番大きいのはライセンスや、取り込まれているバージョンが古いことなどがあげられる。そのためDebian Multimediaなどをaptのsource.listに入れたりすることが多い。

　環境整えるまでの間のトラブルとしては、i386を入れてしまったとか、余計なドライバーが邪魔をしたとかがある。

　つい先週この手のことにハマってしまったので、メモしておく。

症例1 tsMuxerGUIの場合

普通にDebian Multimediaからapt-getで導入した。

% tsMuxerGUI
tsMuxerGUI: error while loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory

ん？　libQtGuiが見つからない？　libqtgui4は入っているから、ライブラリのパスの問題と思い、通してみる。

% set LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
% tsMuxerGUI
tsMuxerGUI: error while loading shared libraries: libQtGui.so.4: wrong ELF class: ELFCLASS64

ELFのクラスが違う？　……もしかしてamd64じゃない？　と調べると導入されていたのがi386版でamd64版がないという。そこで

# apt-get install libqtgui4:i386
% tsMuxerGUI

としたら時間がかかったものの、動作しましたとさ。

症例2 OpenGLの場合

Debian MultimediaからShotcutを導入して動かそうとしたところ、キャプチャーボードのドライバーないのと、OpenGLが有効にならない旨のメッセージが出て止まる。

キャプチャーボードについては最新のソフトウェアを導入して解決も、OpenGLについては、GLXがどうこうというメッセージ。

……AMD A8なのにnVIDIAのドライバーとかが入ってて悪さしてた。関係するパッケージをことごとく削除しましたとさ。

FSViewerのバッチ当て

GNUstep

　WindowMaker環境でのファイルマネージャーはGNUstepとの親和性から、GWorkspaceが一般に用いられている。

　従来はFSViewerが広く用いられてきたものの、現在のDebianのパッケージからは外されている。まあ、Debian Archive (https://mirrors.mediatemple.net/debian-archive/debian/pool/main/f/fsviewer/)から拾ってきて、インストールすればいいけれど、最終版の一つ前(0.2.5)だったりする。

　ということで（？）　ソースコードからビルドしてみる。

　まずはSlackBuildsからfsviewer-app-0.2.6.tar.bz2とfsviewer.tar.gzを拾ってくる。 slackbuilds.org このうちfsviewer.tar.gzはSlackBuildのファイルだけれども、この中のtitlebar.diffとwingsfix.diffが重要で、前者はFSViewerでタイトルバーが表示されない問題を解決するためのパッチ。

　こいつらを遣ってconfigureとmakeしてみる。

GTK3アプリでのスクロールバー問題

Debian FreeBSD GNUstep

　私の環境はWindowMaker+GNUstepである。要はNeXTライク。

　となるとその他のアプリケーションでも似た外観にしたいというのが人情である。

　まずはGTKということでテーマを探してみると、OneStepBackとGTK-GNUstepというテーマが見つけることができた。

www.gnome-look.org

www.gnome-look.org

　しかし、GTK-GNUstepはGTK2用なので、まずはOneStepBackをつかってみることにした。

　テーマの追加方法？　Debianの場合はこいつらを解凍して/usr/share/themesに、FreeBSDなら/usr/local/share/themesに置けば良い。

　テーマの切り替えは設定ファイルを書き換える方法だと、

  • GTK2は~/.gtkrc-2.0
  • GTK3は~/.config/gtk-3.0/settings.ini

のgtk-theme-nameの行を編集すれば良い。GUIでやりたいのならlxappearanceを遣うと楽である。最終的にはGTK2はGTK-GNUstep、GTK3はOneStepBack、そしてアイコンテーマをGNUstep Iconにした。

www.gnome-look.org

　……スクロールバーに反映されない。と思ったら、テーマのディレクトリーのアクセス権(OneStepBack/gtk-3.0)だった。しっかし動きが変なのも確かなので、いろいろいじってみる。

スクロールバーの移動を画面単位にする

　NeXTだとスクロールバーの場所をクリックするとその場所に移動するので、私には違和感がないものの、Windowsとかに慣れている人は一画面単位のスクロールの方が使い勝手が良いらしい。この場合は~/.config/gtk-3.0/settings.iniの[Settings]の中に以下を追加する。

[Settings]
gtk-primary-button-warps-slider = false

GTK3のスクロールバーのオーバーレイ表示を止める

　~/.profileに環境変数を設定する。

export GTK_OVERLAY_SCROLLING=0

　~/.config/gtk-3.0/gtk.cssに次を追加する。

.undershoot.top, .undershoot.right, .undershoot.bottom, .undershoot.left { background-image: none; }

スクロールバーの矢印を表示する

　矢印のあるテーマを使用していれば問題ない。標準で矢印がないテーマについては~/.config/gtk-3.0/gtk.cssに次を追加する。

.scrollbar {
    -GtkScrollbar-has-backward-stepper: 1;
    -GtkScrollbar-has-forward-stepper: 1;
}

　GTK2だと~/.gtkrc-2.0に次のような感じになる。

GtkScrollbar ::has-backward-stepper=1
GtkScrollbar ::has-forward-stepper=1

GNUStepを日本語化する方法

GNUstep 日本語入力

　私のUNIXはNeXT（正確に言えばOPENSTEP for Mach）が最初だった関係で、Workspaceの操作性に慣れていることから、UNIX系OSではWindowMaker+GNUStepという環境を構築している。

　GNUStepの国際化はだいぶ進んできており、日本語フォントを指定すれば日本語を表示もできるし、XIM経由で入力もできる。

　ただ、ロケールを日本にしても、リソースがないのでメニューやらメッセージが日本語にならない。私の知る限り、日本語のリソースが最初から用意されているのは、Jishyo.appくらいである。 （ちなみにOpenBSDだとリソースを用意しても、ロケールが切り替わらないという問題がある。全体的にOpenBSDの国際化はFreeBSDやNetBSD、Linuxに比べて劣っている。）

　こうなると、自分でリソースを作成することになる。

　GNUStepの用意している国際化方法はUNIX向けソフトウェアで広く用いられるgettextと異なり、次の三つの方法がある。

  • Resource/Japanese.lproj/Localizable.stringsを作成する。
  • Resource/Japanese.lproj/*.nibを作成する。
  • Resource/Japanese.lproj/*.gormを作成する。

　最初の二つはNeXTから引き継いだ方法で、最後のgormの書き換えはGNUstep特有の方法である。nibやgormの場合はIBやGORMで直接書き換えることになる。ただ、nibやgormにメッセージをべた書きするのは推奨されておらず、行儀が悪いプログラムとされる。そのため、一般にLocalizable.stringsだけでローカライズできるように設計することが求められる。

　つい先日、GNUMail向けにLocalizabsle.stringsを作成した（http://savannah.nongnu.org/support/?109386）ので紹介する。

　まず、ソースコードからLocalizabsle.stringsの元を作成する。ソースコード（*.m）があるディレクトリーにて、次のコマンドを実行する。

% make_strings -L English *.m

　ここでできたLocalizabsle.stringsの書式は、

"Yes" = "Yes";

というように左に元のメッセージ、右にローカライズしたメッセージを書く形となっている。したがって、メッセージを日本語にするには、

"Yes" = "はい";

というように書き換えればよい。これをアプリケーションのResource/Japanese.lproj/の中に置けば、日本語化することができる。

PDFの煮るなり焼くなりのメモ

PDF

　処理別でPDFの扱い方を備忘としてまとめてみた。対象はQPDFとかPDFTK、MuPDF-tools、Poppler-utils、Ghostscript、libtiff-toolsといったものが入っている環境か。シェル環境があると便利なので*BSD/LinuxやWindowsでもCygwin、MinGWといったものを入れていると良い。

暗号化解除

% qpdf --decrypt in.pdf out.pdf

　暗号化解除といっても、読み込みパスワードがかかっていない場合は制限していないのと同じでこれだけで何でもできるようになる。

PDFバージョン変更

% qpdf --force-version=1.4 in.pdf out.pdf

　フリーソフトにおいては、PDFバージョンが1.4（Acrobat 5）以前にしか対応していないものがある。強制的にバージョンを1.4にすることで読み込みができるようになることが多い。

結合

% pdftk in1.pdf in2.pdf output out.pdf

Javascript除去

　簡単に挙げられる方法としては、三個。

　もし、iTextに親しんでいるなら、スクリプトを書く方法もある。なお、PDFJavascriptRemoverというiText関係のソフトがあるものの、扱い方がわからず。

テキストの抽出

　もしPDFがLibreOfficeとか各種DTPソフトで作成されたものであるとか、OCRがかかっていて透明化テキストがついているとかであれば、Poppler-utilsで抽出できる。OCRが必要な場合はここでは対象外。

% pdftotext -enc UTF-8 in.pdf

画像の抽出

　一括して抽出する場合はMuPDFのツール利用が簡単である。

% mutool extract input.pdf

もう一つは、Poppler-toolsのpdfimagesで

% pdfimages -png in.pdf out // PNGで抽出する場合
% pdfimages -j in.pdf out // JPEGで抽出する場合
% pdfimages -tiff in.pdf out // TIFFで抽出する場合

で抽出できる。pdfimagesの標準はpbm形式なので、上記のように標準的な形式で抽出するか、ImageMagickで変換すると扱い易くなる。

画像のPDF化

　ImageMagickとpdftkを併用する、マルチページTIFFを作成してPDFに変換するといった各種の方法がある。

　元のデータが200 ppiの反転した白黒のpbmをImageMagickとpdftkで変換する場合はこんな感じ。

% mogrify -units PixelsPerInch -density 200x200 -negative -format pdf in*.pbm
% pdftk in1.pdf in2.pdf output out.pdf

　ImageMagick自体はマルチページの画像PDFを扱うことができるので、

% convert -units PixelsPerInch -density 200x200 -negative -format pdf in*.pbm out.pdf

で変換することもできるが、恐ろしくメモリーを消費するので推奨しない。

　元データがTIFF（昔スキャンしたヤツとか）でマルチページTIFF経由でPDFに変換する場合は、libtiff-toolsを入れて

% tiffcp in1.tif in2.tif tmp.tif
% tiff2pdf tmp.tif -o out.pdf

という具合で良い。なお、このケースだと圧縮をかけていないので、モノクロならtiffcpで-c g4や-c g3とか、カラーならtiff2pdfのところで-jオプションをつける。

フォントの抽出

　PDFではフォントを埋め込んでいることがあり、MuPDFやFontForge、PDF FontDecorder (http://papy.world.coocan.jp/p5.html#s3)には抽出機能がある。

　一括して抽出する場合は画像抽出の時と同じオプションで、画像もフォントも一緒にできる。

% mutool extract input.pdf

漢字の字書的データの在処

辞書 日本語入力

　漢字の読みのデータを簡単にまとめてみた。まずはテキストデータとして入手できるものを記載。

Public domain相当なもの

Unihan database (http://www.unicode.org/Public/UCD/latest/ucd/Unihan.zip)

　Unicode consortiumによるCJKV統合漢字のための基礎データで読みや字義、画数、部首、各国の文字コードとの対応表、大型辞書への索引、使用頻度、四角号碼、倉頡輸入法といった情報を含んでいる。

　読みデータとしては、中国語後期中古音（唐代音、Tang）と中国語北方語（Mandarin）、粤語（Cantonese）、日本語（音訓別）、朝鮮語（Korean）、ベトナム語（Vietnamese）。ただし精度は低く日本語においては間違いが結構ある（日本語の間違いについてどなたかまとめていませんかね？）。

　粤語においては、現在は粤拼（JyutPing、あるいはLSHK方式、香港語言学学会拼音方案とも）表記で、Unicode 4.0.1までは改Yale式表記、Unicode 4.1から5.1までがLSHKのPhrase Boxによる粤拼（フリーでなかった）、Unicode 5.2以降は粤拼でpublic domain相当となっている。

JIS X 0208:1997附属書6と7、11、JIS X 0213:2000附属書6と11

　これらのJISは著作権保護の対象外。JIS X 0213:2000の附属書11の音訓索引については、JISX0213 InfoCenter (http://www.jca.apc.org/~earthian/aozora/0213.html)よりテキストデータを入手できる。SKKのJIS X 0213辞書の元データとなっている。

　附属書6は用例を含んでおり、かなり有用なデータであるものの、テキスト化はされていない。

GPL, MITなど

漢字データベースプロジェクト (http://kanji-database.sourceforge.net/index.html?lang=ja)

　説文解字注や宋本廣韻、學生字典といったデータが配布されている。

Creative Commons

MJ文字情報一覧表 (http://mojikiban.ipa.go.jp/1311.html)

　情報処理推進機構(IPA)による文字情報基盤 文字情報一覧表のデータ。戸籍統一文字や住基統一文字といった、要は汎用電子コレクションに収録された文字の情報のデータベース。

独自ライセンス

KanjiDic2 (http://www.edrdg.org/kanjidic/kanjd2index.html)

　Jim Breen氏を中心にまとめている非日本語話者のための日本語の漢字の字書。EDICT/JMDictが非日本語話者のための日本語辞書であるのに対応している。概ねCreative Commonsであるものの、一部著作権が留保されており、特にSKIPコードについてはnon-freeである。

Non-free

KO字源 (http://wagang.econ.hc.keio.ac.jp/zigen/)

　電脳瓦崗寨で公開されているデータ。原文は著作権切れであるので素のテキストについてはpublic domainであるものの、XML化に伴う構造化情報はnon-free。

FreeBSDでのwifi設定

FreeBSD ハードウェア

　時間が開いてしまいました。

　今まで有線運用だったFMV-Lifebook(FMV-R8290、FreeBSD/amd64 11.1)に180円のCardBusな無線LANカードを入れてました。こんなやつ。

  • CONTEC FLEXLAN-DS540
  • Atheros AR5212
  • IEEE 802.11a/b/g対応

FreeBSDからはathとして認識。

　まずは/etc/rc.confから。

wlans_ath0="wlan0"
ifconfig_wlan0="mode 11a country J5 WPA DHCP"

　ここでmode 11a country J5を入れているのは11a(2 GHz)での使用チャンネルの設定のため。

　そしてアクセスポイントの切り替えにはwifimgrを遣うので、pkgかportsで入れる。接続先が一つとかコマンドで切り替えたいならwpa_supplicantとifconfigでできる。

　もし、WPA−PSKのバスフレーズに引用符を用いている場合は、wpa_passphraseでSSIDだけ引数に入れて、パスフレーズをstdinから入力して雛形を作成する。

% wpa_passphrase SSID > wpa.txt

　できたファイルの中のpskのところは16進表記なので、これをwifimgrのパスフレーズの欄に入力すれば接続できる。

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

Debian ハードウェア

　デスクトップの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