https://bugs.kde.org/show_bug.cgi?id=479659
Jakob Petsovits <jpe...@petsovits.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|plasma-b...@kde.org |kwin-bugs-n...@kde.org
Component|general |input
Product|Powerdevil |kwin
CC| |jpe...@petsovits.com
--- Comment #5 from Jakob Petsovits <jpe...@petsovits.com> ---
Not sure what component was assigned initially, but I'll reassign to KWin
because both DPMS and input functionality is located there. From a PowerDevil
point of view, what happens (on Wayland) is:
1. When the screen locker gets activated (via
OrgFreedesktopScreenSaverInterface::ActiveChanged signal), PowerDevil installs
a 100ms KIdleTime timeout (increased from 0s to avoid weird behaviors).
2. Once the timeout triggers, PowerDevil sets keyboard backlight brightness to
0 and then calls KScreen::Dpms::switchMode(KScreen::Dpms::Off), which on
Wayland asks KWin to please turn off the display.
3. Once input is detected (via KIdleTime::resumingFromIdle signal), the short
100ms KIdleTime timeout is removed and we instead install a longer 10s minimum
timeout so the user has time to unlock their session. Also, keyboard brightness
back to where it was before.
None of these behaviors include grabbing input events directly, which makes me
think that whichever race condition is exposed by this would be located closer
to KWin. Perhaps KIdleTime, but on Wayland that also goes through KWin.
--
You are receiving this mail because:
You are watching all bug changes.
