如何解決 Plasma5 充電檢測延遲的問題?
我有最新的
Pop!_OS 20.04
。我最近安裝KDE Plasma
在我的機器上。唯一讓我煩惱的是,一旦我的電池電量不足,我插入充電器,KDE 需要將近半小時才能檢測到這一點。這基本上意味著如果我插入
10%
,即使我的機器已插入,KDE 也會關閉系統。請注意,儘早插入或以 20% 插入不是理想的解決方案。
我為 KDE Plasma 5 編寫了一個小程序,它根據
/sys
界面顯示電池百分比(它會立即更新,並且沒有UPower守護程序或電池和亮度plasmoid 的延遲)。
/sys
實際上是在執行時訪問核心資料結構的介面。它完全駐留在記憶體中,是調試資訊的有用來源。我們需要的資訊是確切的電池百分比:$ tree /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/ . ├── alarm ├── capacity ├── capacity_level ├── cycle_count ├── device -> ../../../PNP0C0A:00 ├── energy_full ├── energy_full_design ├── energy_now ├── hwmon1 │ ├── device -> ../../BAT0 │ ├── in0_input │ ├── name │ ├── power │ │ ├── async │ │ ├── autosuspend_delay_ms │ │ ├── control │ │ ├── runtime_active_kids │ │ ├── runtime_active_time │ │ ├── runtime_enabled │ │ ├── runtime_status │ │ ├── runtime_suspended_time │ │ └── runtime_usage │ ├── subsystem -> ../../../../../../../../../../class/hwmon │ ├── temp1_label │ ├── temp2_label │ └── uevent ├── manufacturer ├── model_name ├── power │ ├── async │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_kids │ ├── runtime_active_time │ ├── runtime_enabled │ ├── runtime_status │ ├── runtime_suspended_time │ └── runtime_usage ├── power_now ├── present ├── serial_number ├── status ├── subsystem -> ../../../../../../../../../class/power_supply ├── technology ├── type ├── uevent ├── voltage_min_design └── voltage_now
例如,我們要查找的號碼位於此文件下(在我的系統中):
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/capacity
它顯示了電池的正確百分比(BAT0):
該 plasmoid 的職責是每三秒定期讀取該數字。
這是項目儲存庫:https
://gitlab.com/P.Mousavi/batperc-indicator 如果您想編譯並執行它,請按照以下說明操作:安裝依賴項(在README.md中解釋)並執行:
git clone https://gitlab.com/P.Mousavi/batperc-indicator.git cd batperc-indicator mkdir build cd build qmake ../plugin/ make sudo make install
如果一切順利,那麼您應該能夠在 KDE Plasma 的小元件側欄中看到 plasmoid Battery 百分比指示器,您可以從那裡拖放它。
有很多 TODO,比如當百分比低於門檻值時更改顏色等。但現在我很忙 :)
希望能幫助到你。
(我做這個答案主要是為了激怒其他人做出更好的答案,以防止我獲得不應得的賞金。請做出更好的答案。請更喜歡投票給我以外的任何其他答案。一旦我注意到任何帶有實際解決方案的答案建議我會很樂意刪除我的。否則讓這個答案得到 2 分,以便至少避免讓 OP 感到沮喪,因為他們失去的聲譽至少沒有完全失去……)
評論中的討論表明,OPs 部分沒有明顯的錯誤。
評論者一致認為這很可能是 KDE 中的一個錯誤。
現在有一個由 OP
https://bugs.kde.org/show_bug.cgi?id=423556#c1送出的錯誤報告
而且似乎該錯誤也已在之前被報告過。
如果問題沒有關閉或刪除,則分析的目前狀態是任何人都可以獲得最接近答案的狀態。