Please try to switch to the xorg modesettings driver.

I've same problem, dual-head setup. ThinkPad x230 & OpenSUSE 42.1. Enabling modeset does not help
systool -m i915 -av
Module = "i915"

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

  Parameters:
    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"

For me the latest 5.8.1 update from opensuse fixed this problem.

I am currently able to reproduce this.

*** Bug 419142 has been marked as a duplicate of this bug. ***

*** Bug 421066 has been marked as a duplicate of this bug. ***

*** Bug 413387 has been marked as a duplicate of this bug. ***

*** Bug 419355 has been marked as a duplicate of this bug. ***

Quite a number of other users are experiencing the same issue, so at least I'm not crazy. :)

*** Bug 437471 has been marked as a duplicate of this bug. ***

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...

Removing pysolfc, qbittorrent and tidy didn't help.

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.

Packages for Plasma 5.18.7.1 were just released for me and seems to resolve the issue. I have input widgets on the lock screen again.

I have this bug wit KDE 5.22.4

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.

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:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

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!

The bug always there, even after upgrading to the last plasma desktop

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 5.18.7.1 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.

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).

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.

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.

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 5.18.7.1.

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?

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]

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]

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...

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?

(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.

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!

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.

(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.

This is X11 only AFAICT.

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?

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.

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.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1267

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.

*** Bug 451897 has been marked as a duplicate of this bug. ***

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...

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

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
fails.

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
sleep.

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

https://invent.kde.org/plasma/plasma-workspace/commit/6c56038777a4a327afd58fca2f5bcaf8fc3a0423