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
Weird, all of those input actions totally should have made the controls and password field appear. Any ideas, Marco?
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.
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?
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.
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.
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.
For me the issue was about 1 time in 10 locks. For now I can not reproduce it three times in a row also.
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.)
(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.
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
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 !
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.
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 ---
@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):".
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
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.)
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.
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.
Downstream bug report for openSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=1177177
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).
Thanks for the update!