After being idle, the screen was automatically locked.

A bit later, I entered my password to unlock, but I got a black
screen, then after some time, the lightdm prompt again. I tried
two other times. Same problem. I eventually rebooted the machine.

IIRC, this was the first time I got such a problem. I couldn't
reproduce it yet.

I couldn't find any error in the lightdm and journalctl logs.

found 913062 1.8.0-3
thanks

I also experience this problem.  It is intermittent, making it difficult
to reproduce, and it may or may not depend on specific hardware.

Switching to a VT and killing the light-locker process restores control
of the locked X session, _until_ the next time the XFCE attempts to lock
the screen, at which point the X session displays only a totally red
screen and is again completely unresponsive.  There is no light-locker
process running at that point.  At this point, the only way out of the
situation is to restart lightdm (or reboot).

A workaround is to simply not use light-locker.  I have not had this
issue since switching to xscreensaver.

------------------------------------------------------------------------
                    IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.

I think I have never reproduced this problem on any machine
(including the same machine, which I still use regularly).

In case this might depend on the driver, I was using the nvidia
driver (and I still use it on this machine).

I don't use a desktop environment (just fvwm as the window manager).

Control: retitle -1 light-locker: screen sometimes black on screensaver deactivation

This now occurs on a different machine (my laptop) from time to
time.

My laptop uses the nouveau driver. So this is not related to the driver.

It is possible to unlock by typing the password (while the screen is
still black), then reactivating the screen saver (I have a keyboard
shortcut to run "sleep 1 && xset dpms force off"), then moving the
mouse.

I'm going to turn on the debug messages to see whether there is a
difference when the problem occurs.

Unfortunately, light-locker does not output any debug message
when the screensaver stops (whether or not the bug has occurred).
The first debug messages are output after I type my password to
unlock.

light-locker does not do anything between the time it locks the
session and the time the session is unlocked by lightdm:

29410 13:02:31 poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}], 4, 27003) = 1 ([{fd=10, revents=POLLIN}])
29410 13:02:54 write(3, "\1\0\0\0\0\0\0\0", 8) = 8

Note: I moved the mouse at about 13:02:40, which showed the lightdm
greeter screen (the bug did not occur), and I typed my password at
about 13:02:50. The first debug message that occurred at 13:02:54
was from gs-listener-dbus.c (listener_dbus_handle_system_message).

I recall the issue:
1. The session is locked by light-locker.
2. Some time after, I move the mouse so that I can unlock the session.

But sometimes, after (2), the screen is entirely black (the backlight
is on, though) instead of displaying the lightdm greeter screen.

There's still something I don't understand: When the bug occurs, I can
type my password, which unlocks the session, but the screen remains
black, and from that, I can type C-M-. with my config, which does a
"sleep 1 && xset dpms force off", and after I move the mouse, I get
the correct display of my desktop back. So, since my password was
understood, I assume that the greeter screen was active, and this is
purely a display bug.

And since the screen remains black after the session is unlocked,
I don't see how this could be a lightdm or lightdm-gtk-greeter bug
(and lightdm alone does not have any issue).

I can see that before it locks the session, light-locker creates a
window on the full screen:

[2020-01-20 13:27:07] light-locker: [gs_manager_create_windows_for_screen] gs-manager.c:548 (13:27:07):  Creating 1 windows for screen 0
[2020-01-20 13:27:07] light-locker: [gs_manager_create_window_for_monitor] gs-manager.c:324 (13:27:07):  Creating window for monitor 0 [0,0] (3200x1800)
[...]
[2020-01-20 13:27:07] light-locker: [gs_window_move_resize_window] gs-window-x11.c:243 (13:27:07):       Move and/or resize window on monitor 0: x=0 y=0 w=3200 h=1800
[2020-01-20 13:27:08] light-locker: [gs_listener_send_lock_session] gs-listener-dbus.c:180 (13:27:08):   Send lock session

Perhaps the black screen is due to this window. More debug messages
would be useful. For instance, gs_manager_create_window_for_monitor()
has one for creation, but gs_manager_destroy_windows() doesn't have
any for destruction, so that one does not know anything about the
window at unlock time, and gs_window_real_visibility_notify_event()
doesn't either (the bug may be related to the window visibility).

What kernel do you use? It's likely related to the *Xorg* driver, which is
modesetting. A workaround has been added in the Linux kernel in unstable.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870641 for example
(sorry, this is a mess because everyone reported a new bug on various
packages).

Regards,

It was the kernel from Debian/unstable at the time I reported the
bug, and it still occurred with linux-image-5.4.0-3-amd64 5.4.13-1.

So it seems that this is not sufficient for me.

Note that in my case, the screen does not remain off (on my laptop,
backlight gets visible) but it is black. Moreover, this is not after
resume, but after locking while the machine is still running. IIRC,
I have not noticed any issue after resume on my laptop.

Hmhm ok. Just to check, do you see the “atomic disabled” message in the kernel
log?

Ok, then I honestly don't know.

Regards,

The whole journalctl log does not contain the word "atomic".

I have a similar bug on a laptop with both Intel UHD graphics and an NVidia
GPU.  Without Nvidia loaded, behavior on unlock is as expected.  With
nvidia modules loaded, even though not used for display, something is
disabling the display _after_ I unlock the screen (screen comes up from
sleep and is enabled until I unlock.   So not a driver issue I think.  I
don't think it's a black window either, because

chvt 7 && sleep 3 && xrandr -d :0 --output eDP-1 --auto

works to recover from it (from a console terminal). Something chooses to
disable output to the display, on _restore_.  I haven't found what it is
though.
(sleep 3 isn't necessary, just for my own sanity to see the pause and avoid
other races if chvt returns a bit early.)

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***