如何解决Plasma5中延迟检测充电的问题？

Question

我有最新的Pop!_OS 20.04。我最近在我的机器上安装了KDE Plasma。

唯一让我恼怒的是，一旦我的电池变低，我插入我的充电器，KDE需要近半个小时才能检测到。这基本上意味着，如果我插入10%，即使我的机器插上电源，KDE也会关闭系统。

请注意，早期或20%的插件并不是理想的解决方案。

Answer 1

我为KDE等离子5编写了一个applet，它显示了基于/sys接口的电池百分比(它会立即更新，不会延迟UPower守护进程或电池和亮度等离子体)。

实际上，/sys是一个用于访问runtime.It的内核数据结构的接口，它完全驻留在内存中，并且是调试information.The信息的有用来源，这里我们需要的是确切的电池百分比：

$ 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)：

这个质体的职责是每三秒定期读取这个数字。

下面是项目存储库：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等离子体中的小部件侧栏中看到等离子电池百分比指示器，并且可以从那里拖放它。

有很多TODOs喜欢在百分比低于阈值etc.But时改变颜色，我现在很忙:)

希望能帮上忙。

Answer 2

(我这么做主要是为了激励别人做一个更好的答案，以阻止我得到不应得的赏金。请做一个更好的。请提出比我的答案更好的答案。一旦我注意到任何有实际解决方案的答复，我将很高兴地删除我的答案。否则，让这个答案得到2分，这样至少可以避免他们失去的声誉至少没有完全丧失的挫败感。)

评论中的论述表明，在执行部分没有明显的错误。

评论者一致认为，这很可能是KDE中的一个bug。

现在有一个被OP归档的错误报告。

https://bugs.kde.org/show_bug.cgi?id=423556#c1

而且，这一错误似乎之前也有报道过。

如果问题没有被关闭或删除，这是分析的当前状态，是任何人能得到的最接近的答案。