PowerDevil merge requests
https://invent.kde.org/plasma/powerdevil/-/merge_requests
2021-12-06T17:53:26Z
https://invent.kde.org/plasma/powerdevil/-/merge_requests/22
Use charge_control_*_threshold instead of charge_*_threshold
2021-12-06T17:53:26Z
Ian Scott
Use charge_control_*_threshold instead of charge_*_threshold
This is now documented as the standard Linux kernel API for charging
thresholds:
https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-class-power
This was added to the `thinkpad_acpi` driver in
https://github.co...
This is now documented as the standard Linux kernel API for charging
thresholds:
https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-class-power
This was added to the `thinkpad_acpi` driver in
https://github.com/torvalds/linux/commit/e33929537b76486d2ed576a0d9ce3ebff51bf851
This will break the feature on Thinkpads with a kernel older than that,
but will also work with other drivers that support charging thresholds.
5.20
Kai Uwe Broulik
Kai Uwe Broulik
https://invent.kde.org/plasma/powerdevil/-/merge_requests/104
Guard against nullable battery objects on disconnect
2022-12-16T17:53:55Z
ivan tkachenko
Guard against nullable battery objects on disconnect
There's a similar check in `onDeviceAdded` above, but this check is
structured such that any possible leftovers will be removed in any case.
---
Note: this patch doesn't prevent Plasma from crashing in presence of a "glitched device", ...
There's a similar check in `onDeviceAdded` above, but this check is
structured such that any possible leftovers will be removed in any case.
---
Note: this patch doesn't prevent Plasma from crashing in presence of a "glitched device", but it gets rid of two annoying errors in logs:
```
Sep 05 23:10:31 orange org_kde_powerdevil[50765]: QObject::disconnect: Unexpected nullptr parameter
Sep 05 23:10:31 orange org_kde_powerdevil[50765]: QObject::disconnect: Unexpected nullptr parameter
```
5.26
ivan tkachenko
ivan tkachenko
https://invent.kde.org/plasma/powerdevil/-/merge_requests/63
UpowerBackend: use DisplayDevice for ac adapter status when avail
2023-02-14T15:05:41Z
MΓ©ven Car
UpowerBackend: use DisplayDevice for ac adapter status when avail
Sometimes powerdevil applet will report the ac adapter to not be plugged in despite it is.
This is due to UPower OnBattery property being unreliable.
Switching to using DisplayDevice instead solves the issue.
For instance with my ac a...
Sometimes powerdevil applet will report the ac adapter to not be plugged in despite it is.
This is due to UPower OnBattery property being unreliable.
Switching to using DisplayDevice instead solves the issue.
For instance with my ac adapter disconnected:
CCBUG [423556](https://bugs.kde.org/show_bug.cgi?id=423556)
CCBUG [440609](https://bugs.kde.org/show_bug.cgi?id=440609)
```
19:41 $ upower -d
Device: /org/freedesktop/UPower/devices/line_power_AC
native-path: AC
power supply: yes
updated: mar. 19 oct. 2021 19:41:34 (11 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: no
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/battery_BAT0
native-path: BAT0
vendor: SMP
model: DELL G8VCF6C
serial: 2166
power supply: yes
updated: mar. 19 oct. 2021 19:41:34 (11 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: discharging
warning-level: none
energy: 23,6056 Wh
energy-empty: 0 Wh
energy-full: 28,7812 Wh
energy-full-design: 51,9992 Wh
energy-rate: 11,7952 W
voltage: 8,561 V
time to empty: 2,0 hours
percentage: 82%
capacity: 55,3493%
technology: lithium-polymer
icon-name: 'battery-full-symbolic'
History (charge):
1634665294 82,000 discharging
1634665213 81,000 discharging
History (rate):
1634665219 11,795 charging
1634665216 10,891 discharging
Device: /org/freedesktop/UPower/devices/line_power_ucsi_source_psy_USBC000o001
native-path: ucsi-source-psy-USBC000:001
power supply: yes
updated: mar. 19 oct. 2021 09:20:16 (37289 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: no
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/line_power_ucsi_source_psy_USBC000o002
native-path: ucsi-source-psy-USBC000:002
power supply: yes
updated: mar. 19 oct. 2021 09:36:30 (36315 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: yes
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/line_power_ucsi_source_psy_USBC000o003
native-path: ucsi-source-psy-USBC000:003
power supply: yes
updated: mar. 19 oct. 2021 14:58:08 (17017 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: no
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated: mar. 19 oct. 2021 19:41:34 (11 seconds ago)
has history: no
has statistics: no
battery
present: yes
state: discharging
warning-level: none
energy: 23,6056 Wh
energy-full: 28,7812 Wh
energy-rate: 11,7952 W
time to empty: 2,0 hours
percentage: 82%
icon-name: 'battery-full-symbolic'
Daemon:
daemon-version: 0.99.11
on-battery: no
lid-is-closed: no
lid-is-present: yes
critical-action: PowerOff
```
This seems semi-related to https://gitlab.freedesktop.org/upower/upower/-/issues/22.
5.24
https://invent.kde.org/plasma/powerdevil/-/merge_requests/162
Draft: Process energy rate history records in upower backend
2023-04-18T02:14:37Z
Fushan Wen
Draft: Process energy rate history records in upower backend
It's wrong to apply EMA to remaining time records.
CCBUG: 434432
It's wrong to apply EMA to remaining time records.
CCBUG: 434432
5.27
https://invent.kde.org/plasma/powerdevil/-/merge_requests/342
daemon: Limit KAuth backlighthelper calls to only one at a time
2024-03-19T16:20:26Z
Jakob Petsovits
daemon: Limit KAuth backlighthelper calls to only one at a time
Turns out #27 or https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3178 were not necessary to make the brightness slider laggy again. CC @nicolasfella, @nclarius, cheers! :beers:
---
KAuth invocations are slower than use...
Turns out #27 or https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3178 were not necessary to make the brightness slider laggy again. CC @nicolasfella, @nclarius, cheers! :beers:
---
KAuth invocations are slower than users can move a slider.
So we get many brightness change requests, and KAuth can't keep up.
As a result, high-frequency brightness change requests for
`BacklightBrightness` (i.e. laptop displays) would feel very laggy
and get worse over time if not given a break to catch up.
This commit fixes the lagginess. Conceptually it's easy:
Don't start a new KAuth helper job until the current one has
reported a result. At that point, check if a different brightness
level was requested in the meantime, and start another job only then.
`BacklightHelper` can deal fine with interrupting a running animation
and starting a new one from the current brightness level. Hence,
there is no need to wait until the end of the brightness animation
to start a new KAuth job - this would only increase latency.
Starting the new job right after receiving a result is perfectly fine.
In the same go, we make two related improvements.
Firstly, the udev-powered brightness observer will not only ignore
events when the animation timer is running, but also in between
`setBrightness()` and the KAuth result handler where the timer
is started.
Secondly, the condition involving `m_brightnessAnimationThreshold`
is changed to something sensible. It makes no sense to simply
check the current brightness against a constant number (100) to
determine whether the brightness change should be animated.
What I think this meant to do is to ensure that there are enough
brightness steps available to animate. So following this commit,
we will now animate when the difference between the current and
the requested brightness is 100 or more integer steps.
Taken together, laptop brightness slider UX now seems decent.
BUG: 481003
---
Notes:
* I have not tested BUG: 470106 which is probably also fixed with this, but would have to spend some time reproducing the original "going out of sync" issue.
* Seems feasible enough to backport to [`PowerDevilUPowerBackend` in Plasma/6.0](https://invent.kde.org/plasma/powerdevil/-/blob/6c7b9727e72ecf0fb6f15c1183ba1576cae431d7/daemon/backends/upower/powerdevilupowerbackend.cpp), but damn has this code come a long way since then already.
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/339
kcmodule: Revert to binding currentIndex in Component.onCompleted
2024-03-16T16:19:35Z
Jakob Petsovits
kcmodule: Revert to binding currentIndex in Component.onCompleted
Thanks to @broulik for finding this bug, and (in advance) for testing this fix on his system. What happened was that I tested the original patch while on battery, which apparently added just enough time for the models to initialize. Whil...
Thanks to @broulik for finding this bug, and (in advance) for testing this fix on his system. What happened was that I tested the original patch while on battery, which apparently added just enough time for the models to initialize. While plugged in though, the KCM starts with the "On AC Power" tab and that one initialized its comboboxes incorrectly.
---
Commit 8ecf6430 _(MR !337)_ caused empty ComboBox selections on initial load.
Turns out `indexOfValue()` can only be used after the
`Component.completed()` signal is emitted, so a purely declarative
binding worked incorrectly if queried too early by QML.
Therefore, we revert back to assigning a `Qt.binding()` to
`currentIndex` in `Component.onCompleted`.
This commit also adapts `PowerProfileModel` and its associated
ComboBox in a similar way as the other two models used in this KCM.
BUG: 483750
CCBUG: 482668
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/338
kcmodule: Don't crash when a configured button action is unsupported
2024-03-16T16:18:17Z
Jakob Petsovits
kcmodule: Don't crash when a configured button action is unsupported
The bounds check in the data() method of PowerButtonActionModel
and SleepModeModel was incomplete, so passing an invalid index
such as -1 (standard value for "not found") could cause a crash.
For power management settings, a user would ...
The bounds check in the data() method of PowerButtonActionModel
and SleepModeModel was incomplete, so passing an invalid index
such as -1 (standard value for "not found") could cause a crash.
For power management settings, a user would run into this crash if
their configuration from powerdevilrc listed a power button action
that's not supported on the current system. For example, a user
may have selected "Sleep" as lid action, but subsequently changed
their systemd configuration to disable suspend-to-RAM because it
caused problems. Or they could have migrated their OS to a new
computer which does not support Sleep.
Fixing this allows us to assign currentIndex declaratively
instead of waiting until Component.onCompleted to (hopefully) find
a valid item in the model.
BUG: 482668
(cherry picked from commit 8ecf6430ee7a3d3670fd9cb1b6af947f9ac2f352)
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/337
kcmodule: Don't crash when a configured button action is unsupported
2024-03-15T04:07:13Z
Jakob Petsovits
kcmodule: Don't crash when a configured button action is unsupported
The bounds check in the data() method of PowerButtonActionModel
and SleepModeModel was incomplete, so passing an invalid index
such as -1 (standard value for "not found") could cause a crash.
For power management settings, a user would ...
The bounds check in the data() method of PowerButtonActionModel
and SleepModeModel was incomplete, so passing an invalid index
such as -1 (standard value for "not found") could cause a crash.
For power management settings, a user would run into this crash if
their configuration from powerdevilrc listed a power button action
that's not supported on the current system. For example, a user
may have selected "Sleep" as lid action, but subsequently changed
their systemd configuration to disable suspend-to-RAM because it
caused problems. Or they could have migrated their OS to a new
computer which does not support Sleep.
Fixing this allows us to assign currentIndex declaratively
instead of waiting until Component.onCompleted to (hopefully) find
a valid item in the model.
BUG: 482668
---
I split this patch into two parts:
* The first one with the above commit message, which fixes the crash and can be cherry-picked to `Plasma/6.0`.
* The second one with just a commit title, which adds `InlineMessage` warnings to tell the user what's actually going on. Due to new strings, this should not go into `Plasma/6.0`.
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/335
actions/powerprofile: guard against empty profiles list in readProperties
2024-03-12T01:36:35Z
Natalie Clarius
natalie_clarius@yahoo.de
actions/powerprofile: guard against empty profiles list in readProperties
BUG: 483216
BUG: 483216
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/334
Check if idle inhibitor is active before blanking the screen
2024-03-12T04:00:11Z
Jakub GocoΕ
Check if idle inhibitor is active before blanking the screen
This was accidently removed during refactor of this area and caused bug 482141
This fixes regression introduced in e9c984a78c9ace207f98922d018ea3ef58ea7cd3
This was accidently removed during refactor of this area and caused bug 482141
This fixes regression introduced in e9c984a78c9ace207f98922d018ea3ef58ea7cd3
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/333
daemon: Avoid constantly locking ddcutil display handles
2024-03-16T23:46:44Z
Jakob Petsovits
daemon: Avoid constantly locking ddcutil display handles
Since libddcutil implemented functionality for per-monitor
device lock files, other programs that are also using libddcutil
(such as the `ddcutil` CLI itself) were blocked from performing
monitor commands because PowerDevil kept all its ...
Since libddcutil implemented functionality for per-monitor
device lock files, other programs that are also using libddcutil
(such as the `ddcutil` CLI itself) were blocked from performing
monitor commands because PowerDevil kept all its handles open.
The better way of interacting with libddcutil as a long-running
program is to store a `DDCA_Display_Ref` for each monitor in question,
use it to get a temporary display handle, and close it again.
Now we can peacefully coexist with other libddcutil programs,
and users can e.g. query their monitor properties again.
As a slight downside, this means it's possible for another program
to set display brightness independently without PowerDevil noticing.
That seems like a smaller evil though, and can't be fixed by simply
using libddcutil itself as it cannot signal any VCP changes.
Common infrastructure such as [digitaltrails/ddcutil-service](https://github.com/digitaltrails/ddcutil-service) or a
future kernel DRM interface for DDC/CI could help to mitigate this.
BUG: 481793
---
Note: Backporting this to the Plasma/6.0 branch won't be trivial, because the ddcutil code has changed quite a bit from @littlesweet's improvements for detecting monitor hot-plugging events. Most of this code should translate to Plasma/6.0 in principle, but we'll run into merge conflicts and it would need to be verified independently after backporting. Not sure if it's worth the extra work, I'm happy to hear opinions on this. (I get that it obviously be neat for new Plasma 6 users if they don't have to wait for another 3-4 months to use `ddcutil` again.)
6.1
https://invent.kde.org/plasma/powerdevil/-/merge_requests/332
actions/dpms: Ignore turn-off triggers when action is disabled
2024-03-12T11:14:40Z
Jakob Petsovits
actions/dpms: Ignore turn-off triggers when action is disabled
Early Plasma 6.0 releases saw many people reporting unintentional
screen turn-off when the screen locker activates/deactivates,
and when the system wakes up from sleep. On X11, this was visible
to the user immediately, whereas on Wayland...
Early Plasma 6.0 releases saw many people reporting unintentional
screen turn-off when the screen locker activates/deactivates,
and when the system wakes up from sleep. On X11, this was visible
to the user immediately, whereas on Wayland it spammed system logs
with warnings of invalid -1 idle timeout registrations.
Ironically, this behavior would occur specifically when the DPMS
action (a.k.a. "When locked, turn screen off") was disabled.
The reason is that the DPMS object gets created either way, and
sets up its screen locker activation change handler as well as
suspend/resume handlers in the constructor. But timeout values
can remain invalid until the action is loaded/enabled and
timeout values are populated from profile settings.
Using invalid timeouts in these handlers caused this headache.
This bug was introduced by commit c58085b4, which fixed a bunch of
things, bug also removed checks for invalid timeout values.
Turns out we still need some kind of checks.
We now prevent bad timeout registrations by interpreting negative
values in m_idleTimeoutWhenUnlocked as "idle timeout disabled".
Checks for this value ensure that registerIdleTimeout() is only
called when the action is loaded, regardless of whether it's
triggered by screen locker changing its activation status,
resume after suspend, or any other event.
Alternatively, we could have also moved some signal connections
into loadAction() and disconnected them in onProfileUnload().
Checking on every registration call seems more robust though
BUG: 481308
BUG: 482077
---
Plus extra commit in the same file: Add new logs to make future debugging easier
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/328
[dimdisplay] Respect profile configurations
2024-02-28T18:29:23Z
Jakob Petsovits
[dimdisplay] Respect profile configurations
Manually conflict-resolved cherry-pick of !314. The only difference is that 6.0 still uses `BackendInterface` (implemented only by `PowerDevilUPowerBackend`) so instead of `core()->screenBrightnessController()->` in master (post-6.0) we ...
Manually conflict-resolved cherry-pick of !314. The only difference is that 6.0 still uses `BackendInterface` (implemented only by `PowerDevilUPowerBackend`) so instead of `core()->screenBrightnessController()->` in master (post-6.0) we now use `backend()->` in the 6.0 branch.
CC @anthonyfieroni who authored the original patch.
---
When profile is loaded after dim action is activated:
1. Restore previous brightness values if new profile doesn't require dimming
2. Override previous brightness values if new profile explicitly set
Signed-off-by: Anthony Fieroni <bvbfan@abv.bg>
(cherry-picked from 3b9a43a9f0547ac7ded68870b42b51d8e2d99090)
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/320
kcmodule: Remove separator line now that NavigationTabBar provides it
2024-02-10T05:28:03Z
Jakob Petsovits
kcmodule: Remove separator line now that NavigationTabBar provides it
This restores the unnecessarily thick line between tabs and
page content to regular thickness.
(cherry picked from commit 9fff8ee019a25dbbc4720db296fd89f9c9d4a4f1)
This restores the unnecessarily thick line between tabs and
page content to regular thickness.
(cherry picked from commit 9fff8ee019a25dbbc4720db296fd89f9c9d4a4f1)
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/319
kcmodule: Remove separator line now that NavigationTabBar provides it
2024-02-10T05:24:29Z
Jakob Petsovits
kcmodule: Remove separator line now that NavigationTabBar provides it
This restores the unnecessarily thick line between tabs and
page content to regular thickness.
This restores the unnecessarily thick line between tabs and
page content to regular thickness.
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/317
kbd backlight: Fix double brightness restore on LidOpen-resume
2024-02-09T18:18:04Z
Jakob Petsovits
kbd backlight: Fix double brightness restore on LidOpen-resume
This fixes the issue that on LidOpen-resume the brightness might get restored
two times. Once to the correct vallue and once incorrectly to 0.
To archive this it uses the same simple "don't restore to 0"-policy as is used
in dimdisplay....
This fixes the issue that on LidOpen-resume the brightness might get restored
two times. Once to the correct vallue and once incorrectly to 0.
To archive this it uses the same simple "don't restore to 0"-policy as is used
in dimdisplay.cpp, dpms.cpp, and handlebuttonevent.cpp.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
(cherry picked from commit aa2fa106)
5.27
https://invent.kde.org/plasma/powerdevil/-/merge_requests/316
kbd backlight: Fix double brightness restore on LidOpen-resume
2024-02-09T18:18:04Z
Jakob Petsovits
kbd backlight: Fix double brightness restore on LidOpen-resume
This fixes the issue that on LidOpen-resume the brightness might get restored
two times. Once to the correct vallue and once incorrectly to 0.
To archive this it uses the same simple "don't restore to 0"-policy as is used
in dimdisplay....
This fixes the issue that on LidOpen-resume the brightness might get restored
two times. Once to the correct vallue and once incorrectly to 0.
To archive this it uses the same simple "don't restore to 0"-policy as is used
in dimdisplay.cpp, dpms.cpp, and handlebuttonevent.cpp.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
(cherry picked from commit aa2fa1067be58a9c68b54f3d80b239291e154911)
6
https://invent.kde.org/plasma/powerdevil/-/merge_requests/315
Make "Prompt Logout Dialog" action invoke logout prompt, not shutdown
2024-02-08T19:36:50Z
Bharadwaj Raju
Make "Prompt Logout Dialog" action invoke logout prompt, not shutdown
The Shutdown prompt (status quo) shows only two options: Shutdown/Cancel. This one shows all options: Sleep/Logout/Shutdown/Cancel, which is most appropriate for the "Prompt Logout Dialog" option.
The Shutdown prompt (status quo) shows only two options: Shutdown/Cancel. This one shows all options: Sleep/Logout/Shutdown/Cancel, which is most appropriate for the "Prompt Logout Dialog" option.
6.1
https://invent.kde.org/plasma/powerdevil/-/merge_requests/314
[dimdisplay] Respect profile configurations
2024-02-28T17:36:19Z
Anthony Fieroni
bvbfan@abv.bg
[dimdisplay] Respect profile configurations
Signed-off-by: Anthony Fieroni <bvbfan@abv.bg>
Signed-off-by: Anthony Fieroni <bvbfan@abv.bg>
6
Anthony Fieroni
bvbfan@abv.bg
Anthony Fieroni
bvbfan@abv.bg
https://invent.kde.org/plasma/powerdevil/-/merge_requests/311
kbd backlight: Fix double brightness restore on LidOpen-resume
2024-02-19T14:52:17Z
Werner Sembach
kbd backlight: Fix double brightness restore on LidOpen-resume
This fixes the issue that on LidOpen-resume the brightness might get restored
two times. Once to the correct vallue and once incorrectly to 0.
To archive this it uses the same simple "don't restore to 0"-policy as is used
in dimdisplay....
This fixes the issue that on LidOpen-resume the brightness might get restored
two times. Once to the correct vallue and once incorrectly to 0.
To archive this it uses the same simple "don't restore to 0"-policy as is used
in dimdisplay.cpp, dpms.cpp, and handlebuttonevent.cpp.
BUG: 469819
5.27