https://bugs.kde.org/show_bug.cgi?id=481308
Nicolas Fella <nicolas.fe...@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas
|ma/powerdevil/-/commit/be2b |ma/powerdevil/-/commit/a150
|83615d879549ecf9a47b66dc668 |b9fa622b71420d3c231eb87be69
|87419a2dc |5d3f96483
--- Comment #51 from Nicolas Fella <nicolas.fe...@gmx.de> ---
Git commit a150b9fa622b71420d3c231eb87be695d3f96483 by Nicolas Fella, on behalf
of Jakob Petsovits.
Committed on 12/03/2024 at 11:15.
Pushed by nicolasfella into branch 'Plasma/6.0'.
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 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.
Related: bug 482077
(cherry picked from commit be2b83615d879549ecf9a47b66dc66887419a2dc)
M +24 -10 daemon/actions/bundled/dpms.cpp
M +1 -0 daemon/actions/bundled/dpms.h
https://invent.kde.org/plasma/powerdevil/-/commit/a150b9fa622b71420d3c231eb87be695d3f96483
--
You are receiving this mail because:
You are watching all bug changes.
