Kobo Touch/Glo/Mini hacking スレ Part.2

>>548

フレームワークのレベルではスリープモードはSleepViewっぽいので、
プラグインみたいにpatchでView自体を乗っ取ることはできるのかな。
本来の処理ロジックがわからないのでPowerOffに落ちるイベントの準備やら
やらなきゃいけないことをすっ飛ばしてしむのでダメか。

今の実験の方式でも、
本来のスリープ画面表示
→5秒アイドルでhookが呼ばれて独自画像
となるので、そこだけみればスリープで独自画像は表示できている(笑)

通常idleで呼ばれたときとSleepViewに入ってから呼ばれたときを
識別しhook側に通知できれば使い物になるような感じ。

多分、スリープモードだとtouch screenのコントローラも落とすために
status-extendedも落とすだろうから、
・cpu sleepのみ
・touchscreen suspend→cpu sleepのシーケンス呼出し
これが識別できればいい。

touchscreenは
"echo %1 >/sys/power/state-extended"
と
"echo 0 >/sys/power/state-extended"
の２つあるからちょい困るな。

あー、hook手法って、出力先だけを変えてpipeに出すようにして
pipe受け側が自前hookという方式のほうが実装がきれいなのかもしれないなあ。
(今は"echo 〜"まるごとを"/usr/local/bin/spms-s3.sh"呼出しに書き換えてる)
待ち受け常駐になるから逆に無駄にメモリ使うだけか？

>>549

/sys/power/state-extendedが読み出し可能らそれを見れば用は済むはずだから
Koboのkernel source見て確認してみるか。

結局nickelの動作をもう少し観測しなきゃ、というのでdebianから抜いてきたstraceを入れて
process,fileのsyscallログを取ることにした。
んー、log fileを出すのにumountされる/mnt/onboardだと不自由だし、
root fsというのも起動からpoweroffまでフルにログ取るとサイズが気になるし、
システムにumountされない専用パーティション作ったほうがいいのかなあ。

んで、sleepの画像はまだhookするタイミングが見つからない。
state-extendedでの判断ではうまくないようだし。

電源オフ画像は、"/sbin/poweroff -f"を呼び出すので、最悪そこをhookすればいいんだが、
"/sbin/poweroff"をunrar方式で差し替えるのは気が引ける(sbinのコマンドだし)
バイナリ書き換えでhookするのも、元文字列が短いので"/usr/local/hogehoge/bin"なんて
深い階層にはできないから、これも抵抗がある。

sleep,poweroff共に/sys/power/stateへの書き込みがあるから
3状態(normal,sleep,poweroff)切り分けられればhook１つだけで済みそうなのになあ。