バーチャルコンソールの移動って、ずっとalt+F?キーでやってた。
ネット接続の検証用に、テキストブラウザを入れたんだけど、キー操作が分からなくて、色々試していたら、、、alt＋カーソルキーの横矢印でコンソールが移ってびっくり！！ｗ
ずっと、しらなかった、、、
けど、感動したｗ
今日は、仕事で秋葉原まで行った！生まれて２回目くらい。
でも、時間が無くてまったく店とか物色できなくて、しょんぼり、、、
前に行ったのってもう１０年くらい前かなぁ？
その時は、あちこち歩いてみたんだけど、何処に何があるのかさっぱりわからんうちに日が暮れて、友達が迎えに来たｗ
とか、どうでもいいんだけど、、、
自分のブログ読み返すと、誤字脱字多いなぁ～
あと、内容で嘘っぽいのもありそう（＾＾；
今、S101にはX入れてなくて、ブログは別パソコンから書いてたりするので、パスとか変数名とか手打ちしてて、なんか写し間違いとかいっぱいありそうな予感。
もし、参考にしてる人がいたら注意してみてくださいねー
2009年10月6日火曜日
無線LANとacpiの連携
acpiの仕組みとかの続き、無線LAN編のメモ
eeepc用のパッケージ「acpi-eeepc-generic」に乗っかってみる。
たぶん、デフォルトでFn+F2キーで無線LANデバイスのオンオフが可能になっているはず。
無線LANの扱い方についての基本は以前のブログ
無線Lan（手動）
ネットワーク（半自動）
辺りのメモが参考になるかも？
以前から「rfkill」とは何ぞや？！と思っていたんだけれど、acpi-eeepc-generic内のスクリプトを覗き見ていて、初めてちょっと理解。無線デバイスの電源のオンオフを行えるモジュール（？）らしい。S101はこの仕組みが使えるようだ。
/sys/class/rfkill以下に、rfkill*ディレクトリがあり、その中に幾つかのファイルがある。nameの中にはそのデバイスの名前があり、rfkill0/nameはeeepc-wlan、rfkill1/nameはeeepc-bluetoothとなっている。そして、同じディレクトリ内のstateファイルには0か1の数字があって、これを変更することでそのデバイスの状態を変更できるらしい。
というわけで、節電術については、この仕組みを使って無線デバイスの電源のオンオフを出来るようにすると良い。そして、無線LANについては、この電源のオンオフに連動してネットにも繋がるようにすれば便利になる。
今までの知識と一緒にまとめると、無線LANデバイス起動の処理は、次の通り。
rfkillスイッチを使って、無線LANデバイスの電源を入れる。
（キーボードの上の無線ラン用表示ランプ点灯）
↓
S101用無線LANドライバath9kのロード
↓
ifconfigによるデバイスの準備
↓
wpa_supplicantによる、回線の接続
↓
dhcpdでのIP取得（もしくは、デバイスのルーティング）
無線LANデバイスの終了は、上の処理を逆順にすることになる。
この手続きを実際に行う手伝いをパッケージ「acpi-eeepc-generic」同梱のスクリプト/etc/acpi/eeepc/acpi-eeepc-generic-toggle-wifi.shが行ってくれる。現実には、このスクリプトの中から、/etc/acpi/acpi-eeepc-generic-functions.sh内の関数を呼び出している。
そこで、まず、/etc/conf.d/acpi-eeepc-generic.confのCOMMANDS_WIFI_TOGGLE変数の値にこのスクリプトを指定する。acpi-eeepc-generic-toggle-wifi.shは、引数を付けずに呼び出した場合、状態のトグルを行うことになる。そして、その内容は、電源が入っていなかった場合、電源を入れて、ドライバをロードし、ifconfigでデバイスの準備をしてくれるまで、逆に、デバイスが起動している状態だと、デバイスを終了させて、ドライバをアンロードし、電源を落としてくれる。
但し、acpi-eeepc-generic-functions.shで定義されているdevice_onの流れを見ると、ドライバをロードする前にifconfigでデバイスをupしようとしているので、このままでは、デバイスがいつもupしないような気がする。ただ、電源管理については、電源を切ってくれるかどうかが重要なだけなので、いつものように他の好きなツールで行うことが出来るので、仕組みさえ分かれば、これで十分。
ここで、/etc/conf.d/acpi-eeepc-generic.confには次の変数が用意されている。
COMMANDS_WIFI_PRE_UP
COMMANDS_WIFI_POST_UP
COMMANDS_WIFI_PRE_DOWN
COMMANDS_WIFI_POST_DOWN
これらの変数にコマンド文字列を定義しておくと、それぞれ、電源を入れる前、入れた後、電源を落とす前、落とした後に実行してくれる。
そこで、以前に紹介したプロファイルを使うnetcfgをここで呼び出す設定をうちではしてみた。こうすることで、Fn+F2を押すたびに、デバイスの電源の入る切るに連動して、自動でネットワークに接続してくれる。
COMMANDS_WIFI_POST_UP=("netcfg myprofile")
COMMANDS_WIFI_PRE_DOWN=("netcfg -d myprofile")
さて、S101の無線LANは、現在の最新のカーネルパッケージでは、ちゃんとネットワークに繋がるようになっているので、ここまでの設定をすることで、快適に無線LAN生活が可能っぽい。
最後に、補足として、やっているうちに気がついた点をメモ
・サスペンド
現在、サスペンドの方はpm-utilsを使っているけれど、スリープとレジーム時の設定をまだしていないので、レジームした時のLANの挙動がおかしくなる。ただ、Fn+F2で一旦切って、立ち上げなおせば、またちゃんと繋げることができる。
pm-utilsについても、電源管理メモとしてまとめる予定。
・netcfgのタイムアウト設定
netcfgで回線接続を行う時、timeoutの設定時間が短いと、１度認証に失敗するとそのまま回線接続も失敗してしまってnetcfgが終了してしまうことが多い。wpa_supplicant自体は何度かトライしてくれるので、少し長めの（20秒位？）timeout時間の設定を明示しておく方がよさげ。
一方で、この間に電源オンオフ操作をすると、またおかしなことになる、、この辺りの挙動は/var/log/messeges.logへのacpiからの出力をみれば、ちゃんとデバイス起動の操作が完了したとかわかるんだけど普段はわからないので、あんまり短期間にFn+F2をプチプチ押さないようにするｗ
・S101の無線デバイスランプ
このランプは、LANとブルートゥースが兼用になっていて、両方の電源が落ちている場合のみ、消灯し、どちらかでも電源が入っていると、点灯する。うちでは、ブルートゥース機器は使ってないので、常時電源を落としてあるので、点灯時は、LAN有効、消灯時、LAN無効となっている。
eeepc用のパッケージ「acpi-eeepc-generic」に乗っかってみる。
たぶん、デフォルトでFn+F2キーで無線LANデバイスのオンオフが可能になっているはず。
無線LANの扱い方についての基本は以前のブログ
無線Lan（手動）
ネットワーク（半自動）
辺りのメモが参考になるかも？
以前から「rfkill」とは何ぞや？！と思っていたんだけれど、acpi-eeepc-generic内のスクリプトを覗き見ていて、初めてちょっと理解。無線デバイスの電源のオンオフを行えるモジュール（？）らしい。S101はこの仕組みが使えるようだ。
/sys/class/rfkill以下に、rfkill*ディレクトリがあり、その中に幾つかのファイルがある。nameの中にはそのデバイスの名前があり、rfkill0/nameはeeepc-wlan、rfkill1/nameはeeepc-bluetoothとなっている。そして、同じディレクトリ内のstateファイルには0か1の数字があって、これを変更することでそのデバイスの状態を変更できるらしい。
というわけで、節電術については、この仕組みを使って無線デバイスの電源のオンオフを出来るようにすると良い。そして、無線LANについては、この電源のオンオフに連動してネットにも繋がるようにすれば便利になる。
今までの知識と一緒にまとめると、無線LANデバイス起動の処理は、次の通り。
rfkillスイッチを使って、無線LANデバイスの電源を入れる。
（キーボードの上の無線ラン用表示ランプ点灯）
↓
S101用無線LANドライバath9kのロード
↓
ifconfigによるデバイスの準備
↓
wpa_supplicantによる、回線の接続
↓
dhcpdでのIP取得（もしくは、デバイスのルーティング）
無線LANデバイスの終了は、上の処理を逆順にすることになる。
この手続きを実際に行う手伝いをパッケージ「acpi-eeepc-generic」同梱のスクリプト/etc/acpi/eeepc/acpi-eeepc-generic-toggle-wifi.shが行ってくれる。現実には、このスクリプトの中から、/etc/acpi/acpi-eeepc-generic-functions.sh内の関数を呼び出している。
そこで、まず、/etc/conf.d/acpi-eeepc-generic.confのCOMMANDS_WIFI_TOGGLE変数の値にこのスクリプトを指定する。acpi-eeepc-generic-toggle-wifi.shは、引数を付けずに呼び出した場合、状態のトグルを行うことになる。そして、その内容は、電源が入っていなかった場合、電源を入れて、ドライバをロードし、ifconfigでデバイスの準備をしてくれるまで、逆に、デバイスが起動している状態だと、デバイスを終了させて、ドライバをアンロードし、電源を落としてくれる。
但し、acpi-eeepc-generic-functions.shで定義されているdevice_onの流れを見ると、ドライバをロードする前にifconfigでデバイスをupしようとしているので、このままでは、デバイスがいつもupしないような気がする。ただ、電源管理については、電源を切ってくれるかどうかが重要なだけなので、いつものように他の好きなツールで行うことが出来るので、仕組みさえ分かれば、これで十分。
ここで、/etc/conf.d/acpi-eeepc-generic.confには次の変数が用意されている。
COMMANDS_WIFI_PRE_UP
COMMANDS_WIFI_POST_UP
COMMANDS_WIFI_PRE_DOWN
COMMANDS_WIFI_POST_DOWN
これらの変数にコマンド文字列を定義しておくと、それぞれ、電源を入れる前、入れた後、電源を落とす前、落とした後に実行してくれる。
そこで、以前に紹介したプロファイルを使うnetcfgをここで呼び出す設定をうちではしてみた。こうすることで、Fn+F2を押すたびに、デバイスの電源の入る切るに連動して、自動でネットワークに接続してくれる。
COMMANDS_WIFI_POST_UP=("netcfg myprofile")
COMMANDS_WIFI_PRE_DOWN=("netcfg -d myprofile")
さて、S101の無線LANは、現在の最新のカーネルパッケージでは、ちゃんとネットワークに繋がるようになっているので、ここまでの設定をすることで、快適に無線LAN生活が可能っぽい。
最後に、補足として、やっているうちに気がついた点をメモ
・サスペンド
現在、サスペンドの方はpm-utilsを使っているけれど、スリープとレジーム時の設定をまだしていないので、レジームした時のLANの挙動がおかしくなる。ただ、Fn+F2で一旦切って、立ち上げなおせば、またちゃんと繋げることができる。
pm-utilsについても、電源管理メモとしてまとめる予定。
・netcfgのタイムアウト設定
netcfgで回線接続を行う時、timeoutの設定時間が短いと、１度認証に失敗するとそのまま回線接続も失敗してしまってnetcfgが終了してしまうことが多い。wpa_supplicant自体は何度かトライしてくれるので、少し長めの（20秒位？）timeout時間の設定を明示しておく方がよさげ。
一方で、この間に電源オンオフ操作をすると、またおかしなことになる、、この辺りの挙動は/var/log/messeges.logへのacpiからの出力をみれば、ちゃんとデバイス起動の操作が完了したとかわかるんだけど普段はわからないので、あんまり短期間にFn+F2をプチプチ押さないようにするｗ
・S101の無線デバイスランプ
このランプは、LANとブルートゥースが兼用になっていて、両方の電源が落ちている場合のみ、消灯し、どちらかでも電源が入っていると、点灯する。うちでは、ブルートゥース機器は使ってないので、常時電源を落としてあるので、点灯時は、LAN有効、消灯時、LAN無効となっている。
2009年10月4日日曜日
acpiの仕組みとか
S101はネットブックなので、電源管理が上手に出来るようにする仕組みを色々調べてたのでまとめてメモ。サスペンドと無線LAN制御の具体的な部分は別メモの予定。
１．acpid
まず、基本はパッケージ「acpid」
acpiイベントに対応した処理を行う仕組み。
http://wiki.archlinux.org/index.php/Acpid
もしくは、man acpidの方が仕組みはよくわかる。
インストールはパッケージ「acpid」が公式リポジトリ[extra]にあるので
pacmanでインストール。
そして、/etc/rc.confのDAEMONS配列にacpidを追加する。
但し、halを導入していている場合、halが自動的に呼び出すので
/etc/rc.confでacpidを呼び出す必要は無い。
acpidは、Adbanced Configuration and Power Interface evet daemonってことらしい。acpidは、/proc/acpi/eventを監視していて、ここにイベントの行が追加されるとこれを読み込んで、/etc/acpi/eventsディレクトリの中にあるファイルで定義されたイベントに対応する処理を検索して実行する仕組み。
/etc/acpi/eventsディレクトリの中のファイルの書式は、「event=」行と「action=」の二つを定義する。eventで捕まえるイベントを定義して、それに対応するコマンドをactionに定義する。
acpidに付属しているanythingを例にみると
event=.*
action=/etc/acpi/handler.sh %e
となっている。
eventについては、正規表現（manによればsee regcomp(3)となっている）を用いることができるらしい。また、action行にある%eはacpidからの渡されるイベントの文字列に展開されて、上の例ではスクリプトの引数として使われている。
archlinuxのwikiでは、
event=button sleep.*
action=/etc/acpi/actions/sleep-button.sh "%e"
という風に、イベント毎に実行スクリプトを個別に定義する方法も紹介されているが、anythingのようにすべてのイベントをひとつのスクリプトに投げてそこで、場合分けするほうが単純でよさげ？
その他のTipsとしては、次のものがあるらしい。
・acpidの処理を一旦中止させる。
/var/lock/acpidというファイルが存在すると、acpidはすべてのイベントを
無視するため、acpidの働きを止めることができる。
・ソケット
/var/run/acpid.soketを通じてAPCIイベントのテキストを受け取ることが
できるので、このソケットに繋がるクライアントプログラムを書ける。
さて、acpiイベントとは具体的には、
電源ボタンを押した
Sleep/Suspendボタンを押した
特定のファンクションボタン＋ファンクションキーを押した
ノートパソコンの蓋を閉めた
ノートパソコンのACアダプタを接続した（外した）
みたいなもの。
もともとは、ノートパソコンの様にバッテリーで動いてたりする場合、出来るだけ電気を使わないようにするための仕組みで、蓋を閉めたり、ACアダプタ接続の状態をシステムが把握して状況に応じて自動で節電しようとする仕組み。キーに対応する処理も出来るのは、特別なキーに対応して、WiFiデバイスの電源を落としたり、ユーザーの意思でサスペンドやハイバネートも出来るようしたりするためかな。S101でもFnキーとファンクションキー(F1とかのキー)の組み合わせでこれらの処理をするようになっていて、ファンクションキーの上にはこれらのイメージが書いてある。
以上がacpidの基本的な仕組み。
システムが発信するacpiイベント、特に何のキーが押された等のイベントは、パソコン毎に違う。eeePCでもモデルによって、特殊なボタンの数も違う。S101では、キーボードの上に銀色のボタンで、左に人が走ってるイメージのボタンと、右には電源ボタンの二つがあるが、他のモデルだともっと他にもあるらしい。
ここで、acpiｄの活用をするためには、じぶんのパソコンに適した設定をする必要がある。そして、もうひとつの注意は、acpidはイベントに対応した処理を定義するだけの仕組みなので、処理の内容についても、システムのアプリの導入状態によって各パソコン毎に違う。なので、acpid付属のhandler.shやacpi-eeepc-generic付属の定義そのままで動く分けではない。特にサスペンドやハイバネートの処理については、色々な方法がある。そこで、ここらへんは別途、自分のシステムに合うものを検討して、一番よい方法を見つけた後、それをacpidの処理に組み込む事が必要。
2.acpi-eeepc-generic
eeePCシリーズの場合、以上のような状況に対応してくれるのがパッケージ「acpi-eeepc-generic」
但し、eeePCシリーズ汎用であるため、スクリプトは結構複雑になっていると同時に、
S101の場合（S101でもロットによるの？）多少手直しが必要な部分もある。
インストールはパッケージがAURにあるので、yaourt等を使う。
（１）概要
acpi-eeepc-genericの主な仕組みは次の通り。
・acpid用の定義
/etc/acpi/events/acpi-eeepc-generic-events
acpidパッケージ付属のanythingで定義されている定義に代えて（コメントアウト）、
このファイルで処理の定義（呼び出すスクリプトファイルの指定）をしている。
具体的には、すべてのイベントについて、/etc/acpi/acpi-eeepc-generic-handler.shを呼び出している。
・処理の定義
/etc/acpi/acpi-eeepc-generic-handler.sh
このファイルで、イベントに対する処理の定義を行っている。
実際には汎用的な定義になっており、イベント及び処理はすべて変数が使われていて、その具体的な定義は別ファイルになっている。
また、これらの中で使われているシェル関数の定義も別ファイルに集められ、その他のユティリティ的なプログラムファイルも別に同梱している。
これらの別定義ファイルをまとめると以下の通り。
キーイベントの定義：/etc/acpi/eeepc/models/以下の各モデル名のファイル
処理の具体的なコマンドの定義：/etc/conf.d/acpi-eeepc-generic.conf
シェル関数の定義:/etc/acpi/eeepc/acpi-eeepc-generic-function.sh
その他のユティリティプログラム：/etc/acpi/eeepc/以下の上記以外のもの
これらのファイルを使ってacpi-eeepc-genericは構成されて動いている。
eeePCシリーズでこのパッケージを使う場合には、モデルが自動で決定されて、それに対応するキーイベントが読み込まれて、処理の内容も一般的なものがデフォルトで定義されており、だいたいは使えるようになっている。
カスタマイズは、/etc/conf.d/acpi-eeepc-generic.confファイルのみで一元管理する仕組みになっている。
acpi-eeepc-generic.confでは、変数の値として具体的なコマンド文字列を定義する（配列として複数コマンドもOK）。
（２）キーイベントの修正
キーイベントとキーの対応について、S101の場合、/etc/acpi/eeepc/models/acpi-eeepc-S101-events.confで定義されている。
ここでの定義は、前半と後半の２段階の定義になっている。前半は、コメントされている「Silver buttons」と「Fn+F? conbination」の部分で、実際のボタンが押された場合にシステムから送られてくる文字列（数字）とボタン名の対応の定義、後半は「Match previous to functions」で、このボタン名の変数とボタン名に対応したイベント名の対応の定義になっている。
まずは、前半のボタンとシステムが送ってくる文字列の関係については次のようになっている。先に述べたとおり、acpidは/proc/acpi/eventを監視して、イベントが起こるたびに/etc/acpi/events以下の定義を実行する。acpi-eeepc-genericパッケージを導入すると「/etc/acpi/acpi-eeepc-generic-handler.sh %e」が実行される。この「%e」の部分がイベント文字列に展開され、acpi-eeepc-generic-handler.shはこの文字列を分析して、場合分けを行って処理している。
イベントに対する「%e」の内容を具体的にみてみる。
例えば、以下のようにしてみる。
/etc/acpi/events/acpi-eeepc-generic-eventsのaction行を一旦コメントアウトして、
action=/etc/acpi/test-handler.sh %e
を追加。
以下の内容で、/etc/acpi/test-handler.shファイルを作成して、実行権限をつける。
#!/bin/sh
echo "$1:$2:$3:$4:$5:$6:$7" >>/etc/acpi/test.log
次に、/etc/acpi/test.logを空のファイルとして作成しておく。
以上の準備ができたら、acpidを再起動する。
# /etc/rc.d/acpid restart
これで、イベントが発生するたびに、acpidが渡してくる文字列が/etc/acpi/test.logに記録される。実際にFn+F1を押してみるとlogファイルには次のような行が追加される。
button/sleep:SLPB:00000080:00000001:::
他のキーを押してみたり、蓋を閉じてみたり、ACアダプタを付けたり外したりして試すと
色々なイベントが追加されるので試してみる。テスト用のスクリプトファイルは、検証のために７つ分の文字列を用意したけれど、送られてくる文字列は、４つの部分に分かれた文字列が送られてくることが分かる。また、４番目の要素は、そのイベントが呼ばれるたびに増えたりするらしいこともわかる。
これらのうち、特にS101でキーを押した場合の%eの３つ目までの要素の対応をまとめてみると以下の通り。
fn+F1 button/sleep SLPB 00000080
fn+F2 hotkey ATKD 00000010
fn+F3 hotkey ATKD 00000037
fn+F4 hotkey ATKD 0000001b
fn+F5 hotkey ATKD 0000002* (押すと数字が下がる)
fn+F6 hotkey ATKD 0000002* (押すと数字が上がる)
fn+F7 hotkey ATKD 00000016
fn+F8 hotkey ATKD 00000030
fn+F9 hotkey ATKD 00000012
fn+F10 hotkey ATKD 00000013
fn+F11 hotkey ATKD 00000014
fn+F12 hotkey ATKD 00000015
fn+space hotkey ATKD 00000039
left_silver hotkey ATKD 00000039
right_silver button/power PWRF 00000080
fn+F5とfn+F6は３つ目の要素が変則的
ここで、acpi-eeepc-S101-events.confと見比べてみると、前半部分の定義は%eの第３要素についての定義をしているのが分かる。そして、定義の内容が多少ずれているのも分かる。また、配列定義になっている部分も、後半部分の定義で第１要素のみを定義しているため不必要っぽい。
そこで、実際に自分で試した結果で前半の定義を書き換えると次のようになる。
#Silver buttons
KEY_SILVER1="00000039"
KEY_SILVER2="00000080"
KEY_SILVER3=NONE
KEY_SILVER4=NONE
#Fn+F? combination
KEY_Fn_F1="00000080"
KEY_Fn_F2="00000010"
KEY_Fn_F3="00000037"
KEY_Fn_F4="0000001b"
KEY_Fn_F5="0000002*"
KEY_Fn_F6="0000002*"
KEY_Fn_F7="00000016"
KEY_Fn_F8="00000030"
KEY_Fn_F9="00000012"
KEY_Fn_F10="00000013"
KEY_Fn_F11="00000014"
KEY_Fn_F12="00000015"
KEY_Fn_Space="00000039"
そして、これに対応して、後半部分も書き換えるが、もともと定義されていない部分、
F3,F4辺りも追加して整理してみると次の通り。
#Match previous to functions
EEEPC_BLANK=$KEY_SILVER1
EEEPC_RESOLUTION=NONE
EEEPC_USER1=$KEY_Fn_F3
EEEPC_USER2=$KEY_Fn_F4
EEEPC_USER3=NONE
EEEPC_SLEEP=$KEY_Fn_F1
EEEPC_WIFI_TOGGLE=$KEY_Fn_F2
EEEPC_WIFI_UP=NONE
EEEPC_WIFI_DOWN=NONE
EEEPC_TOUCHPAD_TOGGLE=NONE
EEEPC_BRIGHTNESS_UP=$KEY_Fn_F5
EEEPC_BRIGHTNESS_DOWN=$KEY_Fn_F6
EEEPC_XRANDR_TOGGLE=$KEY_Fn_F8
EEEPC_XRANDR_TOGGLE_0=NONE
EEEPC_XRANDR_TOGGLE_1=NONE
EEEPC_XRANDR_TOGGLE_2=NONE
EEEPC_TASKMAN=$KEY_Fn_F9
EEEPC_VOL_MUTE=$KEY_Fn_F10
EEEPC_VOL_DOWN=$KEY_Fn_F11
EEEPC_VOL_UP=$KEY_Fn_F12
以上がacpi-eeepc-S101-events.confの修正になるが、注意点がある。
/etc/acpi/acpi-eeepc-generic-handler.shを読み解けば、処理の場合分けの仕組みは、まず、%eの第１要素で大きく分けられている。このうち、acpi-eeepc-S101-events.confの設定は、第１要素が「hotkey」の場合の第３要素の振り分けに用いられている。
つまり、fn+F1と電源ボタンについては、S101の場合ここでの設定は意味が無いことになる。
（３）具体的なコマンドの呼び出し設定。
キーの対応付けが修正できたら、次は/etc/conf.d/acpi-eeepc-generic.confで自分のシステムにあった設定を行うことになる。設定の仕方は、ファイルのコメント部分に記載されている。
・Xアプリの権限 XUSER
XUSERの値として、Xアプリ実行者権限を入れておく。
・お知らせ機能 NOTIFY
NOTIFYの値は、コメント通り
gnome系ならlibnotify
KDE系ならkdialog
汎用のdzenならdzen
特に必要ないなら、NONE
・無線ランドライバ WIFI_DRIVERS
S101の場合、ath9kなので
WIFI_DRIVERS=("ath9k")
・設定完了のしるし EEEPC_CONF_DONE
この変数の値がnoの間、お知らせメッセージに設定未完了の旨の表示がでる。
no以外なら出ないので、設定が終わればこの行をコメントアウトする。
・デバイストグルのリストア
RESTORE_hogehoge変数は、システム起動時に、前のデバイスのオンオフ状態を引き継ぐかどうかのフラグ。１で引継ぎ、０でシステムの初期値
・COMMAND_hogehogeによる、コマンド設定
変数の値は配列も可、コマンドの先頭に@をつけると、ユーザー権限で実行。変数名でおおよその対応イベントが分かるが、詳細な対応は/etc/acpi/acpi-eeepc-generic-handler.shファイルをみて直接確認する。また、実は変数の入れ子や、他のユティリティファイルそのものの変数も混在していて、結構読み解くのはめんどくさい。
デフォルトのままで、画面輝度の調整やボリューム調整はできるとおもう。
３．電力節約術
ACPIは結局のところ、ノートパソコン等で電源を長持ちさせるための仕組みなので、これを実現する幾つかの点に絞ってその設定を検証する。
・サスペンド、ハイバネート
サスペンドはメモリに情報を退避して、休眠状態にする方法
ハイバネートはHDDに情報を退避して、休眠状態にする方法
通常、acpiイベントのsleep/suspendイベントに対応して、処理を行うことになる。
acpi-eeepc-genericでは、sleep/suspendイベントに対応して、COMMANDS_SLEEP変数の値が呼び出される。サスペンド、ハイバネートについては、acpi-eeepc-generic同梱のスクリプトとしてacpi-eeepc-generic-suspend2ram.shがある。
サスペンド、ハイバネートについては、いろいろな方法があるが、pm-utilsを使うことにする。そのあたりは、別文書で記載
・画面表示の電源
Xの場合、画面表示のLED電源を落とすことができる？
未検証
・ワイヤレスデバイスの電源を落とす。
無線ランやブルートゥースデバイスは、よく電気を食うらしいので、これらを使っていないときにデバイスの電源を落とす。特に、無線ランについては、デバイスの制御と共に、ネットワークへの接続も含めてボタンでオンオフ出来るようにすると便利なので、その当りを別文書で検討する。
acpi-eeepc-generic同梱のユティリティスクリプトはacpi-eeepc-generic-toggle-wifi.shだが、そのままではS101の場合上手く働かないように見える。
イベントの対応は、無線ランがCOMMANDS_WIWI_TOGGLE。
ブルートゥースは直接の対応がないので、Fn+F3（上記の設定でCOMMAND_BUTTON_USER1）辺りに割り振る。
１．acpid
まず、基本はパッケージ「acpid」
acpiイベントに対応した処理を行う仕組み。
http://wiki.archlinux.org/index.php/Acpid
もしくは、man acpidの方が仕組みはよくわかる。
インストールはパッケージ「acpid」が公式リポジトリ[extra]にあるので
pacmanでインストール。
そして、/etc/rc.confのDAEMONS配列にacpidを追加する。
但し、halを導入していている場合、halが自動的に呼び出すので
/etc/rc.confでacpidを呼び出す必要は無い。
acpidは、Adbanced Configuration and Power Interface evet daemonってことらしい。acpidは、/proc/acpi/eventを監視していて、ここにイベントの行が追加されるとこれを読み込んで、/etc/acpi/eventsディレクトリの中にあるファイルで定義されたイベントに対応する処理を検索して実行する仕組み。
/etc/acpi/eventsディレクトリの中のファイルの書式は、「event=」行と「action=」の二つを定義する。eventで捕まえるイベントを定義して、それに対応するコマンドをactionに定義する。
acpidに付属しているanythingを例にみると
event=.*
action=/etc/acpi/handler.sh %e
となっている。
eventについては、正規表現（manによればsee regcomp(3)となっている）を用いることができるらしい。また、action行にある%eはacpidからの渡されるイベントの文字列に展開されて、上の例ではスクリプトの引数として使われている。
archlinuxのwikiでは、
event=button sleep.*
action=/etc/acpi/actions/sleep-button.sh "%e"
という風に、イベント毎に実行スクリプトを個別に定義する方法も紹介されているが、anythingのようにすべてのイベントをひとつのスクリプトに投げてそこで、場合分けするほうが単純でよさげ？
その他のTipsとしては、次のものがあるらしい。
・acpidの処理を一旦中止させる。
/var/lock/acpidというファイルが存在すると、acpidはすべてのイベントを
無視するため、acpidの働きを止めることができる。
・ソケット
/var/run/acpid.soketを通じてAPCIイベントのテキストを受け取ることが
できるので、このソケットに繋がるクライアントプログラムを書ける。
さて、acpiイベントとは具体的には、
電源ボタンを押した
Sleep/Suspendボタンを押した
特定のファンクションボタン＋ファンクションキーを押した
ノートパソコンの蓋を閉めた
ノートパソコンのACアダプタを接続した（外した）
みたいなもの。
もともとは、ノートパソコンの様にバッテリーで動いてたりする場合、出来るだけ電気を使わないようにするための仕組みで、蓋を閉めたり、ACアダプタ接続の状態をシステムが把握して状況に応じて自動で節電しようとする仕組み。キーに対応する処理も出来るのは、特別なキーに対応して、WiFiデバイスの電源を落としたり、ユーザーの意思でサスペンドやハイバネートも出来るようしたりするためかな。S101でもFnキーとファンクションキー(F1とかのキー)の組み合わせでこれらの処理をするようになっていて、ファンクションキーの上にはこれらのイメージが書いてある。
以上がacpidの基本的な仕組み。
システムが発信するacpiイベント、特に何のキーが押された等のイベントは、パソコン毎に違う。eeePCでもモデルによって、特殊なボタンの数も違う。S101では、キーボードの上に銀色のボタンで、左に人が走ってるイメージのボタンと、右には電源ボタンの二つがあるが、他のモデルだともっと他にもあるらしい。
ここで、acpiｄの活用をするためには、じぶんのパソコンに適した設定をする必要がある。そして、もうひとつの注意は、acpidはイベントに対応した処理を定義するだけの仕組みなので、処理の内容についても、システムのアプリの導入状態によって各パソコン毎に違う。なので、acpid付属のhandler.shやacpi-eeepc-generic付属の定義そのままで動く分けではない。特にサスペンドやハイバネートの処理については、色々な方法がある。そこで、ここらへんは別途、自分のシステムに合うものを検討して、一番よい方法を見つけた後、それをacpidの処理に組み込む事が必要。
2.acpi-eeepc-generic
eeePCシリーズの場合、以上のような状況に対応してくれるのがパッケージ「acpi-eeepc-generic」
但し、eeePCシリーズ汎用であるため、スクリプトは結構複雑になっていると同時に、
S101の場合（S101でもロットによるの？）多少手直しが必要な部分もある。
インストールはパッケージがAURにあるので、yaourt等を使う。
（１）概要
acpi-eeepc-genericの主な仕組みは次の通り。
・acpid用の定義
/etc/acpi/events/acpi-eeepc-generic-events
acpidパッケージ付属のanythingで定義されている定義に代えて（コメントアウト）、
このファイルで処理の定義（呼び出すスクリプトファイルの指定）をしている。
具体的には、すべてのイベントについて、/etc/acpi/acpi-eeepc-generic-handler.shを呼び出している。
・処理の定義
/etc/acpi/acpi-eeepc-generic-handler.sh
このファイルで、イベントに対する処理の定義を行っている。
実際には汎用的な定義になっており、イベント及び処理はすべて変数が使われていて、その具体的な定義は別ファイルになっている。
また、これらの中で使われているシェル関数の定義も別ファイルに集められ、その他のユティリティ的なプログラムファイルも別に同梱している。
これらの別定義ファイルをまとめると以下の通り。
キーイベントの定義：/etc/acpi/eeepc/models/以下の各モデル名のファイル
処理の具体的なコマンドの定義：/etc/conf.d/acpi-eeepc-generic.conf
シェル関数の定義:/etc/acpi/eeepc/acpi-eeepc-generic-function.sh
その他のユティリティプログラム：/etc/acpi/eeepc/以下の上記以外のもの
これらのファイルを使ってacpi-eeepc-genericは構成されて動いている。
eeePCシリーズでこのパッケージを使う場合には、モデルが自動で決定されて、それに対応するキーイベントが読み込まれて、処理の内容も一般的なものがデフォルトで定義されており、だいたいは使えるようになっている。
カスタマイズは、/etc/conf.d/acpi-eeepc-generic.confファイルのみで一元管理する仕組みになっている。
acpi-eeepc-generic.confでは、変数の値として具体的なコマンド文字列を定義する（配列として複数コマンドもOK）。
（２）キーイベントの修正
キーイベントとキーの対応について、S101の場合、/etc/acpi/eeepc/models/acpi-eeepc-S101-events.confで定義されている。
ここでの定義は、前半と後半の２段階の定義になっている。前半は、コメントされている「Silver buttons」と「Fn+F? conbination」の部分で、実際のボタンが押された場合にシステムから送られてくる文字列（数字）とボタン名の対応の定義、後半は「Match previous to functions」で、このボタン名の変数とボタン名に対応したイベント名の対応の定義になっている。
まずは、前半のボタンとシステムが送ってくる文字列の関係については次のようになっている。先に述べたとおり、acpidは/proc/acpi/eventを監視して、イベントが起こるたびに/etc/acpi/events以下の定義を実行する。acpi-eeepc-genericパッケージを導入すると「/etc/acpi/acpi-eeepc-generic-handler.sh %e」が実行される。この「%e」の部分がイベント文字列に展開され、acpi-eeepc-generic-handler.shはこの文字列を分析して、場合分けを行って処理している。
イベントに対する「%e」の内容を具体的にみてみる。
例えば、以下のようにしてみる。
/etc/acpi/events/acpi-eeepc-generic-eventsのaction行を一旦コメントアウトして、
action=/etc/acpi/test-handler.sh %e
を追加。
以下の内容で、/etc/acpi/test-handler.shファイルを作成して、実行権限をつける。
#!/bin/sh
echo "$1:$2:$3:$4:$5:$6:$7" >>/etc/acpi/test.log
次に、/etc/acpi/test.logを空のファイルとして作成しておく。
以上の準備ができたら、acpidを再起動する。
# /etc/rc.d/acpid restart
これで、イベントが発生するたびに、acpidが渡してくる文字列が/etc/acpi/test.logに記録される。実際にFn+F1を押してみるとlogファイルには次のような行が追加される。
button/sleep:SLPB:00000080:00000001:::
他のキーを押してみたり、蓋を閉じてみたり、ACアダプタを付けたり外したりして試すと
色々なイベントが追加されるので試してみる。テスト用のスクリプトファイルは、検証のために７つ分の文字列を用意したけれど、送られてくる文字列は、４つの部分に分かれた文字列が送られてくることが分かる。また、４番目の要素は、そのイベントが呼ばれるたびに増えたりするらしいこともわかる。
これらのうち、特にS101でキーを押した場合の%eの３つ目までの要素の対応をまとめてみると以下の通り。
fn+F1 button/sleep SLPB 00000080
fn+F2 hotkey ATKD 00000010
fn+F3 hotkey ATKD 00000037
fn+F4 hotkey ATKD 0000001b
fn+F5 hotkey ATKD 0000002* (押すと数字が下がる)
fn+F6 hotkey ATKD 0000002* (押すと数字が上がる)
fn+F7 hotkey ATKD 00000016
fn+F8 hotkey ATKD 00000030
fn+F9 hotkey ATKD 00000012
fn+F10 hotkey ATKD 00000013
fn+F11 hotkey ATKD 00000014
fn+F12 hotkey ATKD 00000015
fn+space hotkey ATKD 00000039
left_silver hotkey ATKD 00000039
right_silver button/power PWRF 00000080
fn+F5とfn+F6は３つ目の要素が変則的
ここで、acpi-eeepc-S101-events.confと見比べてみると、前半部分の定義は%eの第３要素についての定義をしているのが分かる。そして、定義の内容が多少ずれているのも分かる。また、配列定義になっている部分も、後半部分の定義で第１要素のみを定義しているため不必要っぽい。
そこで、実際に自分で試した結果で前半の定義を書き換えると次のようになる。
#Silver buttons
KEY_SILVER1="00000039"
KEY_SILVER2="00000080"
KEY_SILVER3=NONE
KEY_SILVER4=NONE
#Fn+F? combination
KEY_Fn_F1="00000080"
KEY_Fn_F2="00000010"
KEY_Fn_F3="00000037"
KEY_Fn_F4="0000001b"
KEY_Fn_F5="0000002*"
KEY_Fn_F6="0000002*"
KEY_Fn_F7="00000016"
KEY_Fn_F8="00000030"
KEY_Fn_F9="00000012"
KEY_Fn_F10="00000013"
KEY_Fn_F11="00000014"
KEY_Fn_F12="00000015"
KEY_Fn_Space="00000039"
そして、これに対応して、後半部分も書き換えるが、もともと定義されていない部分、
F3,F4辺りも追加して整理してみると次の通り。
#Match previous to functions
EEEPC_BLANK=$KEY_SILVER1
EEEPC_RESOLUTION=NONE
EEEPC_USER1=$KEY_Fn_F3
EEEPC_USER2=$KEY_Fn_F4
EEEPC_USER3=NONE
EEEPC_SLEEP=$KEY_Fn_F1
EEEPC_WIFI_TOGGLE=$KEY_Fn_F2
EEEPC_WIFI_UP=NONE
EEEPC_WIFI_DOWN=NONE
EEEPC_TOUCHPAD_TOGGLE=NONE
EEEPC_BRIGHTNESS_UP=$KEY_Fn_F5
EEEPC_BRIGHTNESS_DOWN=$KEY_Fn_F6
EEEPC_XRANDR_TOGGLE=$KEY_Fn_F8
EEEPC_XRANDR_TOGGLE_0=NONE
EEEPC_XRANDR_TOGGLE_1=NONE
EEEPC_XRANDR_TOGGLE_2=NONE
EEEPC_TASKMAN=$KEY_Fn_F9
EEEPC_VOL_MUTE=$KEY_Fn_F10
EEEPC_VOL_DOWN=$KEY_Fn_F11
EEEPC_VOL_UP=$KEY_Fn_F12
以上がacpi-eeepc-S101-events.confの修正になるが、注意点がある。
/etc/acpi/acpi-eeepc-generic-handler.shを読み解けば、処理の場合分けの仕組みは、まず、%eの第１要素で大きく分けられている。このうち、acpi-eeepc-S101-events.confの設定は、第１要素が「hotkey」の場合の第３要素の振り分けに用いられている。
つまり、fn+F1と電源ボタンについては、S101の場合ここでの設定は意味が無いことになる。
（３）具体的なコマンドの呼び出し設定。
キーの対応付けが修正できたら、次は/etc/conf.d/acpi-eeepc-generic.confで自分のシステムにあった設定を行うことになる。設定の仕方は、ファイルのコメント部分に記載されている。
・Xアプリの権限 XUSER
XUSERの値として、Xアプリ実行者権限を入れておく。
・お知らせ機能 NOTIFY
NOTIFYの値は、コメント通り
gnome系ならlibnotify
KDE系ならkdialog
汎用のdzenならdzen
特に必要ないなら、NONE
・無線ランドライバ WIFI_DRIVERS
S101の場合、ath9kなので
WIFI_DRIVERS=("ath9k")
・設定完了のしるし EEEPC_CONF_DONE
この変数の値がnoの間、お知らせメッセージに設定未完了の旨の表示がでる。
no以外なら出ないので、設定が終わればこの行をコメントアウトする。
・デバイストグルのリストア
RESTORE_hogehoge変数は、システム起動時に、前のデバイスのオンオフ状態を引き継ぐかどうかのフラグ。１で引継ぎ、０でシステムの初期値
・COMMAND_hogehogeによる、コマンド設定
変数の値は配列も可、コマンドの先頭に@をつけると、ユーザー権限で実行。変数名でおおよその対応イベントが分かるが、詳細な対応は/etc/acpi/acpi-eeepc-generic-handler.shファイルをみて直接確認する。また、実は変数の入れ子や、他のユティリティファイルそのものの変数も混在していて、結構読み解くのはめんどくさい。
デフォルトのままで、画面輝度の調整やボリューム調整はできるとおもう。
３．電力節約術
ACPIは結局のところ、ノートパソコン等で電源を長持ちさせるための仕組みなので、これを実現する幾つかの点に絞ってその設定を検証する。
・サスペンド、ハイバネート
サスペンドはメモリに情報を退避して、休眠状態にする方法
ハイバネートはHDDに情報を退避して、休眠状態にする方法
通常、acpiイベントのsleep/suspendイベントに対応して、処理を行うことになる。
acpi-eeepc-genericでは、sleep/suspendイベントに対応して、COMMANDS_SLEEP変数の値が呼び出される。サスペンド、ハイバネートについては、acpi-eeepc-generic同梱のスクリプトとしてacpi-eeepc-generic-suspend2ram.shがある。
サスペンド、ハイバネートについては、いろいろな方法があるが、pm-utilsを使うことにする。そのあたりは、別文書で記載
・画面表示の電源
Xの場合、画面表示のLED電源を落とすことができる？
未検証
・ワイヤレスデバイスの電源を落とす。
無線ランやブルートゥースデバイスは、よく電気を食うらしいので、これらを使っていないときにデバイスの電源を落とす。特に、無線ランについては、デバイスの制御と共に、ネットワークへの接続も含めてボタンでオンオフ出来るようにすると便利なので、その当りを別文書で検討する。
acpi-eeepc-generic同梱のユティリティスクリプトはacpi-eeepc-generic-toggle-wifi.shだが、そのままではS101の場合上手く働かないように見える。
イベントの対応は、無線ランがCOMMANDS_WIWI_TOGGLE。
ブルートゥースは直接の対応がないので、Fn+F3（上記の設定でCOMMAND_BUTTON_USER1）辺りに割り振る。
2009年9月29日火曜日
halevtでマウント
仕事が暇になっちゃったので、久々にメモ
リムーバブルメディアのマウントについて色々みてみた。
S101ではpcmanfmファイラを使って、USBメモリとかSDカードをマウントしてた。
デスクトップで使っている場合、gnomeやkdeがいろいろと面倒をみてくれるし、それに乗っかってるのが楽だけれど、netbookのS101で遊ぶには、ファイラに依存したり、そもそも、Xを立ち上げてるかに関係なく、リムーバブルメディアを差したらマウントしてくれる方が便利。
ここで、整理しておくことは、システムが機器を自動的に認識する仕組みとマウントをする仕組みは別々に考えること。その上で、リムーバブルメディアのマウントについて見てみると次の様な方法がありそう。
（１）udev
udevはデバイスファイルの作成とモジュールのロードを担当する仕組み。
オプションの機能で外部プログラム呼び出しが出来るので、
これでマウントをする事ができるかもしれない。
（２）hal
halはホットプラグに関連して、デバイスの情報データベースを持って
整理し、 これを利用してアプリケーションにデバイスの追加や削除を
含んだ情報配信をしている。
hal自体にオートマウントに機能は無い。（はず）
主にX上のデスクトップアプリケーション（主にファイラ）が
halからのD-busメッセージを経由して、自動的にマウントを行う。
（３）autofs
autofsはそれ自体が、自動的にマウント制御をするもの。
（４）ivman
halとD-busを利用したボリュームマネージャだったが、2007年頃から
開発が停滞。halのアップデートに伴い、pathcが必要。
arcｈではAURのメンテナも撤退？
現在、適切に動くかどうか不明（将来的にはオブソレート？）
（５）halevt
ivmanの後継的位置づけ（？）
halを使わないなら、udevのみでも出来そうな気もする。
autofsはリムーバブルメディアよりも、ネットワークファイルシステムの
自動マウントに昔から使われている仕組みらしい。
で、結局うちで試してみたのはhalevt。
ホームページ：http://www.nongnu.org/halevt/
AURのページ：http://aur.archlinux.org/packages.php?ID=24244
ドキュメントとしては上のホームページに設定の仕方が載っているが、元のソースファイル農中にあるREADMEも参照すると分かりやすい。AURのパッケージをインストールするとその辺のドキュメントはインストールされないので、別途拾ってきて見る方がお勧め。
halevtはhalを利用してデバイスの検知を契機に、任意のアクションを起こす仕組みを提供してくれる。
とりあえず、使いたい場合は以下の設定をする。
１．パッケージインストール
archではＡＵＲにあるので、パッケージ「halevt」をyaourt等でインストールする。
２．設定ファイル
サンプルの設定ファイルが/usr/share/halevt/examples/以下に配置されている。
examplesディレクトリにあるautomatic_sync_mount.xmlを
/etc/halevt/ディレクトリに置く
設定ファイル内のhalevt-mountの-mを000で読み書き実行全て可能
３．マウントの権限
/etc/PolicyKit/PolicyKit.confに以下を追加。
４．デーモン
halevtはhalを利用するので、rc.confのDAEMON配列にhalとhalevtを加える。
以上の設定をしておけば、とりあえず、差したらマウントしてくれる。
その他の方法としては、上の様にシステム側でのデーモンとして動かさないで、ユーザー権限で動かすこともできる。設定ファイルを書いていく上でのとっかかりとして押さえておくオプションは以下のもの。
-f オプションでフォアグラウンドで動く。
-i オプションでモニタモードで動く。
-c オプションで設定ファイルを指定する。
自分で設定ファイルhogehogeを書いて試すときは、次のコマンドでhalevtからの出力も見ることが出きるので調整しやすい。
-cオプションが無い場合、以下の順番でディレクトリを検索。
（aurパッケージの場合）
$HOME/.halevt/
/etc/halevt/
/usr/share/halevt
これらのディレクトリの中で、.xmlで終わるファイルを設定ファイルと
みなして読み込んでくれる。
（同一ファイル名の場合、順序が先のディレクトリにあるものが優先）
xmlの事はあまり詳しくないけれど、設定の基本はmatch要素でデバイスを
マッチさせてそのターゲットについて、OnInit(halevt立ち上げ時),
Insertion（デバイス認識時）,Removal（デバイス削除時）等に、
対応したコマンドラインを設定するらしい。
halevtパッケージにはhal経由でマウントしてくれるhalevt-mount等の
ユティリティが同梱していてこれを利用する。hal経由のマウントについては、
先の設定で紹介したように権限の問題があるので、ユーザー権限で利用する
場合は/etc/PolicyKit/PolicyKit.confにユーザーを登録する必要がある。
その他の注意というか勉強TODOとしては、halが管理する情報のコンフィグ
の仕方の情報ポインタがよく分からない、、
mountポイントの名前付けルール等はhal側の設定になってると思う。
権限の扱いに付いても、イマイチ、、、
自動でマウントは出きるようになった。
しかし、USBメモリを抜く前にumountすべきなんだろうけど、
どういう作法が良いのかよくわからない。
シンクロはしてるようなので、ファイル扱った後、
ちゃんと閉じて、暫くしたら気にせず、ぶっこ抜いとけばいいのかな？w
後はぁ、、halevtとgnome上のファイラとか機能がかぶってるとどうなるのか不明。
まぁ、そのときはhalevtデーモン切ればいいか。。
リムーバブルメディアのマウントについて色々みてみた。
S101ではpcmanfmファイラを使って、USBメモリとかSDカードをマウントしてた。
デスクトップで使っている場合、gnomeやkdeがいろいろと面倒をみてくれるし、それに乗っかってるのが楽だけれど、netbookのS101で遊ぶには、ファイラに依存したり、そもそも、Xを立ち上げてるかに関係なく、リムーバブルメディアを差したらマウントしてくれる方が便利。
ここで、整理しておくことは、システムが機器を自動的に認識する仕組みとマウントをする仕組みは別々に考えること。その上で、リムーバブルメディアのマウントについて見てみると次の様な方法がありそう。
（１）udev
udevはデバイスファイルの作成とモジュールのロードを担当する仕組み。
オプションの機能で外部プログラム呼び出しが出来るので、
これでマウントをする事ができるかもしれない。
（２）hal
halはホットプラグに関連して、デバイスの情報データベースを持って
整理し、 これを利用してアプリケーションにデバイスの追加や削除を
含んだ情報配信をしている。
hal自体にオートマウントに機能は無い。（はず）
主にX上のデスクトップアプリケーション（主にファイラ）が
halからのD-busメッセージを経由して、自動的にマウントを行う。
（３）autofs
autofsはそれ自体が、自動的にマウント制御をするもの。
（４）ivman
halとD-busを利用したボリュームマネージャだったが、2007年頃から
開発が停滞。halのアップデートに伴い、pathcが必要。
arcｈではAURのメンテナも撤退？
現在、適切に動くかどうか不明（将来的にはオブソレート？）
（５）halevt
ivmanの後継的位置づけ（？）
halを使わないなら、udevのみでも出来そうな気もする。
autofsはリムーバブルメディアよりも、ネットワークファイルシステムの
自動マウントに昔から使われている仕組みらしい。
で、結局うちで試してみたのはhalevt。
ホームページ：http://www.nongnu.org/halevt/
AURのページ：http://aur.archlinux.org/packages.php?ID=24244
ドキュメントとしては上のホームページに設定の仕方が載っているが、元のソースファイル農中にあるREADMEも参照すると分かりやすい。AURのパッケージをインストールするとその辺のドキュメントはインストールされないので、別途拾ってきて見る方がお勧め。
halevtはhalを利用してデバイスの検知を契機に、任意のアクションを起こす仕組みを提供してくれる。
とりあえず、使いたい場合は以下の設定をする。
１．パッケージインストール
archではＡＵＲにあるので、パッケージ「halevt」をyaourt等でインストールする。
２．設定ファイル
サンプルの設定ファイルが/usr/share/halevt/examples/以下に配置されている。
examplesディレクトリにあるautomatic_sync_mount.xmlを
/etc/halevt/ディレクトリに置く
設定ファイル内のhalevt-mountの-mを000で読み書き実行全て可能
３．マウントの権限
/etc/PolicyKit/PolicyKit.confに以下を追加。
<config version="0.1">
<match user="halevt">
<return result="yes"/>
</match>
</config>
４．デーモン
halevtはhalを利用するので、rc.confのDAEMON配列にhalとhalevtを加える。
以上の設定をしておけば、とりあえず、差したらマウントしてくれる。
その他の方法としては、上の様にシステム側でのデーモンとして動かさないで、ユーザー権限で動かすこともできる。設定ファイルを書いていく上でのとっかかりとして押さえておくオプションは以下のもの。
-f オプションでフォアグラウンドで動く。
-i オプションでモニタモードで動く。
-c オプションで設定ファイルを指定する。
自分で設定ファイルhogehogeを書いて試すときは、次のコマンドでhalevtからの出力も見ることが出きるので調整しやすい。
$ halevt -f -c hogehoge
-cオプションが無い場合、以下の順番でディレクトリを検索。
（aurパッケージの場合）
$HOME/.halevt/
/etc/halevt/
/usr/share/halevt
これらのディレクトリの中で、.xmlで終わるファイルを設定ファイルと
みなして読み込んでくれる。
（同一ファイル名の場合、順序が先のディレクトリにあるものが優先）
xmlの事はあまり詳しくないけれど、設定の基本はmatch要素でデバイスを
マッチさせてそのターゲットについて、OnInit(halevt立ち上げ時),
Insertion（デバイス認識時）,Removal（デバイス削除時）等に、
対応したコマンドラインを設定するらしい。
halevtパッケージにはhal経由でマウントしてくれるhalevt-mount等の
ユティリティが同梱していてこれを利用する。hal経由のマウントについては、
先の設定で紹介したように権限の問題があるので、ユーザー権限で利用する
場合は/etc/PolicyKit/PolicyKit.confにユーザーを登録する必要がある。
その他の注意というか勉強TODOとしては、halが管理する情報のコンフィグ
の仕方の情報ポインタがよく分からない、、
mountポイントの名前付けルール等はhal側の設定になってると思う。
権限の扱いに付いても、イマイチ、、、
自動でマウントは出きるようになった。
しかし、USBメモリを抜く前にumountすべきなんだろうけど、
どういう作法が良いのかよくわからない。
シンクロはしてるようなので、ファイル扱った後、
ちゃんと閉じて、暫くしたら気にせず、ぶっこ抜いとけばいいのかな？w
後はぁ、、halevtとgnome上のファイラとか機能がかぶってるとどうなるのか不明。
まぁ、そのときはhalevtデーモン切ればいいか。。
2009年8月31日月曜日
次スレが出来てた
２ちゃんのarchスレがいっぱいになって、次のスレに移行してた。
夏は結局仕事が忙しくて盆休みどころか、土日も無くトホホ。。。
その割には、仕事から帰ってから夜な夜なWiiのモンハン３にハマったｗ
s101の方は、相変わらず無線LANが繋がらなくて、どうにかならないものかと
ごちょごちょやってみてた。
デバイス自体はずっと認識されてるから、ドライバの問題なんだろうけど、、
acpi経由（？）でいったん、無線LANデバイスを落としてから、もう一度立ち上げて、
それから、接続手順を踏むと、たまに繋がったりする。
ちゃんと繋がってたカーネルのバージョンもあったので、モジュールのソースの違いを
確かめたらいいのかなぁ、、
で、仕事が一段落したので、なんとなく本屋さんにあったRubyの本を買ってみた。
夏は結局仕事が忙しくて盆休みどころか、土日も無くトホホ。。。
その割には、仕事から帰ってから夜な夜なWiiのモンハン３にハマったｗ
s101の方は、相変わらず無線LANが繋がらなくて、どうにかならないものかと
ごちょごちょやってみてた。
デバイス自体はずっと認識されてるから、ドライバの問題なんだろうけど、、
acpi経由（？）でいったん、無線LANデバイスを落としてから、もう一度立ち上げて、
それから、接続手順を踏むと、たまに繋がったりする。
ちゃんと繋がってたカーネルのバージョンもあったので、モジュールのソースの違いを
確かめたらいいのかなぁ、、
で、仕事が一段落したので、なんとなく本屋さんにあったRubyの本を買ってみた。
2009年7月17日金曜日
texとか
最近、暑すぎる！！
仕事で外に出ることが多くてくたくた＞＜
昔texで仕事の書類を作って見たことがあったので、またやってみようかなぁ〜とか思い、埃をかぶったLatex2eの本達を引っ張り出してきてツラツラ読んだりしてた。
当時使ってたのって、vineかDebianJPで日本のディストリだったから、勝手にインストールされてたんだけれど、、Archの場合、パッケージをインストールして、、ってわけにはいかないのね（＾＾；
なにやら時代はLatex3を通り越してtexLiveとかいうのに進化してるの？？
そもそもtexそのものについて詳しいわけではなく、ディストリに入ってたLatexを使ってただけなので、なんのことかさっぱり分からん。Webで検索してみるとptexliveってのがあって、wiki上で日本のtexのこれからの方向性とか熱く議論されてた。んで、やっぱりわからんw
windozeで昔の本の付録についてるCDからインストールして使うのがお手軽かな
仕事で外に出ることが多くてくたくた＞＜
昔texで仕事の書類を作って見たことがあったので、またやってみようかなぁ〜とか思い、埃をかぶったLatex2eの本達を引っ張り出してきてツラツラ読んだりしてた。
当時使ってたのって、vineかDebianJPで日本のディストリだったから、勝手にインストールされてたんだけれど、、Archの場合、パッケージをインストールして、、ってわけにはいかないのね（＾＾；
なにやら時代はLatex3を通り越してtexLiveとかいうのに進化してるの？？
そもそもtexそのものについて詳しいわけではなく、ディストリに入ってたLatexを使ってただけなので、なんのことかさっぱり分からん。Webで検索してみるとptexliveってのがあって、wiki上で日本のtexのこれからの方向性とか熱く議論されてた。んで、やっぱりわからんw
windozeで昔の本の付録についてるCDからインストールして使うのがお手軽かな
2009年7月2日木曜日
xtermでuim編集時の文字化け
IONノートの方にはなんとなくuim入れたんだけど、xterm上で使うと日本語入力してる最中の編集部分？が文字化けしてた。gtkアプリは問題ないみたい。
解決策はuim-jaっていうメーリングリストの「[uim-ja 142] Re: Mandriva 200 9.1 上でクラッシュ」で紹介されていた。
を~/.Xdefaultsとか~/.Xresourcesとかで読み込ませる。
2ちゃんで質問してみたら、同じ症状の人とかいた。
だけど、多分、普段みんなDE付属のgtkとかqtベースのターミナル使ってるだろうし、今更xtermとかでの不具合に気がつかなかったのかもしれないw
文字化けしてないよーって人が自分の設定とか紹介してくれたけれど、うちでは上手くいかなかった。
結局、文字化けする人としない人の違いって何処だったんだろう？
vineからビットマップフォント流用してみてるって人のを試したら上手く行ったのかな？
XTerm*font: とXTerm*fontDoublesize: で適切なフォントしていしたらxterm*ximFont: もそのフォントになるのかな？リソースの階層？のこととかいまいちよくわからん。
それ以前に、xrdbってのをすっかり忘れてた。はじめ~/.Xdefaultsにカキカキしてて、あれれ？？だった。
Xの起動の仕方によるんだろうけど、うちではstartxでxrdbされてるらしい。
.xinitrcの先頭で
して、リソース設定は~/.Xresourcesに書くようにした。
すぐ忘れるので適当にググってメモ
UNIXの部屋 コマンド検索: ~/.Xresourcesとか？
解決策はuim-jaっていうメーリングリストの「[uim-ja 142] Re: Mandriva 200 9.1 上でクラッシュ」で紹介されていた。
xterm*ximFont: -misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0
を~/.Xdefaultsとか~/.Xresourcesとかで読み込ませる。
2ちゃんで質問してみたら、同じ症状の人とかいた。
だけど、多分、普段みんなDE付属のgtkとかqtベースのターミナル使ってるだろうし、今更xtermとかでの不具合に気がつかなかったのかもしれないw
文字化けしてないよーって人が自分の設定とか紹介してくれたけれど、うちでは上手くいかなかった。
結局、文字化けする人としない人の違いって何処だったんだろう？
vineからビットマップフォント流用してみてるって人のを試したら上手く行ったのかな？
XTerm*font: とXTerm*fontDoublesize: で適切なフォントしていしたらxterm*ximFont: もそのフォントになるのかな？リソースの階層？のこととかいまいちよくわからん。
それ以前に、xrdbってのをすっかり忘れてた。はじめ~/.Xdefaultsにカキカキしてて、あれれ？？だった。
Xの起動の仕方によるんだろうけど、うちではstartxでxrdbされてるらしい。
.xinitrcの先頭で
xrdb -merge $HOME/.Xresources
して、リソース設定は~/.Xresourcesに書くようにした。
すぐ忘れるので適当にググってメモ
UNIXの部屋 コマンド検索: ~/.Xresourcesとか？
登録:
投稿 (Atom)