qpe の置き換え

しょうがねぇ、タッチパネルデバイス真面目に読むか ... という前にタッチパネルを叩いてる /home/QtPalmtop/bin/qpe を qtopia-free のものに置き換えるテスト。 qpe の中でフックするためにはソースがないと困る。

準備

まず、素直な qt-embedded 2.3.2, qtopia-free 1.5.0 を作っておく。

そのまんまリプレースして動けばラクなことこのうえないが、 libqte-ja 突っ込んでハング(?)するらしいマシンがそんな可愛げのある動作をするはずがない。

非互換性

カーネルを読むだけで分かるデバイスの癖、非互換性の一覧、のたぶんごく一部 (--;;

/dev/audio: そもそも仕様が間違ってる。8bit u-law でなければならないのに 16bit PCM になってる。
/dev/dsp (の再生側): 32kHz sampling rate を持たない。また、まったくエラー判定していない。こえーよ。
/dev/dsp (の録音側): ioctl の実装なし。録音アプリ使いもんにならへん。
/dev/sharp_ts: 返す値(構造体) の形は標準的。筆圧は得られない。ハードウエア的には筆圧がとれるっぽいのでもったいないことをする ... 逆に SL-5000 系のが非標準的で、このため互換性なし。
/dev/sharp_kbdctl: まあ、しょうがなかろ。num lock なんて SL-A300 にねーよ。

タッチパネル、キーボード、サウンドは libqte, libqpe が非互換である可能性がある。

qpe の置き換えと起動

常時 qpe が立ち上がってるわけで、そのまんまでは起動する方法がない。リモートから qpe を上げている /home/QtPalmtop/qpe.sh を書き変えて kill -TERM.

# ng /home/QtPalmtop/qpe.sh
# ps  x | grep qpe
 6764 ?        S      0:00 /bin/sh ./qpe.sh
 6767 ?        SN     0:36 qpe
 6791 pts/2    S      0:00 grep qpe
# kill -TERM 6767

... でちゃんと新 qpe が立ち上がる。
はて、動いてる最中の shell script を書き変えた時に、 (書きかえる前の文面でなく)書きかえた後の文面どおりに実行してくれるもんなんだっけか。 ... ま、いいか(をい)。

qtopia-free まんまの qpe を立ち上げると当然のようにコケる。そして qpe.sh は何度も何度も qpe を立ち上げようとして、最後には init が qpe.sh を動かすことを諦めて止まる。

この状態でも、高速起動モードになっている qtopia アプリケーションやリモートログイン中で使ってる ssh などは普通に生きている。あくまで qpe.sh, qpe が死んでるだけ。

したがって qpe.sh を書き直して本来の qpe が立ち上がる状態にしてから kill -1 1 すると本来の qpe が立ち上がって正常復帰する。この間、べつにリセットしたりなんだりするようなことはない。安心して何度もテストできる ... と思うし、実際リセットするはめになったことはないが、常にちゃんと復帰できることを保証するものではない、もちろん :-)

一周目

qpe は qtopia-free の taskbar/ にある。

# cd taskbar
# rm *.o
# make

でもういちど bin/qpe が作り直される。

さて、qpe を動かした時のエラーはというと:

modprobe: Can't locate module char-major-10-214

だそうだ。... すまん、実は数字以外は正確にはおぼてないが、数字だけ合ってればよかろ。 10, 214 が何だと /dev の下を覗くと /dev/sharp_kbdctl だそーだ。

/dev/sharp_kbdctl を叩いてるのは libqte.
qtopia-free の qpe の内部にも /dev/sharp_kbdctl を叩いてる部分があるが、 ... こっちをコメントアウトしても何も変わらんかった。 qpe が期待するものと libqte の実装が違うってことなら、qt-embedded の src/kernel/qkeyboard_qws.o (/dev/sharp_kbdctl を叩いてるやつ) を貰って来て static link してしまえってことで static link してみた。 can't locale なんとかいうエラーは出なくなった。

エラー出なきゃいいんかい、という突っ込みは不許可。エラー出るようでは話にならんという段階。

二周目

qkeyboard_qws の static link だけで動くかってーとそんなことはなく、きっちり止まる。

その qpe, qpe.sh が止まってる最中に覚えたばっかの技を使って、リモートから qpe を strace にかける:

# unset LOGNAME
# strace qpe

これで strace のメッセージがリモートで読める。すると alermserver のなんとかっつーシンボル(すまん、忘れた) が解決できねーとか Global::languageList() が解決できねーなどとのたまう。

... languageList まで手が入ってるって fep 関連か? このあたりは qtopia free の language がそのまま動いてただけに意外。

というわけで qkeyboard_qws.o 以外に alarmserver.o, global.o も qt-embedded から持って来て qpe に static link するとエラーなしに走った。

三周目

落ちなきゃなんとかなるべと qpe.sh 書き換えて起動。

... 正常に起動した。終わり。

証拠写真

証拠写真として通じるかどーか。アイコンの並び順が本来のやつと違う。本来のやつはカレンダーが左上固定になってるんではなかったかな ... もっとも本来の qpe でも↓のようなことはできるかも。

ペンその他は本来の libqte を叩いてるので正常に動く。あくまで qpe だけが置き換えられている。
もちろん alarmserver や language 周りはまた別。実際 suspend/resume でちゃんと復帰できない。

[日記へ] [目次へ]