aweomeとluaの参考書

S101では、gnomeやkde、いわゆるデスクトップ環境（ＤＥ）を起動しない、ウインドマネージャ（ＷＭ）のみを利用している。そして、そのＷＭには、タイリングＷＭの一つ、awesomeを使っている。

以前にもメモした通り、awesomeの設定ファイルはlua言語で書かれていて、その内容は、tagやウインドウの動作に関するルール、キーバインド、ステータスバーやこれに含ませるコンテンツの動作等、awesomeの動作のほぼすべてに渡っての設定を行う事になる。

これは何も設定をしなければ、デフォルトの規定で動くというものではなく（3.4以降はフォールバック機能がありそう）、まさに、何も書かれていないという設定どおりに何もしてくれない。このため、awesomeの設定ファイルには、ＷＭとして動作するための必要最低限の動作のための設定項目が全て書かれており、その設定の内容についても、動作の規定については、フラグ変数でオンオフを書き換えるというようなものでなく、Luaを使ったawesomeのＡＰＩを経由するプログラムを書き換える作業が必要になるため、awesome自体を楽しもうとするならば、Lua言語の知識も多少なりとも必要になる。

以前のメモの時に購入したluaに関する入門書は、プログラミング自体が初めてという感じの初心者向けの本で、言語の事自体を体系的に述べられておらず、「こういう場合はどうなんだろう？」という好奇心が沸いた時には参考にする事が出来ないものだった。

ところが、こないだたまたま本屋に立ち寄った時に、

「Programming in Lua プログラミング言語Lua公式解説書」

という本を見つけた。新しく出版されたらしい。もともと、原文での解説は、前にも紹介したとおりweb上でも公開されている。けれどボリュームがあるので、やっぱり日本語で読めるとありがたい。特に、初めて触れる言語なら、尚更そう思う。実際にこの本を読んでみると、言語自体について、開発者が解説しているためとても分かりやすい。初めてLuaに触れる、若しくは、興味ある人にとってはお勧めの一冊だと思う（必携でもいいと思う）。

S101近況

みんな、ホスト名ってどうやって付けているんだろう？？
うちのは、むかーーし、インターネットを始めた頃、今の「メル友」ってのとは、少しニュアンスの違う昔の文通友達に近いような「メールフレンド」が出来て、その人のペンネームが「madokita」だった。この、「まどきた」っていうのは、どこかの言葉で「マドンナ」と同じらしいって事を聞いた。「マドキータ」とか読むらしい。それ以来、なんかこの単語を気に入って、メインのパソコンのホスト名はいつもこれだ。で、今はこのS101がmadokitaを名乗っている。

当のまどきたさんとメールのやりとりをしていたのは、かれこれ14、5年位前になるけれど、元気にしているのかなぁ？と、たまに思い出す。

おいらをlinuxの世界に引き込んだ友達は、飼い猫の名前をホスト名にしていた。彼とも長いこと連絡をとっていないけれど、今でもそうなのかなぁ？もし、このメッセージをみたら、連絡をよこすように！！！w

さて、オークションでゲットしたintel wifi link 5300っていう無線lanデバイスをとりつけてみた。調子の方は上々。一旦つながってしまうと勝手に切断されてしまうことはないようなかんじ。ただ、サスペンド等、デバイスの電源を落とした後の、デバイスの再起動の時はいまいち動作が安定しないかんじ、、、pm-utils用のスクリプトも書いてみたけど、イマイチ。もういちど、ちゃんと動作させようと思うと、一旦、システム自体の電源を落とした後に、立ち上げなおすと、普通に動く。まぁ、、前よりは普通に使えるようになったので満足。

数日前にawesomeが3.4にアップデートされていた。
もともと、gitの方で3.4も試してみていたんだけれど、モジュールが一新されていて、3.3以前のコンフィグファイルだと立ち上がらない。書き換えるのがじゃまくさいってのは、書き換えたら済むはなしなんだけれど、別の点で困ったことに、xcompmgrとの相性が悪くなっていた。

公式リポジトリにアップデートされるまえのgitの状態では、画面表示が思いっきり重くなってて、実用レベルじゃなかった。その時点では、xcompmgr-gitは、xorgの公式リポジトリのバージョンが低くて、コンパイルが弾かれてた。

で、公式リポジトリにアップデートされた今、awesomeを3.4にして、xcompmgr-gitもコンパイルが通るようになったので、それを導入してみた。通常は普通に使えるけれど、同じタグ内に複数のウインドウを開くと、重くなる症状がでたりする。一旦タグ移動したあと、戻ると、治ったりするけれど、イマイチ不安定。

せっかく、3.4用のrc.lua書いたけど、一応3.3に戻して様子見かなぁ

あと、しばらくxorg入れてなくて、コンソールで作業してることが多かったので、バッシュのプロンプトも適当に書いてみた。acpiコマンドからバッテリーの様子を引っこ抜く関数を適当に書いて呼び出してるせいか、プロンプト表示にワンテンポかかる（＾＾；
っていうか、.bashrcにいろいろとかくと、ターミナル起動時にプロンプトがでるまでに1秒くらいかかってるかも、、

ヤフーオークションやってみた！

節電術のPM-Utilsのメモ書こうとおもってたんだけど、インストールするだけで動いてるからイマイチ色々試してみる気が起こらない。

唯一引っかかるところは、無線LANが繋がってる状態で、サスペンドして、リジュームすると、上手く元に戻らないんだけど、、pm-utilsには、一般的に必要になりそうな、サスペンド前処理スクリプトと、リジューム後スクリプトが用意されていて、netcfgを使っている場合には、これらの処理を上手くこなしてくれるスクリプトも用意されている。

そんで、無線LANについて、上手くいかないのは、pm-utilsの問題じゃなくて、やっぱり、S101の無線LANのデバイスなんじゃなかろうか？って感じ。acpi関連のメモを書き始めた時のカーネルバージョンでいつの間にか無線LANがまた使えるようにはなっていたんだけれど、イマイチ動作が不安定だった。だいたい、１０分間、何もしないでいると勝手に回線が切れちゃうっていう症状がある。

前と違って、ifconfigでデバイスアップした後は、iwlist scanが必ず出来るようになっていたので、wpa_suplicantでの制御がおかしいのかなぁ、、と、接続にWPAを使わず、認証無し状態だと、どんな感じか試しているところなんだけれど、回線が切れない状態が続くような感じ、、でも、勝手に切断もあった。

そんなこんなしている最中に、なんとなくシステムのアップデートをしてみたら、カーネルの.31がtestingからcoreに来ていた！！カーネルのアップデートはだいたい、無線LANに影響があるからignoreしていたんだけれど、.31はやっぱり試したくなる！ｗ

早速　pacman -Syu　して、再起動してみたら、、、いつもは起動時にUDev ueventsなんとかいう処理で結構待ったんだけれど、その待ち時間があんまりなくなって、すぐにログインプロンプトが出てきた！！

おおお！！！いいぞーーー！！とか、ちょっと興奮したｗ

で、、問題の無線LAN。恐る恐る、Fn+F2ボタンを押してみる。こないだ、メモに書いた時は、立ち上げ後処理でnetcfgとか登録してたけれど、今は外してあって、ifconfigでのデバイスのupまでにしてある。つまり、ifconfigで確認したらwlan0があるはずなんだけど、、、ない！！

iwconfigで見ると、あるので、手動でifconfig wlan0 upとしてみると、見たこと無いエラーが出現。。。。トホホ

いつものように、archlinuxのフォーラムでath9kで検索すると、ひっかかった。
みんな、うちとまったく同じ状況らしいｗ結構レスがあったけど、チラッと見る感じみんな不具合の症状ばかりかいてるみたいなので、めんどくさくなって、あまり読まずに、カーネルを.30のに戻して終了（＾＾；

どうも、無線LANの不安定さはいつまでたってもひっかかるので、googleで「s101 無線LAN」とか何気なく検索すると、やっぱり、無線LANデバイスの換装の話題が引っかかる。あれこれ読んでいると、前に探してたintel wifi 5300とかいう、ノートに内蔵できるカードがオークションで安く手に入るらしい事が書いてあり、ヤフーオークションで見てみると、5300以外にも結構な品数があった。最近の流行はwimaxが使えるやつらしく、ニセモノとかも出回る大賑わいらしかったｗ

ヤフーオークション自体は、ずーーっと前に、缶コーヒーのおまけについてるミニカーコレクションをしていたら、全部集められなくて、足りないのをオークションで買ったｗ

だけど、だいぶん昔に１度やってみただけなので、取引のやり方とかイマイチよくわからない。まぁ、何とかなるかと思いながら、オークションに参加。ボタン押したら即決だったらしく、そのまま終了しちゃった。そっから、先がまたよくわからないので、画面の指示通りなんとなく、出品者に「落札しました」ってメッセージを送ってみたけど、それでいいのかな？

上手く取り付けられるかわからないけれど、早く試してみたいな～！！快適wireless生活になるのかな？？ｗ上手くいったらionノートにもつけてみよーっと！

CPUの節電

acpi絡みでCPUの節電ってのを始めて知ったのでメモ。

CPUの節電のために、パワーを制御することが出来る。S101のCPU、Atom N270はデフォルトで1.6GHzで駆動しているが、あまり作業をしていないときなどにクロック数を下げて節電する仕組みがある。archlinuxのWikiで見かけるこの種のユティリティは、CpuFrequtilsとPowernowdの2つ。

CpuFrequtilsの方が[Extra]リポジトリにあるので、こっちを導入してみたが、powernowdの方が設定は簡単っぽい。

パッケージ「cpufrequtils」
インストールはpacmanから。

前準備として、acpi-cpufreqモジュールをロードする。
#modprobe acpi-cpufreq

常時読み込みのため/etc/rc.confのMODULES配列に加えておく。
MODULES=(acpi-cpufreq ...)

モジュールが読み込めたら、以下のコマンドでS101のCPU情報を見ることができる。
$cpufreq-info

N270については、cpu0とcpu1の二つの情報がみれて、
そのそれぞれについてセッティング出来るクロック数や現在のクロック数がみれる。

1．cpuの設定モジュール「scaling govenor」
通常、CPUはいつも最大出力で動いている。しかし、cpufrequtilsは、あまり働かない時にはクロック数を下げる等のいくつかの決まった節電パターンで動かすためのモジュール（govenor）を提供してくれる。モジュールの種類は以下の通り

performance
　いつも最大クロックで駆動する。（カーネル付属のデフォルトモジュール）
cpufreq_ondemand
　システムロードに従って、クロック数を変化させる。（お勧めモジュール）
cpufreq_conservative
　ondemandと似ているが、保守的でクロックスピードは上品に変化する？
cpufreq_powersave
　最小クロック数で駆動させる。
cpufreq_userspace
　ユーザーがルールを定義できる。

これらのうち、好きなモジュールを（全てでも良い）ロードする。
　※modprobe、恒常的には/etc/rc.confのMODULES配列で読み込み。

読み込んだモジュールのうち一つを選択してcpufreq-setコマンドを使い、対応したパターンでCPUを動かすことが出来る。

#cpufreq-set -g ondemand

使い方は、-gオプションでgovernor名を指定する。
ロードしていないモジュールのgovernorは選択できない。

2．しきい値の変更
ondemandモード等でCPUが動いている場合、CPUの使用率が低い時にクロック数は最小値で動いている。そしてデフォルトではこの状態からCPUの使用率が95％を越えると、クロック数が変更されるようになっている。この95％のしきい値を変更する事も出来る。

現在のしきい値は/sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_thresholdファイルに記されているので、catコマンド等で確認できる。もう少し機敏に反応したい場合は50程度の数値を設定しても良いらしい。

#echo 50 >/sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

但し、これらはリブート時にリストアされないので、/etc/rc.local等で設定して置くと良いらしい。

３．デーモン
/etc/conf.d/cpufreqを設定ファイルとして、/etc/rc.d/cpufreqをデーモンとして動かすことが出来る。

設定ファイルでの設定は、governorパターンの選択のみでOK
governor="ondemand"

最小クロック数と最大クロック数の部分はコメントアウトして自動認識に任せる。
#min_freq="1GHz"
#max_freq="2GHz"

設定ファイルの書き換えがおわったら、rc.confのDAEMONS配列にcpufreqを加えて置く。

alt+→とか

バーチャルコンソールの移動って、ずっとalt+F?キーでやってた。
ネット接続の検証用に、テキストブラウザを入れたんだけど、キー操作が分からなくて、色々試していたら、、、alt＋カーソルキーの横矢印でコンソールが移ってびっくり！！ｗ
ずっと、しらなかった、、、
けど、感動したｗ

今日は、仕事で秋葉原まで行った！生まれて２回目くらい。
でも、時間が無くてまったく店とか物色できなくて、しょんぼり、、、
前に行ったのってもう１０年くらい前かなぁ？
その時は、あちこち歩いてみたんだけど、何処に何があるのかさっぱりわからんうちに日が暮れて、友達が迎えに来たｗ

とか、どうでもいいんだけど、、、
自分のブログ読み返すと、誤字脱字多いなぁ～
あと、内容で嘘っぽいのもありそう（＾＾；
今、S101にはX入れてなくて、ブログは別パソコンから書いてたりするので、パスとか変数名とか手打ちしてて、なんか写し間違いとかいっぱいありそうな予感。
もし、参考にしてる人がいたら注意してみてくださいねー

無線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無効となっている。

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）辺りに割り振る。