Bug 370676 - Greeter shows wallpaper, but no input widgets; cannot unlock screen
Summary: Greeter shows wallpaper, but no input widgets; cannot unlock screen
Alias: None
Product: kscreenlocker
Classification: Unclassified
Component: greeter (show other bugs)
Version: unspecified
Platform: Other Linux
: VHI critical
Target Milestone: ---
Assignee: Plasma Bugs List
Keywords: regression
: 413387 419142 419355 421066 (view as bug list)
Depends on:
Reported: 2016-10-13 18:18 UTC by Teemu Rytilahti
Modified: 2022-05-16 14:30 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25


Note You need to log in before you can comment on or make changes to this bug.
Description Teemu Rytilahti 2016-10-13 18:18:06 UTC
Sometimes there is no input widgets at all visible in the lock screen, requiring unlocking through loginctl. I have seen this happening for a while, but it's been possible to use "loginctl unlock-session" to get the desktop back.

However, although since the new lock screen / Plasma 5.8 doing unlock-session doesn't work anymore, unlock-session_s_ (plural) & inputing the root password lets me still access the desktop.

Reproducible: Sometimes

Steps to Reproduce:
1. Lock the screen
2. Realize that there's no place to input the password
3. Try to unlock through loginctl unlock-session

Actual Results:  
1. Unable to lock screen without swithing to console & calling loginctl unlock-sessions

Expected Results:  
In the best case there'd be password field for input (like it does now and then).
Even if not, loginctl unlock-session should unlock the session, without a need to resort to unlock-sessions which require root. (This part may be a mistake in my configuration though)

X.org, Intel, multihead setup:
[    37.213] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20160425
[    37.213] (II) intel(0): SNA compiled from 2.99.917-711-gbd33d0a
[    37.214] (WW) Falling back to old probe method for modesetting
[    37.214] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[    37.214] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4600
[    37.214] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx, avx2; using a maximum of 4 threads

Locking the screen + switching to VT + doing the unlock produces the following log:
[ 98198.863] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 98199.305] (II) systemd-logind: got pause for 13:72
[ 98199.305] (II) systemd-logind: got pause for 226:0
[ 98199.305] (II) systemd-logind: got pause for 13:85
[ 98199.305] (II) systemd-logind: got pause for 13:73
[ 98199.305] (II) systemd-logind: got pause for 13:81
[ 98199.305] (II) systemd-logind: got pause for 13:66
[ 98199.305] (II) systemd-logind: got pause for 13:65
[ 98199.305] (II) systemd-logind: got pause for 13:67
[ 98199.305] (II) systemd-logind: got pause for 13:70
[ 98199.305] (II) systemd-logind: got pause for 13:74
[ 98199.305] (II) systemd-logind: got pause for 13:80
[ 98199.305] (II) systemd-logind: got pause for 13:69
[ 98199.305] (II) systemd-logind: got pause for 13:64
[ 98199.305] (EE) xf86OpenSerial: Cannot open device /dev/input/event17
        Permission denied.
[ 98199.305] (WW) synaptics: SynPS/2 Synaptics TouchPad: cannot open input device
[ 98199.305] [dix] couldn't enable device 15
[ 98209.093] (II) systemd-logind: got resume for 13:72
[ 98209.093] (II) systemd-logind: got resume for 226:0
[ 98209.093] (II) Open ACPI successful (/var/run/acpid.socket)
[ 98209.093] (II) AIGLX: Resuming AIGLX clients after VT switch
[ 98209.093] (II) intel(0): switch to mode 2560x1440@60.0 on DP2-1 using pipe 1, position (0, 0), rotation normal, reflection none
[ 98209.153] (II) intel(0): switch to mode 1920x1200@60.0 on DP2-2 using pipe 2, position (2560, 0), rotation normal, reflection none
[ 98209.455] (EE) intel(0): sna_mode_shutdown_crtc: invalid state found on pipe 0, disabling CRTC:26
[ 98210.605] (II) systemd-logind: got resume for 13:85
[ 98210.605] (II) systemd-logind: got resume for 13:73
[ 98210.605] (II) systemd-logind: got resume for 13:81
[ 98210.605] (II) systemd-logind: got resume for 13:66
[ 98210.606] (II) systemd-logind: got resume for 13:65
[ 98210.606] (II) systemd-logind: got resume for 13:67
[ 98210.606] (II) systemd-logind: got resume for 13:70
[ 98210.606] (II) systemd-logind: got resume for 13:74
[ 98210.606] (II) systemd-logind: got resume for 13:80
[ 98210.607] (II) systemd-logind: got resume for 13:69
[ 98210.607] (II) systemd-logind: got resume for 13:64

Archlinux with recent Plasma.
Plasmashell: 5.8.1 (missing version btw)
Comment 1 Martin Flöser 2016-10-14 05:26:33 UTC
Please try to switch to the xorg modesettings driver.
Comment 2 Tommi Tervo 2016-10-17 07:43:38 UTC
I've same problem, dual-head setup. ThinkPad x230 & OpenSUSE 42.1. Enabling modeset does not help
systool -m i915 -av
Module = "i915"

    coresize            = "1204224"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "8"
    srcversion          = "17F9DEDA72F2C053AD17DFB"
    taint               = ""
    uevent              = <store method only>

    disable_display     = "N"
    disable_power_well  = "1"
    disable_vtd_wa      = "N"
    enable_cmd_parser   = "1"
    enable_execlists    = "0"
    enable_fbc          = "-1"
    enable_hangcheck    = "Y"
    enable_ips          = "1"
    enable_ppgtt        = "1"
    enable_psr          = "0"
    enable_rc6          = "3"
    fastboot            = "N"
    invert_brightness   = "0"
    load_detect_test    = "N"
    lvds_channel_mode   = "0"
    lvds_downclock      = "0"
    lvds_use_ssc        = "-1"
    mmio_debug          = "0"
    modeset             = "1"
    nuclear_pageflip    = "N"
    panel_ignore_lid    = "1"
    prefault_disable    = "N"
    preliminary_hw_support= "1"
    reset               = "Y"
    semaphores          = "-1"
    use_mmio_flip       = "0"
    vbt_sdvo_panel_type = "-1"
    verbose_state_checks= "Y"
Comment 3 Tommi Tervo 2016-10-19 14:13:22 UTC
For me the latest 5.8.1 update from opensuse fixed this problem.
Comment 4 Nate Graham 2021-06-21 22:20:12 UTC
I am currently able to reproduce this.
Comment 5 Nate Graham 2021-06-21 22:20:43 UTC
*** Bug 419142 has been marked as a duplicate of this bug. ***
Comment 6 Nate Graham 2021-06-21 22:21:29 UTC
*** Bug 421066 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2021-06-21 22:56:54 UTC
*** Bug 413387 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2021-06-21 23:07:16 UTC
*** Bug 419355 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2021-06-21 23:07:37 UTC
Quite a number of other users are experiencing the same issue, so at least I'm not crazy. :)
Comment 10 Nate Graham 2021-06-21 23:08:43 UTC
*** Bug 437471 has been marked as a duplicate of this bug. ***
Comment 11 Duns 2021-08-05 07:45:01 UTC
Until yesterday on a new laptop with kde neon I had not this bug. 
Today I have.
I don't know if after some my new installation (pysolfc? tidy? qbiottorrent?) of after upgrading something...
Comment 12 Duns 2021-08-05 07:53:08 UTC
Removing pysolfc, qbittorrent and tidy didn't help.
Comment 13 Wedge009 2021-08-05 13:18:33 UTC
Also within the last 24 hours, I had a number of components upgraded (via Kubuntu PPA on Focal LTS) from Plasma 5.18.4/5 to 5.18.7. Since then I also find the same behaviour: upon locking the screen, am unable to see anything besides the wallpaper and mouse cursor, and neither key presses nor mouse clicks will do anything to bring up any input widgets, etc. Until I remembered how to use loginctl again, I had no choice but to reboot to regain control of my system.

I note this happens on all my machines that are running Kubuntu LTS that have updated to Plasma 5.18.7. Kubuntu Hirsute, running Plasma 5.22.4, doesn't have this issue. Odd.
Comment 14 Wedge009 2021-08-06 01:43:08 UTC
Packages for Plasma were just released for me and seems to resolve the issue. I have input widgets on the lock screen again.
Comment 15 Duns 2021-08-07 09:52:52 UTC
I have this bug wit KDE 5.22.4
Comment 16 Nate Graham 2021-08-18 15:34:38 UTC
FWIW I am no longer able to reproduce this issue with current git master, after being able to for the entirety of the Plasma 5.22 cycle.

For any of you who are able to reproduce the issue and are comfortable with unstable software, would you be able to use the latest git master KDE software from your distro's "Unstable KDE" repos and see if it's fixed for you too? That would be much appreciated.
Comment 17 Bug Janitor Service 2021-09-02 04:36:07 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 18 Duns 2021-09-02 06:05:02 UTC
The bug always there, even after upgrading to the last plasma desktop
Comment 19 Wedge009 2021-09-02 06:23:07 UTC
I think they need more information than that. Nate indicates it's no longer a problem for him. I confirm it's not an issue with Plasma nor 5.22.4 on (K)Ubuntu. You mentioned KDE Neon before - is it possible to try a fresh installation and see what happens? I generally find a reliable means to replicate the problem would be a good starting point - cannot easily diagnose an issue that one cannot replicate.
Comment 20 Duns 2021-09-02 06:39:13 UTC
Here my pc:

Operating System: KDE neon 5.22
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.3
Kernel Version: 5.11.0-27-generic (64-bit)
Graphics Platform: X11
Processors: 2 × Intel® Core™ i3-7100 CPU @ 3.90GHz
Memory: 7,7 GiB of RAM
Graphics Processor: GeForce GT 710/PCIe/SSE2

To replicate this bud I have only to give the screen-lock command (in my case meta+l): I see the correct slideshow, but no way to get rid of it: no field for password (nor time).
Comment 21 Duns 2021-09-02 06:40:49 UTC
Fresh installation? I did it on a laptop, and initially all was good, but after a while the bug rise even there. And even on other 3 my pc with kde neon.
Comment 22 Wedge009 2021-09-02 06:43:31 UTC
I meant how to replicate from a clean installation, since neither Nate nor I - and presumably no-one else right now - can replicate the issue still.
Comment 23 Wedge009 2021-09-02 06:50:50 UTC
Perhaps it's worth checking what you have installed for the plasma-workspace and/or libkworkspace5-5 packages. The issue for me was introduced with 5.18.7 and went away with
Comment 24 Duns 2021-09-02 06:58:33 UTC
OK, thanks. But how can I get a (text) list of that packages?
I see in Synaptic but a screenshot doesn't seem a good idea, does it?
Comment 25 Duns 2021-09-02 07:03:49 UTC
apt list --installed | grep plasma-workspace

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

plasma-workspace-wallpapers/focal,focal,focal,now 4:5.22.5-0xneon+20.04+focal+release+build31 all [installed,automatic]
plasma-workspace-wayland/focal,now 4:5.22.5-0xneon+20.04+focal+release+build43 amd64 [installed,automatic]
plasma-workspace/focal,now 4:5.22.5-0xneon+20.04+focal+release+build43 amd64 [installed,automatic]
Comment 26 Duns 2021-09-02 07:04:38 UTC
apt list --installed | grep libkworkspace5-5

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libkworkspace5-5/focal,now 4:5.22.5-0xneon+20.04+focal+release+build43 amd64 [installed,automatic]
Comment 27 Nate Graham 2021-09-02 15:28:09 UTC
If you can't reproduce it on installation, but then it comes back later. then there is definitely some transient condition that causes it. Even though I cannot reproduce the issue now, that's what I was experiencing too. It comes and goes. For me it's been gone for a while, but I guess this means it may come back...
Comment 28 Nate Graham 2021-09-14 15:16:13 UTC
For anyone affected: do you have a locally-installed copy of the Breeze global theme in ~/.local/share/plasma/look-and-feel/org.kde.breeze.desktop?

If so, does the problem go away if you delete it?
Comment 29 Duns 2021-09-14 16:02:32 UTC
(In reply to Nate Graham from comment #28)
> For anyone affected: do you have a locally-installed copy of the Breeze
> global theme in ~/.local/share/plasma/look-and-feel/org.kde.breeze.desktop?
> If so, does the problem go away if you delete it?

Unfortunately, no, I don't.
Comment 30 Duns 2021-09-14 16:40:35 UTC
But, indeed, copying the folder /usr/share/plasma/look-and-feel/org.kde.breeze.desktop from Kubuntu (where ther is no this bug) to KDE Neon (/usr/share/plasma/look-and-feel/org.kde.breeze.desktop), fixed the problem!
Thank you very much!
Comment 31 Matthew 2021-11-17 16:34:48 UTC
I am able to consistently reproduce this on debian with kde-plasma-desktop by pressing TAB.

Typically clicking or pressing ESC will toggle the display of the password field, but once TAB has been pressed this behavior no longer does anything.
Comment 32 Méven Car 2021-12-08 08:58:19 UTC
(In reply to Nate Graham from comment #28)
> For anyone affected: do you have a locally-installed copy of the Breeze
> global theme in ~/.local/share/plasma/look-and-feel/org.kde.breeze.desktop?
> If so, does the problem go away if you delete it?

I reproduced it, I don't have  a ~/.local/share/plasma/look-and-feel/org.kde.breeze.desktop file, not even a ~/.local/share/plasma folder.
Comment 33 Méven Car 2021-12-08 10:08:30 UTC
This is X11 only AFAICT.
Comment 34 Matthew 2021-12-09 17:19:58 UTC
when running $  /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet --testing
the output contained

file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/VirtualKeyboard.qml:23:1: Type InputPanel unavailable
qrc:/QtQuick/VirtualKeyboard/content/InputPanel.qml:127:5: Type Keyboard unavailable
qrc:/QtQuick/VirtualKeyboard/content/components/Keyboard.qml:38:1: module "QtQuick.VirtualKeyboard.Plugins" is not installed

After installing https://packages.debian.org/sid/qtvirtualkeyboard-plugin the problem has resolved for me. Is the an optional dependency which should be required?
Comment 35 Nate Graham 2021-12-09 17:30:26 UTC
OK, so it looks like that's a mandatory dependency. If it's marked as such in our CMake code, then the problem is on the distro side. If not, it's our problem and we should mark it as a mandatory dependency, since it apparently is required or else the screen locker breaks.
Comment 36 Nate Graham 2021-12-09 18:13:32 UTC
Indeed it's our fault. I'll fix it.

Now it makes sense why it only affects X11 too, since the file that imports the Qt Virtual Keyboard module is only used on X11; on Wayland, we use a different thing.

Merge Request incoming.
Comment 37 Bug Janitor Service 2021-12-09 18:14:59 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1267
Comment 38 nyanpasu64 2022-03-10 01:47:20 UTC
I think qtvirtualkeyboard-plugin doesn't so much "fix" kscreenlocker but workaround the bug. Pressing Tab leaves the entire screen invisible, but once you move your mouse, the virtual keyboard button (not the password field) is focused, and typing your password does nothing. I think this is a bug in of itself.

The bug lies in Qt Quick, where pressing Tab when *all* focusable items have invisible *parents* hangs the app. Installing the virtual keyboard causes kscreenlocker to add an extra button which itself becomes invisible while its parent remains visible (https://invent.kde.org/plasma/plasma-workspace/-/blob/0d491641f3ea148417283819994228aab6896041/lookandfeel/contents/lockscreen/LockScreenUi.qml#L523-535). This coincidentally avoids the condition necessary to trigger the Qt Quick hang bug. The upstream bug reports are:

- I reported https://bugreports.qt.io/browse/QTBUG-96762 (marked as duplicate of below)
- https://bugreports.qt.io/browse/QTBUG-87190 (unfixed)

Qt Quick has a long history of tab focus bugs:

- https://bugreports.qt.io/browse/QTBUG-81839 (marked as duplicate of below)
- https://bugreports.qt.io/browse/QTBUG-81510 (fixed in 5.14.2 and 5.15.0)
- https://bugreports.qt.io/browse/QTBUG-65943 (unfixed)
- https://bugreports.qt.io/browse/QTBUG-59181 (fixed in 5.12.0)

(And Qt Widgets has scenarios where Tab followed by Shift+Tab doesn't return to the starting widget, which is less severe than a hang. Tab navigation is hard.)

Idea: When the password entry is hidden, intercept Tab presses and treat it like moving the mouse (show the lock screen and focus the password field), rather than letting Qt search for an item to focus. When the password entry is shown, let Tab switch widgets as usual.
Comment 39 Nate Graham 2022-04-01 03:09:35 UTC
*** Bug 451897 has been marked as a duplicate of this bug. ***
Comment 40 nyanpasu64 2022-05-07 00:12:15 UTC
https://github.com/qt/qtdeclarative/commit/e74bcf751495d9fe27efd195bc04e2a6ae6732a4 purportedly fixes this bug (https://bugreports.qt.io/browse/QTBUG-87190) in Qt 6. However kscreenlocker is still on Qt 5. Should this be cherry-picked to https://invent.kde.org/qt/qt/qtdeclarative/-/tree/kde/5.15 or not (now or once it's released in a stable Qt 6.x patch)?

I still think kscreenlocker's behavior could be improved with or without the Qt bug fixed, and with or without virtual keyboard support installed. See my previous comment. I might get around to implementing it at some point...
Comment 41 Nate Graham 2022-05-09 15:38:14 UTC
Might be good to backport that indeed. You can submit a backport request: https://community.kde.org/Qt5PatchCollection#How_do_I_get_a_patch_merged.3F
Comment 42 Nate Graham 2022-05-16 14:30:57 UTC
Git commit 6c56038777a4a327afd58fca2f5bcaf8fc3a0423 by Nate Graham, on behalf of David Edmundson.
Committed on 16/05/2022 at 14:30.
Pushed by ngraham into branch 'master'.

Fix loading the lockscreen fallback UI

kscreenlocker has a fallback UI loaded if the main QML from the LNF

As the main code is in a loader the lockscreen /always/ loads even if
the main contents can't be loaded. It also
contributes to a black flicker when loading the lockscreen.

The rationale for the loader was to make the window appear faster. This
hopefully isn't needed now we have the logind integration delaying the

If it turns out this is feature desired it would be far more productive
to do this in the greeterapp c++ code. Show an empty QtQuick window and
then set the source on it later. It'd be far faster which would help towards 
the original goal and allow us to check the loading.

This patch also removes the opacity fade as there's already an opacity
fade on contents when one moves the mouse when the "screensaver" like
code looks smoother.
FIXED-IN: 5.25

M  +2    -28   lookandfeel/contents/lockscreen/LockScreen.qml