今天是 HyRead 這台機器預購的日子，限量 100 台，特價 10,999 的機器，在我中午吃飯時看已經售完，再來 11,999 的機器，在我當下寫文章的時候都還能下單。
也算是記錄一下幾家知名廠商預購的狀況吧？
在我看來，感覺是每下愈況，參與過的幾台機器，個人覺得當初 mooInk Pro 10 吋的預購最踴躍。
2022年7月28日 星期四
2022年5月26日 星期四
《文豪們的私房酒單》在 Kobo Elipsa 的閱讀結果
網路上有人說這本書在 Kobo 看起來不正常，我原本以為他是某家買的，但在我打字的同時想想又不太對，會問這個問題的人應該不懂 EPUB 格式，理論上是沒有能力把這本書拿出來放到別的機器上才對？
我前幾天看到這篇文章的第一直覺應該是 meta data 或 span 區塊，至少我知道某家很多版式書籍會這樣編排。
剛下班後馬上手刀速速的購買此書來驗證，果然跟我想的一樣，有 span 區塊存在，但並不是我以為的圖片 + append 文字的版式書籍。
那看來應該是沒轉 EPUB 的關係？果然在沒轉的情況下，所有 span 區塊裡的文字會浮在圖片上面，這個問題在轉了 KEPUB 之後就迎刃而解。
2022/06/01 更新
雖然轉 KEPUB 後，Kobo 就能正常顯示，但因為翻頁速度有點慢，故嘗試改用 Plato 來閱讀，看起來 Plato 也無法處理帶有 span 區塊的固定版面書籍，其顯示效果會先顯示圖片，再來換另一頁顯示 span 區塊裡的內容。
HyRead Gaze Pocket 不關機待機測試
被測試資料搞得一頭霧水，所以今天比較早下班XD
來看一下久沒關機跟上網的 Pocket 狀況，想不到待機情況比我想像中的好，真是對現在的開放式機器刮目相看，不過 CPU 還是差了點沒錯，雖然前一陣子有新的 Note Plus 預購，但問了 CPU 規格也得不到答案，著實是讓人沒勁。
2022年5月2日 星期一
HyRead Gaze Note Plus 7.8 吋一日限量預購
目前時間晚上 10:30 分，還在跟我的 C++ 教材奮戰，為了轉換一下心情，看了一下官網，限量 200 台，優惠價為 NT $8,299 的 7.8 吋閱讀器，目前還是可以順利的加入到購物車。
去年經歷了 Kobo Elipsa 的預購，那時就覺得整個活動熱潮比不上之前讀墨一代 10 吋的預購。這次 HyRead 的活動，只是 200 台的數量，想不到還是無法順利完銷？
我想原因應該是出在 CPU 的使用效能不如文石的開放式閱讀器吧，雖說兩者的價差還是有將近 2000 塊，但看起來似乎消費者不太願意買單，支持 HyRead 的讀者，我想應該都已經入手了閱讀器，再加上過年前才剛推出 Gaze X Plus 10 吋閱讀器，應該也是影響了新 7.8 吋機器的銷售。
無獨有偶，Readmoo 也在最近推出新的 7.8 吋閱讀器預購，雖然我已經退出社團很久了，但我估計應該會比 HyRead 賣的好，畢竟讀墨社團的催敗力及向心力一直都是讓我很佩服的行銷範例。
雖然我不覺得影片在知識傳播上會比文字來得讓人易懂，但以行銷方面來說，影片確實會比較吸睛，這點讀墨確實是比凌網強。
考慮了良久，還是沒有下單 Gaze Note Plus 這台機器，在很大的機會上還是延用同一家 CPU 情況下，實在不是讓人很感興趣。算了，還是用我的 Gaze Pocket 吧！畢竟目前上網速度都還在可以接受的範圍內。
2022年4月18日 星期一
Kobo Expense
既然現在都在 Kobo 買書居多，是該時候寫個 Kobo Expense Chrome Extension 了，晚上稍微拿 Readmoo Expense 改了一下，看起來只要改 gethtml.js 就好，原本產生報表的 popup.js 只要維持一樣的 object record 回傳回去，完全可以無痛接軌，雖然我當初並未定義 interface，但也可以稍微的從中感受到介面的威力。
簡單分析一下購書狀況，從去年 5 月後跳巢到 Kobo，故每月開始有持續買書，但因為 Kobo 不像讀墨有好用的不定時三本七五折券，故在 Kobo 不太容易一次買大量的書。雖說 Kobo 有 555 點送 111 點的活動，但需要使用者自行拆單，故我不認為有多好用。
這樣也好，越不方便的機制，使用者就越不容易亂花錢，這也算是個意外之喜吧？
2022/05/18 更新
Kobo 網頁居然又改版了，所以我又要更改 parsing regex，看了一下網頁原始碼，原本會換行的資料現在又不換行了？真搞不懂 Kobo 的工程師在幹嗎？不太可能為了這個一直去更新插件，看來只好用 local 版的 Kobo Expense。
2022年4月17日 星期日
Bug or Feature ?
最近 Kobo 系統又有更新了，那個因為 Wi-Fi 已經打開，導致進去藍牙設定頁面的時候 Bluetooth 也跟著打開的 Bug 終於修掉了！（但是據已更新的國外網友所說，在兩者都關閉的時候，單獨打開藍牙，Wi-Fi 還是會跟著打開）
好笑的是國外論壇在上一版的討論串中，就有兩派人在爭論這到底是 Bug 還是設計問題？
其實以一個使用者的觀點來說，沒在我預期之下跑出任何我沒預期的行為，這無疑是一個 Bug 沒錯！使用者才不管你這是因為設計還是程式沒有寫好的緣故。
之前開發 Wi-Fi 翻頁器時，我就對 Kobo 會關掉 Wi-Fi 這件事很感冒，正常的設計應該是在系統進入休眠的時候，才順勢的讓週邊進入省電狀態。假設使用者設定休眠的時間是 10 分鐘而使用者的 Wi-Fi 是開啟的，怎樣系統都不應該在不到 3 分鐘的時候就偷偷把使用者的 Wi-Fi 關掉，這很明顯的不符合使用者預期。
同樣的，一個功能打開也會影響另外一個功能的開啟，這也是不符合使用者預期的行為。
即使目前主流 Wi-Fi 和 BT 都是在同一顆晶片上，通電和使用狀態本來就可以透過 UI 和 driver 的配合來達到一個良好的使用者體驗，Kobo 在這一點上確實是沒做好沒錯。
這又讓我不禁想到前一陣子 Kindle 又更新他的 UI 了，這應該是我近幾年來有印象的第三次更新了！
這個更新就真的是設計問題沒錯，姑且不論有沒有更好用，但至少我個人認為這個新的更新是比前一個差沒錯，因為破壞了我習慣的介面閱讀習慣。
究竟這個新的 UI 是不是有符合大部份的人的使用習慣呢？我想我應該也無法知道這個問題的答案吧？
2022/04/18 更新
下圖是 Kindle Oasis 2 更新到 5.14.2 的 UI 介面，上一版的 UI，現在要透過 list + sort，才能有近似前一版的畫面，最大的差別就是 collection 會多顯示資料夾的圖示，套句史蔕芬周的話：真是多餘呀XD
對比一下 Kindle Paperwhite 3 版本 5.13.7 的 UI 畫面，list 的 collection 介面就不會有不必要的資料夾圖示，整體看起來清爽多了。理論上 PW3 應該也還能升級版本，但可能是我 4G 的空間已經所剩不多，直到現在都還未收到下一版本的更新通知，也算是塞翁失馬的意外之喜吧。
2022/06/09 更新
早上因為 Elipsa 在充電，故拿我的 PW3 來改看《USB Complete》這本書，沒想到在沒關掉 Wi-Fi 的情況下，我的中亞系統也更新了！不是說要收攤了，還那麼認真要幹嗎？
同樣的設定在 PW3 只剩 5 個資料夾可以顯示，但我又不想用 Collection 顯示方式，因為真的跟我本來的習慣不一樣，再加上緊密放在一起的排列，真的是很兩難呀。
2022年4月6日 星期三
武林絕學 - 金星幻式 - 七星連線
標題雖然是布袋戲的招式名稱，但我想不到比這個貼切的標題了XD
從 3 月下旬開始，為了研究 Libra 2 的藍牙，不但買了 Libra 2 本人回來研究，還陸續買了 E-PCG233 藍牙滑鼠以及 8BitDo Zero 2 搖桿回來，正所謂孩子的學習不能等呀？
好不容易大概釐清了 Libra 2 的藍牙問題？但後續還有一個小尾巴卡在我心中，那就是為什麼滑鼠以及我的 R500 翻頁器都會按下一次鍵後觸發 2 次事件？雖然我大概已經能猜測出問題出在哪裡就是了（按下及放開的事件，Key Scan Value 都一樣）。
我認為天底下的問題只有兩種，一種是目前可以解決的，另一種則是目前無法解決的。
很顯然的，我認為這個小尾巴是屬於前者的範疇！
今天還蠻早起來的，故想直接用 cat 抓 raw data 來看，畢竟我在 KoboPageTurner 專案就已經有相關經驗了，但不知為什麼，早上突然想用 PC Linux 來測試，想說順手用 evtest 來看一下，結果發現 Linux 版的 evtest (1.34)，居然可以判讀更多的 raw data，故可以一目了然的確定問題便是出在放開按鍵的事件沒錯。
Raw Data 長這樣（不同時間抓的）。
那我們要怎麼解決 kobo-btpt 收到兩次事件的問題？一個是我之前寫的 filter，過短時間內收到相同的 event 便忽略它，可惜的是一樣的 code 只在 Elipsa 生效，Libra 2 沒有辦法成功（後來發現自己耍笨，同時執行了原本的 kobo-btpt 及自己修改的版本）。另外一個則是希望 Kobo 的 Input Subsystem 也能收到 type 1, code 272 的事件，那我們只要在 value = 1（1 是按下，0 是放開）時觸發 Kobo 藍牙翻頁函式即可，換句話說，kobo-btpt config file 要如下設定，注意這裡都是 10 進制：
prevPage 1 272 1
nextPage 1 273 1
雖然我還沒測試，但我想八九不離十可以成功。
那這個跟我們的布袋戲標題有啥關係？
此招式是天宇一好漢的武功之一，我認為作學問也是如此，雖然我們從 Google 搜尋來的都是片斷屬於點的知識，但當你一點一滴的累積之後，知識自然會從點擴展到線，最後則變成面的學問。
因此，只要是屬於目前可以解決的問題，我希望都能把它搞懂，也許將來的某一天就會派上用場也說不定。
期許自己能夠永遠的不忘初心。
題外話：我想懂 Linux Input Subsystem 的人，應該會覺得這麼簡單的事，哪來這麼多感想XD
2022年4月4日 星期一
kobo-btpt 真是個有趣的專案
去年 Elipsa 剛出來時，網路上就有人提到有些藍牙裝置雖然可以跟 Elipsa 連接，但可能送出的事件，不是 Elipsa 有監聽的（這裡指的是閱讀軟體，也就是那個 Qt5 GUI），故無法使用那些裝置來翻頁。因為我本來就有可以順利連線的 Logitech R500，所以也沒有很在意這件事。
今年陸續有人問我藍牙翻頁器的事，詢問為什麼 Libra 2 都不能用？我的第一直覺應該就是藍牙相容性的問題，畢竟連旗艦機種 Elipsa 上的藍牙相容性都 2266，更何況是最便宜的 Libra 2？我當初也覺得應該是翻頁器太便宜，如果是使用 Logitech R500 應該是輕鬆就能搞定。直到有人說他買了 R500 後續機種也不能使用翻頁器後，才引起我的興趣。
本來是想直接去三創測試，但內心覺得可能沒那麼簡單，故最後還是買了一台 Libra 2 回來研究，原本就預期測試完就賣掉，故選擇人氣比較旺的白色機種，坦白說，白色外殼真的是很刺眼，真不知道為什麼大家都說白色好看，根本就就不適合用來閱讀。
一到手就知道 Libra 2 的藍牙沒那麼簡單，R500 光配對就搞了老半天，有時候明明連接上了卻一直顯示未連接，還好過程中發現可以使用 /bin/bluetoothctl 來 debug，才能順利連線，果不其然，我也無法使用 R500 來翻頁。
但因為我之前就知道 kobo-btpt 這個專案，也知道該作者順利使用 8BitDo Zero 2 搖桿來翻頁，故我直覺搞不好可以使用便宜的藍牙滑鼠 + kobo-btpt 就可以順利翻頁。
一開始我的藍牙滑鼠 E-PCG233 可以長出 /dev/input/eventX 裝置，evtest 也可以抓到不同的左右鍵事件，但不論我怎樣設定，kobo-btpt 都沒有反應。
還好，open source 的威力在此就展現出來，下載 source code 研究後，發現設定檔最後一行不能有換行字元，因為程式會以為它是不正確的設定就不把這個裝置加入。
搞定這個後，還是無法順利翻頁，沒關係我們有無敵絕招 printf 大法，在修改程式碼並印出收到的事件後，我才知道 evtest 抓到的 value 欄位是 16 進制，修改之後，果然可以順利翻頁。雖然我買的便宜滑鼠一次會發送兩次事件，導致一次翻頁多頁，但這又是另外一個故事了 ~~
總之，很多事的成功都必須先有先前一點一滴的累積努力，最後才能順利的水到渠成。做事最忌諱一步登天，慎之慎之。
修改 kobo-btpt 原始碼需要知道的事
01. 知道 NickelHook 是什麼。
02. 會基本的 Linux 操作。
03. 知道 Cross-Compiler (Docker - NickelTC)。
04. 知道 /dev/input/eventX 。
05. 看得懂 C/C++ 語言。
06. 知道 QT。
07. 知道 makefile。
上面只要到知道的程度及可，不需到專精，應該就有辦法改 source code 了。
2022/04/05 更新
E-PCG233 這支滑鼠在我的 Elipsa 一樣是按下鍵後會收到兩次事件，但奇怪的是我幫 kobo-btpt 加上的 filter 似乎可以起作用，我的 filter 在過短的時間內，如果收到相同的事件，我會不讓 kobo-btpt 觸發翻頁的動作。
不過同樣的 filter 在 Libra 2 就無法成功，且印出訊息時感覺呼叫 Kobo 藍牙翻頁的函式似乎是非同步呼叫，故訊息印出的順序很怪（後來找到問題了，其實 filter 是有成功的，但我誤把原始的 libbtpt.so 改名後一樣放在 /usr/local/Kobo/imageformat 下，導致 Kobo 同時執行了兩支 libbtpt.so）？
總之，我只是想確定 kobo-btpt 的用途，結論就是只要是可以連接 Kobo 系統並可以長出 /dev/input/eventX 的藍牙裝置，如果遇到無法翻頁，可以透過安裝 kobo-btpt 去監聽使用者註冊的事件，只要收到註冊的事件，kobo-btpt 便會幫我們呼叫 Kobo 底層系統的藍牙翻頁函式（透過 NickelHook）。
2022/04/08 更新
kobo-btpt 使用說明（搭配 8BitDo Zero 2 gamepad）：
01. 去 kobo-btpt 網站下載 v0.0.2 版的 KoboRoot.tgz。
02. 將閱讀器插上電腦，確認檔案總管可以看到隱藏資料夾。
03. 將下載下來的 KoboRoot.tgz 放到機器的 ".kobo" 資料夾並退出閱讀器，此時閱讀器應該會重開機。
04. 重開機後一樣將閱讀器插上電腦，此時應該可以看到 ".btpt" 資料夾。
06. 按下 8BitDo Zero 2 的 X 鍵及 start 鍵，進入 X-Input 模式後，然後長按 select 鍵進入藍牙配對模式。
07. 配對成功後，回到書本閱讀頁面能夠翻頁就是成功了，不行就在藍牙設定畫面忘記裝置再重新配對。
2022年4月3日 星期日
如何使用 kobopatch-patches
前情提要：
kobopatch 是工具原始碼，kobopatch-patches 是高手針對各系統版本包好的執行檔，可以直接用此工具來依設定檔做 patches 並產生 patched 好的 KoboRoot.tgz 系統更新檔。
01. 去 https://github.com/pgaskin/kobopatch-patches/releases/ 下載最新的 kobopatch release，目前最新版本是 v74，並在 v74 裡面下載對應的系統版本，假設是 4.30.18838，便下載 kobopatch_4.30.18838.zip，裡面會有設定檔及產生 KoboZoot.tgz 系統更新檔的工具。
02. 解壓縮 zip 檔後，src 資料夾裡面會有一個 download_firmware_here.txt 的檔案，去檔案裡面的網址下載對應硬體及系統版本的系統 zip 檔案，並把它放在步驟 01 解壓縮資料夾 src 的資料夾內。
03. 針對要 patch 的項目修改，有兩種方式：一種是用 overide 的方式，直接修改步驟 01 解壓縮資料夾的 kobopatch.yaml 檔案，記得要 patch 的項目前要用 4 個空格，不要用 tab 鍵。另外一種則是直接修改步驟 01 解壓縮資料夾內 src 裡對應要修改的系統檔案的 yaml 檔。
04. 如果電腦是 Windows 系統，直接執行步驟 01 解壓縮資料夾的 kobopatch.bat，假設沒有錯誤，便會在步驟 01 解壓縮資料夾 out 資料夾裡看到 KoboRoot.tgz 及 log.txt，可以從 log.txt 看到是否有正常 patch。
以你的例子要直接修改 src\libnickel.so.1.0.0.yaml，在最後面貼上你找到的解決方式。
Enable markup for sideloaded kepubs:
- Enabled: yes
- ReplaceBytes:
Base: "KepubMarkupDelegate::isMarkupSupported(Volume const&)"
Offset: 390
FindInstBLX: {SymPLT: "Content::isSideLoaded() const"}
ReplaceH: 4F F0 00 00
05. 將閱讀器插上電腦，把 KoboZoot.tgz 放到閱讀器內的 .kobo 資料夾內，在電腦退出閱讀器後，閱讀器便會重開機安裝 patch。
2022年3月29日 星期二
Kobo Libra 2 vs Logitech R500
為了測試 Libra 2 這台的藍牙是否真如傳說中的不堪？狠下心來購買了它，一試之下，果然跟傳說中的一樣爛XD
在 debug 過程中，無意間發現了一支程式 /bin/bluetoothctl，查了一下似乎可以用來設定藍牙？好不容易在 unpair 和 pair 的過程中，終於可以成功與我的 Logitech R500 成功連接。
感覺研究研究，搞不好可以找到問題在哪？
另外，使用 logread 讀取 log，可以看到一個錯誤訊息。
Mar 29 23:18:52 bluetoothd[1397]: src/service.c:service_accept() input-hog profile accept failed for EF:06:4D:1A:69:69
雖然藍牙初嘗試不是很順利，但至少我的 KoboPageTurner 可以成功使用，直接使用 Elipsa 觸控封包格式即可，總算不是一事無成。
2022/03/30 更新
比對了一下 Elipsa 和 Libra 2，目前看到有兩個差異，Elipsa 的 kernel 和 Bluetooth management interface 都比 Libra 2 新，感覺是 kernel issue？
Bluetooth management interface 1.9 (1.14).
2022/03/31 更新
雖然不懂藍牙，但這幾天查了一些資料，我覺得問題可能是出現在以下幾個地方：
1. CONFIG_RFKILL kernel 未編譯進去。
2. 一樣是 kernel 哪邊的問題 (uhid)。
3. BT chip 本身的問題 (RTL8723DS vs RTL8821CS)。
看起來似乎不是改改設定就可以解決的事，至少嘗試調整 /etc/bluetooth/main.conf 或是 /etc/bluetooth/input.conf 中的參數，看起來都沒有幫助。
2022/04/01 更新
無意間在網路上看到一份 porting guide，看起來要支援 HOG，kernel 應該要打開一些功能，就不知道 RTL8723DS 本身是否有支援就是？假設不是 BT chip 的問題也不是 Kobo 為了市場區隔的問題，後續只要系統更新，應該就能支援翻頁器了。
另外，大部份的 Linux 使用的 Bluetooth Stack 都是 BlueZ，其 daemon 是 bluetoothd，路徑為 /libexec/bluetooth/bluetoothd，在 Kobo 下如果嘗試要修改設定，可以使用 kill 砍掉它，再重新背景執行 deamon 即可。
晚上使用 bluetoothd -d -n 開啟 debug 訊息，可以看到 Elipsa 對待 R500 的方式。
profiles/gap/gas.c:gap_probe() GAP profile probe (EF:06:4D:1A:69:70)
src/service.c:change_state() 0x183a8c8: device EF:06:4D:1A:69:70 profile gap-profile state changed: unavailable -> disconnected (0)
profiles/input/hog.c:hog_probe() path /org/bluez/hci0/dev_EF_06_4D_1A_69_70
src/device.c:gatt_debug() (chan 0x1837f58) ATT PDU received: 0x1b
src/device.c:gatt_debug() (chan 0x1837f58) ATT PDU received: 0x1b
上面最後兩行是按下 R500 翻頁鍵後 Elipsa 吐出來的訊息，Libra 2 雖然無法使用 R500，按下翻頁鍵後一樣能吐出相同的訊息，真的覺得更新 kernel 應該就可以正常了？
另外，Bluetooth 的 spec 看起來是公開的，目前是 Core_v5.3。
2022/04/03 更新
前幾天買了一支便宜的藍牙滑鼠，原本以為使用 kobo-btpt 專案就可以正常使用，但還是不如預期，留個 log 當記錄。
晚上又認真比對了 Elipsa 和 Libra 2 配對 R500 的行為。
Elipsa：
bluetoothd 沒有錯誤訊息，會長出一個 /dev/input/eventX 的裝置，使用 evtest 可以成功補捉左右鍵的 scan code。
Libra 2：
bluetoothd 有錯誤訊息，無法長出 /dev/input/eventX 裝置，故錯誤訊息其實不是斷線，pair 和 connect 都有成功。
2022/04/04 更新
evtest 的 value 是 16 進位數字，在修正了此錯誤後，終於可以使用我的藍牙滑鼠（E-books E-PCG233）翻頁，真是得來不易呀。雖然這個滑鼠按下一次鍵會發送 2 次 event，但我只是想要研究 Libra 2 的藍牙，故對我來說，這個學習已經完成XD
2022/04/05 更新
昨天順手在 kobo-btpt 裡加了一個 filter，避免過短時間內收到相同的 event，不過在 Libra 2 無法成功，且呼叫 Kobo 藍牙翻頁的函數感覺是非同步？但同樣的 filter 在 Elipsa 就可以正常工作。
晚上又認真的在 Elipsa 上試了一下 R500，使用 evtest 補捉的結果，一樣是按一下鍵會送 2 次 event，既然是一樣的行為，那為什麼 Kobo 只會翻一次頁，我想這裡面可能還有我不知道的事在？
Event: time 1649163457.612279, type 4 (Misc), code 4 (ScanCode), value 70050
Event: time 1649163457.612279 ------- Report Sync ------ x: 400 y: 80 p: 0 ------------
Event: time 1649163457.657992, type 4 (Misc), code 4 (ScanCode), value 70050
Event: time 1649163457.657992 ------- Report Sync ------ x: 400 y: 80 p: 0 ------------
如果要我猜的話，會不會 1 個是按下事件，1 個是放開事件？故 kobo-btpt 應該要有能力去判斷放開事件，可能要從別的 event，因為 type MISC 的 press value 應該都一樣，以上面例子來看都是 0x70050。不過問題來了，evtest 只有顯示出 Report Sync 並未顯示出其他 event ，會不會是 evtest 並沒有能力解析，故才沒有顯示呢？
2022/04/06 更新
太相信 Kobo 內附的 evtest tool 了，明明藍牙滑鼠有其他更適合的 event 可以監聽，詳此篇。
最後正確的設定檔如下：
prevPage 1 272 1
nextPage 1 273 1
2022/04/07 更新
昨天晚上本來以為已經妥當了，沒想到用了 EV_KEY 後，行為還是不符預期，一樣會觸發翻頁兩次，再加上剛到的 8BitDo Zero 2 gamepad 在 Libra 2 也是時好時壞，有時候可以長出 device，有時候又不行，如果不是像我一樣 telnet 進去閱讀器的人，一定不知道到底發生了什麼事？
就在正準備睡覺的時候，熊熊想到，之前改了 kobo-btpt source code 來 debug，把原始的 libbtpt.so 改個名字，一樣放在 /usr/local/Kobo/imageformats 裡面，這個資料夾裡的 .so 檔，應該是會被 Kobo 自動載入，故我其實是同時在跑兩支 libbtpt.so 而不自知，難怪之前的 debug 訊息才會覺得如此之怪，移除之後，果然一切恢復正常，搞定收工（還是不應該使用 EV_MSC type，因為會收到兩次事件，之前的問題是組合技，既用了不該用的 type，也執行了兩支 libbtpt.so）。
2022/04/08 更新
找到檢查 Linux Kernel Config 的方法了（/proc/config.gz），看起來 Libra 2 禁用了很多 Elipsa 有打開的項目，就不知道是 Kobo 為了市場區隔，還是只是單純的因為 Libra 2 的藍牙晶片不支援的緣故呢？
2022/04/09 更新
昨天晚上下班後決定要來編譯模組了，目標放在 uhid.ko。
CONFIG_HIDRAW=y （這個也許沒影響？）
CONFIG_UHID=m
使用環境
Windows 10 + Docker Desktop (ghcr.io/pgaskin/nickeltc)
linux-4.1.15.tar.gz
Copy /proc/config.gz of Libra 2 to /linux-source/.config
make ARCH=arm CROSS_COMPILE=/tc/arm-nickel-linux-gnueabihf/bin/arm-nickel-linux-gnueabihf- oldconfig
make ARCH=arm CROSS_COMPILE=/tc/arm-nickel-linux-gnueabihf/bin/arm-nickel-linux-gnueabihf-
中間有遇到找不到 bc 及 lzop 兩個執行檔錯誤，我檢查一下 Windows 10 Docker Desktop，感覺底層還是 Windows 的那個 Linux Subsytem（WSL），故我直接複製 WSL 裡的這兩個執行檔及相關的 so 檔進去我的 docker instance，然後建立 soft link（ln -s liblzo2.so.2.0.0 liblzo2.so.2 ... ），看起來這樣就過了？雖然我前後總共重 build 了 3 次就是！
感謝有 make，只有初始檢查比較久，編譯過的都不用再重新編譯，但我的 8 歲老筆電果然很吃力呀，打文章的同時，整個程序都還沒跑完，我只是先偷跑去 /linux-source/drivers/hid 下，把 build 好的 uhid.ko 複製出來測試XD
阿母，我成功了！我的 Logitech R500 終於可以爽爽用了，要感謝的人太多了，就感謝天吧XD
2023/07/02 更新
6 月份買了一台 Clare 2E，為了取代電池快卦掉的 PW3，試了一下，藍牙跟 Libra 2 有一樣的問題，由於 kernel 版本一樣，直接拿原本的 solution 來用，完全無痛接軌。
另外，我的 KoboPageTurner 專案一樣可以用在 Clare 2E 上，raw data 使用 Elipsa 格式，觸控座標設成跟 Clare 一樣即可。
2022年3月21日 星期一
程式人最開心的事
kobofileserver 已經開發完快 3 個月了，用到現在一直覺得很滿意，雖然對不懂程式的人在初期安裝上有些困難，但我覺得這是非戰之罪，為了 patch Kobo 系統，不得不透過 NickelMenu 這樣的啟動器來啟動第三方軟體。也因為這樣的緣故，我也很懶得去推廣，只有剛好看到有關的論壇討論才會稍微提及這個專案。
前幾天無聊用關鍵字查詢一下，居然看到有人在 reddit 提及這個軟體，而且還提了兩次，看起來這個網友應該是覺得 kobofileserver 專案還可以吧XD
我想這應該也是程式人最開心的一件事吧 ~~
2022/04/08 更新
感謝 usimon 的使用，在 usimon 的建議下，新增了上傳多檔的功能，感覺還行，雖然我不太會用到就是XD
2022年2月19日 星期六
Kobo Elipsa 待機三四天後沒電問題分析
這個問題大概發生了至少三次！我待機的時候都會關掉 Wi-Fi 與自動同步，故應該不是這兩個原因影響。
記得網路上有人說過第三方軟體有可能會影響待機耗電，我目前安裝的有：
NickelMenu
FBInk
KOReader
Plato
KoboPageTurner
kobofileserver
後兩個是我自己開發的軟體，平常不會自動啟動而是透過 NickelMenu 選單啟動，故應該跟這兩個軟體無關，同理還有中間那兩個 PDF 閱讀軟體，所以基本上可以排除後面四個。
至於 NickelMenu 會 Hook 到 Kobo 系統，理論上是寄生在 Kobo 系統內，故休眠時應該沒有任何動作。
而 FBInk 是去動 framebuffer 做一些顯示，故應該也與它無關才對。
我個人比較傾向是 Kobo 的 Bug，但我懶得整個 reset 測試，故也無法百分之百肯定？
最後一個方法就是寫支小程式，定時 5 分鐘記錄一下 CPU or RAM 使用排名前十名的 processes，也許就可以知道是哪些 processes 在作怪啦！
講是這樣講，但我年後上班後除了工作的程式，下班後都沒什麼心情再寫程式了，都是這個爛天氣害我不太想動XD
2022/02/20 更新
雖然還不想寫程式，但還是可以做些前置作業。在正常的 Linux 可以用 ps 來排序 processes "ps -o pid,pcpu,comm,rssize"，但 Kobo 這種的 Embedded Linux 則是用 busybox 來取代 Linux 常用的指令，故並沒有 pcpu 可以用。
雖然我們可以改用 top output 來取得 CPU 使用率的排序，但據我測試的結果，感覺頻繁的使用 top 指令，也許會改變我本來想要監控的目的，目前暫時有點兩難。
2022/05/18 更新
05/13 對完信用卡帳單後就沒有關過機了，今天打開看電力還剩下 88 %，看起來似乎沒有耗電的問題了？目前版本為 4.32.19501 (2022/04/14)。
要說跟以前不一樣的地方？差別在這次開機還未使用過 Plato 等軟體，當然 NickelMenu 是一直都在的，因為它在開機時就會 hook 到 Kobo 系統！
改天嘗試使用過 Plato 後不關機再看會怎樣？
2022/06/01 更新
看起來 19501 新版本有解決耗電問題，即使有用過 Plato，在不關機的狀態下，過幾天再開的電力看起來都還算正常。
2022年2月11日 星期五
Kindle 閱讀器收藏夾不見的解決方式
先說解決方式！
01. filter 往下滑，選到 collection，此時會進入 collection 篩選模式。
02. 在此模式下應該會看到各個 collection 了，前面沒有星號的表示在本機看不到，點擊右邊 3 個圓點進入設定頁面，選擇「加到下載」。
03. 之後在排序那，應該就可以選 collection 了。
-------------------
這兩天為了閱讀《雪中悍刀行》這本小說，在美亞買了該本書，於是又拿起我塵封已久的 Kindle Oasis 2 來閱讀。
看著看著才無意發現，原來我也沒有收藏夾了？記得前一陣子也有另一位網友有類似的問題？但因為我這台閱讀器買了沒什麼看，故我也不確定跟版本有無關係？但據我認真回想，似乎舊版本就是這個樣子沒錯？
一開始以為是不是什麼設定沒設好，翻來翻去也看出不出所以然，突然在那位苦主的留言處看到有人說 filter 選項因為太多，故看不到收藏夾的項目，雖然下拉後可以點到收藏夾的篩選選項，但這跟原本的收藏夾顯示方式似乎不太一樣？
於是又在那邊搞了老半天，最後才在收藏夾的篩選畫面中的各別收藏夾設定中找到「加到下載」的功能，選了這個之後，該收藏夾就會多個星號，之後取消篩選後，便可以在排序中點選「收藏夾選項」了！
總覺得這是個 Bug！照理說不加到下載，也應該在 ALL 的類別中看到，或者說這個本來就應該同步，不應該分兩次設定搞定？至於這個到底是 feature 或是 Bug，我也不好說XD
這次事件讓我學到三件事：
01. 不要相信別人的話XD，還是需要認真看過解決文章再下評斷，當初以為真的沒用，故忽略了該篇文章的內容。
02. 讀書最高境界就是以為沒吸收到但確實往心裡去了XD，找到解決方式後我還以為是我試出來的，後來回頭看該篇文章才發現跟他的解決方式一模一樣。
03. 寫文章的技巧或者說排版很重要，不確定是該篇文章圖片太多（應該說廣告太多）還是沒有分段，乍看真的是很不好懂，不如我列出 3 點的解決方式一目瞭然。
2022年2月6日 星期日
四維禮義廉
雖然不想在讀墨買書了，但為了做些測試及比較的購買我倒是不會排斥！剛在讀墨首頁看到18禁的書籍推薦，搞得我想測試的心情都沒了！
我雖然不是什麼道德狀元郎，也會看些謎片XD，即使讀書並不是多高尚的事，但我覺得賺錢還是要有底限，真不知道廠商在想些什麼？
雖然樂天的網站一直被人垢病，但我現在越看越喜歡樂天書城的網站了，真的是沒比較沒傷害。
最近也越來越討厭 Google，斗大的廣告佔據瀏覽器視窗下面 1/8 的位置，我之前還一直以為是我電腦中毒了，直到問了黑暗執行緒本人，才知道這是 Google 廣告改版的緣故，在網路上也找不到相關討論，網路世界的自由真的是蕩然無存了，天涯何處是吾家呀…
2022年1月19日 星期三
Kobo 字型顯示問題分析
今天在討論區看到有網友在發問為何 Kobo 無法顯示兩種字型？感覺這個問題很有意思，於是便分別在 Readmoo 和 Kobo 買了同樣的書，書名為《二人生活》。
初步分析結果，Readmoo 有分別針對不同句子指定字型，例如 body 是 gfont，特別的句子則是 kfont，而 kfont 我猜是楷體的意思，應該是 Readmoo 內部自己定義的。
至於 Kobo 其 CSS 檔案確實沒有指定第二種字型，只有單純指定顏色。
故我針對某句加了 Kobo 的內建字型來實驗，經實測還是無法指定字型。
網路查了一下，需使用 kobopatch 才能解決此問題。
使用 "Un-Force user font-family in KePubs:" 為關鍵字去查詢，終於在 kobopatch 的 yaml 檔案中看到註解。原來原本 Kobo 是可以使用兩種字型，但在開放使用者自訂字型後，Kobo 使用了一種簡單粗暴的方法來把原本電子書裡面的字型強制改成使用者的自訂字型，故才產生無法同時顯示兩種字型的問題。
長知識了，還好我對顯示多種字型沒什麼感覺，我只要可以顯示我的 Kindle 圓體就好了XD
2022/01/19 更新
本著實驗的精神，實際來試一下 kobopatch 的流程，雖然我是寫程式的，還是覺得有點複雜，跟我當初第一次閱讀 NickelMenu 的說明文件一樣XD
kobopatch 說明文件有提到，需要去該網站下載對應版本的韌體（kobo-update-4.30.18838.zip），並放入 src 資料夾內，但我進去該網站時，我的防毒軟體不知為何會跳出有毒的提醒？雖然我是相信那些開發者的，但既然我本來就有 telnet 進去機器的能力，簡單下個指令把我要的 .so 檔 tar 出來就好，再包成 kobopatch 程式要求檔名的 zip 檔（kobo-update-4.30.18838.zip）。
tar czvf KoboRoot.tgz -c /usr/local/Kobo libnickel.so.1.0.0
接著修改根目錄的 kobopatch.yaml，因為我想使用 override 的方式，避免去動原本 src 裡面的 yaml 檔案。
最後則是點擊 kobopatch.bat，如果沒有錯誤，在 out 資料夾便會出現我們常用的 KoboRoot.tgz，之後再用原本 patch 的方式更新系統即可。
patch 後的 libnickel.so.1.0.0 的差異如下：
接著修改 Kobo 原書的 CSS 檔案，簡單在原本顏色的 class 增加字型設定。
最後呈現出來的結果。
2022年1月5日 星期三
開發或使用 Kobo 第三方軟體注意事項
陸續開發了兩套軟體，碰到了一些問題，記錄一下，以供後人參考。
Note：有新發現會不定期更新。
01. 如果是不需要 GUI 的程式，可以使用 Go 並設定跨平台編譯即可。
02. 如果需要 GUI，一些軟體的做法是先把東西畫到 framebuffer，再一次更新，就不會有閃爍的問題，可以參考 KOReader plugin 或是 application 的作法，另外，寫一個活在 KOReader 裡的軟體，就可以使用 KOReader API 開發 GUI App，開發語言是 Lua。
雖然沒有很懂架構，但寄生在雲端儲存 App 裡面，開啟一個對話盒看起來沒有問題。
03. 如果是透過程式將檔案加到 device，要觸發 device 重新掃瞄檔案系統，有兩種方式：
a. 掛載一個假的 SD，並通知 sd add event to /tmp/nickel-hardware-status。
b. 利用 /tmp/nickel-hardware-status，觸發 usb plug add event，不用真的插線，但使用者需按下連接，接著 sleep 幾秒，再觸發 usb plug remove event。這樣 device 就會重新掃瞄了。
Warning：掛載 SD 方法，之後如果插拔 USB，會讓書出現 2 次，原因是我們把 /mnt/onboard 下的資料夾掛載到 /mnt/sd，但插拔 USB 時，又會去掃 /mnt/onboard，故同樣的檔案才會出現 2 次。我們可以改用 NickelMenu 內建 action 去觸發，查了一下，KoboCloud 也有這種問題，但因為它把檔案下載到 .add 目錄，故用 ExcludeSyncFolders 的方式排除。
04. Kobo 只有在退出 USB 或是使用內建瀏覽器下載檔案時會觸發重新掃瞄檔案系統，也可以直接對 database 動手腳，我還看過有用 database trigger 的，但後者比較難，相容性也不好。
05. 英文網站常會看到 Nickel 這個單字，就是指 Kobo 的系統。
06. 以前的 Kobo 不會對隱藏目錄建立索引，但從版本 4.17 開始會處理隱藏目錄，故有用到 Kobo 支援格式檔案的第三方軟體的檔案就會被顯示在我的書籍中，當利用排除方式處理後，Kobo 會把不再索引的檔案砍掉，這會造成第三方軟體因為缺少檔案而無法啟動，故需要重新安裝軟體。
[FeatureSettings]
ExcludeSyncFolders=(\\.(?!kobo|adobe).+|([^.][^/]*/)+\\..+)
07. Kobo 設定檔在某些不知名情況下會被重設，故偶爾會造成系統異常，如果有看到似乎是重新設置系統的畫面，可以考慮直接關機，重開機後也許就不需重設帳號。
/mnt/onboard/.kobo/Kobo/Kobo eReader.conf
08. Kobo 不支援需要密碼的 PDF 檔案，故重新掃瞄檔案系統看不到檔案是正常的。
09. 下面這套軟體似乎是用 Qt 寫 App，也有提到跨平台編譯？
10. Send to Kobo app，該 app 會自動收信到 device。
11. NickelDBus 是一個使用 Linux D-Bus（軟體訊息匯流排）協定的工具，可以觸發它去做一些事，比如重新掃瞄檔案系統，設定 Wi-Fi 等，以 Qt 和 C++ 開發。
12. NickelMenu 底層的原理，稍微 trace 一下，應該就是透過 NickelHook 去呼叫 libnickel.so 裡面的函數，來達到相關功能。也就是 Linux 的 dlopen and dlsym（使用動態連結函式庫的 c function），其實作可詳 NickelHook / nh.c，故要在 Golang 使用，可能只能走 cgo 模式了。
Warning：沒那麼簡單，libnickel 有用到 Qt Lib，以 import book 來說，還要寫成 QApplication 才能呼叫成功，但我最後還是沒試成功。
Warning：想要在 Kobo 上使用 Qt，要使用 QPA。
13. Cross-Compile C code.
a. git clone https://github.com/koreader/koxtoolchain
b. ./toxtoolchain/gen-tc.sh kobo
c. The tool is in /home/xxx/x-tools/arm-kobo-linux-gnueabihf
d. Before you compile your code, set up your env.
export PATH=/home/xxx/x-tools/arm-kobo-linux-gnueabihf/bin:$PATH
source /home/xxx/koxtoolchain/refs/x-compile.sh kobo env
e. Use arm-kobo-linux-gnueabihf-gcc to build your code.
f. 執行時如果需要外部動態函式庫，可以在編譯時指定路徑給 gcc，"-Wl" 是告知 gcc 後面 "-rpath" 是給 linker 用的，"," 代表空白好讓 linker 知道。
-Wl,-rpath,/usr/local/Kobo -Wl,-rpath,/usr/local/Qt-5.2.1-arm/lib
14. 如果要 compile Qt，可以用 NickelTC，高手已經把環境包好。
15. 判斷機器型號的方式，開啟 /mnt/onboard/.kobo/version，檢查最後 3 碼即可，比如說 387 就是 Elipsa，可以看 plato.sh 裡面的判斷方式。
大概就是這些吧 ...
2022年1月1日 星期六
世界上不存在完美的電子紙閱讀器，因為看書的人就是小眾市場
從以前對每台新出的電子書閱讀器都抱有滿腔的期待，到現在變成只是淡淡的喔了一聲，絲毫不以為意！原因無他，那就是不可能有一台完美的電子書閱讀器，因為看書的人就是那麼少！廠商不太可能為了這種沒賺錢的生意，花費心血設計一台 90 分的電子書閱讀器（是的你沒看錯，我不覺得現在的閱讀器有到 90 分的程度，但這是以一台什麼事都可以做的閱讀器的基準來評分），如果想要走精品路線，我也懷疑有多少人願意買單？
每個人對完美的閱讀器標準不同，我也降低了我的標準，故我希望擁有 3 種不同形式的閱讀器，來滿足我的個人需求：
01. 一台國產的電子紙閱讀器手機。
我希望是一台國產或是不要偷傳封包的機器，畢竟我真的是要當手機使用，轉帳什麼的對手機來說是家常便飯，故安全性很重要。另外效能也不能太差，故處理器至少要是聯發科等級，如果能是高通當然是更好，至於電量可以撐過一天即可。
海信 A5 雖然效能 OK，但因為不知名封包，故我也無法當手機使用。
02. 一台 6 吋的可上網電子書閱讀器（4：3 比例的螢幕，非手機狹長形的）。
6 吋是最適合手拿的尺寸，也是最適合看流式 EPUB 的尺寸，想要簡單看個 PTT，FB 或是其他網路文章也不會很吃力。
其實 1 和 2 的需求其實很像，重點就在安全性和效能。
03. 一台 10 吋的可上網電子書閱讀器。
10 吋加上裁邊功能，這樣 PDF 也可以擁有更好的閱讀體驗，看固定版面 EPUB 也還可以。某些時候上網用大螢幕還是比較方便。
----------------
因為我上網只是要查資料，故有沒有彩色我也沒有很介意。但就算已經分成 3 台電子書閱讀器了，我目前也找不到一台可以達到 90 分的閱讀器。
如果再把需求限縮，目前我覺得可以達到 90 分的電子書閱讀器只有 2 台：
6 吋看流式 EPUB - Kindle Paperwhite 3
10 吋看 PDF - Kobo Elipsa + 第三方軟體
前後買過 10 台機器的我，還得加上降低標準，這樣也才 2 台達到我的需求，你說無不無奈？
2021年12月30日 星期四
Dropbox on Kobo
Kobo 在高階的機種上都有提供 Dropbox 服務，可以隨意選擇想要閱讀的書才下載，整體操作還蠻順暢的，可惜的是，免費版只有 2 GB 可以用，如果有很多書要放的話，一下子空間就滿了。
如果想要付費取得更多容量，一起跳就是 2 TB，不像 Google Drive 有 200 GB 的選項可以選擇，同樣 2 TB 的價錢，Dropbox 也是比 Google Drive 貴了幾百塊。
這禮拜在上傳了一堆 PDF 檔案後，我也開始遇到空間不足的問題了，本想直接付費搞定，但本著黑手的精神，還是想看看有沒有 DIY 的解決方法？
如果要使用我有付費訂閱的 Google Drive，目前只想到幾種解決方式：
01. 完成我之前想做的 GUI App，但之前的調查想要從無到有似乎有些困難？
02. 寫一個 Sync 的 App 或是找尋現成的 solution，不論哪種方式，都不會很困難，缺點就是一股腦同步，空間馬上會不夠用（KoboCloud 砍掉後下次還是會下載，故不算是現成的解決方案）。
03. 想辦法寫一個 KOReader 的 plugin，比照現有的 cloud storage，借用 KOReader 本身的 API 來達到 GUI 的目的。
看起來第三點比較符合我的需求，沒有意外，我應該會朝此方向努力吧？
如果不是想要使用 Google Drive，花錢升級 Dropbox 應該是比較快，為了做這個所花的時間代價，都不只差額 2000 多塊（目前我 GDrive 200 GB 每年只要 NT $900）。
如果我真的想不開把這個功能做好，就把這個差額再捐出去做好事吧，看這樣會不會比較有動力去完成它XD
2022/01/05 更新
跨年夜晚上睡不著覺時在想，GUI App 真的是我的需求嗎？最後才發現我比較需要的是 Wi-Fi 傳檔功能！感謝所有開發 Kobo 第三方軟體的前輩們，減少了我很多嘗試錯誤的時間。我終於可以隨時隨地的上傳檔案到 Kobo Elipsa 上了。
2021年12月29日 星期三
最有才的解 DRM 方式
今天 Google 跳出來了一篇文章《Quick and dirty way to rip an eBook from Android》，裡面只是簡單寫個 shell script 再加上 adb command 就把電子書再轉成掃瞄圖檔的電子書。
原理就是利用抓圖及觸發觸控翻頁，就可以輕鬆的抓完整本書囉。
備註：據我實驗的結果，圖片品質、執行時間及校稿時間都是此方法的致命傷，玩玩可以，但不實用，直接買 Kobo 及 Google 的書就好了。另外，某些國外資訊類的電子書都是無 DRM 的，購買後都可以直接下載，想在哪看就在哪看。
2021/12/30 更新
經實測確實還蠻好用的，不過要注意左右邊座標要設偏一點，否則流式 EPUB 的書有可能剛好點到註解，整個頁面就跳轉到亂掉了XD
另外，抓圖的那台機器，如果速度太慢，要調整一下 delay 值，我也遇到點了後已經 delay 4 秒，但翻頁還是翻不過去，是哪台機器就不說了XD
雖然用手機應該不會有這些問題，但手機螢幕如果不是 4 比 3，抓圖比例也怪，故也是兩難呀！
2021/12/31 更新
我的天呀，居然還有點一頁會跳兩頁的書，難怪沒有人想用這個方法！也許用 PC 閱讀軟體才是最好的方式，程式好寫又簡單不需要另外一台機器，不過，據我先期驗證的結果，某些書商版式的書，點開時不知道是在做解密還是幹嘛，光 delay 可能都不只要 4 秒，故這個方法，後續還要校稿，自動化的意義就不大了。
結論：這還是一個很有才的方式，但因為書商閱讀軟體寫的不好，還是需要後續校稿，故這個方式不實用。
2021/12/31 下午 更新
雖然覺得不實用，但還是想知道使用 PC 實作起來會如何？下午花了約快 2 個小時使用 Golang 實作它，大部份的時間都花在找套件。
原本以為 Node.js 會比較容易，但在編譯時還是遇到一些問題，Golang 一開始也是遇到問題，在換了作者建議的 C Compiler 後，便順利的編譯成功。
看來要在 Windows 下實作，呼叫 Win32 API 還是比較快，記得以前用 C 只需要不到 40 行即可。
目前覺得用 PC 才是唯一的最佳解，雖然也是不好用就是。另外我也找到了偶爾會 delay 的原因了，有些書商會定時在背景同步，如果同步的流程做得不好，確實有可能會造成翻頁 delay，不論是在 PC 或 Android 皆有可能。
花費了那麼多功夫測試，還不如把時間拿來多看幾本書，如果可以有一台完美的開放式閱讀器，就什麼問題都解決了。
訂閱：
文章 (Atom)