dynabook SS SX/15AのNetBSD/i386で音が出ない

dynabook SS SX/15AにNetBSD/i386をインストールし、Windows Vistaから環境を移行する作業を続けています。主要なアプリケーションが入ったので、動作確認を兼ねて、Vistaの環境で出来ていたことがNetBSD/i386でもできるか確かめてみました。

WebブラウザからNHKの「らじる★らじる」やrajiko.jpを利用しようとしたら、Adobe Flashプラグインが入っていないというエラーになってしまいました。世間的にはAdobe Flashは使わない方向のはずですが、現状で使われているサイトがあるのは仕方ありません。何か逃げ道があるのか、どうしようもないのか、調べてみようと思います。

そもそもオーディオ機能が利用できるのか確認したら、ブートログでエラーが出ていました。

hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: couldn't map mmio space

Ubuntu-MATE 16.04を起動したときには次のように認識されていましたので、NetBSD/i386のGENERICカーネルにはドライバが入っていないのかもしれません。

[   45.211496] snd_hda_codec_realtek hdaudioC0D0: ALC262: SKU not ready 0x598301f0
[   45.211780] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC262: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   45.211787] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   45.211793] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
[   45.211797] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[   45.211801] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[   45.211807] snd_hda_codec_realtek hdaudioC0D0:      Internal Mic=0x19
[   45.211812] snd_hda_codec_realtek hdaudioC0D0:      Mic=0x18
[   45.281447] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[   45.281639] input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9

Windowsの「ドキュメント」にあるファイルをNetBSD/i386側に転送

NetBSD/i386側からWindows10の共有フォルダをマウントできることが確認できました。そこでWindows10のアカウントFURUSAWAにある「ドキュメント」フォルダ以下を全てNetBSD/i386側に転送しておきます。

転送はNetBSD/i386上のrsyncを使います。Windows10の共有フォルダをNetBSD/i386上のディレクトリにマウントしておけば、ローカル対ローカルの転送のように見せかけることができます。

rsyncには数多くのオプションが用意されています。よく使われるオプションは決まっているのですが、念のために全てを確認していくと「--iconv」というオプションを見つけました。これは転送元と転送先でのファイル名の文字コードを変換してくれるようです。それならばrump_smbfsを使ってマウント時に文字コード変換をおこなわなくてもよくなります。mount_smbfsでファイル名の文字コードを無変換のままにマウントしておき、rsyncで転送する時点で--convオプションでファイル名の文字コードを変換させてやればよいわけです。ファイル名の文字コード変換をrump_smbfsでやるかrsyncでおこなうかは、システム構成の全体像を踏まえて決定されるべき事項です。

方式が決まったので、シェルスクリプトを作って一括転送をおこないました。ところがネットワークがおかしいのか、ハードウェアの問題なのか、よく転送が固まりました。いわゆる「刺さる」という状態で、強制的な電源断しかできなくなります。何が問題の原因なのか現時点では不明ですが、解決しておきたい問題です。

NetBSD/i386でmount_smbfsを使ってみる

dynabook SS SX/15AのWindows VistaをNetBSD/i386に移行するために重要なのは、Windows10が動いているデスクトップPCにあるドキュメント以下のファイル群を同期させることです。Vistaを使っていれば、同じWindowsですから、ネットワークを介してファイル転送することは容易です。Windows10側からVistaに向かってファイルを送り出す形でファイルの同期をとっていました。

Windows VistaをNetBSD/i386に変えたら、どのような方式でファイル同期をとれば良いのか検討しなければなりません。実現の難易度は別にして、次のような方法が考えられます。

1. NetBSD/i386にSambaをインストールして、以前と同じようにWindows10からVistaに向けてファイルを送り出す。
2. Windows10にNFSサーバーを入れて、Windows10のディスクをNetBSD/i386からマウントする。
3. Windows10にNFSクライアントをいれて、 NetBSD/i386のディスクをWindows10からマウントする。
4. FTPを使って、Windows10からNetBSD/i386に向かってファイルを送り出す。

この中で最も実現しやすそうなのがSambaを利用する方法です。ただし同期させるためだけにSambaを入れるのは「牛刀をもって鶏を割く」の諺が思い浮かぶので、どうも気が進みません。

ここでNetBSD/i386にはmount_smbfsがあることに気付きました。これはWindowsで使われているSMBプロトコルでリモートファイルシステムをマウントさせるものです。これを使えば、余計なインストールが発生せず、ちょうど良い感じです。

Windows10のデスクトップPCが、WINDOWSという名前で192.168.1.99というIPアドレスだとします。この場合なら次のようなコマンド打つことになります。ここで-Nオプションを指定しておくと、接続時に必要となるパスワードを/root/.nsmbrcで指定しておくことができます。

mount_smbfs -I 192.168.1.99 -E UTF-8:CP932 -N //FURUSAWA@WINDOWS/Users /mnt

さてWindowsでは当たり前のように使われている日本語ファイル名を変換するために-E UTF-8:CP932オプションを指定したのですが、どうも変換されていないようです。マウント自体は成功しているのですが、ファイル名に含まれている日本語が化けてしまっています。ロケールをja_JP.SJISにすると問題なく読めるので、CP932からUTF-8へのコード変換が効いていないようです。

Webで調べてみると、FreeBSDでは問題ないようです。正確には、過去には問題があったけど、今は修正されているようで、今は問題なく利用できる状態になっているようです。FreeBSDとNetBSDは同じBSD系と言っても、独自の進化を遂げているので、微妙なところで使い勝手に違いがあります。

どうしたものかと頭を抱えてしまいました。ここは基本に戻って、ドキュメントをしっかり読むことから始めようと、MOUNT_SMBFS(8)を最初から最後まで読んでみました。すると最後に次のような記述がありました。

BUGS
The -E option works only if you mount with rump_smbfs(8) instead of mount_smbfs. 

要するに/sbin/mount_smbfsではなく/usr/sbin/rump_smbfsを使わなければならないのだそうです。オプション等は同じように指定できるようなので、コマンド名だけを変えて実行してみたところ、無事に日本語変換がおこなわれることを確認しました。

NetBSD/i386上でWindows10のファイルをマウントすることができることがわかりました。このようにマウントした状態で、rsyncを利用して、リモート側（Windows10） のファイルをローカル側（NetBSD/i386）に同期させようと思います。

方針は定まりましたが、NetBSD/i386のrump_smbfsは動作が不安定な印象を受けます。反応が遅いと思っていたら、マウントが切れていたりします。負荷をかけても大丈夫なのか若干心配は残りますが、頻繁に利用するつもりはないので、なんとかなるかと思います。

NetBSD/i386でLinuxバイナリ版LibreOfficeの日本語変換に成功

ここしばらくNetBSD/i386のLinuxエミュレーション環境でLibreOfficeの日本語入力を可能にしようと試行錯誤を続けてきましたが、ようやく成功しました。これは大きな一歩です。このことでdynabook SS SX/15AのWindows VistaをNetBSD/i386+MATEの環境に移行できる見込みが高まりました。

まず日本語変換を出来るようにするための手順を紹介します。次に解決に至るまでの試行錯誤の一端を紹介します。

1. NetBSD/i386のLinuxエミュレーション環境はOpenSuse 13.1のサブセットです。pkgsrcからLibreOffice5-binを入れた時にエミュレーション環境も同時にインストールされましたが、日本語変換に必要なファイルが足りなかったようです。
2. OpenSuse 13.1用RPMを2つ追加する必要があります。適当なミラーサイトからRPMを入手し、/usr/pkg/sbin/rpm2pkgでインストールします。必要なRPMは次の2つです。
• ibus-gtk-1.5.4-1.1.i586.rpm
• gtk2-immodule-xim-2.24.22-2.1.i586.rpm
3. 追加したモジュールを有効にするため、/usr/pkg/emul/linux/usr/bin/gtk-query-immodules-2.0を使って/emul/linux/usr/lib/gtk-2.0/2.10.0/immodules.cacheを更新します。

以上の処理をおこなうことで、LibreOfficeでiBus-Mozcが利用できることを確認しました。

この問題を解決するまで、試行錯誤を繰り返し、時には袋小路に入ったりしました。その全てを書いても仕方ないし、いろいろな可能性を考え、試したので、もう細かいところは覚えていません。

役にたったのは、本物のOpenSuse 13.1の環境を用意したことです。これはWindows10上のVirutualBoxを利用しました。本物のLinux上でLibreOfficeの日本語変換ができることを確認し、どの設定を変えると日本語変換が出来なくなるのかを探ろうとしました。

ここで次のような情報を見つけました。

1. GTK+2のバージョンによってimmoduleの情報の内部記録の方法が変わったらしいこと。
2. 環境変数GTK_IM_MODULE_FILEを使うと、このファイルの指す場所を変えられること。

NetBSD/i386を調べてみるとGTK+2のimmoduleの情報が、NetBSD/i386ネイティブ用とLinuxエミュレーション環境用の2つがあることがわかりました。

• /usr/pkg/lib/gtk-2.0/2.10.0/immodules.cache
• /emul/linux/usr/lib/gtk-2.0/2.10.0/immodules.cache

これらを比べてみると、Linuxエミュレーション環境用のファイルにはibusやximのエントリがありませんでした。NetBSD/i386ネイティブ用のファイルの方にはエントリが入っています。この段階で、どうやら日本語入力が出来ない原因はこれではないかと見当をつけました。

そこで環境変数GTK_IM_MODULE_FILEに/usr/pkg/lib/gtk-2.0/2.10.0/immodules.cacheを指定してみたのですが、LibreOfficeが起動しなくなりました。正確には起動しようとして、落ちてしまいます。その時に、次のようなエラーが出てしまいます。

(soffice:3007): Gtk-WARNING **: /usr/lib/libelf.so.1: symbol __deregister_frame_info, version GCC_3.0 not defined in file libgcc_s.so.1 with link time reference

(soffice:3007): Gtk-WARNING **: Loading IM context type 'ibus' failed
Application Error

NetBSD/i386のLinuxエミュレーション環境というのは、なんでもかんでもLinux用の共有ライブラリを使う訳でもなくて、場合によってはNetBSD/i386ネイティブの共有ファイルもつかうようです。これを期待して環境変数を指定してみたのですが、エラーが出てしまったので、OpenSuse用のバイナリをエミュレーション環境に入れることにしたのです。それが上述した手順です。

また本物のOpenSuseでは、環境変数GTK_IM_MODULE_FILEを指定して、一時的に作成した空ファイルを指すようにしてみました。すると、Mozcが反応しなくなったのです。これはNetBSD/i386上のLinuxエミュレーション環境で動作するLibreOfficeの問題と同じです。このようにして問題となる現象が再現できた（気がした）とき、解決への確信も生まれました。

「立入禁止」と“Keep Out”

事件や事故が発生すると警察が来て現場を調べるため、関係者以外が入ってくるのを防止するためロープなどで区分します。そこには「立入禁止」と掲示があります。外国のニュースなどを見ていると、英語圏では「Keep Out」と掲示されるようです（他の表現もあるようですが）。これらの意図することは同じで、要するに「関係者以外は入るな」ということです。

日本で使われる「立入禁止」というのは「（事件の発生した内部に外部から）入ることを禁止する」という意味です。英語圏の「Keep Out」というのは「（事件の発生した内部の）外側で留まり（侵入するな）」という意味でしょう。

言語文化によって、その表現に差が現れるのは、とても興味深い問題です。これらはあまりにも日常的な光景なので、意識の端にのぼることもなく通り過ぎていく情報だと思いますが、こういうことの積み重ねが文化圏の常識を形作っていきます。

異文化が接触したときに真っ先に気付くのは、相手側の発想の違いです。なぜそうなのかを問いただしたい気持ちにかられます。しかし相手側からすると当たり前すぎること（すなわち常識）なので、何故と言われても困るのです。

気を付けたいのは、どちらの発想が「正しい」のかとか、「あるべき姿なのか」などを決めることではありません。「違う」ということを知ること、「違いがあることを認める」ことが大切ではないかと思います。多様性とはそういうことでしょう。

ストーブとファンヒーターの違いは、LPとCDの違いのようなもの

冬になると暖房器具の出番になります。ストーブは燃えている炎が直に見えているので狭い場所で使うのは火事が心配です。ファンヒーターなら内部で燃焼して暖気が出てくるだけなので安心して使えます。

ストーブでもファンヒーターでも部屋を暖める機能としては同等なのに、感覚的にはストーブのほうが暖かい気がするのは何故でしょうか。個人で所有している人は珍しいと思いますが、暖炉ならば燃えている炎を直接見る事ができます。目が炎を見ているという信号を脳に送ることで、「暖かいはずだ」という感覚を脳が作り出しているわけではないとは思います。

 薪ストーブのメーカーが「ぽかぽか暖房を発生させるためには？」という情報を出しています。暖房器具の暖かさの源泉は遠赤外線ですが、ストーブなら遠赤外線が暖房機能に直接関わってきます。これに対してファンヒーターの場合は遠赤外線が器具の外に出てくる事はなく、温められた暖気が出てくるだけです。

これらの器具の違いを考えていたら、LPとCDも似たような関係にあるのではないかという気がしてきました。

LPとCDの違いというのは、記録媒体がアナログ式かディジタル式かということです。CDの場合は人間の可聴音域以外の情報をカットしてあります。これに対してLPなら可聴音域以外の情報も入っている可能性があります（それがピックアップやアンプで再現できるかどうかは別問題ですが）。

人間の可聴音域は20Hz～20kHzと言われていますが、個人差や年齢差があるので、実際にはもっと狭い範囲しか聴き取れないと思われます。しかし耳では聞こえていなくても、身体では音を検知していて、脳に信号が伝わっているとする研究があるようです。

暖気を排出することで部屋を暖めればよいとするファンヒーター（エアコンも同様でしょう） はCDのような割り切りがあり、一方でストーブは熱源が発する遠赤外線の全てを部屋中に放射するのでLPのようなものではないかと思うのです。

LibreOfficeで日本語入力できるようにするには、どうすれば良いのか?

NetBSD/i386でLinuxバイナリを使ってLibreOfficeを動かすと日本語入力ができない問題を調べていますが、なかなか手掛かりがつかめません。

「LibreOfficeで日本語入力が出来ない」と書いていますが、それはLinuxバイナリを使っているのがLibreOfficeしか今のところないからであって、それだけのことです。おそらくLinux用バイナリならばLibreOffice以外でも同様の問題を抱えていると思っていますが、確認しておいた方が良いかもしれません。

また日本語入力はibus-Mozcを使っています。これも同様に、ibus-mozcだから起きている問題ではないと思っています。ただ念のため、他のエンジンを使っても同様の現象がおきるのか、 または起きないのか、確認しておくべきかもしれません。

iBusの設定画面を開くと、エンジンとして「japanese」と「Mozc」が登録されています。これを切り替える機能は「<Super>+<Space>」というキーに割り当てられています。<Super>というのはWindowsキーのことらしいです。さて、LibreOfficeで日本語入力は出来ないのですが、エンジン切り替えは出来ることに気がつきました。つまりLibreOfficeに渡したキー入力はiBusに伝わっているということです。それならば何故Mozcにまで伝わっていないのでしょうか。

pkgsrcからlsofを入れて、調査してみることにしました。NetBSD/i386では次のような情報が得られました。このときLibreOfficeも起動しているのですが、immodulesというディレクトリにあるファイルをアクセスしていないようです。

sh         1997     root  cwd     VDIR        4,4      512 2039616 /usr/pkg/emul/linux/usr/lib/gtk-2.0/2.10.0/immodules
mate-term  6976 furusawa  txt     VREG        4,4    33519 1266968 /usr/pkg/lib/gtk-2.0/2.10.0/immodules/im-ibus.so
mate-pane  7623 furusawa  txt     VREG        4,4    33519 1266968 /usr/pkg/lib/gtk-2.0/2.10.0/immodules/im-ibus.so

さて比較のためにWindows上のVirtualBoxでUbuntu-MATEを動かしたみて、同様の情報を調べてみました。ここではLibreOfficeも現れています。

tilda     2999        furusawa  mem       REG                8,1    34840     416052 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-fcitx.so
gmain     2999 3055   furusawa  mem       REG                8,1    34840     416052 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-fcitx.so
gdbus     2999 3056   furusawa  mem       REG                8,1    34840     416052 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-fcitx.so
clock-app 3155        furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gmain     3155 3168   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gdbus     3155 3170   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
dconf\x20 3155 3256   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
mate-term 3315        furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gmain     3315 3318   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gdbus     3315 3320   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
dconf\x20 3315 3321   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
threaded- 3315 3322   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
soffice.b 3421        furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
rtl_cache 3421 3423   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
OfficeIPC 3421 3425   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gmain     3421 3426   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gdbus     3421 3427   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
ICEConnec 3421 3429   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
Selection 3421 3430   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
threaded- 3421 3455   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
thread-po 3421 3931   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so

このような状況をみると、immodulesのディレクトリにあるファイルをアクセスしていれば日本語入力が出来て（Ubuntu-MATEの場合）、アクセスしていないなら日本語入力できない（NetBSD/i386の場合）と考えられます。しかし、では何をすれば良いのか、さっぱり見えてこないので、調べてみたものの結局何の役にもたちません。なかなか手強い問題ですが、何か糸口が見つからないかと足掻くような思いです。