Open LearnLinuxTV opened 6 years ago
Upon further testing, this bug appears to be due to the HiDPI daemon crash. Basically, GNOME is crashing at some point during either suspend or resume, and rather than seeing the lock screen, you're seeing the contents of the screen. I think at this point, we could probably either close this bug as it would probably be fixed when the GNOME crash with HiDPI daemon is fixed, or we can move this to system76-driver.
Just wanted to drop in and say this issue still persists on PopOS 19.04 with the following hardware (at least):
Lenovo X1 Extreme i7- 8750H 32GB RAM 2x 256GB SSD Nvidia 1050 Ti
Chiming in here as I'm also experiencing the same issue.
Distribution: Pop!_OS 22.04 LTS
Related Application and/or Package Version: Lock screen and suspend functionality
Issue/Bug Description: Sometimes after opening the lid and waking from suspend on my Dell Latitude 5430, the desktop and its contents are visible for about 5 seconds before the lock screen appears. During that time, I can move the mouse and try to click on things. For example, dock icons will be highlighted, but clicking on them doesn't do anything.
If I close the lid to where I can barely see the screen, I'm sometimes able to observe that the lock screen never engages and the system goes straight to suspend.
Steps to reproduce: Suspend and resume the computer. Doesn't happen every time, but maybe 20% - 50% of the time.
Expected behavior: On resume, only the lock screen should be displayed. It's a privacy and potential security risk for the desktop to be visible when the system is supposed to be locked.
Other Notes: I've tried adding a script to /lib/systemd/system-sleep/
that runs sleep 5
, xdg-screensaver lock
, and loginctl lock-sessions
with no success.
It was suggested here that the HiDPI Daemon could be the cause, but I uninstalled that package and this issue still occurs.
I do see this line in journalctl upon resume, but everything else looks normal:
/usr/lib/systemd/system-sleep/pop-default-settings_bluetooth-suspend failed with exit status 1.
I have noticed a pattern. After a reboot, the first suspend always seems to have issue. The lock screen never engages before suspend happens. The bluetooth script error doesn't appear either, only on subsequent suspends. Tried removing that bluetooth script, but it didn't make a difference.
If there are additional logs I could provide, I would be glad to do so.
I'm curious, are you able to reproduce this behavior if lock screen notifications are disabled? I haven't seen this on any of my systems in a while but fresh installs of Pop!_OS has this issue. The only thing I can think of that's different between my config and the default one is the lock screen notifications being disabled.
I'm curious, are you able to reproduce this behavior if lock screen notifications are disabled? I haven't seen this on any of my systems in a while but fresh installs of Pop!_OS has this issue. The only thing I can think of that's different between my config and the default one is the lock screen notifications being disabled.
Lock Screen Notifications are disabled by default for me.
Good to know. I've disabled mine a long time ago so it must've became default at some point later.
I've been having this problem for a while, exactly as described above. Running PopOS 22.04, but more concerning is that my computer actually unlocked. It showed the suspend screen, then the lock screen, then the desktop, and then I could click on things normally and use the system without putting a password. Like others have said, it seems to be only the first suspend after system boot. I will try disabling HiDPI.
@Rick1029 Even though that seems similar to this issue, I think it's probably something completely different. What does the command gsettings get org.gnome.desktop.lockdown disable-lock-screen
return? If you've been running Phoronix Test Suite, for example, that setting may have been activated to prevent the lock screen from interfering with any benchmark results.
I am seeing this on stock Adder WS, as shipped, with normal updates, no customization.
Hi!
I see this 100% of the time on my machines. It doesn't matter which GPU the machine is using I'm normally in "hybrid graphics", but I see this on my old macbook air 2011 with the same installation as well.
Steps to reproduce: 1.) Close laptop lid 2.) Open laptop lid, screen content's are live and fully visible for about 1-2 seconds. No interaction seems possible. 3.) desktop locks after about 2 seconds.
Linux speedbeans 6.8.0-76060800daily20240311-generic #202403110203~1714077665~22.04~4c8e9a0 SMP PREEMPT_DYNAMIC Thu A x86_64 x86_64 x86_64 GNU/Linux
ASUSTeK COMPUTER INC. ASUS TUF Gaming F15 FX506HM_FX506HM NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] / Mesa Intel® UHD Graphics (TGL GT1)
Secondary machine is an old macbook Air 2011 whith the same behavior
for completion, there is an "old" gnome GIT open.
Screen / desktop briefly visible on resume just before lock screen is activated https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3294
and even older, an old bugzilla. https://bugzilla.gnome.org/show_bug.cgi?id=753678
Just did a fresh install on a Dell Precision 5540 (i7-9750H, 32GB RAM, Quadro T1000), and I'm having the same issue.
Reporter info
Issue/Bug Description When you close the lid to suspend the laptop and then wake it up, the contents of the screen are visible briefly before the lock screen appears. This is a security/privacy risk, because the contents of the screen should not be visible until after the screen is unlocked.
Steps to reproduce (if you know)
Expected behavior The contents of the screen should not be visible until after the screen is unlocked
Other Notes Perhaps this is a race-condition? I'm assuming that the suspend event happens before the lock event, perhaps we should reverse that so the screen locks before the system suspends