https://bugs.kde.org/show_bug.cgi?id=523504
Bug ID: 523504
Summary: No password prompt: PowerDevil immediate DPMS after
automatic idle lock can race with KScreenLocker
greeter initialisation on Wayland
Classification: Plasma
Product: plasmashell
Version First 6.7.3
Reported In:
Platform: KDE Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Power management & brightness
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: 1.0
DESCRIPTION
No password prompt, after return, from automatic idle lock:
PowerDevil immediate DPMS can race with KScreenLocker initialisation on
Wayland.
When the display is configured to turn off "immediately" after locking, the
screen can be powered off before the KScreenLocker UI is ready.
After the display wakes, the session resumes without showing the expected
password prompt.
Automatic idle locking: reproduces consistently
Manual locking (Meta+L): does not reproduce
STEPS TO REPRODUCE
Conditions:
- Screen Locking > [Lock Screen Automatically]:TIME < Power Management > [Turn
off Screen]: TIME
- Screen Locking > [Delay before password required]: set greater than 0
- Power Management > Display and Brightness > Turn off Screen > "When locked:
Immediately"
1. KDE Plasma Wayland session
2. System settings > Screen Locking
- Lock screen automatically: 1 minute
- Delay before password required: 5 seconds
3. System settings > Power Management > /Display and Brightness
- Turn off Screen: 2 minutes
- When locked: Immediately
4. Wait 1 minute for display to turn off, then another 5 seconds for password
required
5. Attempt to interact with lock screen
OBSERVED RESULT
After 1 minute screen goes black
Wait 5+ seconds to ensure password required is applied.
Interact with mouse/keyboard.
Screen activates and auto-resumes session - without password prompt.
EXPECTED RESULT
After 1 minute screen goes black
Wait a 5+ seconds
Interact with mouse/keyboard.
Password prompt to log in.
Log in.
SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 7.1.4-204.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 28 × Intel® Core™ i7-14700K
Memory: 64 GB of RAM (62.5 GB usable)
Graphics Processor 1: Intel® Graphics
Graphics Processor 2: AMD Radeon RX 7900 XTX
ADDITIONAL INFORMATION
I believe this is a race condition between KScreenLocker reporting the lock as
active and PowerDevil starting its immediate DPMS timeout (to create the
expected instant screen off visual).
---
The relevant PowerDevil code is in:
daemon/actions/bundled/dpms.cpp
---
PowerDevil intentionally uses a short timeout when the lock screen is
activating:
static constexpr std::chrono::milliseconds s_minIdleTimeoutWhenActivatingLock =
100ms;
---
The lock activation handler:
void DPMS::onScreenLockerActiveChanged(bool active)
{
unregisterIdleTimeouts();
m_isActivatingLock = active && !m_isAboutToSuspend;
if (m_isActivatingLock) {
// entering lockscreen - fast display turn-off if the config calls for
it
registerIdleTimeout(m_idleTimeoutWhenActivatingLock);
}
}
---
This timeout is triggered from the
org.freedesktop.ScreenSaver.ActiveChanged(true) signal received through the
PowerDevil policy agent.
The lock activation path is:
idle timeout
v
KScreenLocker starts locking
v
KSldApp::lockScreenShown()
v
org.freedesktop.ScreenSaver.ActiveChanged(true)
v
PowerDevil DPMS::onScreenLockerActiveChanged(true)
v
100ms idle timeout
v
DPMS off
---
KScreenLocker:
greeter/main.cpp
---
The greeter has an initial setup phase:
app.initialViewSetup();
With comments:
// This allow ksmserver to know when the application has actually finished
setting itself up.
// Crucial for blocking until it is ready, ensuring locking happens before
sleep, e.g.
---
daemon/ksldapp.cpp
---
The lock state transition emits locked():
void KSldApp::lockScreenShown()
{
if (m_lockState == Locked) {
return;
}
m_lockState = Locked;
m_lockedTimer.restart();
Q_EMIT locked();
Q_EMIT lockStateChanged();
}
---
Which eventually results in:
daemon/dbus/interface.cpp
---
void Interface::slotLocked()
{
sendLockReplies();
Q_EMIT ActiveChanged(true);
}
This means ActiveChanged(true) is emitted as part of the lock state transition.
It does not appear to guarantee that the Wayland greeter is fully ready for an
immediate DPMS transition.
---
The observed failure occurs shortly afterwards:
kscreenlocker_greet: eglSwapBuffers failed with 0x3003
kscreenlocker_greet: The Wayland connection broke. Did the Wayland compositor
die?
The issue may be that the event used to start the timer, may occur before
KScreenLocker is ready for the display to be powered off.
Possible solutions could be:
- a lock-screen-ready signal separate from ActiveChanged(true)
- delay PowerDevil immediate DPMS path until KScreenLocker reports readiness
- clarify whether ActiveChanged(true) is intended to signal lock state only, or
lock-screen readiness
--
You are receiving this mail because:
You are watching all bug changes.
