自從知道 KoboCloud 這個專案後,我就一直在想能不能套用這個概念,自己寫一個 Client/Server 架構的專案來實現翻頁器的功能?由於 porting 一個藍芽 driver 沒那麼簡單,可能還需要 OTG 等,故我這個專案的概念很簡單:
01. Run a Web-Server on Clara, accept two API, /left and /right。
02. Another Client, send two API to Clara.
03. Web-Server clicks screen to simulate to turn page when receiving two API.
看起來應該沒有什麼大問題,目前第一個問題是要選擇哪一種語言來寫 Web-Server?有了 KoboCloud 的信心後,我決定使用 Golang,因為 Golang 本身就內建 Cross-Compiler 的功能,不用像 C 一樣,要準備編譯環境。
底下是我陸續嘗試的過程,留下記錄以供日後參考。
Web-Server
目標:
01. 仿造 KoboCloud,寫一個 KoboServer 機制 - Done
02. 快速寫一個 Server,在 Clara 上驗證可行性,看是否能收到 API - Done
03. Google Linux Mouse Event 之用法 - Done
04. 研究 Linux udev 機制,確定 rule 之行為 - Done
05. 根據 04,寫出一個穩定的 Server,避免 udev rule 一直觸發,運行太多的 Server 實體,導致 Clara 當機 - Done
Client
目標:
01. 當 Server Ready 後,先使用 PC 打 API 即可 - Done
02. Write an Android App to send two API to Server - Done
03. Write another Android App to receive Bluetooth event, then send two API to Server - Done
2020/07/17 日記
由於工作環境都是 Windows,所有的 Script 換行字元都要改成 Linux 下的,否則 Shell 會不開心,另外不論是 Script 或是 Server 的執行檔,移到 Linux 下包裝成 KoboRoot.tgz 時,記得先給執行權限,不然不確定會不會有問題?故最好的方式是直接在 Linux 下 開發,反正我的 UltraEdit 26 也有 Linux 版的授權。
Golang Cross-Compile 方式 on Windows
SET PATH=%PATH%;C:\Go\bin
SET GOPATH=%CD%
SET GOOS=linux
SET GOARCH=arm
SET GOARM=7
2020/07/20 更新
原本以為觸發 Linux Mouse Event 是一件很簡單的事,
沒想到 Event Structure 會跟 Kernel 版本有關,如果是用到不對的 Structure,不論我 Event 怎麼組,一定什麼事都不會發生!結果還是需要花點時間整理消化資料。
幸好之前就有想到一招,就是在組 KoboRoot.tgz 時,裡面預留一道指令,把相關程式搬到 Kobo 顯示的電腦磁碟機內,則不論我是要抽換 HTTPServer 程式,或是要測試一些指令都會很方便,之後也可以如法泡製 udev 的 Script ,目前先留一個測試 Script 方便我除錯就好。
2020/07/21 更新
Google 一個 ParseDir 的 Script 函數,想要看看 Kobo 系統裡面有什麼,結果印了 10 萬多行後,後面全部是亂碼,我猜是因為 Stack 爆掉了,因為 ParseDir 是使用遞迴,而印象中 Clara 記憶體只有 512 MB,晚點最好是只 Parse /etc or /usr/local 等等的資料夾,或者也可以直接下 cp 指令把整個 root 複製一份到 /mnt/onboard 上,我認為 udev 執行時應該是 root 的權限。
至少目前可以看出一些資訊了:(From dmesg command)
01. Linux version 4.1.15-00089-ga2737fc02713 (gallen@gallen-M51AC)
02. gcc version 5.3.0 (GCC)
03. tps6518x 1-0068: PMIC TPS6518x for eInk display
04. mousedev: PS/2 mouse device common for all mice
05. Battery Table (Open Circuit Voltage)
PMU: ricoh61x_set_OCV_table : 00% voltage = 3590900 uV
PMU: ricoh61x_set_OCV_table : 10% voltage = 3687400 uV
PMU: ricoh61x_set_OCV_table : 20% voltage = 3742300 uV
PMU: ricoh61x_set_OCV_table : 30% voltage = 3774100 uV
PMU: ricoh61x_set_OCV_table : 40% voltage = 3788700 uV
PMU: ricoh61x_set_OCV_table : 50% voltage = 3814400 uV
PMU: ricoh61x_set_OCV_table : 60% voltage = 3874200 uV
PMU: ricoh61x_set_OCV_table : 70% voltage = 3927900 uV
PMU: ricoh61x_set_OCV_table : 80% voltage = 3982900 uV
PMU: ricoh61x_set_OCV_table : 90% voltage = 4057300 uV
PMU: ricoh61x_set_OCV_table : 100% voltage = 4141600 uV
06. PMU: ricoh61x_init_fgsoca : * Rbat = 233 mOhm n_cap = 1385 mAH (1500 ?)
07. SD Card
mmc0: new ultra high speed DDR50 SDHC card at address aaaa
mmcblk0: mmc0:aaaa SS08G 7.40 GiB
mmcblk0: p1 p2 p3
VFS: Mounted root (ext4 filesystem) on device 179:1.
08. PMU:_config_ricoh619_charger_params set SDP 500mA charging.
09. Event Information.
/dev/input/by-path/platform-1-0024-event
/dev/input/by-path/platform-ntx_event0-event
/dev/input/event0
/dev/input/event1
/dev/input/mice
晚上試著使用 cp 指令複製 /,一直無法成功,不知道是為什麼?
目的地要寫絕對路徑,不能用相對路徑。
ls -al / 結果
ls -al /usr/local 結果
cat /proc/bus/input/devices 結果
2020/07/22 更新
從 /proc/bus/input/devices 來看並搭配 Google 結果,/dev/input/event1 應該是 TouchPanel,所以我們應該從這下手,而不是找跟 Mouse Event 有關的。
先用手機來抓 Event Raw Data,我的手機是 /dev/input/event4(一個一個試出來的),使用 cat 記錄按下時的 data,結果如下圖。
struct input_event {
struct timeval time;
unsigned short type;
unsigned short code;
unsigned int value;
};
下班再來試試 Kobo 的 Raw Data 是否有不一樣的地方。
回家依樣畫葫蘆抓取 Raw Data,不抓不知道,看起來 Clara HD 是 32 位元 OS?
針對翻頁這件事終於開始有點曙光了,現在只剩是否能用寫檔方式模擬點擊 Touch Panel 動作?
2020/07/25 更新
終於把概念實做出來了,早上就已經完成了向右翻頁,但一整天都搞不定向左翻頁,現在雖然搞定了,但還需要花時間整理資料。
影片連結
程式碼
Event
參考資料
2020/07/26 更新
2020/07/27 更新
執行 Web Server 後,記憶體增加了 380 KB,佔總記憶體 0.07 %,我想應該還算可以吧?
2020/07/28 更新
看了一堆 Kobo hacks 的相關資料,貌似在閱讀界面時,Wi-Fi 是被 Kobo 關起來的?可能是為了省電!也許我可以在 HTTPServer 裡跑一個 goruntime,只要偵測到 Wi-Fi 關閉,就再把它打開,就看對耗電量的影響如何。
晚上實測的結果,即使一直使用我的 KoboPageTurner 翻頁,約莫 2 分 10 秒後,Wi-Fi 便會自己關閉,有空再用 ping command 來確認更精確的時間。
2020/07/29 更新
這是從 Clara HD 說明書看到的,看起來是被系統自己關掉 Wi-Fi 沒錯,但是沒有活動是如何判斷?我猜可能是判斷是否有在做同步,或是有進 Kobo Store,亦或是有開瀏覽器,而不是真正的判斷是否有使用中的 TCP/IP 封包。
晚上實測的結果,在不動作的情況下,不論是在首頁還是 Kobo Store,也是約 2 分鐘多一點,Wi-Fi 便會自動關閉。另外,也試了不要休眠,關掉自動喚醒功能,還是無法解決問題,看來是像說明書說的是由系統自動關閉。
2020/07/31 更新
早上突然想到,也許 Kobo 檢查的是外網的封包,而 Web Server 是屬於內網的封包,故會被認為 inactive?雖然我個人是覺得不合理就是!最簡單的方式就是在 Web Server 內開一個 goruntime,定時一分鐘便去連 Kobo Store,應該就可以避免 Wi-Fi 被關閉,待驗證?測試的結果,沒用。
哈,知道方向就好搞,在我多方 Google 之下,終於發現一個設定可以避免 Wi-Fi 被關閉,但是網路上說沒有效?晚上測試的結果,果然不會再自動斷線了,但是 Wi-Fi 也無法再手動關閉,故這個方式也不是正解。
[DeveloperSettings]
ForceWifiOn=true
另外,從 cyttsp5_mt_process_touch (kernel/drivers/input/touchscreen/cyttsp5_mt_common.c) 這支 function,看起來有解釋如何計算 ABS_X 和 ABS_Y,但我心算似乎不符合我從 raw data 抓到的?
2020/08/01 更新
忙了幾天,唯一的收獲是知道 Clara HD 的原點是在右上角,且設值時 X, Y 要互換。
2020/08/02 更新
改了一版程式,Web Server 開啟時,會去設定 "ForceWifiOn=true",離開 Web Server 時再把設定設成 false,實測的結果並沒有幫助,我確定設定檔都有更改成功!唯一可能的解釋是當我們在程式中動態改變設定檔時,對 Kobo System 來說,那些值可能已經在它的 memory 裡,故它並不知道要強制開啟 Wi-Fi,如果有方法可以強制它重讀設定檔,也許這個解決方式就能生效?
我不確定插上 USB 生成磁碟機,接著退出磁碟機的那個時間點,Kobo 系統是否會重新載入設定檔,如果這個流程是確定的,也許有機會解決?
另外,我發現這個動態更改設定檔的方式,似乎有機會讓 Wi-Fi 在開開關關幾次後就無法使用,可能是 Kobo 比對 memory 和 file 後,因為未同步而導致錯亂?
2020/08/15 更新
忙了兩個禮拜,終於有時間再來搞一下這個專案,Google 了一下,寫了一個簡單的 Android App,終於實現完我當初所有想做的事。
下一個新目標:使用 ESP8266 實做硬體翻頁器。
1. 如何實做 3.3 V 供電電路?
2. 供電電路是否需要穩壓?
3. 外殼使用 3 D 列印?