自從知道 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
原本以為觸發 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 列印？
