ここには、FreeBSD の「X に関するメモ」を置きます。
必要なら 「インストールに関するメモ」 「その他のメモ」 も参照してください。
FreeBSD に関するページへ戻る「X に関するメモ (05/06 2022)」 にも書きましたが、 ThinkPad の X 上でのマウスの中ボタンが使えなかった件ですが、 泥縄ですが (理屈はよくわかっていませんが)、 とりあえずそれなりに使えるようになりましたので、紹介しておきます。
まず、現在はドライバが libinput になっているので、
設定が従来の「"Emulate3Buttons」などではないようです。
xinput というコマンドを使って、
「xinput list」
「xinput list-props Mouse0」
「xinput list [id]」
などで状態を表示させながら、
そして man -S 4 libinput の説明を見ながら試行錯誤してみました。
どうやら、ThinkPad の中ボタン (本来は多分スクロールボタン) は、 libinput でもスクロールボタンとして割り当てられているため、 通常の左や右のボタンと働きが違っていました。 実際、xev でイベントを調べても、左、右ボタン (button 1,3) は press, release のイベントが、ボタンを押す、離すで即時に出るのですが、 中ボタン (button 2) は、押してもイベントがでず、離したときに press, release が同時に出ていました。
これは、xorg.conf の InputDevice のセクションに、
「Option "ScrollButton" "0"」
を入れて (default は 2 になってる)、
中ボタンのスクロールボタン割り当てをやめてあげると、
めでたく押す、離すで即時に press, release がでるようになりました。
しかし、中ボタンを押しながらトラックポイントの移動がうまくいきません。
具体的には、kterm などで、Ctrl + 中ボタンで出るプルダウンメニューを、
トラックポイントで移動ができず、
カーソルを移動するとすぐにプルダウンメニューが閉じてしまいます。
左ボタン、右ボタンはそんなことはなくうまくいっています。
また、左右の同時押し (Emulate3Buttons) は libinput では 「MiddleEmulation」になっているので、それも書いてみたのですが、 それも全く反応がありません。一応 xinput list-props では それは有効になっているように見えますが、同時押しは全く効きません。
ところで、
「xinput list」で見ると、マウスはいくつか認識されていて、
「Virtual core pointer (id=2)」「Virtual core XTEST pointer (id=4)」
「Mouse0 (id=6)」「System mouse (id=8)」「TPPS/2 IBM TrackPoint (id=12)」
などが認識さています。Mouse0 というのは、xorg.conf の InputDevice
や ServerLayout セクションに書いているものです。
実際には、InputDevice セクションは以下のようにしてあります。
Section "InputDevice"
Identifier "Mouse0"
Driver "libinput"
Option "Device" "/dev/input/event5"
Option "Protocol" "PS/2"
Option "MiddleEmulation" "Yes"
Option "ScrollButton" "0"
EndSection
Section "InputClass"
Identifier "Mouse0"
MatchIsPointer "on"
Driver "libinput"
MatchDevicePath "/dev/input/event*"
Option "Protocol" "PS/2"
Option "MiddleEmulation" "Yes"
Option "ScrollButton" "0"
EndSection
なお、InputClass の方だけにして InputDevice セクションを削除するとだめですし、 InputDevice セクションの中にある MiddleEmulation と ScrollButton の設定を消して InputClass の方だけにその設定を残しても (それでうまくいくかと思ったのですが) うまくいきませんでした。
ということで、全く理解はしていないのですが、 ようやく中ボタンがそれなりに使えるようになりました。 ただし、本来の意味のスクロールボタンとしては 使えなくなったのかもしれませんが、そちらについてはわかりません (し、使いませんのでそもそも考えていません)。
「インストールに関するメモ (11/15 2022)」 に少し書きましたが、 ThinkPad の OS の 13.1 へ更新がうまくいきました。 それにともない、X 回りの更新も ports でやりました。 それについて報告します。
まず、 「X に関するメモ (05/06 2022)」 に書いた、intel ドライバ、というか i915kms がうまくいかない件ですが、 これはようやく解決しました。以下の情報が参考になりました。
この p10, p11 に以下のように書かれています。
これに従って、rc.conf に
「kld_list="i915kms"」と、その下に
「kld_list="acpi_video"」を入れて
reboot したら、今度は blackout は起きませんでした。
とすると「blackout」だと思っていたのは、
「バックライトが消灯」ということだったのかもしれません。
ちゃんと xdm も立ち上がります。
なお、i915kms は、あらためて graphics/drm-kmod を再インストールしました。
そしてこの設定であれば、X のドライバとして、デフォルトで vesa でなくちゃんと intel が選択されました。 ただ、Xorg.0.log を見ると、
(EE) AIGLX error: dlopen of /usr/local/lib/dri/i915_dri.so failed
(Cannot open "/usr/local/lib/dri/i915_dri.so")
(EE) AIGLX error: unable to load driver i915
なお、このエラーが出るのは、実際に i915_dri.so がないからなのですが、 それは graphics/mesa-dri で i915_dri.so が入らないようになったからのようです。 無理矢理やれば、Makefile の GALLIUM_DRIVERS に I915 を追加すれば、 work/stage/usr/local/lib/dri に i915_dri.so が作られるようになるようですが、コピーはされませんし、 手動で単にコピーしてもやはりエラーがでてましたので、 うまく使えるようにはならないかもしれません。
「インストールに関するメモ (04/13 2022)」 に少し書きましたが、 ThinkPad の OS を 13.0 に更新し、その設定などをやっています。 Xorg もインストールして、先日ようやく X の起動をやってみました。 そこで引っかかったところなどを簡単にまとめておきます。
コンソールでのグラフィカル表示のために i915kms をやってみました。
graphics/drm-fbsd13-kmod をインストールして、/etc/rc.conf
「kld_list="i915kms"」をやったのですが、
そのロードによってグラフィカルな画面に切り替わったと思ったら、
その直後もう一回画面が切り替わって、blackout してしまいます。
そこから復帰ができません。
このマシンだと、i915kms のロードをしなくても、 同じようなタイミングで一度画面が切り替わるようなことが起こります。 i915kms をロードしない場合は実際には何も変わりませんが、 画面表示では以下のようなものが表示されています。 ただし、その切り替えが表示されているものに対応して起きているのかどうかは わかりません。
smbus0: <System Management Bus> on ichsmb0
acpi_dock0: <ACPI Docking Station> on acpi0
driver bug: Unable to set devclass (class: uart devname: (unknown))
ログイン後 startx で X を起動すると、keyboard、 マウスはちゃんと反応して一応使えましたが、 キー配列が日本語設定になっていません。
/etc/X11/xorg.conf.d/ にいつもの通り ServerLayout セクション、 Screen セクション、Monitor セクション、 InputDevice セクションのファイルを置いてみましたが、 やはり InputDevice セクションの設定が効きません。 /var/log/Xorg.0.log を見ると、 「config/udev」とか「/dev/input/event1」とかいっていて、 前にも見たことのあるものでした。 従来はそれを避けて設定したのですが、 今回はまずこれに沿った設定をしてみました。
Xorg.0.log の event* を見ると、 このマシンでは以下のようになっているようでした。
キーボードは event4 らしいので、 キーボードに関する設定は以下のようにしてみました。
Section "InputDevice"
Identifier "Keyboard0"
# Driver "kbd"
Driver "libinput"
Option "Device" "/dev/input/event4"
Option "XkbRules" "xorg"
Option "XkbModel" "jp106"
Option "XkbLayout" "jp"
Option "XkbOptions"
"ctrl:swapcaps,terminate:ctrl_alt_bksp"
EndSection
Driver "kbd"」としていたのですが、
それがどうもだめで、libinput に変えて、
Device として適切なものを指定したらとりあえずうまくいきました。
これでエラーも出ず、一応日本語キー配列になりました。
ただ、これで正しいのかはよくわかりません。
また、キーのいくつか ('\' や '|' や 'i' など) がキー刻印と合っておらず、 それらは xmodmap (~/.Xmodmap) で変更していますが、 結構合っていないものがあるので、 もしかしたら上の設定 (例えば Xkb*) に変なところがあるかもしれません。
マウスも同様 (event0) に設定しています。
マウスの中ボタンがうまく使えていません。通常のマウスの場合は、
「Emulate3Buttons」を設定して
左右同時押しで使っていたりしたのですが、
このマシンの場合、中ボタンのようなものがあり、
一応それが中ボタンとして使えます。
ところが、「kterm の Ctrl + 中ボタンでプルダウンメニューを出して、 そこから下にあるメニュー項目を選ぶ」といった作業が全くできません。 プルダウンメニューがでなかったり、 出たとしてもその状態を維持しつつカーソルを移動することができなかったり、 という状態です。 暇なときにでも色々試行錯誤してみたいと思います。
(cf. 「X に関するメモ (11/25 2022)」)
「X に関するメモ (06/08 2021)」 に書いた、scim を起動するライブラリを避けるために GTK_IM_MODULE_FILE をデタラメな値に設定する、 という逃げの方法ですが、 これだと逆に gtk の immodule を利用するクライアント、 例えば firefox で問題がでることがわかりました。 uim による日本語入力ができなくなります。
それを設定しなければ、ちゃんと uim が使えるので、 とりあえずは firefox の起動時に GTK_IM_MODULE_FILE を unsetenv して対応しています (逃げの逃げ)。 ちなみに、うちでは firefox はよく落ちて core dump を吐くため、 前後の処理をするスクリプト起動にしているので、 今のところそちらで対応しています。
そろそろ「その他のメモ」の方が適切な気もするのですが、 一応流れでこちらに書きます。 「X に関するメモ (05/28 2021)」, 「X に関するメモ (05/28 2021; no.2)」, 「X に関するメモ (05/31 2021)」 に書いた、scim の不具合の件ですが、 uim に変えたせいで (?)、 今まで顕在化していなかった問題が起きたようなので、 ここに記録しておきます。
ports にある math/gnuplot 以外に、 私は自前でも gnuplot をコンパイルしていますが、 その自前でコンパイルした gnuplot で wxt terminal を使って グラフを描かせようとすると、 なぜか次のようなメッセージがでて SCIM が起動されてしまいます。
Launching a SCIM daemon with Socket FrontEnd...
Loading simple Config module ...
Creating backend ...
Loading socket FrontEnd module ...
Starting SCIM as daemon ...
GTK Panel of SCIM 1.4.9
ldd で比較してみると、 /usr/local/bin/gnuplot の方は libgtk-3.so.0 を引いていますが (wxGTK3 を使っている)、 自前でコンパイルした gnuplot の方は libgtk-x11-2.0.so.0 の方を引いているようです (wxGTK2)。 この辺りに挙動の違いの原因がありそうです。
ただ、GTK_IMMODULE, GTK_IM_MODULE などの環境変数を色々いじってみたのですが、 状況は変わらず SCIM が起動されてしまいます。
それが、ふとどこかで見かけた環境変数 GTK_IM_MODULE_FILE に適当な値を設定したらうまく SCIM の起動を回避できました。 この環境変数は、gtk の immodule が input method を起動するための設定用のファイルを指定するもののようで、 それに適当な名前を設定することで immodule が失敗してくれているのだろうと思います。 とりあえずはこれで回避しようと思いますが、 できれば自前の gnuplot でも wxGTK3 を引くようにしてみようと思います。
(cf. 「X に関するメモ (06/09 2021)」)
「X に関するメモ (05/28 2021; no.2)」 に書いた、scim の不具合の件ですが、 skkinput の代わりに uim-anthy (japanese/uim-anthy) を試してみました。 これも今のところ、特に問題なく使えています。 ほかにも、ibus-anthy や fcitx-anthy なども選択肢としてあるようですが、 とりあえずは uim-anthy でいくつもりです。
ただ、uim は scim と違って入力パネルがでない (ほぼ使ってはいなかったですが) ので、 現在日本語入力モードなのかそうでないのかがわからないのが 少しまだ慣れないです。
(cf. 「X に関するメモ (06/08 2021)」)
「X に関するメモ (05/28 2021)」 に書いた、X の不具合の件ですが、 まだ確定ではないですが、どうやら scim が問題のようです。
私は、
「X に関するメモ (05/28 2021)」
にも書いた通り、.xsession (実際はそこから起動する csh script)
の最後で foreground の kterm を立ち上げているのですが、
その前の行に scim -d で scim-anthy (japanese/scim-anthy)
を立ち上げています。
その挙動が今までと少し違うこと (変換モードにしてもミニウィンドウが出てこない)、 scim の起動に以前より時間がかかるようになった気がすることなどから、 その scim を外してみたら問題は起きなくなりました (確定ではありませんが)。 再び、手動で scim を立ち上げるとまた問題が起きます。
もしかしたら OS か X 回りの更新に伴って、 scim に関する XIM 関連の変更でもあったのかもしれませんが、 まだそこまではわかりません。
とりあえず scim-anthy を一旦やめて、 skkinput (japanese/skkinput) を入れて、 しばらくはそれを使うようにするつもりです。 emacs では普段 skk で日本語変換をしているので、 skk 流の変換はそれほど苦にはなりません。 今のところこちらでは skkinput で問題はあまり起きていませんが、 慣れていないせいか操作ミス (?) で kterm 等が固まるトラブルがありました。 ただし、すべての kterm が止まるということにはなっていないので、 少なくとも scim の状況よりはましです。
SA が出たので、早速 freebsd-update で 13.0-p1 に更新して、 ついでに portsnap と portupgrade で ports も更新したのですが、 X に関する不具合がでました。
今まで通りに xdm でログインすると、 .xsession にしたがって kterm や emacs などが立ち上がるのですが、 それが何かの拍子に全く反応しなくなります。 最初は反応していたものが、kterm, emacs, firefox などの X クライアントがある時に一斉に反応しなくなる場合もありますし、 xdm の起動時に既に全く反応しない kterm 等が立ち上がる場合もあります。
いずれも、一番最後に foreground で立ち上げた kterm を fvwm の機能で強制終了させればログアウトできるので、 全くお手上げというわけではありませんが、結構困ります。
長いファイルに grep をかけるなど、負荷のかかる仕事をさせる (特に LANG=C でないと今の grep はかなり負荷が高い) とそういう状態になりやすいような気がしますが、 まだ原因の特定も対処法もみつけていません。 OS の更新が原因なのか、X 回りの問題なのかどうかもわかっていません。 Xorg.0.log, dmesg でも従来と特に変わったものはでていません。
多分うちだけではないと思うので (2 台の別なマシンで同様の状態になりました)、 そのうちに情報がでるか改善がなされると思うので、 それを待ち、しばらくはだましだまし使うことにしたいと思います。
(cf. 「X に関するメモ (05/28 2021; no.2)」, 「X に関するメモ (05/31 2021)」, 「X に関するメモ (06/08 2021)」)
「X に関するメモ (05/13 2021)」 で報告した、 MT-7900 の X のキーボードとマウスが反応しない件ですが、 とりあえず解消できたのでここに記録しておきます。
これは、原因は 「X に関するメモ (05/15 2020)」, 「X に関するメモ (08/21 2020)」 で報告した、devd の件でした。現在の FreeBSD 13 の xorg-server では、 devd でなく、udev がデフォルトになっているのですが、 それが古い config の状態のまま devd で xorg-server がコンパイルされていたためにうまくいっていなかったようです。
ちなみに、このマシンで x11-servers/xorg-server で
make config して状態を確認しようとしたのですが、
オプションの設定画面が表示されずに「Options unchanged」
としか言われなくなっていました。
それは、どうやら ports-mgmt/dialog4ports の問題で、
freebsd-update で OS の更新を繰り返した際に、
どこかの段階で古いコンパチライブラリを入れ忘れて
dialog4ports が起動できない状態になっていたようです。
これを reinstall して、ようやく make config
でオプションの設定画面が出るようになりました。
それで UDEV を有効にして xorg-server を install し直して、
その install の際に表示される、
「# sysctl kern.evdev.rcpt_mask=6」
を実行してから startx したら、
まだマウスやキーボードはうまく効かなかったのですが、
C-A-F2 とか C-A-BS とかが少し効くようになっていました。
あとは /usr/local/etc/X11/xorg.conf.d/ の設定なのですが、
従来の設定を多少今風に変えて、マウスの設定を削除して、
キーボードの方には、
「Driver keyboard」という行を削除して、
「MatchDevicePath "/dev/input/event*"」
を入れてみたら、ようやくマウスとキーボードが使えるようになりました。
報告してなかったのですが、実は既に Mouse Computer MB-B401B2 の方は、そのような設定で udev で動いていました。 今回はほぼそれに合わせただけで、 すべての FreeBSD マシンを 「X に関するメモ (08/21 2020)」 のような devd も udev も使わないようにしているわけではありません。
EPSON Endeavor MT-7900, HP Compaq dc7700 の FreeBSD/i386 も 12.2 から 13.0 に更新しました。 すると、「X に関するメモ (04/28 2021)」 と同じでいずれも X が正常に起動しなくなりました。 vesa になるというより、X そのものが起動しません。
いずれも対処は同じで、
make install
kld_list="i915kms"」を追加、
dc7700 の方は
「kld_list="radeonkms"」を追加
reboot
で一応 X はうまく出るようになりました。
ただし、MB-B401B2 で X の画面がおかしくなる (テキストだけ白くでて、あとは真っ黒) ことがあったり、MT-7900 の X の設定がまだうまく行ってない (キーボードとマウスが反応しない) など、多少問題はありますが、時間があるときに設定をやっていきたいと思います。
(cf. 「X に関するメモ (05/17 2021)」)
最近、 Mouse Computer MB-B401B2 の FreeBSD/amd64 を 12.2 から 13.0 に更新したのですが、 それに伴なって X の状態が変わってしまいました。 丁度、「X に関するメモ (06/15 2012)」 に書いたような 1024x768 の横に伸びたような表示になってしまいました。 Xorg.0.log を見ると、以下のエラーがでて、intel ドライバの認識に失敗して vesa になってしまっています。
(II) intel: Driver for Intel(R) HD Graphics
(II) intel: Driver for Intel(R) Iris(TM) Graphics
(II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
(II) modesetting: Driver for Modesetting Kernel Drivers: kms
(II) scfb: driver for wsdisplay framebuffer: scfb
(II) VESA: driver for VESA chipsets: vesa
(--) Using syscons driver with X support (version 2.0)
(--) using VT number 9
(EE) open /dev/dri/card0: No such file or directory
(WW) Falling back to old probe method for modesetting
(EE) open /dev/dri/card0: No such file or directory
(WW) Falling back to old probe method for scfb
scfb trace: probe start
scfb trace: probe done
(WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
(EE) Screen 0 deleted because of no matching config section.
ネット上を調べてみたところ、似たような状況を以下に見つけました。
その最後のところに、以下のように書かれています。
make install WITHOUT_DRM_MODULE=t WITHOUT_DRM2_MODULE=t
でインストール
kld_list="/boot/modules/i915kms.ko"」
を追加して reboot
新しい ports には、graphics/drm-fbsd13-kmod があったので、
特にオプションなどつけずにそれを make install して、/etc/rc.conf に
「kld_list="i915kms"」を入れて reboot したら、
boot 画面で devd が起動する辺りから vt のような小さい文字の画面になり、
それで X を起動したら、
元通り wide な 1366x768 の画面で使えるようになりました。
状況は全く把握できていませんが、
とりあえずはこのまま使ってみるつもりです。
私は、普段は FreeBSD マシンを使って日常の作業していますが、 MS-Windows で作業をしなければいけない場合は、 別の PC の MS-Windows を立ち上げて、 そこに RDP (リモートデスクトップ) で入って作業をします。 以前は rdesktop を使っていましたが、 Windows 10 に対応していないようだったので、 現在は xfreerdp (net/freerdp) を使っていて、 Windows の画面を FreeBSD 側に表示させて作業しています。
そのような場合、FreeBSD 側のテキストを Windows 側にコピーペーストしたくなるときがあります。 FreeBSD 内部では、マウスのドラッグと中ボタンだけでできるので便利ですが、 それを xfreerdp の Windows 画面に持っていって 「貼り付け」などをやっても何もでてきません。
少し調べてみると、xfreerdp の +clibboard オプション (clipboard リダイレクションの有効化) を使うといいようなのですが、 残念ながらそれでも変化ありません。
ここでふと思い出したのですが、 私は FreeBSD 側では KDE や gnome などのデスクトップ環境を使っておらず、 ほぼ裸の X + ウィンドウマネージャ (fvwm2) という環境で使っています。 この場合、FreeBSD でドラッグしたものは いわゆる正規のクリップボードには入っていない、 というような話を聞いたような気がします。 そこで、x11/xclipboard をインストールして、 FreeBSD 側でドラッグしたものを xclipboard に一旦落としてから Windows 側の xfreerdp (+clipboard 付き) の方で「貼り付け」をすると うまくペーストできました。
ただし日本語のコピーペーストは簡単ではありませんでした。 まず、私は FreeBSD 側では普段日本語コードは EUC-JP を使用していますが、 それだと xclipboard でも化けるだけですし、 Windows 側でも日本語にはなりません。 ただ、xclipboard のソースを見ると、UTF-8 には対応している、 とあるので、FreeBSD 側の EUC-JP テキストを一旦 UTF-8 に変換し、 それを xclipboard に落としたところ、 xclipboard 上では正常には表示されません (ロケールの問題かも) が、 それを xfreerdp 上の Windows 側で貼り付けるとうまく日本語になります。 今のところ貼り付けたのは Windows の firefox のフォーム入力みたいなところでしたが、 それ以外、例えばコマンドプロンプトへの貼り付けなどは試していませんので、 それでもうまくいくのかはわかりません。
なお、細かいことを言えば、全く問題がなかったわけではなく、 上のような作業では日本語文字列の先頭、あるいは半角文字との境目あたりに ゴミのような 2 文字ほどが挿入されたりしました。
ただし、上のやり方はコード変換も必要ですし、手順が多すぎるので、 とても快適とはいえず、よほど長い文章をコピーペーストするのでなければ、 今のところはむしろ Windows 側で直接書いてしまった方が楽そうです。 しかし、FreeBSD 側のマウスアクションは fvwm2 でカスタマイズできるので、 「ドラッグしたテキストを UTF-8 に変換して xclipboard に送る」 という仕組みを簡単なマウスアクションなどに組み込むことができれば それなりに実用的になるかもしれませんので、 暇なときにでも調べてみたいと思います。
「X に関するメモ (05/15 2020)」 に書いた 1.20.8 の Xorg に関する話の続きです。 別なマシンで少し試してみたら、今の 1.20.8(_3) でもちゃんとキーボードやマウスの設定が使えるようになりましたので 報告します。 やったことは以下の通りです。
どれが実際に効いたのかはよくわからないのですが、 色々ネット上の情報を調べて試行錯誤した結果、 だいたい上のような感じでうまくいきました。
なお、最初は reboot せずに xorg.conf.d/ の設定を変えながら startx で試していたのですが、Xorg.0.log に相変わらず config/devd とかでてきて、 1. なのにどうも変だなと思い、 xdm もうまく立ち上がらなかったので reboot してみたらうまく行って、 log も問題なくなりました。
現在の入力回りのログはこんな感じです。
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
.....
(II) LoadModule: "mouse"
(II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
compiled for 1.20.7, module version = 1.9.3
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 24.1
(II) LoadModule: "kbd"
(II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
compiled for 1.20.7, module version = 1.9.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 24.1
.....
(II) Using input driver 'mouse' for 'Mouse0'
(**) Option "CorePointer"
(**) Mouse0: always reports core events
(**) Option "Protocol" "auto"
(**) Option "Device" "/dev/sysmouse"
(**) Mouse0: Protocol: "auto"
(**) Mouse0: always reports core events
(==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50
(**) Option "ZAxisMapping" "4 5 6 7"
(**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7
(**) Mouse0: Buttons: 7
(II) XINPUT: Adding extended input device "Mouse0"
(type: MOUSE, id 6)
(**) Mouse0: (accel) keeping acceleration scheme 1
(**) Mouse0: (accel) acceleration profile 0
(**) Mouse0: (accel) acceleration factor: 2.000
(**) Mouse0: (accel) acceleration threshold: 4
(II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0
.....
(II) Mouse0: SetupAuto: protocol is SysMouse
(II) Using input driver 'kbd' for 'Keyboard0'
(**) Option "CoreKeyboard"
(**) Keyboard0: always reports core events
(**) Keyboard0: always reports core events
(**) Option "Protocol" "standard"
(**) Option "XkbRules" "xorg"
(**) Option "XkbModel" "jp106"
(**) Option "XkbLayout" "jp"
(**) Option "XkbOptions"
"ctrl:swapcaps,terminate:ctrl_alt_bksp"
(II) XINPUT: Adding extended input device "Keyboard0"
(type: KEYBOARD, id 7)
なお、xorg-server インストール時に sysctl もした方が、 というメッセージが出るのですが、そちらは今のところやっていません。
(cf. 「X に関するメモ (05/17 2021)」)
今月 3 日位から x11-servers/xorg-server が 1.20.8,1 から 1.20.8_1,1 に変わりました。 うちの FreeBSD マシンの xorg-server も昨日 portupgrade で更新されたのですが、 今朝 xdm からログインしようとしてキーボード、 マウスが効かないことに気がつきました。 キーボードは全く反応がないわけではなく、 押しているとなにやらランダムな文字がでてきます。 とはいっても、キー配列の問題ではなく、 押し続けていてたまに変な文字が出てくる、 あるいは何かが押されたままの状態になる、といった感じです。 xdm でなく console だとキーボードは使えるので、 更新された xorg-server の問題のようです。
なお、以下のログの確認等は、別の Windows マシンから
putty でログインして確認しました。
xdm がだめで、X も落とせなかったので、仕方ありません。
もう一台手近に FreeBSD PC があったのですが、
そちらも同時に portupgrade してあって、
やはり xdm で止まってしまっています。
(ということは、結構あちこちの FreeBSD で起きているかも)
Xorg.0.log を見ると、入力デバイスが通常の atkbd0, kbdmux0 などではなく、/dev/input/event0 などのようになっています。
(II) config/devd: EVDEV_SUPPORT is enabled, ignoring device atkbd0
(II) config/devd: detected event input: System mouse, bustype=0006,
vendor=0000, product=0000, version=0000
(II) config/devd: adding input device /dev/input/event0
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(EE) config/devd: error 1 adding device /dev/input/event0
...
(II) config/devd: EVDEV_SUPPORT is enabled, ignoring device kbdmux0
(II) config/devd: EVDEV_SUPPORT is enabled, ignoring device psm0
(II) config/devd: EVDEV_SUPPORT is enabled, ignoring device sysmouse
(II) config/devd: detected USB HID of unknown type
...
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(EE) config/devd: error 1 adding device /dev/uhid0
(II) config/devd: EVDEV_SUPPORT is enabled, ignoring device ukbd0
(II) config/devd: EVDEV_SUPPORT is enabled, ignoring device ums0
この名前を Makefile に変えて x11-servers/xorg-server に入れて、
「make ; make deinstall ; make install clean」
でいけるかと思います。
緊急性が高そうな話なので、とりあえず前のものに復旧する、 というあまり価値のない情報をあげましたが、 のちほどもう一台の方で設定の変更を試してみて、 何かわかったらまたここで報告したいと思います。
Lenovo B590 のノート PC で現在 ThinkPad のトラックポイント付きの ワイヤレスキーボード (Bluetooth) を使っています。 Bluetooth の設定は普通通りで、 /etc/bluetooth/hcsecd.conf, /etc/bluetooth/hosts, /etc/bluetooth/bthidd.conf の設定をして、rc.conf で必要なものを起動して 認識させると keyboad が vkbd とかいうものとして使えて、 トラックポイントも普通に使えていました (2018 年 4 月頃)。
portupgrade しても問題なく使えていたのですが、 今回 3 ヶ月ぶりくらいに portupgrade したら、 ワイヤレスキーボードが使えなくなってしまいました。 ノート PC 本体のキーボードやタッチパッドの方は使えます。
Xolg.0.log を見たら、portupgrade で更新された X server が dbus を要求しているようで、こんなエラーがでています。
(EE) dbus-core: error connecting to system bus:
org.freedesktop.DBus.Error.FileNotFound (Failed to connect
to socket /var/run/dbus/system_bus_socket: No such file or
directory)
とりあえず rc.conf に hald_enable, dbus_enable を久しぶりに復帰させて reboot すると、 今度はそのエラーは出なくなって、 ワイヤレスキーボードは使えるようになったのですが、 トラックポイントや左右のボタンの方がまだ反応しません。 本体のタッチパッドは使えています。
色々試してみたのですが、Bluetooth デバイスの認識状況が dmesg でも、lshal でも、xinput でも、また Xorg.0.log にも どうも明確に出てこないので、状況がなかなかわかりませんでした。
ふと古い Xorg.0.log と比較してみると、マウスの方のデバイスが、 古い方は「/dev/sysmouse」なのに対し、 今のは「/dev/psm0」となっている違いがあることに気がつきました。 ということで、moused を立ち上げて sysmouse になる必要があるのでは、 と思い、rc.conf に moused_enable を入れて reboot したら、 ようやくワイヤレスキーボードのトラックポイントが使えるようになりました。 よく状況を理解していないやっつけ仕事ですが、 ワイヤレスキーボードをほぼメインで使っていたので一安心です。
ただ、複数のキーボード (本体とワイヤレス側)、 複数のマウスに対して別々の設定をしたい場合、 現在それぞれがどのように X 側に認識されているのか、 という情報が必要だと思うのですが、 上に書いたようにどうもそれがよくわからないので、 その辺はまた調べたいと思いますが、 とりあえずはワイヤレス側が主なので、 そちらに合わせた設定をしています。
HP Compaq dc7700 で 「X に関するメモ (05/15 2019)」, 「X に関するメモ (05/20 2019)」, 「X に関するメモ (02/22 2020)」 に書いた、ati のドライバ (19.0.0) でマウスカーソルが消える件ですが、 その後、023/05 2020 (19.1.0_1), 03/23 2020 (19.1.0_2) あたりでも更新されたのですが、あいかわらず問題は解消されませんでした。
それが今日 19.1.0_3 でやってみたらなんとようやく マウスカーソルが出るようになりました。 詳しくは以下の「Commit History」の、 19.1.0_3,1 の Description をご覧ください。
HP Compaq dc7700 で 「X に関するメモ (05/15 2019)」, 「X に関するメモ (05/20 2019)」 に書いた、ati のドライバ (19.0.0) でマウスカーソルが消える件ですが、 最近 ati のドライバが更新 (19.1.0) されたので試してみたのですが、 やはり問題は解消されませんでした。 しばらくは様子見です。
(cf. 「X に関するメモ (04/17 2020)」)
「X に関するメモ (05/15 2019)」 に書いた、ati のドライバ (19.0.0) でマウスカーソルが消える件ですが、 既に bugzilla にも登録されているようです。
まだ対応はされていませんが、そこにも書かれているように、 先日更新された 19.0.1 でも問題は解消されませんでした。 しばらくは様子見です。
HP Compaq dc7700 ではグラフィックカードは ATI RADEON X1300 Pro を使っていて、 1680x1050 の解像度の X を、ATI ドライバ (x11-drivers/xf86-video-ati) の radeon ドライバモジュールで使用しています。
それが、今回 portupgrade したら ATI ドライバが 18.1.0,1 から 19.0.0,1 に更新され、そのせいでマウスカーソルが表示されなくなってしまいました。 man radeon には、
Option "SWcursor" "boolean"
vidcontrol の情報もありましたが、結局うまくいかず、 ATI ドライバを古いものに戻すことにしました。
ちょっと強引な力技ですが、 x11-drivers/xf86-video-ati の Makefile と distinfo を 18.1.0 用に書き直して (SIZE, SHA256 の値、ファイル名)、それで make deinstall install して、 古いドライバを復帰しました。これでとりあえずマウスカーソルも復帰しました。
vesa も試してみたのですが、vesa だと 1280x1024 までしか出ず、 wide スクリーンではちょっと困ります。 また、ati には x11-drivers/xf86-video-ati-legacy もあり、 それで古いドライバも使えるようで、それでもうまくいくのかもしれませんが、 7.9.0 とかなり古そうなので今のところそちらは利用していません。 よって、ati ドライバが更新されてマウスカーソルの問題が解消されるまでは、 とりあえずこれでしのごうかと思っています。
ちなみに、マウスカーソルがでなくても、 日常作業の半分以上は問題なくできますし、 見えないカーソルの場所も fvwm のウィンドウフォーカス色表示などのおかげで ある程度はわかるのですが、 Web ブラウザ上などの GUI 作業が相当制限されますし、 コピー & ペーストもできません。 以前マウスカーソルを音などで代用することを考えたことを思い出しましたが、 いざというときの代用法も考えておいた方がいいかもしれません。
(cf. 「X に関するメモ (05/20 2017)」, 「X に関するメモ (02/22 2020)」, 「X に関するメモ (04/17 2020)」)
「X に関するメモ (01/12 2018)」 の下の方に書いた、X のフォントの件ですが、 FreeBSD bugzilla に送ったところ、 x11-fonts/libXfont が更新 (1.5.2 から 1.5.4) されてそのような挙動になったようだ、 よって、今後はシンボリックリンクはやめて、 直接 /usr/local/share/fonts/misc/ などの X が参照できるディレクトリにインストールするように変える、 という報告がありました (Thanks FUTATSUKI Yasuhito さん、 WATANABE Kazuhiro さん、Yuichiro NAITO さん、MANTANI Nobutaka さん)。
「インストールに関するメモ (01/12 2018)」 で書いた HP Compaq dc7700 の OS の 11.1 への更新に伴う X の更新の際に気がついたこと、 問題点を書きます。
まず、portupgrade では X はうまく更新されずかなりこけていたので、 ports でちまちま一つずつ更新していきました。 後で考えれば「portupgrade -fR x11/xorg」とすれば だいぶ楽ができたはずですが、とりあえず一つ一つ手動で make install していきました。 「インストールに関するメモ (01/12 2018)」 にも書きましたが、 例えば x11-servers/xorg-server では 「fatal error: 'epoxy/gl.h' file not found」と出たりしましたが、 pkg-plist に関して grep をかけてそれが含まれる ports を探して graphics/libepoxy を入れる、といった手順を取っていました。
とりあえず xorg は終わったのですが、 reboot すると X がうまく起動しません。/var/log/Xorg.0.log を見ると EE 行に backtrace の記録が残っていて /lib/libcrypto.so.7 とか出ています。 しかし、現在の X サーバが引いているのは /lib/libcrypto.so.8 なので、 /lib/libcrypto.so.7 を一旦隠す (ディレクトリを一つ作ってそっちに移動) と X は立ち上がりました。
しかし、xdm で今までは X に -listen tcp をつけて起動していたのが 引き継がれていないことに気がつきました。 どうやら xdm の設定ファイルの場所が /usr/local/lib/X11/xdm/ から /usr/local/etc/X11/xdm/ に変わっていたのが原因でした。
また、/lib/libcrypto.so.7 を隠したせいで、 portupgrade で更新しなかったいくつかのコマンド (w3m や rdesktop など) で /lib/libcrypto.so.7 を引いていたものが起動しなくなってしまいます。 とりあえず、/usr/local/bin, /usr/local/sbin, /usr/local/lib, /usr/local/libexec のコマンドや shared library を ldd で見てみて、 /lib/libcrypto.so.7 を引いているものを ports で一つ一つ手動で更新しました。 これも、正しくは portupgrade で対応できるのではないかと思いますが、 よくはわかりません。 なお、libcrypto.so.7 は、X のモジュールも引いているようで、 それが Xorg.0.log に出ていました (/usrlocal/lib/dri/r300_dri.so, /usrlocal/lib/dri/swrast_dri.so)。 古い dri を削除して、graphics/mesa-dri を入れ直す必要がありました。 で、さらに xorg-server や xorg-drivers なども再インストールしました。
ここまででもかなりの手間で、update ではなく、 もしかしたら一からクリーンインストールした方が速かったかもしれません。
ところが、今回一番困ったのは、X のフォントです。 標準的な日本語フォントだけはでるのですが、 japanese/font-shinonome のように japanese/alias-fonts で入れたものは大半が使えません。 xlsfonts では表示されるのですが、xlsfonts -l ではだめで、 xfontsel, xfd でも japanese/font-shinonome のフォントは全然見れません。 ネットで調べても同様の情報が全くなく、 色々テストを繰り返してみて、ようやく以下のことがわかりました。
xset +fp /usr/local/share/font-shinonome ; xset fp rehash」
のようにユーザレベルでフォントの置き場所を追加しても
使えるようにはならない。
シンボリックリンクを開くことができなくなったのは、 フォントファイルを検索するプログラムかライブラリの 改変によるものだと思いますが、それが意図した仕様の変更なのか、 バグなのかはわかりません。 ただ、そちらが改変されるか、または ports の日本語フォントのインストールを シンボリックリンクする形式をやめるようにしないと、 今後もこの現象が続くことになると思います。
とりあえず私のところでは、ハードリンクにしておこうと思います。
「X に関するメモ (09/22 2017)」 で、 EPSON Endeavor MT-7900 を更新したら X がうまく使えなくなった問題 (fbPolySegment) の話を書きました。 そこでは xorg.conf の Module セクションの修正でうまくいった、 と書きましたが、 実際にはそのマシンの X をほとんど触ってなかったので、 本当はうまくいってなかったことに気がついていませんでした。 今回ちゃんと動くようにできましたので、ここにまとめておきます。
まず、EPSON Endeavor MT-7900 の環境説明にある通り、グラフィックは Intel G31 です。 これは、intel driver では G33 と認識されるようです。
まず、startx や xdm (前はうまくいっていた) を起動すると、 うまくいかないだけでなく、正しく console に戻ってきません。 それは、例のごとく、/boot/loader.conf に「kern.vty=vt」 として vt を使うことでなんとかなりました。
次に、/var/log/Xorg.0.log をみると (EE) 行でこんなのがありました。
(EE) config/hal: couldn't initialise context: unkown error (null)つまり xorg server が hald 版になっていたので、 x11-servers/xorg-server/ で make config して devd 版を作り直して、 「make deinstall ; make install」してそのエラーは消えました。
「X に関するメモ (11/27 2017)」 に書いた Thinkpad の場合のように、xorg.conf を消して試しみましたが、 相変わらず fbPolySegment 等の問題がでて、 このマシンでは、結局以下の 3 つを xorg.conf の Module セクションに入れる必要がありました。
Load "fb"
Load "vgahw"
Load "shadow"
とりあえずこれで Xorg.0.log のエラーはなくなり、 startx で立ち上がりそうになるのですが、 コンソール画面が黒くなったあと、マウスカーソルが出て、 しかしスクリーンは黒いままです。マウスカーソルはちゃんと動きます。 他のマシンからリモートで X のプロセスを kill すると ちゃんとコンソールに戻りますし、Xorg.0.log にもエラーはありません。
intel ドライバでも再インストールしてみるかと、 x11-drivers/xf86-video-intel/ で make config して気がついたのですが、 アクセラレータモードがデフォルトで SNA とかいうものになっています。 Sandy bridge 用の新しいアクセラレータらしいので、もしかしてこれかと、 man intel で確認して、xorg.conf の Device セクションに、
Driver "intel"
...
Option "AccelMethod" "UXA"
なお、handbook によると、最近は、1 ファイルの xorg.conf を書くのでなく、 xorg.conf.d/ にセクション毎のファイルを書くのが主流なんだそうですが、 xorg.conf が長いからでしょうか。 私は xorg.conf は vi ではなく emacs で保守してますので、 xorg.conf でもそんなに長いと思いませんが、 vi で保守することを考えると確かに少し大変かもしれません。
「インストールに関するメモ (11/27 2017)」 に書いた通り、9 月頃に ThinkPad X40 の OS を 10.3 から 11.1 に freebsd-update を使って更新しました。 その際、portupgrade でソフトを更新したら色々 conflict が出て、 llvm37 とか消したりしていたら xorg 回りも消されてしまったので、 X の入れ直し (X.Org 1.18.4, intel driver) をしました。
x11/xorg で make install したのですが、X を立ち上げようとすると panic してしまいます。hint.agp.1.disabled=1 などは既にやっていて、 これを外すと今度は boot すらしなくなります (OK プロンプトで手動でそれを設定しないといけなくなる)。 どうやら、古い xorg.conf (や xorg.conf.d/) があると panic するようで、 それらを消したらなんとか動きました。 近頃の xorg.conf にはたいしたことは書いてないのですが、 最近はそれすらあってはいけないんでしょうか、よくわかりません。
ある意味で、 「X に関するメモ (02/27 2017)」 で報告した、 Toshiba Dynabook (Satellite J40 140C/5, Intel 852GM chipset) の FreeBSD で portsnap + portupgrade したら X が立ち上がらなくなった件の続報になります。
恐る恐るですが、Dynabook よりは少しは新しい EPSON Endeavor MT-7900 で 久しぶりに portsnap + portupgrade しました。 だいぶ色んなものが upgrade されるため結構時間もかかりましたし、 あちこちつっかえて何度もやり直したりしましたが、 なんとか終わりました。 そこは、だいたいいつもの作業 (手動で conflict のものを pkg delete したり あとで ports で追加したり、 multimedia/mplayer の失敗 (01/12 2017) とか、 print/tex-luatex の失敗 (09/26 2016) など) なので省略しますが、問題は X です。
reboot したら残念ながら X が上がりませんでした。 状況は Dynabook (02/27 2017) の場合と同じです。 検索してみたら、一件情報が見つかりました。
最後の方に、intel ドライバの config オプションを変えてコンパイルしてみる、 という話があったので試してみましたが変わりませんでした。 そこで、上の方にある、xorg.conf の Module セクションに
Load "fb"
Load "vgahw"
Dynabook の方はその対応ではだめだったのですが、 とりあえず EPSON Endeavor MT-7900 ではうまくいったようです。 これで、このマシンでは今後も portsnap + portupgrade が 一応はできそうです。
「X に関するメモ 02/20 2017」で報告した、 Toshiba Dynabook (Satellite J40 140C/5, Intel 852GM chipset) の FreeBSD で portsnap + portupgrade したら X が立ち上がらなくなった件の続報です。
具体的には、/var/log/Xorg.0.log に以下のように出ています。
(EE) Failed to load /usr/local/lib/xorg/modules/drivers/intel_drv.so:
/usr/local/lib/xorg/modules/drivers/intel_drv.so:
Undefined symbol "fbPolySegment"
(II) UnloadModule: "intel"
.....
(EE) Failed to load /usr/local/lib/xorg/modules/drivers/vesa_drv.so:
/usr/local/lib/xorg/modules/drivers/vesa_drv.so:
Undefined symbol "shadowUpdatePacked"
(II) UnloadModule: "vesa"
.....
しかし、やはり状況が変わりません。 ドライバのコンパイル時の config.h や xorg-server.h などを比較しても古いものとの違いはないのですが、 intel_drv.so のサイズは古いものとは違っています。 ldd しても引いている shared ライブラリに若干違いがあります。 どこに原因があるのか、どこを修正すれば改善するのかは ちょっとわかりませんでした。
結局、どこまで、どれをダウングレードすれば解決するのか がわかならなかったので、portdowngrade をあきらめて、 もう少し一式まとめて古いものに置き換えてしまうことにしました。 最初は、/usr/local/lib/xorg あたりとサーバ /usr/local/bin/Xorg をまとめて古いものにすればいいかと思ったのですが、 /usr/local/lib のライブラリを引いているファイルもあるので、 そういう怪しげな方法はあきらめて、最終的に以下のようにしました。
2. の ports ツリーの交換ですが、 幸い近くに同じバージョンの FreeBSD マシンで ports を最新のものに更新してなかったものがあったので、 それをそっくりコピーしました。 おかげで無事に前のように X が立ち上がるようになりました。
もちろんあまりお勧めできる手順ではなく、 最後の手段といった感じですが、 他の方法は今のところわかりません。 pkg の全削除、全インストールし直しは普通は抵抗もあるでしょうが、 私は前回一度それをやっていましたし、 大きいものは firefox や TeX 以外は入れてありませんので、 個人的にはそれほど抵抗はなかったです。
今後は、portsnap + portupgrade は、 癖のあるマシンでは少し控えようかなと思っています。
(cf. 「X に関するメモ (09/22 2017)」)
私は適宜 freebsd-update して portsnap, portsupgrade もしているのですが、 先日 Toshiba Dynabook (Satellite J40 140C/5, Intel 852GM chipset) (「インストールに関するメモ (04/19 2013)」) で portsnap, portupgrade したら、 X のサーバ、intel ドライバなどが更新されたようで、 X (xdm) が立ち上がらなくなりました。 X のサーバは xorg-server-1.18.4、 intel ドライバは xf86-video-intel-2.99.917.20170103 です (多分)。
/var/log/Xorg.0.log を見ると、intel ドライバば load できない、 と出ていて、fbPoly なんたらの symbol が見つからないとか出ています。 どうやらそれは、/usr/local/lib/xorg/modules/libfb.so に含まれているようなので、 /etc/X11/xorg.conf の Module セクションで「Load "fb"」 を追加すると、それは解消されるのですが、 また他のものが見つからないとでます。 そして最後に vgaHW なんたらの symbol が見つからないということの解消のために 「load "vgahw"」と書いて startx したら reboot してしまいました。
vesa の方も shadow なんたらの symbol が見つからないというので 「load "shadow"」して startx したらエラーは出なくなったのですが、 うまく立ち上がってくれませんでした。 もう少し試してみたいと思いますが、 いざとなったら別の PC の /usr/local/bin/Xorg や /usr/local/lib/xorg などのバイナリを使って少し前の X のサーバ (xorg-server-1.17.4, xf86-video-intel-2.21.15_9) 等に戻してやるとかするしかないかもと考えています。 ネットで検索しても似たような情報はあまりありませんが、 また何かわかったら報告したいと思います。
(cf. 「X に関するメモ (02/27 2017)」)FMV-6333T7 の FreeBSD 10.2 で X に関して一点はまったことがありますので、紹介しておきます。
先日、portupgrade -a を使って、package の更新を行ったのですが、 その際 Xorg server も 1.14 から 1.17 に更新されました。 しかし、それから急にリモートホストの X クライアントが立ち上がらなくなりました。
私はこのマシンの X は xdm 等ではなく、 コマンドラインから startx (x11/xinit) を使って起動しているのですが、 その後他のホストの xload や xbiff, kterm などを実行しています。 それらが一斉に起動しなくなりました。
手動で xhost や DISPLAY の設定などをやっても、 「Can't open display hoge:0.0」のように返されるだけです。
色々調べてようやくわかりましたが、Xorg の 1.17 系では、 デフォルトでは TCP アクセスを受け付けないようになっているようで、 TCP アクセスを許可するためには、 「-listen tcp」オプションをつけて実行しないといけないようです。 startx では X サーバ向けのオプションは「--」の後ろにつけて起動しますので、
% startx -- -listen tcp
古いメモを読むと、かなり昔似たようなオプションがあったようです (「-listen_tcp」とアンダースコアが入る) が、 またそれに似たものが復活してきたということでしょうか。 しかし、その辺りの説明がなかった (見落した ?) ので、 正解にたどりつくまでかなり苦労してしまいました。
FMV-6333T7, および Toshiba Dynabook (Satellite J40 140C/5, Intel 852GM chipset) (「インストールに関するメモ (08/21 2012)」, 「インストールに関するメモ (04/19 2013)」 参照) で OS を FreeBSD 8.4 から 10.2 に上げたのですが、 その X について書いておきます。
まず、FMV-6333T7 ですが、 graphic card は Matrox Millennium G200 (8MB) なので、 x11/xorg 以外に x11-drivers/xf86-video-mga が必要で、 これでとりあえず X は動くようになりますが、 /var/log/Xorg.0.log を見ると、以下のエラーが出ています:
(EE) AIGLX error: dlopen of /usr/local/lib/dri/mga_dri.so failed (Cannot open "/usr/local/lib/dri/mga_dri.so")確かにそのようなファイルはありません。 graphics/dri でもそれをインストールはしないようで、 graphics/linux-f10-dri にはあるようですが、 まあ動いてはいるのでとりあえずは置いておきます (swrast_dri.so はある)。
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Loaded and initialized swrast
また、mouse, keyboard が Disable になっているので調べてみたら、 今の X (Xorg 1.14.7) では、hald を使わなくなって devd を使うのだそうです。 ということで、/etc/X11/xorg.conf.d/ を作って、 以下を参考にして、そこに input.conf を作りました。
hald, dbus は /etc/rc.conf から追い出しました。 しかし、FreeBSD ハンドブックは、いまだに hald, dbus で書いてあるので、 知らない人は今後もでるのではないでしょうか。 なお、このマシンでは、一般ユーザからの startx も問題なく動いています。
もう一台の dynabook の方ですが、こちらは少し厄介でした。 まず x11/xorg を入れて、前の xorg.conf を使って startx してみたり、 Xorg -configure をやってみたりしたのですが、 起動するとすぐに reboot してしまいます。 これも、10.2 OS の場合と同じく、 以下からのスレッドによる情報でわかりましたが、 /boot/loder.conf に「set hint.drmn.1.disabled=1」がいるようです。
うちの Dynabook も Intel 852GM chipset なので、 共通の問題なのだろうと思います。 しかし、これで一般ユーザで startx すると OS は落ちなくなったものの、 black のままで X が正常には立ち上がりません。 C-A-F1 をしてみると、「Protocol not supported by server」というメッセージが ゆっくり出続けています。それで X がうまく起動していないのかもしれません。 driver は intel を使っていましたが、vesa でもだめで、 vesa だと C-A-F1 も効きません。
結局、intel で root で起動したらちゃんと X が立ち上がったので、 以前と同じく xdm を使うことにしました。これでほぼいけてます。 hald, dbus を切って input.conf を作るのは上と同じです。
ただし、この dynabook に firefox を入れたところ、 「/etc/machine-id がない」とかいうメッセージが出て起動しませんでした。 調べてみると、それには dbus がいる、とかいうことのようなので、 rc.donf に dbus_enable="YES" を入れて dbus を起動しました (service dbus start)。 これで firefox も使えるようになりました。
Sun Blade 150 に入れた FreeBSD/sparc64 での X について書いておきます。 FreeBSD/sparc64 では X は package インストールできないので、 x11/xorg-minimal とか x11/xorg とかの ports でコンパイルして インストールします。相当時間がかかります。
X のドライバは、当初 sunfbb かなと思ったのですが、 「Xorg -configure」では vesa になりますが、 Blade 150 のグラフィック (ATI Rage XL) は、 mach64 ドライバを使用するようです。以下に情報がありますが、 モニタの設定と ReferenceClock の設定をすると、 もちろんディスプレイによりますが 1280x1024 位は出るようになります。
なお、このページの設定では、「Driver "mach64"」と 「Driver "ati"」の 2 つが書かれていますが、 「Driver "mach64"」だけでいいようです。 ati ドライバは逆にインストールできません (i386, amd64 のみ)
なお、X を startx で起動したのですが、X を終了すると black out します。 10.1 なので vt が使えるかと思って kern.vty=vt を /boot/loader.conf に入れてみたのですがどうもうまくいきません。 まあ xdm で運用するようにすればそれほど問題はかなろうとは想像しています。
ThinkPad X40 (Intel 855GME) の FreeBSD 10.1-RELEASE + vt + Xorg (intel driver) が うまくいったことに気をよくして、ついでに MB-B401B2 (Ironlake) も同じ環境にしてみたのですが、これもあっさりうまくいきました。 intel ドライバで苦労していたのがうそのようです (外部出力のテストはまだ)。
実は、もう一台、Lenovo B590 (Celeron 1005M, Ivy Bridge) のノート PC が別にあり、 これも MS-Windows 7 professional と FreeBSD 10.0 の dual boot にしてあった (MB-B401B2 とほぼ同じ環境) のですが、 これも X は vesa しか動かず intel はうまく動かないし、 X を抜けるとブラックアウトする、という他と同様の障害だったのですが、 上記と同じ FreeBSD 10.1-RELEASE + vt + Xorg (intel driver) にしたところ あっさり動作しました。1366x768 のワイド画面もちゃんとでています。
vt コンソールが X から戻ると解像度が起動時とは変わって 文字が小さくなってしまうようですが、 それでもブラックアウトせずにちゃんと使える形で戻るのは大きいですし、 何より intel ドライバがそれなりに動作するのがいいです (まだ「安定」して動作するかどうかまで確認はしていません)。 これまで intel ドライバで苦労していたのが嘘のようです。
しばらくこのページを更新していませんでしたが、 ThinkPad X40 (Intel 855GME) は現在は FreeBSD 10.1-RELEASE にしていて、 X は intel ドライバで使用しています。
10.0-RELEASE で、/etc/make.conf に WITH_NEW_XORG=yes, WITH_KMS=yes を入れて xorg を入れたのですが、 最初 vesa でやりましたが、特に問題はないようでした。 ただし、以前試したときには vesa では外部出力に問題があり、 ディスプレイ画面と外部の両方にでるようにはできませんでしたので、 intel ドライバで動かしてみました。 それも以前とは違い、X を落とすとブラックアウトすること以外は 特に問題なく動作するようでした。 外部出力も、ディスプレイ画面とプロジェクタの両方にすんなり出ました。
その後、freebsd-update で FreeBSD 10.1-RELEASE に更新し、 vt を有効にした (/boot/loader.conf に kern.vty=vt を入れる) ら、 X を落とした後もコンソールがブラックアウトしなくなったようです。 まだテストは十分ではありませんが、 これならそれなりに使えるかもしれません。
「X に関するメモ (06/21 2012)」、 「X に関するメモ (06/15 2012)」 で、 ThinkPad X40 (Intel 855GME) と MB-B401B2 の 2 台のノート PC での X の話を書きました。
しかしいずれもあまりに不安定なため、現在は使用していません。 特に、本来の目的はプロジェクタにつないでプレゼン用に、 ということだったのですが、そのあたりが全くだめです。 MB-B401B2 の方は出たりでなくなったりするし、 ThinkPad X40 の方は X 自体がかなり不安定です。 ということで、現在は両者ともまともに使っていません。
「X に関するメモ (06/15 2012)」 に、 ThinkPad X40 (Intel 855GME) も intel ドライバのバージョンを上げれば (2.17.0) うまくいくかもしれない、 と書きましたが、その後試してみましたので、簡単にまとめておきます。
結論から言えば、FreeBSD 9.0-STABLE (with KMS) + Xorg 1.10.6 にして、 新しい intel ドライバ (2.17.0) でとりあえず X の画面が出るようにはなったのですが、いくつか問題があります。
1., 2. は MB-B401B2 の場合と同じ症状ですが、 3. は MB-B401B2 では一般ユーザでも startx でちゃんと立ち上がりますので、 ThinkPad X40 特有の現象です。 また、4. が最も問題なのですが、 マウス (トラックポイント) の反応がすごく遅く、 移動させようとしても一拍後にガタッガタッっという感じで スムーズには動いてくれません。 9.0-Release + vesa のときはこんなことはなかったので、 これは intel ドライバ、あるいはそれと 855GME との相性などの問題ではないかと思います。
検索すると、動作が遅い場合は AccelMethod のオプションを設定してみたら、 という情報がありましたが、やってみても変化はなく、 実際ログを見るとそのオプションは無視されてしまうようです。 他のオプションも試してみましたがいずれもうまくいきませんでした。 残念ながらこのままではちょっと使える状態ではありませんので、 9.0-RELEASE に戻して vesa でしばらくは使おうかなと考えています。
なお、その vesa なのですが、ThinkPad X40 では 液晶ディスプレイと外部出力の両方を同時に表示することができません。 Alt-F7 で両者の切り替えはできるのですが、同時には一方しか出せません。 BIOS の設定で Video 出力を両方 (Both) に選択しても 残念ながら変化はありませんでした。 また、接続のタイミングが悪いと 1024x768 も出なくて 800x640 になってしまうこともあるようです。
以前、Intel Ironlake Chipset のマウスコンピュータのノート PC MB-B401B2 での X の話を書きましたが (「X に関するメモ (09/08 2011)」)、 その後前進がありましたので報告します。
元々 MS-Windows では 1366x768 のワイド画面が使えていたのですが、 FreeBSD (8.2, 9.0) の X では vesa でしか使えず、 しかも 1024x768 の横に伸びたような表示しかできていませんでした。 vesa でも 855resolution, 915resolution (ports の sysutils/915resolution) を使えばワイドの設定ができるのでは、という情報がありましたが、 MB-B401B2 の Ironlake Chipset は認識してくれず、だめなようです。
先日、以下のサイトで、 「FreeBSD を 10-CURRENT にして、KMS が使えるようにすると、 新しい intel ドライバで多くの chipset が使えるようになる」 という情報を見つけました。
実は、OS はすでに 9.0-RELEASE に入れ直してあったので、 10-CURRENT に cvsup で上げてみたのですが、 そこで紹介されている KMS 用のパッチがうまく当たらず、 パッチの日付から類推して 10-CURRENT の 7 月末位のものに替えてみたらちゃんとパッチは当たって、 カーネルの作り直しまではできたのですが、 そのカーネルでのブートがうまくいきませんでした (ブートの途中で死んでしまいます)。
上記のサイトを再び確認したら、現在はそのパッチは 9-STABLE (RELNG_9) や HEAD (10-CURRENT) には取り込まれているようで、 以下の情報をまた新たに見つけたので、 もう一度 9.0-RELEASE を入れ直して、 9.0-STABLE にしてからやってみることにしました。
9.0-RELEASE を入れた後、上記サイトに従って cvsup で RELNG_9_0 (9.0-STABLE) の src-all を持ってきて、 KMS 用のパッチを当てて kernel を再構築します。
次は、X のインストールの前に ports を cvsup で更新します。 こちらは tag=RELNG_9_0 ではなく、 tag=. で最新のものに更新する必要があるようです。 ports を更新せずに 9.0-RELEASE 用の ports のままだと、 上記サイトのようにやっても Xorg の新しいもの (1.10.6) はインストールできませんでした。 ports を更新したら (make index もやったら)、 後は上記サイトに従って Xorg をインストールするのですが、 手元では、前にインストールした X 関連のものがいくつか残っていたりしたので、 更新にはだいぶ手間取ってしまいました。
なお、intel ドライバについては、ports の x11-drivers/xf86-video-intel/files/ にある extra-i915kms のパッチが当たると、 うちでは「i915kms kernel module がロードできない」 (実際に i915 ドライバしかありません)、 と言われてしまうので、そのパッチを当てないようにしました。 これでなんとか intel ドライバで X を立ち上げることができ、 めでたく 1366x768 の画面が立ち上がるようになりました。
ただし、最初はマウスもキーボードも使えず、これまでは同様の症状に効いていた 「Option "AllowEmptyInput" "off"」 も効かず、ログにも 「(WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.」などと出ていて困っていましたが、 調べてみると、今は「Option "AutoAddDevices" "off"」 とするといいようです。
ただ、まだ完全に安定しているとは言えず、 例えば X を落としてもコンソール画面が復帰してくれません。 他にも問題があればまた報告したいと思います。
「X に関するメモ (06/05 2012)」 に書いた、 ThinkPad X40 の Intel 855GME も、 もしかしたら同じ方法で intel ドライバのバージョンを上げれば うまくいくかもしれませんので、 時間があるときにそちらも試してみたいと思います。
(cf. 「X に関するメモ (06/21 2012)」)
他の研究室からもらった ThinkPad X40 に FreeBSD 9.0 を入れ、Xorg 1.7.7 を入れてみました。 簡単にまとめておきます。
「#Xorg -configure」でできる xorg.conf を見ると、 chip は intel ドライバが設定されています。 しかしそのままそれを使って立ち上げるとハングアップします。 /var/log/Xorg.0.log にもログが残らないので、 かなり早い段階でハングアップしているようです。
また、なぜか 2 つのスクリーンがデフォルトで書かれていて、
Section "ServerLayout"
.....
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
ログにも残らないのでどうしようもありませんが、 インターネットで検索してみると、 i810 ドライバを使うとか、 「Option "NoAccel" "true"」する、 といった話が見られるのですが、 FreeBSD には i810 はありませんし、 /usr/ports で intel, intel29 を試してみてもいずれもだめ、 NoAccel もだめ、ということで intel ドライバは結局うまくいきませんでした。 実際、「Intel 855GM はいいけど、X40 に載ってる 855GME はだめ」 という情報もあるようです。
しょうがないので vesa ドライバを使用したらあっさり使えました。 解像度はとりあえず 1024x768 で、 1280x1024 が使えないかと色々試してみましたが、 残念ながら 1280x1024 は無理なようでした。
(cf. 「X に関するメモ (06/05 2012)」)
卒研中間発表会のプレゼンテーション用に設定をしている EPSON Direct のノート PC EdiCube F750 ですが、いくつか設定でつまづいたところがありますので、 備忘録代わりに書き残しておきます。
Ctrl-Alt-BS で X が落ちません。 調べてみると、今は xorg.conf に
Option "DontZap" "off"を入れて、
# setxkbmap -option terminate:ctrl_alt_bkspか、または xorg.conf の InputDevice セクションに
Option "XkbOptions" "terminate:ctrl_alt_bksp"が必要なんだそうです。なんかいつの間にか面倒になりました。 これが有効かどうかは、「xkbcomp $DISPLAY」として出てくる 「key <BKSP>」のエントリが
key <BKSP> {のようになって確認できるようです。
type= "CTRL+ALT",
symbols[Group1]= [ BackSpace, Terminate_Server ]
};
外部ディスプレイにつなぐと、 X が起動して両方の画面に表示が出るまで 1 分位かかりました。 まあそういうものなのかなと思っていたのですが、 次は実際の講義室に持っていってプロジェクタにつないでみたら、 いつになっても X が立ち上がってくれませんでした。 Ctrl-Alt-BS, Ctrl-Alt-DEL などにも全く反応しません。 こうなるとしかたないので、電源ボタンを押して強制的に止めるしかありません。
色々テストしてみたら、 なぜかネットワークをつないでいないと X が立ち上がらないことに気がつきました。 特別にネットワーク用の設定をしたわけでもありませんし、 NIS も動かしていません。xdm 環境でも startx でもいずれもだめです。
なんらかのネットワークの問い合わせをして タイムアウトを待っているのかと思いましたが、 tcpdump で見てもなんのパケットも出していないようでした。 /etc/nsswitch.conf や /etc/hosts を修正しても変化ありません。
最終的には、問題の起こる場合のコンソール画面に drm 関係のメッセージが出ていた ([drm] Loading R300 Microcode とか) ことをヒントに、 xorg.conf の Module セクションの
Load "dri"を
Load "dri2"
Disable "dri"に変えて dri モジュールを無効にすることでこの問題は解消し、 ネットワークにつながなくても X が立ち上がるようになりました。 この EdiCube F750 と drm ライブラリとの相性の問題なのか、 理由は全くわかりませんが、 それまでは、xdm 環境でログアウト後も 次のログイン画面が出るまで 1 分くらいかかっていたのですが、 それもだいぶ短くなったような気がします。
Disable "dri2"
なお、外部のプロジェクタも xrandr でリセットすればちゃんと 1280x1024 が出るようですが、それだとプロジェクタの文字が少し小さいので、 デフォルトの 1024x768 での使用が良さそうです。 本体の LVDS (液晶) の方もそれに合わせて 1024x768 にしています (最大は 1400x1050 が出る)。
学生は主に Fvwm95 を使っているのですが、 これでプレゼンテーションしようとすると、 一番下にあるタスクバー (FvwmTaskBar) は 常にウィンドウ前面にでるので邪魔ですし、 fvwm95 の「ウィンドウの移動」用のメニューは root ウィンドウ上のマウス中ボタンで出るのですが、 このマシンでは中ボタンは左右のボタンの同時クリックによる エミュレーション (中ボタンらしきスイッチは認識していない) なので、 ウィンドウの移動にこれを使うのは操作性がかなり悪いです。
特に、acroread をフルスクリーン表示から復帰させると、 なぜか少し上に移動していて acroread のウィンドウバーやメニューが見えない状況になるので、 fvwm95 のメニューによるウィンドウの移動が必要になります。 よって、.fvwm95rc の設定で、
としました。 これでそれなりに使えるようになったのではないかと思います。
新しく買ったマウスコンピュータのノート PC MB-B401B2 に FreeBSD 8.2 を入れて、Xorg を入れてみました。 卒研発表会のプレゼンテーション用なので、外部出力、 および Magicpoint, xpdf, Acrobat Reader などを動作させることが目標です。 ディスプレイは 14 のワイド型で解像度は 1366x768、 グラフィックはオンボードの Intel Ironlake Mobile Graphics Controller です。
X の標準的なセットを package, ports でインストールして、 Xorg -configure でデフォルトの xorg.conf を作ったところ、 ドライバは vesa が使用されました。 しかし、vesa ドライバでは、1024x768 以上の解像度は出ませんでしたし、 1024x768 は 4:3 で 1366x768 の 16:9 とはかなり違いがあるため、 アスペクト比が正しくならず、kterm も表示される文字も、 すべて横長になってしまいます。
また、外部ディスプレイへの出力がうまく行きません。 OS のブート時に外部ディスプレイをつなぐとそちらにはでるのですが、 今度は本体のディスプレイに何も表示されません。 F2 などをやっても応答なしです。 xrandr で見ても、vesa ドライバのせいか出力は 1 つしか表示されず、 切り替えることができません。 解像度も、本体のディスプレイは 1024x768 以上あがりません。
よって、無理矢理やればブート時にプロジェクタにつなげば X の画面を出せないことはないのですが、 本体のディスプレイには出ないので使いづらく、 プレゼンテーションにはちょっと使えません。
また、xdm にすると、シャットダウン時にコンソール画面に復帰しない、 という現象も起きました。
汎用の vesa でなく、 intel ドライバが対応してくれればなんとかなりそうですが、 残念ながら Intel Ironlake には対応していないみたいで、 intel ドライバで立ち上げても対応するデバイスが見つからない、 と言われます。 FreeBSD の ports にある xf86-video-intel29 が ironlake 用のようなのですが、ports で make すると
xf86-video-intel29-2.9.1 we have to wait of GEM support to get ironlake chips to work.などと言われて止まります。 しばらくは、これが対応するまで待つしかなさそうです。
ちなみに、EdiCube F750 の方は、 Driver を radeon にしたら液晶ディスプレイは 1400x1050 が出て、 外部もちゃんと認識され、
xrandr --output VGA-0 --auto
(cf. 「インストールに関するメモ (09/08 2011)」, 「インストールに関するメモ (09/08 2011; no.2)」, 「X に関するメモ (06/15 2012)」)
現在 VZ-3000 で FreeBSD 8.1 + X.org 1.7.5 を使用しているのですが、 テンキー付きの標準的な 106 キーボードにやや不満があったので、 いくつかのキーボード (サンワサプライのコンパクトキーボード、 HHK Lite2, HHK Professional JP 等) を試してみて、 現在は東プレの RealForce 91 (PS/2) を使っています。 いずれの場合もキーは xmodmap で自分の打ちやすい配列に変えていますが、 その xmodmap に関して問題がありましたので、 備忘録も兼ねてここにあげておきます。
まず、サンワサプライのテンキーレスのコンパクトキーボード (USB) は パンタグラフ式のせいか、キー入力が少し疲れるし、 隣のキーを打ちやすいこと、 また boot 時と X の起動時に Num Lock の状態になってしまう、 右 Shift が遠い (上矢印キーの右) ので xmodmap で入れ変えたのですが それだと Shift キーが小さくて打ちにくい、 などの問題を感じていました。
次に Happy Hacking Keyboard Lite2 (USB) に変えてみたのですが、 これはキー配列にはそれほど不満はなかったのですが、 やはりキータッチに関する不満と、 これに変えてから X の起動時によく HD のアクセスランプが つきっぱなしになってキー入力が何も効かなくなる (Ctrl-Alt-BS 等も) 現象が起きるようになってしまいました。 こうなると別のマシンから remote ログインしてブートするしかありません。
そして HHK Professional JP (USB) に変えてみたのですが、 これはやや高級品なだけあってキータッチはいいのですが、 少し HHK Lite2 とはキー配列が違っていて サンワのと同様右 Shift が遠い (上矢印キーの右) のが難点でした。 よってしばらく親指シフトにして使ってみましたが、 なかなか慣れませんでした。
その後、東プレの RealForce 91 (PS/2) に変えてみたのですが、 これは矢印キーが右に分離しているので、 大きめの右 Shift がちゃんと付いているし、 左 Ctrl (本来の Caps-Lock; 入れ替えている) も大き目なので、 Emacs ユーザとしては打ちやすくて助かっています。 最前列に変換キーやカナキーなど不要なものがあるために スペースキーがやや小さいのですが、スペースキーの両脇の変換キー、 無変換キーも無理矢理スペースに変えて使っています。 ただ、矢印キーがやや離れているので、 矢印キーを使うときは手を離さないといけないのが、 HHK Lite2 に比べると難点かなと思います。 個人的には、HHK Lite2 の配列で HHK Professional JP のキータッチのものがあればいいのかな、と思います。
さて本題はここからなのですが、 この RealForce でも xmodmap でキーマップを色々入れかえているのですが、 modifier キーの設定でうまく行かないところがありました。
まず、/etc/rc.conf で keymap="jp.106x" としているので、 X の前のレベルで左 Ctrl と Caps-Lock が入れ変えてあります (cf. /usr/share/syscons/keymaps/jp.106x.kbd)。
xmodmap では、いくつかのキーの変更 (~ と ` の入れ替え、 スペースの両脇をスペースに、左上角の半角/全角を ESC に) をした後で、以下のことをやろうとしました。
これは、Caps-Lock (左下角の元々は左 Ctrl) は、 手の左側でたまに押してしまうことがあることと、 右 Ctrl はほとんど使わないためです。 これらを行う場合、.Xmodmap ファイルは多分次のようにするはずです:
!! Caps-Lock (左下角の元々の左 Ctrl) の keycode = 37しかしその後 xmodmap -pm で確認すると、 なぜか keycode 37 の Shift_L が lock にあったり、 keycode 109 の Caps_Lock が control にあったりしていました。 さらに以下のようなエラーが出ました:
!! 右下角の右 Ctrl の keycode = 109
remove lock = Caps_Lock
remove shift = Shift_L
remove control = Control_R
keycode 37 = Shift_L
keycode 109 = Caps_Lock
add shift = Shift_L
add lock = Caps_Lock
X Error of failed request: BadValue (integer parameter out of range for operation)これは、xmodmap -e で一行ずつ実行しながら確認すると、 最後の "add lock = Caps_lock" で出ているようでした。 検索すると、同様のエラーが xorg のバグとして報告されているようだったので、 しばらく色々試してみたら、以下のような回避策を見つけました。
Major opcode of failed request: 118 (X_SetModifierMapping)
Value in failed request: 0x17
Serial number of failed request: 11
Current serial number in output stream: 11
ということで、現在は以下のような .Xmodmap ファイルを使用して、 .xinitrc スクリプトで setxkbmap を実行した後で xmodmap ~/.Xmodmap を 実行することでうまくいっています:
!! ~ と ` の入れ替え本来は、もちろんバグの修正された xorg を使うのが筋でしょうが、 このような回避策、または回避策の探し方もある、 ということであげておきます。
keycode 21 = asciicircum grave
keycode 34 = at asciitilde
!! スペースの両脇をスペースに
keycode 129 = space
keycode 131 = space
!! 左上角の半角/全角を ESC に
keycode 49 = Escape
!! CapsLock を左 Shift に、右 Ctrl を CapsLock に (workaround)
remove lock = Caps_Lock
remove control = Control_R Control_L
keycode 37 = Shift_L
keycode 109 = Caps_Lock
add shift = Shift_L
add lock = Caps_Lock
remove lock = Control_L
add control = Control_L
EPSON Direct のノート PC EdiCube に FreeBSD 8.1 + Xorg 1.7.5 をインストールしましたので、 ここに備忘録としてまとめておきます。
まず xorg は、handbook に従って
# setenv PACKAGESITE ftp://ftp3.jp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/latest/でインストールしました。X -configure で /root/xorg.conf.new を作ると、 graphics は ATI RV350 [Mobility Radeon 9600 M10] と表示され、 vesa ドライバで動くようでした。よって、 xkbcomp, xclock, xterm, twm を pkg_add でインストールした後、 startx で起動しましたが、キーボードとマウスが動きませんでした。
# pkg_add -r xorg-minimal
キーボードは /etc/X11/xorg.conf に
Section "Serverflags"を、マウスは "/dev/sysmouse" を "/dev/psm0" にすることで動くようになりましたが、Ctrl-Alt-「+」, Ctrl-Alt-「-」, Ctrl-Alt-BS が使えていません。「Option "DontZap" "No"」、 「Option "DontZoom" "No"」 のようなものを入れても変化ありませんでした。
Option "AllowEmptyInput" "No"
EndSection
解像度は、デフォルトでは vesa ドライバで 1400x1050 (SXGA+) が出ているようですが、 xf86-video-ati, xf86-video-radeonhd を追加インストールして X -configure すると radeon ドライバを使う設定になります。 しかし、これで起動すると画面が暗いままで何も出なかったり、 X が立ち上がっても X を落とすと画面が暗いままでコンソール画面に復帰しない (OS は生きている) 状態になったり、復帰にだいぶ時間がかかったりしました。 ati ドライバに設定しても実際には radeon ドライバが使われるようで、 症状は変わりませんでした。 よって今は vesa に戻してあります。
また、vesa ドライバでも、
Modes "1400x1050" "1280x1024" "1024x768" "800x600" "640x480"や、
Modes "1024x768" "800x600" "640x480"と指定するのは問題ないのですが、 デフォルトの解像度を 1024x768 あたりにして 1400x1050 も選択できるように
Modes "1024x768" "800x600" "640x480" "1400x1050" "1280x1024"とするとなぜかうまく表示されず画面が崩れてしまいます。 どうせ、Ctrl-Alt-「+」、Ctrl-Alt-「-」が使えていないので、 後者のような書き方は今は使っていません (cf. EdiCube 用の xorg.conf xorg-edicube-20100927.conf)。
VZ-3000 に FreeBSD 8.1 をインストールしたので、 X もそれに合わせて更新したのですが、 前の形 では立ち上がらなくなって、多少苦労しましたので、 ここに備忘録としてまとめておきます。
Graphic デバイスはオンボードの ATI Mach64 3D Rage Pro (8MB)、 Display は FMV-DP978 で同期周波数は、 富士通の情報 によれば水平が 30-70kHz, 垂直が 50-150Hz です。
まずパッケージから Xorg-server, (nest,vfb,xfstt 等も)、 xf86-input-keyboard, xf86-input-mouse, xf86-video-ati, xf86-video-vesa, xf86-video-fbdev, xorg-drivers, xkbcomp, twm, xclock, xterm, およびフォントを入れ、
# X -configureとしてできた /root/xorg.conf.new を、 以前の xorg.conf に合わせて書き直してみたのですが どうもうまくいきませんでした。
まず、Device セクションの Driver は ati でも mach64 でも、 /var/log/Xorg.0.log を見ると mach64 を使っているようなので mach64 でいいようなんですが、以前 X.org 6.8.2 ではうまくいっていた Depth 16 の 1280x1024 を指定して X を立ち上げると OS が reboot してしまいます。1024x768 でも同じでした。 Depth 8 にすると reboot はしないのですが真っ黒のままです。
Driver を vesa にすると一応立ち上がるようになるのですが、 vesa だと Depth 8 でも 1280x1024 が出てくれません。
Monitor の DisplaySize を指定して (xorg.conf.new でコメントアウトされているものを外す)、 mach64 で Depth 8 で試してみるとようやくちゃんと立ち上がり、 1280x1024 も出るようになりました。 どうやら Depth 16 だと reboot してしまいますが、 Depth 15 なら 1280x1024 でもちゃんとでるようです。
また、Serverflags セクションに
Option "AllowEmptyInput" "No"を書かないとマウスもキーボードも反応しないようです。 結局、今のところ以下のような xorg.conf でうまくいっています。
なお、最初は一般ユーザとして手元に xorg.conf を書いたものを
% X -config xorg.confのように起動してみたのですが、/var/log/Xorg.0.log に 「Unable to locale/open config file: xorg.conf」とか出てしまいました。 root でやればいいのかもしれませんが、とりあえず、 root になってそのローカルの xorg.conf から /etc/X11/xorg.conf にリンクを貼って一般ユーザでテストをしました。 これだとちゃんと /etc/X11/xorg.conf を読んでくれます。
また、startx は現在は xinit に入っているので、 /usr/ports から xinit, xorg-cf-files, xauth などを入れて startx でテストを行いました。
Vz 6000 が動かなくなってしまったので、代わりに Epson Direct の MT7900 を買って、 FreeBSD 8.0-RELEASE をインストールしました。 USB メモリからインストールしたのですが、 それはあっと言う間に (ほんの数分で) 終ってしまいました。
その後、X.org をパッケージからインストールしたのですが、 これが少し苦労しましたので、ここにまとめておきます。
MT7900 のビデオボードはオンボードの Intel G31 Express というもののようです。 これは、intel ドライバが対応しているらしいので、 それで設定しようと思ったのですが、 package インストールした X.org-1.6.1 (xorg-server-1.6.1,1) に xorgconfig がついていません。 調べてみると、どうやら root で X -configure として自動的に生成される /root/xorg.conf.new を使うらしいです。
マウスやキーボード、モニタに関する設定をして、再び root で
# X -config /root/xorg.conf.newとしたのですが、display はリセットされるのですが 真っ黒のまま何も出てきません。 /var/log/Xorg.0.log にも、エラーらしきものはなく、 動作しているような雰囲気すらあります。 Ctrl+Alt+F1 で console に戻して Ctrl+C で終了させないと復帰できません (Ctrl+Alt+BS も効きません)。
その後、intel ドライバがいけないのかと思い vesa ドライバにしてみたのですが、 多少エラーメッセージのようなものが出るものの、 あまり変化はありませんでした。
この intel chip に X が対応してないのかと思って、 手元にあった Knoppix (Knoppix math 2007, Knoppix 5.3.1/DVD, Knoppix 6.0.1/CD) でそれぞれブートしてみたのですが、 多分これらは vesa ドライバだと思いますが、 表示はされるものの解像度が変だったり、マウスがうまく使えなかったり、 とややおかしな挙動を示しました。
ということで一旦オンボードの Intel G31 Express をあきらめ、 実績のあるビデオボードを入れてみました。 使用したのは、PCI-Express 用の ATI Radeon HD4500 です。 これは、radeon ドライバ、ati (generic) ドライバなどで対応しているようですし、 vesa でもいけそうです (radeonhd も OK ?)。 で、これで上と同じことをやってみたのですが、 やはり状況は変わらず、相変わらず root で
# X -config /root/xorg.conf.newとすると真っ黒のままでした。 モニタを LCD ではなく別のブラウン管のものに変えてみたのですが状況は同じです。 しかし、これは Knoppix ではちゃんと正しく立ち上がります (LCD で 6.0.1 の場合はだめだった)。
ということは、モニタやビデオカード等が悪いのではない、と思い、 一旦作成された xorg.conf.new を /etc/X11/xorg.conf としてコピーし、 root ではなく一般ユーザとして startx してみたら、 なんと X がちゃんと立ち上がりました。 ドライバは ati でも radeon でも vesa でも (radeonhd でも) 問題ありませんでした。
ならば、と思い、この ATI Radeon HD4500 を抜いて、 intel ドライバで startx してみたら、 これもちゃんと X が立ち上がりました。
ということで、原因はよくわかりませんが、 どうやら root で「X -config [config file]」とすることに問題があったようです。 なお、一般ユーザでは「X -config [config file]」とするのは問題があるようで、 指定した config ファイルを見てくれないようです (単にパーミッションの問題だったのかもしれませんが)。 よって、少なくともうちでは以下のような順をたどればよかったようです。
ただ、今のところ、Ctrl+Alt+F1, Ctrl+Alt+F2 等は効くものの、 Ctrl+Alt+BS や Ctrl+Alt+(+|-) が使えていません。
Section "ServerFlags"のようなものは入れてあるのですが、だめなようです (AllowEmptyInput を削ると Ctrl+Alt+F1 等も使えなくなる)。
Option "DontZap" "off"
Option "AllowEmptyInput" "off"
EndSection
FMV-6333T7 には元々 graphics card は AGP バスに Diamond FireGL 1000 Pro (4MB) が入っていたのですが、 それを multihead の Matrox Millennium G450DX/D32AD (AGP) にしてしばらく使っていました (cf. 「X に関するメモ (08/29 2006)」)。
その後 Vz6000 がだめになってしまったので、 その入っていたハードディスクを急遽 FMV-63333T7 につなぎ直して代用にしたのですが、 その際、FreeBSD 7.0 + X.Org 1.4.0 用に xorg.conf を書き直しました。 ただ、代用なので multihead ではなく singlehead として使ってました (cf. FreeBSD-7.0 + X.org X Server 1.4.0 + Matrox Millennium G450DX/D32AD (AGP) で使用している xorg.conf)。
そのうちに、graphics card を Diamond FireGL 1000 Pro (4MB) に戻そうとしたのですが、これ用のドライバは xf86-video-glint らしく、 それを package install しようとするとうまくいかなかった (既に 7.0-RELEASE 用のものはなく 7.2 用のものを入れようとしたら途中でこけた) ので、 結局 Vz6000 についていた Matrox Millennium G200 8MB (AGP) に変えて、 Vz6000 で使っていた xorg.conf (vesa driver) を今は使用しています (なお、その後 7.0 用の package を持っているサイトを見つけたので、 そこから glint ドライバは取得できました)。
WL2130 の HD の交換に伴い FreeBSD のバージョンを 4.8 から 7.0 に上げて、 X も入れかえました。package から以下のものを入れました。 Video card は、オンボードの SIS630 です。
xorgconfig で Chipset は SIS generic を選択して (SIS 630 のエントリはないよう)、 あとはほぼ前に使用していた XFree86 と同じ設定でやったのですが、 startx が見つからず xinit というパッケージを入れて、 startx してみると今度はフォントがないとか言われて x11-fonts の必要そうなものを一通り入れてやっと X が起動しました。
ちなみに vesa ドライバでも X は立ち上がるようですが、 少し問題もあるように感じましたので、sis 用のドライバで動作させています。
fvwm は、このマシンでは今までは fvwm-1.24 を使っていたのですが、 今回 fvwm-2.4 に入れかえて設定ファイルを変換することにしました。 しかし、fvwm-2.2 から 2.4 への変換ツール (fvwm24_convert) しかついていないようだったので、 fvwm-2.5.14 をインストールした別の FreeBSD マシンに設定ファイルを コピーして、それに付属するもので変換しました。 本来は fvwm-2.4 系にも 1.x から 2.x へ変換するシェルスクリプト (fvwmrc_convert) がついているはずなのですが、 それはインストールしてくれないようです (なぜかマニュアルはインストールされます)。
ところで、何かのタイミングで、キーボードが全く受け付けなくなる現象を 2 度ほど経験しています。マウスは効いているので、 1 度はマウスだけでうまくログアウトできたのですが、 もう 1 度は xdm 環境でログアウトした直後だったので、どうにもできず、 Ctrl-Alt-BS や Ctrl-Alt-Del も効かないので、 別のマシンから remote login してなんとか shutdown できましたが、 それしか対処法がないとすると、 出先に持っていったときにこのようになるのが少し恐く感じています。 X のキーボードドライバの不具合なのか、 私のマシンの問題なのかはわかりません。
VZ-6000 の FreeBSD のバージョンを 4.11 から 7.0 に上げたのですが、 それに伴って X を入れ替えようとしたのですが、 package から以下のものを入れてみたのですが、うまくいきませんでした Video card は Matrox Millennium G200 8MB です。
ログ (/var/log/Xorg.0.log) を見ると、いくつか (EE) の箇所があるのですが、 なんとか twm の画面が出るのですが、位置も大きさもずれていて、 xvidtune での調整もまったく効きません。 今まででていた 1280x1024 もまるで出ず、 1152x768 から全く変更できず、しかもスクリーンにも収まっておらず、 少なくとも正常な表示とは言えない形でした。
以前の FreeBSD 4.11 の頃は XFree86 でちゃんと使えていたので、
XFree86 にしようかと思ったのですが、
7.0 用の x11-servers の package には XFree86 のエントリがありません。
これは、/etc/make.conf 内に
インターネットで情報を調べてもはっきりせず、 かなり色々試したのですが、結局 mga ドライバではなく、 generic な vesa ドライバを入れてそれを使うことでうまく行きました (「XF86Config, xorg.conf の設定ファイル」 参照)。 これで 1280x1024 (16bpp) が使えています。 xvidtune は使えないようですが、 Ctrl+Alt+{+,-} による解像度の切り替えはできるようです。
うちの研究室では、現在 fvwm-2.4.19 のマニュアルの日本語訳を やっているのですが、 そこに出てくる「マルチヘッド」(マルチモニタ、マルチディスプレイ、 デュアルヘッドなどとも言われます) や「Xinerama」というものの概念が なんとなくわかるものの実際に触ってみないとよくわからない、 ということで、 夏休みを利用してよそからもらった FMV 6333T7 に FreeBSD-5.5RELEASE と XOrg 6.9.0 をインストールして実験してみましたので、 それをここにまとめておきます。
「マルチヘッド」 は、1 台のマシンに複数のディスプレイがついた状態で、 それは複数のグラフィックカードを差して使うか、 複数のディスプレイアダプタのついたグラフィックカードを使用することで 利用できます。 FreeBSD や XOrg では、 新しいカードを使うよりも少し前のカードで実績のあるものを選ぶ方が 安全で、付属のドキュメントによると Matrox のカードは複数の口があるものも使えそうだったので、 結局以下のカードを使って実験してみました。
最後のカッコ内は X.Org でのドライバ名です。 man glint 等でそのドライバ固有のオプション等が参照できます。 card1 が元々 FMV に入っていた AGP バスのグラフィックカード、 card2 は PC9821Xv13 に元々入っていた PCI 用のカードですが、 今回実験のためにそれを抜いて使用しました。 card3 が今回新たに用意したカードで、 これのみディスプレイアダプタ (Dsub15) の口が 2 つついています。
AGP バスは一つしかありませんので、 今回のマルチヘッドの実験は、
現在の X.Org 6.9.0 はマルチヘッド環境も十分に配慮していて、 よって最初から man xorg.conf には 丁寧にマルチヘッドに関する設定も書かれてありますので 思ったほど苦労はしませんでしたが、 よくわからない不具合などもあり、その調査には時間がかかりました。
まず、card1 (AGP) + card2 (PCI) の場合、 xorg.conf には以下のように書きます (直接関連する部分のみ抜粋):
Section "Monitor"
Identifier "FMV-DP978"
HorizSync 30-70
VertRefresh 50-150
EndSection
Section "Device"
BusID "PCI:1:0:0"
Identifier "Diamond"
Driver "glint"
EndSection
Section "Device"
BusID "PCI:0:14:0"
Identifier "MGA1"
Driver "mga"
VideoRam 2048
Option "NoInt10" "On"
EndSection
Section "Screen"
Identifier "Screen1"
Device "Diamond"
Monitor "FMV-DP978"
# DefaultDepth 8
DefaultDepth 16
Subsection "Display"
Depth 8
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
EndSection
Section "Screen"
Identifier "Screen2"
Device "MGA1"
Monitor "FMV-DP978"
DefaultDepth 8
# DefaultDepth 16
Subsection "Display"
Depth 8
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
EndSection
Section "ServerLayout"
Identifier "Diamond+MGA1"
Screen "Screen1"
Screen "Screen2" RightOf "Screen1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
もちろん、Mouse1, Keyboard1 もちゃんと定義したものを使いますが、
その記述は省いてあります。
要は、
Device セクションの "BusID" は昔はなかったと思いますが、 マルチヘッドを使う場合はほぼ必須で (シングルヘッドなら省略可)、 PCI や AGP のバス番号を記述することで 物理的にどのバスを使用するかを指定します (AGP でも PCI と書くようです)。 私は、とりあえず簡単な xorg.conf で X を起動させてから /var/log/Xorg.0.log のログを見ると、 X がバスを調べて認識した結果が以下のように記録されていたので それを見て書きました。
(--) PCI: (0:14:0) Matrox Graphics, Inc. MGA 2064W [Millennium] rev 1, Mem @ 0xfecfc000/14, 0xfc800000/23
(--) PCI:*(1:0:0) Texas Instruments TVP4020 [Permedia 2] rev 1, Mem @ 0xfebc0000/17, 0xfd800000/23, 0xfe000000/23
また、MGA1 の Device セクションの "NoInt10" は、 これがないと、一度 X を落した後にもう一回 X を立ち上げたときに X が起動せず固まってしまったので入れてあります (キーボードも効かなくなったので、リモートログインして reboot しました)。 元々 2 枚目のグラフィックカードは、 デフォルトで Int10 モジュールを使って初期化する (ソフトブート) らしいのですが、"NoInt10" を On にすると それをやらないようになります。
ドライバ名の "glint" や "mga" などは、 xorgconfig に吐きださせたものを使っています。 モニタは FMV-DP978 というもので、WWW で検索すると 水平周波数は 30-70 kHz, 垂直周波数 50-150 Hz のようです。
以上の設定で startx すると見事に両者のディスプレイに X の画面が表示されます。 同じものが表示されているわけではなく、 別々のスクリーンと見なされているようです。 Xinerama を使用しないデフォルトの状態では、
次に、ServerFlags セクションに「Option "Xinerama" "On"」 を書いて、Xinerama を使ってみました。 この場合は上と違い、
今度は card3 (G450) 一枚のみのマルチヘッド環境について紹介します。 card3 を card1 と入れかえて AGP バスにとりつけますが、 この場合は、非 X の状態から両方の口から同じデータが出て、 2 つの同じ表示が行われています (いわゆるクローンモード)。 なお、上の card1 (Diamond, AGP) + card2 (MGA, PCI) の場合は、 X 以外の場合は card1 側にしかデータは出ておらず、 card2 側は X 以外の場合はブラックアウトしたままです。
この場合の xorg.conf の設定は以下のようになります。
Section "Monitor"
Identifier "FMV-DP978"
HorizSync 30-70
VertRefresh 50-150
EndSection
Section "Monitor"
Identifier "A702H"
HorizSync 27-96
VertRefresh 50-160
EndSection
Section "Device"
Identifier "G450-1"
Driver "mga"
# Chipset "mgag400"
# ChipRev 0x80
# VideoRam 16384
BusID "PCI:1:0:0"
Screen 0
Option "NoHal" "On"
EndSection
Section "Device"
Identifier "G450-2"
Driver "mga"
# Chipset "mgag400"
# ChipRev 0x80
# VideoRam 16384
BusID "PCI:1:0:0"
Screen 1
Option "NoHal" "On"
EndSection
Section "Screen"
Identifier "Screen1"
Device "G450-1"
Monitor "A702H"
# DefaultDepth 8
DefaultDepth 16
# DefaultDepth 24
Subsection "Display"
Depth 8
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 24
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
EndSection
Section "Screen"
Identifier "Screen2"
Device "G450-2"
Monitor "FMV-DP978"
# DefaultDepth 8
DefaultDepth 16
# DefaultDepth 24
Subsection "Display"
Depth 8
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 16
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 24
Modes "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection
EndSection
Section "ServerLayout"
Identifier "G450"
Screen "Screen1"
Screen "Screen2" RightOf "Screen1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
まずモニタですが、両者を見分けやすいように今度は別のモニタを使用しました。 Screen1 側は飯山電機の A702H を使用しました。
Device セクションですが、 上に少し書いたのですが man xorg.conf を見ると分かるように この Device セクションは「各カード毎に一つ」書くのではなく、 「各ヘッド毎に一つ」書くことになっています。 よって、今回のようにカードに 2 つ口がある場合は、 同じ BusID, 同じ Driver の Device セクションを 2 つ書きます。 もちろん Identifier は別にしますが、それを物理的に分けるのは "Screen" という項目です。 Screen は、カードについている口のそれぞれに 0 番からの番号が振られます。 G450 の場合は、AGP の端子に遠い側 (ネジに近い側) が 0, もう一つが 1 になるようです。
Chipset, ChipRev は、man mga に G450 の場合はこのように記述する、 と書いてあるのですが自動的な検出でもうまくいっているようです。 また Option "NoHal" は、mga_hal ドライバの読み込みを行なわない という命令で、 mga_hal ドライバは Matrox 社から提供されていて ドライバのソース、あるいは Linux 版のバイナリドライバであれば
後の Screen セクション、ServerLayout セクションの記述は前と同じです。 ただし、DefaultDepth が 8 の場合はなぜか X が起動しませんでした。 DefaultDepth が 16, 24 の場合はちゃんと起動します。 また、ServerLayout セクションの Screen2 の方をコメントアウトすれば G450 の Screen 0 (上の Screen1; A702H 側) だけを使うことはできるのですが、 逆に Screen 1 側 (上の Screen2; FMV-DP978 側) のみを使うことはできないようで、 そのように設定すると X が起動しません。 両方のスクリーンの Depth が異なる場合も X がうまく起動しないことがありましたが、 Xinerama なしなら Module セクションで Load "dri" をしておくと起動するようです (ログで DRI の初期化がどうとか出てたため)。 Ctrl+Alt+'+/-' で両者の解像度を異なるものにすることも可能です。 しかし Xinerama を使うようにすると異なる Depth では Load "dri" としても X は起動しませんでした。
Xinerama の動作、環境変数 DISPLAY の値等は、 card1 + card2 の場合と全く同じです。
最後に card3 + card2 の場合ですが、これもほぼ上と同様です。 ただ、Xinerama を使う場合は 3 つの画面が一つになるのですが、 Depth が異なっているとやはり X が起動しません (Xinerama を使わない場合は大丈夫です)。 Depth を揃えると、解像度は違っていてもそれなりに起動します。 card2 の VRAM が小さかったせいで、 Depth 16 では 1024x768 が精一杯だったので、 これでは 3 画面の X 環境にはちょっともの足りないのですが、 実験としては一応感覚を掴むことはできました。
(cf. 「X に関するメモ (12/29 2009)」)
FreeBSD-4.11 のマシンには XFree86-4.4 あたりが入っています。 昔はインストーラで X のインストールのときにサブメニューがあって、 そこでフォントだとか何だとかを選択できるようになっていましたが、 最近はそういうものがないようで、 いわばおまかせ状態でインストールしたように思います。
ところで、先日ある X のクライアントソフト (xdu) を 手動でインストールしようとしたのですが、 ふと imake 環境 (xmkmf) が入っていないことに気がつきました。 これまでは割と XFree86 も手動でインストールすることが多かったのですが、 普通に XFree86 を手動でインストールすると、 必須のファイル群の中に imake 環境は入っているので、 はてどこに入っているのかとだいぶ悩みましたが、 結局 /usr/ports/devel/imake-4 にあることがわかりました (/usr/ports/devel/imake-6 なんてのもありますが こちらは X.Org 用のようです)。 これを入れると XFree86 のソースアーカイブから imake 環境を入れてくれるようです。
個人的には、X を入れるなら imake 環境がインストールされるのはほぼ必須では、 と思うのですが、今ではそういう感覚は古いんでしょうか。
私は今だに NEC PC9821 に FreeBSD (+ XFree86) を入れて使っているのですが、 PC98 (のキーボード) は複数のキーの同時押しの認識が優れていて、 例えば今でも視覚障害者用の点字の 6 点入力ソフトで使われていたりします (MS-DOS 環境の BASE 等)。
しかし、これは MS-DOS 上で特殊な (ハード寄りの) プログラミングをやっているに違いない、と思っていたのですが、 先日ふと X 環境でのキーの同時押しを xev などで確認してみたところ、 PC98 なら X 環境でもキー同時押しの認識ができそうなことが分かりました。 xev で見ていると、キーを同時押しすると、 その押したキーの分だけ KeyPress イベントが続いて起きて、 離すとそのキーの分の KeyRelease イベントが続いて起きるようです。 よって、X で複数のキーの同時押しを取得するには、 まずは次のような方法が考えられます。
しかし、これは KeyRelease が起きて (つまりキーを離して) 初めてキー同時押し集合を認識できるので、 押したときと少しタイミングがずれ、 作成するソフトによっては問題となる場合があります。 それに対して、以下のような方法もあります。
これだと押したときに認識されるのでタイミングのずれはなくなりますが、 最終的な確定まで追加され続けることになるので、 これも作成するソフトによっては問題となる場合があります。 他に、
という方法もありますが、これも KeyPress, KeyRelease のどちらを 手がかりに入手するかで結局上のやり方と同じ問題が起きます。
これらを利用した点字の 6 点入力タイプ練習ソフトの プロトタイプのようなものも作ってみたのですが、 環境が限定されていますので (PC98 + FreeBSD + X)、 今のところ急いで公開できる位まで完成度を上げる作業を行うことは 考えていません (時間があれば少しずつ作業をしたいと思いますが)。
なお、Sun ワークステーション (SS5, Ultra 1, Blade150) + Solaris や、 非 PC98 の FreeBSD 上で同様のものを試してみましたが、 その場合は 3 キー位の同時押しなら認識できるのですが、 4 キー以上になると上手くいきません (KeyPress の蓄積も、XQueryKeymap() も)。 同時でなくじわっと押し重ねるなら 6 キー位も認識できたりするのですが、 それでは 6 点入力には意味がなさそうです。
今や、PC98 + FreeBSD + X など使っている人はほとんどいなさそうですが、 そんな点 (だけ ?) に関しては、 他にはない良い面があると言えそうです。
FMV-5166 に以前 FreeBSD 4.9 + XFree86-3.4 を入れたときの XF86Config を公開し忘れていましたので公開しました (cf. 「使用している XF86Config, xorg.conf, kernel の設定ファイル」。 また、今回このマシンを FreeBSD-5.4 + X.Org-6.8.2 に上げたので、 その config ファイル (xorg.conf) も公開しました。
「その他のメモ (10/30 2005)」 にも書きましたが、FreeBSD 4.9 では
pci0: <ATI Mach64-GU graphics accelerator> at 8.0 irq 9と出ていたのですが、5.4 では
pci0: <display, VGA> at device 8.0 (no driver attached)のようになってしまったので X もうまくいかないかと心配しましたが、 xorgconfig で ATI Mach64 を選択して Video RAM を 2048KB に設定して 立ち上げたら従来通りちゃんと 1280x1024 で立ち上がりました。
モニタ (FMV-DP978) は WWW で検索すると水平周波数 30-70kHz のようだったので、
1280x1024x60 (31.5-64.3kHz)辺りを選んでおきました。
50-70Hz
(cf. 「その他のメモ (10/30 2005)」)
普段主に使用している PC (PC9821Xs) を FreeBSD (98) 2.2.8R から FreeBSD(98) 4.7R に入れ換えて、 X はそのまま前の FreeBSD 2.X 用のもの (XFree86-3.3.3 for FreeBSD 2.2) を使用していたのですが (cf. 「X に関するメモ (11/22 2004)」)、 この状態では X のソフトをコンパイルできないことに気がつきました。 FreeBSD 4.X はバイナリは ELF ですが、FreeBSD 2.X は AOUT 形式なので コンパイラの生成するコードが X のライブラリと合わないことが原因です。
XFree86 4.X は 98 用のものはないようなので XFree86 3.X を探して、 XFree86-3.3.6 の FreeBSD 3.x 用のものを入れました。 FreeBSD 4.x 用のものはなさそうでしたが、 FreeBSD 3.x は ELF なんでとりあえずそれで間に合わせています。
XF86Config ファイルは、 前のものと見比べたところうちの環境に関係する違いはなかったようなので XFree86-3.3.3 用のものをそのまま使っています。 また、前に FreeBSD 2.2.8 でコンパイルした X のソフトが まだたくさんありますので、 XFree86-3.3.3 も /usr/local/XFree86-3.3.3/X11R6 のようなディレクトリに 残してあり、/etc/rc.conf 内で
ldconfig_paths_aout="$ldconfig_paths_aout /usr/local/XFree86-3.3.3/X11R6/lib"
普段主に使用している PC (PC9821Xs) を FreeBSD (98) 2.2.8R から FreeBSD(98) 4.7R に入れ換えたのですが (cf. 「インストールに関するメモ (11/22 2004)」) FreeBSD(98) 4.7R 用の XFree86 には、 今までのような NEC PC98 用のサーバがあるかどうか分かりませんでしたので、 今まで 2.2.8 で使用していた XFree86 を使用しています。 今のところはとりあえずは問題なく今まで通り使えているようです。 ただし、ldconfig は /etc/rc.conf 内で
ldconfig_paths_aout="$ldconfig_paths_aout /usr/X11R6/lib"
(cf. 「X に関するメモ (01/16 2005)」)
SOTEC の note PC 用に USB マウスを一つ買って来ました。 マウスはマウスデーモン (moused) を使っています。 FreeBSD が立ち上がった後につないでも使えませんが reboot すると使えるようになります。 タッチパッドと同時に使えるのですが、ps -axw で見てみると 2 つ moused が立ち上がっているようです (最初の方がマウス)。
% ps -axw | grep moused
85 ?? Is 0:00.07 /usr/sbin/moused -p /dev/ums0 -I /var/run/moused.ums0.pid
117 ?? Is 0:00.00 moused -p /dev/psm0 -t auto
色々調べて、Option "external"、Option "extern_disp" といったキーワードを見つけて、 XF86Config に書いてみたのですがどうもうまくいきません。 /var/log/XFree86.0.log を見ても
(WW) SIS(0): Option "external" is not used
(WW) SIS(0): Option "extern_disp" is not used
SOTEC の note PC WL2130 に FreeBSD 4.7 + XFree86 4.2.1 をインストールしました。
X のセットアップ時には、 フルグラフィックモードでのセットアップを選択すると 画面が真っ白になってしまいましたが、 とりあえず Ctrl-Alt-BS で元に戻せたのでその後テキストモードで続けました。 ディスプレイの数値等もよくわからなかったので、適当な値 (card: Sis630; Hsync: 31.5-48.5, Vsync: 50-70, depth: 24bits, mode: 1024x768) で設定しましたが、今のところ特に問題なく使えています (cf. wlnote/421/XF86Config-wl-20030218)。 できれば 1152x864 位出て欲しいのですが、それはだめなようです。
マウスはタッチパッドで、とりあえずは使えますが、 小さいマウスを一つ買った方が使いやすそうです。
PC9821Xv13 の OS を FreeBSD(98)3.5.1R-Rev01 から FreeBSD(98)4.5R-Rev01 に入れ換えましたが、 XFree86 のバージョンは全く同じ (3.3.6) なので、 前の物をそのまま使っています。特に問題は無いようです。
以前 Vz-6000 + FreeBSD-3.5 + XFree86-3.3.6 の定義ファイルを 「XF86Config の設定ファイルの節」 に置いていましたが、 キー定義を修正したのを書き忘れていました。 xv-vz/336/XF86Config-vz6k-20020211 に書いてあるように
XkbModel "jp106"
XkbLayout "jp"
Xs + 飯山 MF-8615B (15inch) で XF86Config を調整して、 1152x864 (16bpp) を出せるようにしました。 今までも 8bpp では 1280x1024 が出ていましたが、16bpp では Video RAM が 2MB しかないので 1024x768 しか出ていませんでした。 ただし、Xp 同様、16bpp は立ち上がり時はうまく出ませんので Ctrl+Graph+{+/-} で切り替えています。
Xp + PC KM152 (15inch) で XF86Config を調整して、1152x864 (16bpp) を 出せるようにしました。 ただ、1152x864 は少し設定をだましているのでやや危険です。 本当はディスプレイは HorizSync の値は 24.8-62kHz なのですが、 これでは 1152x864@70Hz が立ち上がらないので、HoriSinc の値を 24.8-63 のように設定しています。 また、1152x864 は最初はうまく立ち上がらないので、デフォルトでは 1024x768 が立ち上がるようにしていて、それを Ctrl+Graph+{+/-} で 切り替えています。
また、8bpp では、1024x768 もちゃんと立ち上がるのですが、 16bpp ではきれいには立ち上がりません。 よってこれも Ctrl+Graph+{+/-} で切り替えています。 切り替えるとちゃんと出ます。
Xv13, VZ6000 ともに、現在はディスプレイは飯山電機の A702H (1600x1200; 17inch) を使用しています。そして、いずれも 1600x1200 まで出すことができました。ただし、
なお、XF86Config.98 には 1600x1200 や 1152x864 のエントリは ありませんが、それは VZ6000 の方にあったものから持って来ました。 startx のログに DotClock の最高値が残るので、それを元に 動作可能なエントリを探し、それがうまく立ち上がれば、 後は xvidtune で微調整し、それを XF86Config に書き戻す、 ということを行いました。
ただ、1600x1200 は 17inch のディスプレイではややつらいので、 通常は 1280x1024 で立ち上がるように設定してあります。
Xv13 で、1280x1024 の表示枠がやや狭かったので、 XF86Config でなく、ディスプレイの方の設定メニューで 枠を広げてしまいました。 このときは本体に最初についていたディスプレイ NEC PC-KM173R (1280x1024; 17inch) を使用していました。X を落としてからも、 キャラクタ画面が広がったままだったので変に感じていたのですが、 次回の電源投入時にディスプレイが壊れてしまいました。 X の設定は慎重を期さないといけないようです。
Xv13 は、マニュアルにはグラフィックボード上に 4MB のメモリを 積んでいるように書いてありますが、4MB と設定するとうまくいかず、 Cards98 にあるように 2MB と設定する必要があるようです。
EPSON 586RA は X の test をしていてハングアップしてリセットが かかることがありますが、その後メモリチェック後 うまく立ち上がらなくなります。 そうなると電源をいったん落として再立ち上げする必要があるようです。
EPSON 586RA が持っているグラフィックビデオボードは PCSKB5 (S3-964) ですが、現在 (も過去も) XFree86 は対応していません。 EGC サーバもだめのようです。 よって、X のインストールはしましたが、X のサーバは立ち上げて いません。ネットワーク経由で X のクライアントを利用するのみです。 ディスプレイ CR-4700 は EPSON 純正の 14 inch のものですが、 MS-Windows 3.1 では 1280x1024 まで出ていましたので、 X が動くことを期待しているのですが...