KoboPageTurner v0.4.0 改版記錄

Kobo Elipsa 已經內建體驗版的藍牙功能，經實測與我的 Logitech R500 翻頁器搭配良好，也有其他網友測試過其他廠牌的翻頁器，看來也有幾款可以使用，故我認為 Elipsa 支援更多的藍牙翻頁器只是早晚的事。

既然 Elipsa 已經內建藍牙，理論上可以不用出動我的 KoboPageTurner 專案。但既然是自己生的孩子，總是想知道用在 Kobo 其他機器上的相容性好不好？於是便有了此篇文章的誕生XD

最早以為只是 event 號碼不同，據我使用 cat /proc/bus/input/devices 檢查的結果，Elipsa 的 Event Handler 應該是 event2。

在設定檔中修改了 eventFile 的設定後，原本以為可以從此一帆風順？沒想到會變成選取的效果，除了翻頁無效外，螢幕需要手動多點幾下後才可以恢復正常功能，這很明顯的就是我拿之前在 Clara HD 存取的封包傳給 Elipsa 的觸控螢幕後，一定是那邊的格式不符預期，Elipsa 才無法正常工作。

解決的方式也很簡單，再抓一次 Elipsa 的封包資料即可，但第一次用 Linux 內建指令抓的資料太多又斷在不正常的地方，二來因為年代久遠，一時無法理解觸控封包的正確格式，只好先回頭再看一次之前 Clara HD 的封包再來解析 Elipsa 的封包。

Clara HD 之前的封包感覺簡單多了，不像 Elipsa 光 X, Y 的小封包層就有 6 個，嘗試用我理解的方式去送，沒想到結果依舊？

後來排列組合多次還是不能如我所願，最後只好再寫一支程式來幫忙記錄及印出封包，雖然小程式沒有如我預期的正常結束，但還是幫助我看出端倪，原來是 code 0x39 的 ID 要送出一個 value 為 0xFFFFFFFF 的封包，這個就是我之前無法成功的關鍵！

有了完整的 raw data 就好辦了，雖然有 6 個小封包，但我覺得應該不用那麼多？應該只要按下及放開的封包再加上結尾的 0x14A 即可？試著簡化過後，下面就是我最後送出的封包格式。

為了因應此次改版，config file 也增加了 rawData 欄位，舊版的就會自動套用 ClaraHD。

下面則是實際翻頁的結果：

自己生的孩子果然還是最帥XD

2021/07/07 更新

昨天睡覺前，又修改了一下我的 debug 小工具，改用 Go channel 來完美結束程式，真的越來越喜歡 Go 語言了，只可惜目前還不太能用 Go 寫出跑在機器上的 GUI App，可能是我還太菜吧XD

2021/07/12 更新

0x39 那個 ID event 應該跟最後一個 0x14A 是一組的比較合理？不過這種東西可能會隨著觸控螢幕不同而有所不同，沒必要糾結在這個地方，反正遇到新機器就是重抓一次封包即可，只要有一次的封包，所有細節都能一目了然。

當然可以再做一些加強，把 gEvent 的 hard code 變成一個檔案，這樣當遇到新機器就不需要重新編譯，只要新增 gEvent 檔案即可。

這個專案的缺點就是 Wi-Fi，會導致機器較耗電，但這也是 SW 最方便處理的方式，如果改成有線的 patch，一般人實在是不容易 DIY。

另外，我發現我新做的 debug 工具，如果沒有按下觸控，程式會停在 Read 的地方，無法像我想的讓 Timer 去觸發結束程式，我想 Go 底層可能是用同步的方式，故在沒有資料可以讀的情況下會卡在 Read 那一行，知道有這個情況即可，反正是多按一下就可以解決的事，暫時先這樣處理即可。