日立冷氣 RA-28NA 拆卸前面板

前幾天晚上清洗冷氣濾網時，無意間發現兩邊出風口內部的保麗龍居然一層黑灰，也不知道是灰塵還是霉菌，我猜應該是兩者都有。

今天趁著假日下午，稍微試了一下，終於讓我發現卸除方式，前面板跟濾網都是同一塊，故不用特別先移除。。

首先先從下半部左右兩側稍微出點力的把它退出來，注意左邊的藍圈處有排線，故不能太大力，建議先從右邊退出就好。

再來則是上方紅圈處及橘圈處有兩個小洞，故整個前面板其實會卡在這兩個洞裡，故我們把下半部的前面板退出後，接著把前面板往上抬起直到卡榫高過這兩個洞後便可輕易的拆卸了。

上面是卡榫洞的照片，可以看到出風口內部保麗龍壁確實很髒，理論上兩邊出風口最裡面中間應該還有一個輪子，但這要專業人士整個拆解後才有可能清除到。

故整個拆卸步驟如下面所示。

附上其他照片供以後參考。

亞馬遜正式支援 EPUB 檔案推送？

Kindle 有個很好用的功能，那就是可以把支援的電子書檔案上傳到指定的電子郵件信箱，這樣電子書便可以被轉檔儲存在個人文件空間，之後在不同機器間的閱讀進度便可以同步了！

因為我始終覺得 Kindle 是閱讀體驗最好的機器，故我本人很依賴這個功能，不論是之前的 R 家或是現在的 K 家，我都是以這樣的方式在我的 Kindle Paperwhite 3上閱讀購買的繁體中文電子書。

昨天在電子書閱讀器討論區看到有網友提到可以直接將 EPUB 檔案上傳到亞馬遜的心得分享，二話不說馬上跑去將我之前轉完 MOBI 超過 25 MB 的電子書上傳測試，果然可以順利的加入到個人文件，不論是中亞或是美亞都沒有問題。我自己之前經驗是約莫 22 MB 的 EPUB 電子書轉完 MOBI 後都會超過 25 MB。

美中不足的是，亞馬遜後台看起來還是透過 kindlegen 程式去做處理，原本用 kindlegen 轉檔失敗的書一樣還是會被亞馬遜退件，所以我們還是得自己手動處理，幸好這樣的書並不多，我昨天上傳了 20 本，也只遇到 2 本有問題。

如果可以再找到附件限制為 50 MB 的電子郵件帳號，除了漫畫及固定版式的 EPUB 外，幾乎所有的書都可以上傳到到亞馬遜了，以後看書就更方便了。

下面就是前一陣子購買收藏用的《牧羊少年奇幻之旅》一書，直接將快 25 MB 的 EPUB 上傳到亞馬遜後，終於不用再透過電腦放進閱讀器了，真是感動的一晚呀。

2022/04/24 更新

kindlegen 轉檔常見錯誤解決方式。

错误(prcgen):E24010:无法解析目录中的超链接 - 1

错误(prcgen):E24010:无法解析目录中的超链接 - 2

错误(prcgen):E23029

错误(opfparser):E20006

2022/04/26 更新

感謝討論區花圓的提醒，雖然我過幾天才會意過來，原來 Hinet 本身便可以支援 50 MB 的信件大小，故扣掉標頭等信件本身資訊，應該可以支援到約 45 MB 的附件。不然國外付費郵箱 mail.com 也可以支援 50 MB 的附件（一年約美金 30）。另外一些大陸郵箱也有支援較大的附件大小，但因需要大陸門號，故不一定能順利申請。

2022/05/01 更新

目前官方文件已正式提到加入 EPUB 格式支援，另外在 2022 年底也不再支援 .MOBI 以及 .AZW 格式的推送，照官方說法是這兩種格式因為太舊已不符合新 Kindle 的需求。  

2022/05/31 更新

下午試了一下美亞，因為只有這台機器是國際無廣告版。據測試的結果，即使沒有滿足 JPG/JFIF 封面，上傳的書籍也還是在 DOC 分類裡，但我的 oasis 2 仍然可以正常的在待機時顯示書封。

GNU Global 一些數據參考

很久以前在做 Windows Mobile 手機時，trace code 都是使用 Global，後來比較沒機會接觸到這樣龐大的 code base，故都是用我的 UltraEdit 搞定。

最近有同事問我 trace linux kernel 的事，拿 5.17.3 版本試了一下，留下記錄當做參考。

兩種使用方式

01. VSCode + Global

可以參考這裡。

02. 直接使用 Global 並產生 HTML 檔案

gtags 執行速度很快，大概不到 10 分鐘就建好 tag 資料庫。

htags - sna 總共花了約 4 小時又 43 分才建好所有 HTML。

另外，HTML 整包資料夾的大小約為 12.1G，硬碟大小則是 17.3G，裡面共產生 2,047,758 支檔案及 8 個資料夾。

我們也可以直接用指令查詢 tag 資料庫，只要記住兩個指令就好。還有下指令時不需要在 tag 檔案那層，隨便一層都可以。

global XXX  直接找 XXX 定義的地方。

global -r XXX 則是找 XXX 被使用的地方。

加上 -x 則是取得詳細的資料。

記得在使用 Global 前，要先 build 過 kernel 幾分鐘，好讓相關的 CONFIG_XXX 自動生成，其位置是在 CodeRoot/include/generated/autoconf.h

Chrome Extension - Manifest V3

Manifest 是 Chrome Extension 的一個架構檔案，裡面會描述所需要的權限以及 action 等相關。

好像是從去年開始，版本從 v2 升級到 v3，故從 2022/01 開始，無法在 Store 上架 v2 的套件，明年 2023/01 以後，則是不允許執行 v2 的套件。

有些 property 改名字了，有些則是 API 呼叫方式改變，以我的 KoboExpense 來說，大概有一成需要更動，整體來說並沒有到很麻煩。

另外 v3 版本的 API 很多都會回傳 promise，故在非同步的處理上應該會更方便。

2022/04/21 更新

前天上架的 KoboExpense 被退回來了，原因是用到不需要的權限。因為從 v3 開始，呼叫執行 script 的 API 參數有變，需要多傳一個 tab ID，故我以為需要 tabs 的權限，後來仔細再看了一遍文件，發現只有存取 tabs.Tab 裡的一些欄位才需要此權限（url, pendingUrl, title, or favIconUrl）。

可見目前審核是比較嚴格，故上架時還是要多注意是否加了不必要的權限。

2022/04/22 更新

下午收到審核通過的信件，看起來整個流程差不多要兩天，不過還是得看同時要上架的 Extension 有多少而訂。

grep 多行匹配

換行字元 pattern 為 \r or \n。

grep -Pzo "pattern" file

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。

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 顯示方式，因為真的跟我本來的習慣不一樣，再加上緊密放在一起的排列，真的是很兩難呀。

手邊的 Arm 產品比較

平常一直沒特別注意，今早突然想到，來列一下手邊機器的 Arm 規格，由上到下依 Arm 架構新舊順序排列，有可能因為頻率或核心數關係，故不一定哪一台比較快，雖然以我的例子，我感受的順序也跟下面一致（除了 Elipsa，使用起來感覺是比 Pocket 快）。

01. Chromecast with Google TV 

ARM Cortex-A55 (Armv8-A (Harvard), 64)

02. Hisense A5

Qualcomm Snapdragon 439 - Arm Cortex-A53 (Armv8-A, 64)

03. HTC Desire 19s

MediaTekR Helio P22 - Arm Cortex-A53 (Armv8-A, 64)

04. HyRead Gaze Pocket

Rockchip PX30 - Arm Cortex-A35 (Armv8-A, 64)

05. Kobo Elipsa 

Allwinner B300 - Arm Cortex-A7 (Armv7-A, 32)

06. Kindle Paperwhite 3

Freescale i.MX7 Dual - Arm Coretex-A7 + Arm Cortex-M4 

不查不知道，原來我的 Google 電視盒居然比我目前用的手機還快？

Linux kernel coding style

最近不知道為什麼喜歡看 Linux Document XD 雖然大部份都看不懂居多！

https://www.kernel.org/doc/html/latest/process/coding-style.html

上面文章描述了 kernel coding style 的注意事項，其中開宗明義就提到最好使用 tab 字元，而縮排應該是 8，因為較深的區塊顯示可以讓工作一整天的 kernel developers 更容易的注意到縮排的區塊。如果因為縮排為 8 而讓文字超過螢幕 80 個字元的寬度，這就表示你的 code 有問題了，一般來說不應該超過 3 層。

想想還蠻有道理的，Go 語言也是提倡要用 tab 縮排。

Bluetooth Spec 初步了解

BR/EDR 和 LE 是屬於兩種不同的協定，要想支援所有的藍牙裝置，則兩種協定都要懂，才能分別用不同的協定與裝置溝通。

目前 Core Spec 是 v5.3，此 Spec 只描述 Host 和 Controller 層，以及核心相關的 Profile，其他的會是屬於 Application 的 Spec。

整個 Core Architecture 如下，C-plane（Control）、U-plane（User）：

同 TCP/IP Model 一樣，一樣有分層的概念：

10 幾年前做手機時，常聽到 BT 同事提到 Profile，Core_v5.3 是這樣描述的：

Bluetooth profiles define the required functions and features of each layer in the Bluetooth system from the PHY to L2CAP and any other protocols outside of this specification. The profile defines the vertical interactions between the layers as well as the peer-to-peer interactions of specific layers between devices.

這個網站的主人，似乎是個高手，先留個記錄先。

http://www.wowotech.net/bluetooth/bt_protocol_arch.html

Linux Input Subsystem 入門參考文件

Linux 果然是世界上最棒的作業系統呀 ~~

https://www.linuxjournal.com/article/6396

Logitech R500 events

It maps to three input devices on Ubuntu Linux.

Logitech R500 Keyboard (Kobo Elipsa uses this mode)

Right - 1(EV_KEY), 106(KEY_RIGHT), 1

Left   - 1(EV_KEY), 105(KEY_LEFT), 1

8BitDo Zero 2 gamepad events

X-Input (X + start, then hold to press select)

Up    - 3(EV_ABS), 1(ABS_Y), 0

Down  - 3(EV_ABS), 1(ABS_Y), 65535

Left  - 3(EV_ABS), 0(ABS_X), 0

Right - 3(EV_ABS), 0(ABS_X), 65535

X     - 1(EV_KEY), 307(BTN_NORTH), 1

B     - 1(EV_KEY), 304(BTN_SOURTH), 1

Y     - 1(EV_KEY), 306(BTN_C), 1

A     - 1(EV_KEY), 305(BTN_EAST), 1

L     - 1(EV_KEY), 308(BTN_WEST), 1

R     - 1(EV_KEY), 309(BTN_Z), 1

武林絕學 - 金星幻式 - 七星連線

標題雖然是布袋戲的招式名稱，但我想不到比這個貼切的標題了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

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" 資料夾。

05. 將此檔案下載下來並放到 ".btpt" 資料夾，檔名只能是 "8BitDo Zero 2 gamepad"，然後將閱讀器重開機並進到藍牙設定頁面。

06. 按下 8BitDo Zero 2 的 X 鍵及 start 鍵，進入 X-Input 模式後，然後長按 select 鍵進入藍牙配對模式。

07. 配對成功後，回到書本閱讀頁面能夠翻頁就是成功了，不行就在藍牙設定畫面忘記裝置再重新配對。

如何使用 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。