ブランク
めぐり合わせでGX/SXではCWMをリリースさせてもらってますが、
X10でchargemon scriptをごりごり書いていたころからすると
実は１年近く(10ヶ月ぐらい？)ブランクがあったりします。
X10の頃は、主にchargemon scriptをいじいじしていて、
押下するキーによって、カスタムカーネルを起動しわけたり、
xrecoveryの0.3と1.0を起動しわけたり、
SD起動もできるようにしたりと、そんなことをやってました。
この辺は、一部の開発者さんに配っただけだったですが。
その流れから、カスタムカーネルの切り替えアプリの企画で、
連携用のchargemon書かせてもらったりもしましたが、
こちらは志半ばで…。ご迷惑をおかけしました。
その頃、大型案件のリリースがあって忙しく身動きがとれなかったのです。
で、そのままフェードアウトぎみに、地下にもぐってしまうのですｗ
いや、なんというか、年末だったか年明けだったか、
rayを中古で購入して、特に不満がなかったのですよねー。
まー、X10で言えば、Cobrato氏がdual recoveryとかやってたし、
DoomLoRD氏がBoot Managerみたいのもやってたし、
なんかとりあえず、自分が以前手をつけてたのはもう他の人が形にしちゃってるー。
ので、とりあえずいっかー的な。
とか思っていたら、どんどんセキュリティ面が強化され、
日本モデルはガラスマ化して、なんかこうglobalモデルのカスタムからしたら、
bootloader unlock何それ、おいしいの？的な制約下での
カスタムっつーのが目の前にあったわけです。
ぇーと、まぁ、技術は全く追いついてないんですが…、
locked環境でどこまでやれるかー、ってのがテーマです。
まずやりたかったのは、物理キーが減ってしまったので、
CWMをベースにして、ユーザ定義のスクリプト呼べるメニューアプリ。
その前段としてCWMコンパイルしてたら、ごろうさんからメンテ引き継ぐことになったのですがねｗ
まー、その後はkexecをなんとかしたいのですが、ハードル高い！
全然見えてない。つよさん巻き込むぞー！
前につよさん自分じゃむりー言うてたけどｗ
chargemon:キー押下の検出
cat /dev/input/event2 > /dev/keycheck&
sleep 3
kill -9 $!
if [ -s /dev/keycheck ]
then
…(略)…
fi
どうやら、ハードキーを押すと
/dev/input/event2
に何やらキーイベントが吐き出されるみたいですね。
ここでは、それをcatしてファイルに吐き出させて、そのファイルのサイズが0 byteより大きくなっていることを見て、キーが押された判断をしているようです。
ざっとそんなところが推察されるわけですが、
/dev/input/event2
ってどんなデバイスなんでしょ？
見当はつきますが、SunOS→FreeBSD→Solarisと渡り歩いてきた身には、？？？な代物です。
ググってみると、どうやらlinux kernel 2.2以降からあるInput Subsystemというものらしいです。
event?のひとつひとつが、なにがしかの入力デバイスと結び付いていて、このデバイスファイルを読み取るとデバイスの入力をイベントとして受けとれ、逆に書き込むと、書き込んだイベントに応じた入力が発生したものとして扱われるようです。
かなり便利なデバイスファイルですが、ちょっち危なっかしいですね。
ですが、ということは、chargemonでいうと、吐き出されたkeycheckファイルの中身を見れば何のキーが押されたか、判別できそうだぞってことですね。
では、/dev/input/event2にどんな形式でイベントが吐き出されているか中身を見てみましょう。
私が見たサイトでは、とりあえず、hexdumpで見てみるとどんなもんかわかるよ的なことが書いてあったので、いきなり/dev/input/event2をhexdumpしてみましたw
0000000 43a7 0000 e707 000a 0001 0073 0001 0000
0000010 43a7 0000 3adf 000e 0001 0073 0000 0000
0000020 43a9 0000 e5f6 000c 0001 0072 0001 0000
0000030
これは↑キー押して離したて、↓キー押したまでのものです。
ほうほう、概ねなんとなく見当がつきなすね。
前8 byteは、時間かそれに準ずる何かっぽい。
9,10 byte目は、よーわからんけど固定値？
11,12 byte目が、キーコードっぽい。
13,14 byte 目は、キーのダウン、アップを表してるっぽい。
と言ったところでしょうか。
今回は、とりあえず、見てみましたが、ググればすぐにわかります。
linuxの/usr/include/linux/input.hに構造体がきってあり、
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
こうなってました。
詳しくはググってみてください。
大体あってましたね。
chargemonの中でテキスト処理をすることを考えると、キーイベント1個が16 byte というのは、非常に扱いやすくて良いですね。
単純にhexdumpして1行が1イベントですから。
ということで、私の場合は以下のようにして、キーコードを取り出すことにしました。
cat /dev/input/event2 > /dev/keycheck &
sleep 3
kill -9 $!
if [ -s /dev/keycheck ]; then
# get latest button down event
KEY_CODE=`hexdump /dev/keycheck | egrep ' 0001 0000$' | tail -1 | awk -F' ' '{print $7}'`
fi
keycheckファイルをhexdumpして、まずは、ボタンダウンイベントだけ取り出してます。
今回は最後に押されたキーで判断する仕様にしているのですが、この場合でもシャッターボタンの深押しを判定できるようにするためです。
この場合、
half push down,
full push down,
full push up,
half push up
のようなイベント順序になるからです。
で、downイベントだけ取り出した後tailで最後のイベントだけ拾って、awkで7カラム目のキーコードだけにしています。
後はキーコード値を判定すれば、chargemonの中で処理を分けるのは容易ですね。
一応キーコード値は、以下のようになってます。
# key code definition
KEY_UP="0073"
KEY_DOWN="0072"
KEY_FORCUS="00d7"
KEY_SHUTTER="00d4"
KEY_MENU="00e5"
KEY_HOME="0066"
KEY_BACK="009e"
今回はここで書いてるように、わりと感覚的にこうだろ？でやっちゃってます。
本来はちゃんと裏を取りながら進めていくべきですね。
#文章中では、間に挟んでますが、後から調べたことが多いのです(^^;
chargemon:いぢるきっかけ
xRecovery導入済環境では、Sony Ericssonロゴ表示時に何かキーを押した場合に、OSの代わりにxRecoveryを起動するためのscriptに差し換えられています。
このchargemon scriptでは何かハードキーが押されたという状況だけを判別しており、何のキーが押されたかは、見分けていません。
このことに疑問を覚えたのは、誰かが、xRecoveryの起動に音量キーを使っているという書き込みを見たときでした。
ぇ？！バックキーじゃなくてもいいんだ？
というか、何のキーでもいいんだ…
これがスタート地点なんですが、この時は深く追求してません。
特にキーを見分けてやりたいこともなかったので。
それがxRecovery 1.0.0がリリースされたことで状況が変わりました。
0.3から1.0.0でサポートするscriptがamendからedifyに変更になり、amend scriptで書かれた既存のupdate.zipをそのままでは適用できなくなったのです。
これだけなら、0.3を当面使い続ければ済む話しなんですが、当然過渡期においてはamendなupdate.zipとedifyなupdate.zipが混在して、めんどくさそーです。
もちろん1.0.0にはすぐに使いたい便利な機能もあります。
例えば、backup & restoreに、.android_secureが含まれるようになったこととかです。
これは2.2以降でapp2sdを使ってるユーザには大きいですよね。
そんなわけで、
xRecoveryのv0.3とv1.0.0を両方使いたい！
となるわけです。
では、それを実現するのになにが必要か…？
ひとつは、前半からの流れで、押されたキーで二者の起動を処理分けできること。
ふたつめは、二者を共存させ、それぞれを起動できるようにすること。
というわけで、これらの処理に関わるchargemon scriptの中身を見ていくことになるわけです。
ふぅ、前置きおわり！
次回はchargemonでどうやってキー押下を検出してるかって話しになると思います。