https://bugs.kde.org/show_bug.cgi?id=528294
Bug ID: 528294
Summary: Lock screen starts PAM authentication immediately on
multi-monitor setups, so face unlock fails and isn't
retried
Classification: Plasma
Product: plasmashell
Version First 6.8.2
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Screen locking
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: 1.0
Setup: Laptop with its built-in screen plus one external monitor, using a
non-interactive PAM module (biopass face recognition, auth sufficient before
pam_unix in the kde stack).
Steps:
1. Connect an external monitor (two outputs active).
2. Lock with Meta+L, or let the idle timeout lock the screen, and walk away.
3. Come back and press a key.
Expected: Authentication starts on user activity, as it does with a single
monitor and as it did in 6.7.5. Face unlock then succeeds.
Actual: On multi-monitor setups, the greeter calls startAuthenticating() about
1 s after locking, with no user input. The face module runs with nobody in
front of the camera and fails, and PAM falls through to pam_unix's Password:
prompt. Pressing a key later doesn't restart authentication, so the password is
the only way in.
Single-monitor control case: the same lock waits for input, then face unlock
succeeds.
Log evidence (kscreenlocker_greet.debug and kscreenlocker.worker.debug
enabled):
19:01:04 Greeter is starting up. (2 lock screen windows created)
19:01:04 Ping received "Hello from worker!" (x2)
19:01:05 Interactive authenticator kde changed business <- auth starts, no
input
19:01:07 [PAM worker kde] Message: Echo-off prompt: Password:
19:05:42 responding to interactive authenticator <- user typed
password
Single-monitor lock at 18:47:18: after the ping, nothing happens until 18:48:40
(key press), then success.
In every multi-monitor lock, kwin logs "Input method is trying to show itself
but without a context" 3 times, compared with once with a single monitor.
Suspected cause: plasma-desktop 6.8 LockScreenUi.qml added a 1-second heartbeat
that calls startAuthenticating() while uiVisible is true, and handleMessage()
now sets uiVisible = true. With one lock screen window per output, something on
the extra window seems to make uiVisible true at startup. The extra
input-method activation looks like the trigger, but this isn't confirmed.
--
You are receiving this mail because:
You are watching all bug changes.