Bug 395583 - Cannot login after lock screen which went to sleep
Summary: Cannot login after lock screen which went to sleep
Status: RESOLVED UPSTREAM
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-18 21:08 UTC by Piotr Mierzwinski
Modified: 2020-10-01 17:56 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
journaictl (159.06 KB, text/plain)
2018-07-14 02:00 UTC, pointless
Details
journalctl on an openSUSE 15.2 system (69.28 KB, text/plain)
2020-10-01 09:12 UTC, Tristan Miller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Mierzwinski 2018-06-18 21:08:30 UTC
I locked screen manually by key shortcut. I left computer and started doing something else and after some time monitor went sleep. I back to computer to wake up it. I did it by moving of mouse, and in fact it woke up. I saw pretty screen. The issue was that login field was missing. I clicked in screen, moved mouse cursor but it didn't help. Only I saw pretty screen with date and time on top, but no login field. So how could I unlock my Plasma session?

I coped with this by some workaround, I mean just switching to text console (Ctrl+Alt+F2) and back to graphical mode (by Alt+F1). Thanks that I got login field and could unlock session.

kscreenlocker in version 5.13.0

I use: Plasma-5.13, Qt-5.11, KF-5.47
Linux distribution: up-to-dated Antergos
Comment 1 Nate Graham 2018-06-27 18:15:32 UTC
Weird, all of those input actions totally should have made the controls and password field appear. Any ideas, Marco?
Comment 2 Piotr Mierzwinski 2018-06-27 23:45:50 UTC
Maybe this is matter. My monitor is connected by DVI link. Additionally between monitor and DVI there is also adapter: HDMI->DVI. 
Issue not happens when I turn off monitor (when screen is locked), and on it again.
Comment 3 Ben Daines 2018-07-12 19:57:03 UTC
Same issue here.  Also Arch-based (Manjaro).  

It has nothing to do with your DVI adapter, as I'm seeing the same thing on a laptop with only an internal display.  Seems to unlock properly every time when opening the lid, but if the machine goes to sleep and is woken back up with the keyboard or power button plasma will fail to unlock.  

If the screen is locked, but the machine has not gone to sleep, there doesn't seem to be any issues unlocking. 

Being that both of us are running Arch, this may be an Arch issue.  However, I did not see anyone complaining about it on their forums, and there doesn't seem to be a bug report.  

Hopefully someone running a distro other than Arch can confirm this. 

Piotr, has this resolved itself with any subsequent updates?
Comment 4 Piotr Mierzwinski 2018-07-12 23:17:52 UTC
Hmmm. I tested this issue today and seems that all is fine.
I made the same test like previously. Only my monitor turned off itself. I turned it on and after moving mouse cursor I got proper field to enter password.

I don't know if this is Arch issue only because that users other distributions (not based on Arch) didn't reported. Please note that only you and me reported this. Where are others?
Also conditions of test changed, because I have up-to-date distribution. I suppose since time first test one have changed many software and of course I have newer Plasma (5.13.3), so kscreenlocker is newer. Additionally Qt is newer (5.11.1). I don't know where the problem was. 
To be sure that issue went away I will make next test later.
Comment 5 pointless 2018-07-14 02:00:22 UTC
Created attachment 113925 [details]
journaictl

Hi to all!

I confirm: exactly the same as Piotr Mierzwinski in his first paragraph wrote (https://bugs.kde.org/show_bug.cgi?id=395583#c0).

But I never know (so never tried) about hot keys he wrote. And I just reboot PC with partly unsaved work (it is long HEVC video encoding process - it is important to know if you will see my log files - and I need it console output) :(

Today the issue was the 3 or 4 time since about 5-July-2018. Manjaro KDE 17.1.11 (is was update from 17.1.10). I think besides others it was Plasma update also. I can provide full update log. Then I installed Manjaro 17.1.10 in the beginning of May-2018 the issue never happen (during 2 months) and effect starts only after update. So, I see that at least 1 time in every 4 days.

One more detail: if to move mouse over the screen I can see the moment there mouse pointer becomes a cursor (like under text field). So I tried to click in that point and to type password a few times and later after reboot I saw in journalctl logs that it was several login tries. So looks like password field is present but completely invisible in black background with black there mentioned below. Also I can not confirm that field is working cause my tries was failed to login.

What we need to do to help to trace and fix that very weird problem?

I can attach logs you want

After some idle time screen was waked up in 16:50 - this time was all 26 minutes before I reboot PC in 17:16 by reset btn on PC case.

As I saw that problem a few times I can saw that idle process before the issue can be 1 hour or 8 hours.

I am also have DVI monitor connected via passive (zero-power consumption) cable into HDMI-port of motherboard if it helps.

Poitr wrote:
> Issue not happens when I turn off monitor (when screen is locked), and on it again.
>
As about me than I never tried this.

I do not any of sleep/hibernate activity on my desktop PC (video coding, torrents, remote connection)

Poitr wrote:
>Please note that only you and me reported this. Where are others?
>
Noooo! And me also! I was too lazy to report it and have several weird discussions to use manjaro forum to report component bugs (but every GNU/Linux are all about components).

Also the issue eith lock screen does not appear constantly: it may be 10 successful lock and unlocks and eleventh unlock will be "broken".

So may be it is fixed in 5.13.3 but I still has 5.13.2.

Theme: Breeze Dark

kscreenlocker version via Octopi package manager: 5.13.2-1

KDE Plasma: 5.13.2
KDE Frameworks: 5.47.0
Qt: 5.11.1
Kernel: 4.14.53-1-MANJARO
OS type: 64-bit

CPU: Intel Celeron G1610 and I use it's GPU core without discrete video card.
RAM: 16 GB (reports as 15.4 GiB)

GNU/Linux disro: Manjaro KDE 17.1.11 - stable branch - is up-to-date.
Comment 6 Piotr Mierzwinski 2018-07-15 20:31:54 UTC
As I promised I made test, again. Twice.
Steps:
- lock screen (by key shortcut)
- leave computer till monitor will go sleep
- wake up it by moving mouse cursor
- try to unlock it through entering password into appearing proper field

I can say that I was able to unlock computer twice.
Of course working with up-do-dated Antergos.
Comment 7 pointless 2018-07-16 12:20:27 UTC
For me the issue was about 1 time in 10 locks. For now I can not reproduce it three times in a row also.
Comment 8 cantabile 2018-12-28 16:28:20 UTC
Hi. I have this problem too.

I can't tell what triggers it. Sometimes the lock screen works correctly, sometimes only the lock screen's background picture, the clock, and the mouse cursor will appear. I hibernate often, and I'm pretty sure that the lock screen always works correctly right after resuming from hibernation.

Even though the password input field doesn't appear, I can type the password to unlock the screen. I can tell it works even though the lock screen's background picture doesn't vanish, because after I press Enter the mouse cursor changes into I-beam if I left KWrite open, for example.

And of course the Ctrl-Alt-F2 followed by Ctrl-Alt-F1 workaround mentioned by the others works. Before or after I type the password.

A detail I didn't see mentioned above: one time when the lock screen was "malfunctioning", I left the computer alone for a few minutes, and noticed that the time displayed on the lock screen was not updated. It was stuck at whatever the time was when I first woke up the screen. So it's not just that the password input field and the button below it don't appear. The program's graphics seem to be frozen completely.

My system is an oldish laptop with "Intel Corporation Mobile GME965/GLE960 Integrated Graphics Controller".

The operating system is plain Arch Linux, currently running plasma-desktop 5.14.4-2, plasma-framework 5.53.0-1, qt5-base 5.12.0-1, xf86-video-intel 1:2.99.917+855+g746ab3bb-1, mesa 18.3.1-1. (But I've had this problem for months.)
Comment 9 Ben Daines 2018-12-29 04:41:21 UTC
(In reply to cantabile from comment #8)
> Hi. I have this problem too.
> 
> I can't tell what triggers it. Sometimes the lock screen works correctly,
> sometimes only the lock screen's background picture, the clock, and the
> mouse cursor will appear. I hibernate often, and I'm pretty sure that the
> lock screen always works correctly right after resuming from hibernation.
> 
> Even though the password input field doesn't appear, I can type the password
> to unlock the screen. I can tell it works even though the lock screen's
> background picture doesn't vanish, because after I press Enter the mouse
> cursor changes into I-beam if I left KWrite open, for example.
> 
> And of course the Ctrl-Alt-F2 followed by Ctrl-Alt-F1 workaround mentioned
> by the others works. Before or after I type the password.
> 
> A detail I didn't see mentioned above: one time when the lock screen was
> "malfunctioning", I left the computer alone for a few minutes, and noticed
> that the time displayed on the lock screen was not updated. It was stuck at
> whatever the time was when I first woke up the screen. So it's not just that
> the password input field and the button below it don't appear. The program's
> graphics seem to be frozen completely.
> 
> My system is an oldish laptop with "Intel Corporation Mobile GME965/GLE960
> Integrated Graphics Controller".
> 
> The operating system is plain Arch Linux, currently running plasma-desktop
> 5.14.4-2, plasma-framework 5.53.0-1, qt5-base 5.12.0-1, xf86-video-intel
> 1:2.99.917+855+g746ab3bb-1, mesa 18.3.1-1. (But I've had this problem for
> months.)

Just going to chime in and say this is the same behavior I am seeing too.  It will go for a good long while working, and then suddenly I'll start having issues again. 

Ctl+Alt+F2/1 fixes it as well.  I am also running intel graphics and Arch.
Comment 10 Kelvin Miller 2019-02-10 22:43:24 UTC
See this also on a fresh install of Manjaro KDE on a Surface Pro 4. This doesn't happen at all on my other laptop with KDE Neon. Here is my system information:

inxi -Fxzc0
System:
  Host: surface-p4 Kernel: 4.19.20-1-surface x86_64 bits: 64 
  compiler: gcc v: 8.2.1 Desktop: KDE Plasma 5.14.5 
  Distro: Manjaro Linux 
Machine:
  Type: Laptop System: Microsoft product: Surface Pro 4 
  v: D:0B:08F:1C:03P:38 serial: <filter> 
  Mobo: Microsoft model: Surface Pro 4 serial: <filter> 
  UEFI: Microsoft v: 108.2318.769 date: 08/14/2018 
Battery:
  ID-1: BAT1 charge: 34.1 Wh condition: 34.1/38.2 Wh (89%) 
  model: SMP X910527 status: Full 
CPU:
  Topology: Dual Core model: Intel Core i5-6300U bits: 64 
  type: MT MCP arch: Skylake rev: 3 L2 cache: 3072 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 19968 
  Speed: 500 MHz min/max: 400/3000 MHz Core speeds (MHz): 1: 500 
  2: 500 3: 500 4: 501 
Graphics:
  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Microsoft 
  driver: i915 v: kernel bus ID: 00:02.0 
  Display: x11 server: X.Org 1.20.3 driver: intel 
  unloaded: modesetting resolution: 2736x1824~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 520 (Skylake GT2) 
  v: 4.5 Mesa 18.3.2 direct render: Yes 
Audio:
  Device-1: Intel Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
  Processor Imaging Unit 
  driver: N/A bus ID: 00:05.0 
  Device-2: Intel driver: N/A bus ID: 00:14.3 
  Device-3: Intel Sunrise Point-LP HD Audio driver: snd_hda_intel 
  v: kernel bus ID: 00:1f.3 
  Sound Server: ALSA v: k4.19.20-1-surface 
Network:
  Device-1: Marvell 88W8897 [AVASTAR] 802.11ac Wireless 
  driver: mwifiex_pcie v: 1.0 port: 3000 bus ID: 02:00.0 
  IF: wlp2s0 state: up mac: <filter> 
Drives:
  Local Storage: total: 238.47 GiB used: 80.03 GiB (33.6%) 
  ID-1: /dev/nvme0n1 vendor: Samsung model: MZFLV256HCHP-000MV 
  size: 238.47 GiB 
Partition:
  ID-1: / size: 76.90 GiB used: 23.01 GiB (29.9%) fs: ext4 
  dev: /dev/nvme0n1p5 
  ID-2: swap-1 size: 7.81 GiB used: 0 KiB (0.0%) fs: swap 
  dev: /dev/nvme0n1p6 
Sensors:
  System Temperatures: cpu: 37.0 C mobo: 0.0 C 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 186 Uptime: 5h 26m Memory: 7.72 GiB 
  used: 1.64 GiB (21.3%) Init: systemd Compilers: gcc: 8.2.1 
  Shell: bash v: 5.0.0 inxi: 3.0.30
Comment 11 gomera 2019-03-18 21:43:14 UTC
I have the exactly same issue and I also notice that the lock screen was only rendered on the secondary display (and works if I move the mouse and give focus). On the primary one only the mouse is visible. I am using nvidia proprietary driver & plasma 5.13.5 (kubuntu 18.10). My primary display is connected with display-port (Asus monitor) and the secondary is HDMI (Samsung TV) Please let me know if you need any debug info I can provide. Thanks !
Comment 12 cantabile 2019-07-09 11:14:22 UTC
Shortly after I commented back in December 2018 I learned about the xorg modesetting driver. I removed xf86-video-intel and I've been using the modesetting driver ever since. This being Arch Linux, lots of packages got updated since then, so maybe the modesetting driver has nothing to do with it, but I haven't had this problem with the lock screen since then.
Comment 13 MrAndersen 2020-02-05 17:01:39 UTC
I am experiencing the same behavior as first poster. Password prompt don't show when returning after locking and screensaver. Switching terminal via CTRL-ALT-F2 and back to F1 works around the problem, and prompt is shown. I can also type my password and press enter, before switching terminal, and then I get back to my unlocked session.

I have had the problem for a long time now. I kind of just have lived with it, however having to do this terminal switching everytime I get back to my computer is beginning to be annoying. Also if I reboot my computer, the problem usually don't show right away, but after some time it starts again (I usually suspend-to-ram every day, and only reboot/poweroff when needed).

Running Manjaro with the latest updates on a Lenovo T430s with Intel graphics.

5.4.15-2-MANJARO #1 SMP PREEMPT Mon Jan 27 17:27:50 UTC 2020 x86_64 GNU/Linux

I'm not sure if I'm using xf86-video-intel driver (I have it installed) or the modesetting driver. Xorg.0.log indicates, that I'm using both, if that is possible:

[121263.291] (II) LoadModule: "intel"
[121263.291] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[121263.291] (II) Module intel: vendor="X.Org Foundation"
[121263.291]    compiled for 1.20.6, module version = 2.99.917
[121263.291]    Module class: X.Org Video Driver
[121263.291]    ABI class: X.Org Video Driver, version 24.0
[121263.291] (II) LoadModule: "modesetting"
[121263.291] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[121263.294] (II) Module modesetting: vendor="X.Org Foundation"
[121263.294]    compiled for 1.20.7, module version = 1.20.7
[121263.294]    Module class: X.Org Video Driver
[121263.294]    ABI class: X.Org Video Driver, version 24.1
[121263.294] (II) LoadModule: "fbdev"
[121263.294] (WW) Warning, couldn't open module fbdev
[121263.294] (EE) Failed to load module "fbdev" (module does not exist, 0)
[121263.294] (II) LoadModule: "vesa"
[121263.294] (WW) Warning, couldn't open module vesa
[121263.294] (EE) Failed to load module "vesa" (module does not exist, 0)
[121263.294] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
        i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
        915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
        Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
        GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[121263.295] (II) intel: Driver for Intel(R) HD Graphics
[121263.295] (II) intel: Driver for Intel(R) Iris(TM) Graphics
[121263.295] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
[121263.295] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[121263.295] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20190822
[121263.295] (II) intel(0): SNA compiled from 2.99.917-899-gf66d3954
[121263.312] (WW) Falling back to old probe method for modesetting
[121263.313] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4000
[121263.313] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx; using a maximum of 2 threads
[121263.313] (II) intel(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[121263.313] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[121263.313] (==) intel(0): RGB weight 888
[121263.313] (==) intel(0): Default visual is TrueColor
[121263.315] (II) intel(0): Output LVDS1 has no monitor section
[121263.316] (**) intel(0): Found backlight control interface intel_backlight (type 'raw') for output LVDS1
[121263.316] (II) intel(0): Enabled output LVDS1
[121263.316] (II) intel(0): Output VGA1 has no monitor section
[121263.316] (II) intel(0): Enabled output VGA1
[121263.316] (II) intel(0): Output HDMI1 has no monitor section
[121263.316] (II) intel(0): Enabled output HDMI1
[121263.316] (II) intel(0): Output DP1 has no monitor section
[121263.316] (II) intel(0): Enabled output DP1
[121263.317] (II) intel(0): Output HDMI2 has no monitor section
[121263.317] (II) intel(0): Enabled output HDMI2
[121263.317] (II) intel(0): Output HDMI3 has no monitor section
[121263.317] (II) intel(0): Enabled output HDMI3
[121263.317] (II) intel(0): Output DP2 has no monitor section
[121263.317] (II) intel(0): Enabled output DP2
[121263.317] (II) intel(0): Output DP3 has no monitor section
[121263.318] (II) intel(0): Enabled output DP3
[121263.318] (--) intel(0): Using a maximum size of 256x256 for hardware cursors
[121263.318] (II) intel(0): Output VIRTUAL1 has no monitor section
[121263.318] (II) intel(0): Enabled output VIRTUAL1
[121263.318] (--) intel(0): Output LVDS1 using initial mode 1600x900 on pipe 0
[121263.318] (==) intel(0): TearFree enabled
[121263.318] (==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
[121263.318] (==) intel(0): DPI set to (96, 96)
[121263.318] (II) Loading sub module "dri3"
--- snip ---
Comment 14 cantabile 2020-02-05 20:36:35 UTC
@MrAndersen:

It's using the intel driver. When the modesetting driver is used you get lots of lines with "modeset(0):" in them instead of "intel(0):".
Comment 15 MrAndersen 2020-02-15 10:00:02 UTC
After my last comment, I immediately uninstalled xf86-video-intel and just like cantabile, I haven't had the problems with the login screen since.

Also this article on ArchWiki states that KDE recommend NOT installing xf86-video-intel. I don't recall having installed it myself, but now that it's gone, I'm a happy camper. :)
https://wiki.archlinux.org/index.php/Intel_graphics#Installation
Comment 16 gdiamondfist 2020-02-22 12:01:27 UTC
I have the same problem as the first poster.  I locked the screen and came back after the monitor went to sleep I couldn't log in.  I hit the switch user button and it let me put in my credentials. The screen gave me the KDE symbol along with the spinning curser wheel which then stopped spinning.  I waiting and nothing happened.  I dropped to the console and found that the kscreenlocker process was taking 100% of my CPU.  
I am using Kubuntu 19.10 with backports turned on.  

Operating System: Kubuntu 19.10
KDE Plasma Version: 5.18.1
KDE Frameworks Version: 5.67.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-40-generic
OS Type: 64-bit
Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor
Memory: 31.3 GiB of RAM
Video card:  GeForce RTX 2080
Nvidia Driver:  440.59
kscreenlocker version:  5.18.1-0ubuntu1~ubuntu19.10~ppa1
Monitors: 3440x1440 (main monitor standard rotation)  1200x1920 (physically rotated 90 degrees clockwise.)
Comment 17 Tristan Miller 2020-09-07 09:38:28 UTC
I have the same problem as originally reported, except that switching to a text console and back again doesn't work around the issue.  That is, about 10% of the time when the screen locks, the login form doesn't appear when manipulating the mouse or keyboard.  The date and time displayed on the lock screen are frozen, but the mouse pointer can still be moved around the screen.  Switching to a text console works, but running htop doesn't reveal anything out of the ordinary.  Manually running "loginctl unlock-session n" (where n is the session number) has no effect.  Trying to force a logout using "qdbus org.kde.ksmserver /KSMServer logout 0 0 0" seems to work after a long delay (a minute or two) in that it looks like it shuts down the session and brings back the KDE login screen, but when you try to log in, the panel and desktop, and many other Plasma elements fail to appear, making the system almost unusable.

System details:

OS: openSUSE Leap 15.2 (64-bit)
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.71.0
Qt Version: 5.12.7
Kernel Version: 5.3.18-lp15236-default
Hardware: Acer TravelMate B115 netbook, which has an Intel ValleyView Gen7 graphics controller driving the built-in display

I'm happy to provide further information (logs, etc.) if someone tells me what is needed, though since the problem isn't reliably reproducible it might take me a while.
Comment 18 Tristan Miller 2020-10-01 09:12:02 UTC
Created attachment 132041 [details]
journalctl on an openSUSE 15.2 system

Attached is the output of journalctl on an openSUSE 15.2 system for the period when this bug occurs for me.  Here is a high-level timeline:

08:00:16 I suspend my computer by pressing the suspend key.

08:24:29 I wake up my computer.  The login screen appears but after typing the first couple characters of my password, the login screen becomes unresponsive.

08:24:42 I switch to tty1 and log in as root (and do the same on tty2) and then issue a shutdown -r command.

08:26:24 The system reboots.

Perhaps something in this log indicates what the problem might be.
Comment 19 Tristan Miller 2020-10-01 09:41:01 UTC
Downstream bug report for openSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=1177177
Comment 20 Tristan Miller 2020-10-01 14:59:42 UTC
With the help of the openSUSE developers I have discovered the cause of the lock screen freezing after resuming from suspend, at least on my computer.  The problem was not kscreenlocker but rather a recent regression in the X.Org xf86-video-intel driver.  This driver is known to cause issues when used with relatively modern graphics hardware (mine is from 2015), particularly with KDE Plasma, as detailed at <https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs>.  The solution for me was to uninstall the xf86-video-intel driver and instead use the modesetting driver (which is the default on most GNU/Linux distributions these days).

So any of you who are still suffering from this bug, please check if you are using the xf86-video-intel driver, and if so, try switching to the modesetting driver instead.  (Or conversely, if you are using the modesetting driver on a very old Intel graphics controller, try changing to xf86-video-intel.)  If this solution works for everyone, then the present bug report can be closed (as INVALID or UPSTREAM or whatever is appropriate).
Comment 21 Nate Graham 2020-10-01 17:56:11 UTC
Thanks for the update!