Gala: Only Cursor Visible on Log In after suspend

Created on 4 May 2021  Â·  34Comments  Â·  Source: elementary/gala

What Happened

The following behavior does not happen always. It happens approximately once in five times even in a clean install.

On closing the laptop lid, elementary OS (referred to as eOS hereafter) is set to suspend (default). On closing the lid, eOS suspends normally. On opening the lid, the eOS resumes and shows me the login greeter.

On logging in, I am greeted with a black screen with the mouse pointer moving when I use the trackpad. None of the windows are visible, no wingpanel, no plank, nothing but only a black screen with a Mouse Pointer.

When I use three-finger up gesture, I see the multitasking view open, all the windows are displayed as usual in multitasking view. Once I close multitasking view (three-finger down) again the screen turns black with only the mouse pointer visible.

Keyboard shortcuts like ⌘ + S for multitasking view also do not work

Expected Behavior


On logging in, I am greeted with a black screen with the mouse pointer moving when I use the track-pad. None of the windows are visible, no wingpanel, no plank, nothing but only a black screen with a Mouse Pointer instead of how eOS normally works.

No such issue persisted in Elementary OS 5 (Hera)

Steps to Reproduce

The following behavior does not happen always. It happens approximately once in five times even in a clean install.

  1. Close the lid, eOS automatically suspends
  2. Open the lid, Login Greeter is displayed
  3. Enter your credentials and login, A Black screen with only a mouse pointer is visible and only track-pad gestures work

On logging in,

image

On using three-finger up touchpad gesture, (⌘ + S does not work)

image

On closing multitasking view (three finger down),

image

I tried killing gala using htop in tty6 (Ctrl + Alt + F6) and retured to tty7. On doing this, I observed that all windows were visible no black screen (Of course, the windows were misaligned and I could not use the apps as I killed gala). I did not try restarting gala as I neither could open a terminal in tty7 due to the black screen on login nor did I try it using the CLI in tty6 as I did not know how to.

Logs


Trying to fetch gala logs.

Platform Information


Operating System: elementary OS 6
Edition: (Public Beta)
Hardware Information:

  • Quad-Core Intel® Coreâ„¢ i5-8250U CPU @ 1.60GHz
  • Intel® UHD Graphics 620 (Kabylake GT2)
  • 7.7 GiB memory
  • 467.2 GB storage (SSD)
  • Laptop Information: HP Pavilion x360

    Confirmed High

    Most helpful comment

    When afflicted by this issue, I discovered I can mouse to the top-right corner (assuming the gesture is setup) and reveal Multi-tasking view which allows me to close applications. Then Ctrl+Alt F2 for a terminal login, login, and sudo reboot instead of forcing a shutdown. This should reduce chances of disk corruption.

    All 34 comments

    Found that someone else also has the same issue, check out issue https://github.com/elementary/gala/issues/1064.

    Thanks for the report! This is something I haven't been able to reproduce, but hopefully you'll be able to gather some more info to help track it down.

    It should be possible to restart gala from the TTY after killing it by running:

    DISPLAY=:0 gala &
    

    Next time this happens, could you gather some logs with:

    journalctl | grep gala
    

    Sure @davidmhewitt, I am glad to help and I will gather the logs and post it here the next time this issue occurs.
    The issue does not occur every time I suspend but, in 2 days (after Clean Install eOS 6 Public Beta) the issue persisted 5 times.

    Approximately, On suspending 15 times, the issue occurs at least 5 times.

    Thanks for the report! This is something I haven't been able to reproduce, but hopefully you'll be able to gather some more info to help track it down.

    It should be possible to restart gala from the TTY after killing it by running:

    DISPLAY=:0 gala &
    

    Next time this happens, could you gather some logs with:

    journalctl | grep gala
    

    Hi there @davidmhewitt,
    There's a stunning discovery I've made in regards to this issue.

    • This issue as mentioned above does not happen randomly
    • The steps to reproduce the issue is listed again below

    Steps to Reproduce

    Taking tty7 as the default GUI interface in eOS,

    1. Turn On your computer running elementary OS 6 (Public Beta)
    2. Login when the greeter is displayed, everything works as expected
    3. Now Ctrl + Alt + F6 to switch to tty6
    4. Login to tty6, execute some command (I used htop)
    5. Switch to tty7 and use the GUI to suspend (or close the laptop lid) [Do not type exit or logout in tty6 to close tty6]
    6. On opening the lid, the login greeter displays, Login with your credentials
    7. Boom! You will be seeing the issue now

    Logs

    Download the Log File Here

    I can't reproduce the issue by following those steps exactly. I tried both suspending from the GUI and by closing the laptop lid. The system resumed correctly in both cases.

    There's nothing obvious in your logs either.

    You could try the following to get some more in-depth debug logs:

    1. Edit /usr/share/applications/gala.desktop
    2. Change the Exec=gala line to:
    Exec=env G_MESSAGES_DEBUG=all gala
    
    1. Reboot the computer
    2. Reproduce the issue
    3. Gather logs again with journalctl | grep gala

    I can't reproduce the issue by following those steps exactly. I tried both suspending from the GUI and by closing the laptop lid. The system resumed correctly in both cases.

    There's nothing obvious in your logs either.

    You could try the following to get some more in-depth debug logs:

    1. Edit /usr/share/applications/gala.desktop
    2. Change the Exec=gala line to:
    Exec=env G_MESSAGES_DEBUG=all gala
    
    1. Reboot the computer
    2. Reproduce the issue
    3. Gather logs again with journalctl | grep gala

    I forgot to mention something in step 6 (Steps to reproduce), writing them here again:

    Steps to reproduce

    Taking tty7 as the default GUI interface in eOS,

    1. Turn On your computer running elementary OS 6 (Public Beta)
    2. Login when the greeter is displayed, everything works as expected
    3. Now Ctrl + Alt + F6 to switch to tty6
    4. Login to tty6, execute some command (I used htop)
    5. Switch to tty7 and use the GUI to suspend (or close the laptop lid) [Do not type exit or logout in tty6 to close tty6]
    6. On opening the lid, the login greeter displays, Login with your credentials Switch to tty6 and then to tty7
    7. Boom! You will be seeing the issue now

    Thanks, I can reproduce this now. There are definitely some broken things, but seeing a black screen on tty7 before unlocking is kind of expected.

    The greeter runs on tty8, so tty7 should be "locked" until you put your password in. It's clearly not locked well enough since you can use gestures and hotcorners etc.

    But also, after I unlocked the session in tty8, the unlocked session in tty7 was kind of broken too.

    Thanks for this, at least I can now reproduce these issues for testing and development. I'll keep this updated as I find/fix things.

    Thanks, I can reproduce this now. There are definitely some broken things, but seeing a black screen on tty7 before unlocking is kind of expected.

    The greeter runs on tty8, so tty7 should be "locked" until you put your password in. It's clearly not locked well enough since you can use gestures and hotcorners etc.

    But also, after I unlocked the session in tty8, the unlocked session in tty7 was kind of broken too.

    Thanks for this, at least I can now reproduce these issues for testing and development. I'll keep this updated as I find/fix things.

    Welcome @davidmhewitt

    @davidmhewitt, Another additional piece of information related to this problem. After the display in elementary OS 6 dims automatically on timeout, the greeter is displayed on cursor movement. When I log in the same issue of a black screen with a cursor occurs.

    By Auto-Dimming, I refer to the turn off display when inactive for setting Switchboard Power Plugin:
    Screenshot from 2021-05-25 12 30 38

    So for anyone else wanting to test this;
    The prerequisites are:

    • System Settings > Power > 'Turn display off when inactive for' has to be set to something lower than the suspend time
    • System Settings > Security & Privacy > Locking > 'Lock after screen turns off' has to be on

    To reproduce:

    1. Wait until the display turns off from inactivity
    2. Wake the display and log in

    You now should be stuck in a session where the normal desktop view is blocked, apart from when using the multitasking view gesture. I haven't been able to get it to recognise keyboard input (incl. power or suspend)

    Edit: @candiedoperation are you also able to reproduce this by locking manually with ctrl+L?


    @davidmhewitt From some speculation I already had on this issue over the last half-year (?) before seeing this issue and realising its cause, I may have an idea of the logical problem causing it;
    the issue seems to be the fading to black effect being 'frozen' because the system locks itself in sync with that effect, meaning that it never 'resets' its opacity and function - so maybe anyone willing could take a look at how the fade-out effect starts and stops

    nevermind it seems to be linked to the screen shield directly, since locking manually and closing the lid can trigger it too (albeit inconsistently)

    This is still present in the final version
    You could focus here, it is a critical issue
    @danrabbit @cassidyjames

    Problem seen on a thinkpad x1
    log.txt

    Happens on my Lenovo Yoga 370 as well.
    Core i5 7th Gen
    8GB RAM

    Happens on my MSI Creator 17m
    CPU: Intel i7-10750H
    GC: NVIDIA GeForce GTX 1660 Ti Mobile

    I faced the exact same issue on the latest odin stable build as well. Had to force reboot my laptop

    My laptop

    MSI GF63 thin 9SC
    9th gen intel i5
    NVIDIA GeForce GTX 16650 Max Q
    Nvidia Drivers 470 (latest)

    When afflicted by this issue, I discovered I can mouse to the top-right corner (assuming the gesture is setup) and reveal Multi-tasking view which allows me to close applications. Then Ctrl+Alt F2 for a terminal login, login, and sudo reboot instead of forcing a shutdown. This should reduce chances of disk corruption.

    Happening in my Dell Inspiron-15-3573.

    So, it seems that the steps I gave below are not working for all the people; Hence I have crossed it out. I did not change anything but this to fix the issue but I will check and see if that isn’t the case and update it here.

    Experiencing the same issue with my HP Envy x360.

    But I wanted a temporary fix and found this thread regarding Freya https://elementaryos.stackexchange.com/a/591~~

    • Run sudo -i vim /etc/default/acpi-support
    • Find and change POST_VIDEO=true to POST_VIDEO=false
    • Find and change SAVE_VBE_STATE=true to SAVE_VBE_STATE=false
    • Restart your laptop, issue should be solved.
      So far, after updating the above values, I have not encountered the issue again. Hopefully, it is fixed within gala itself.

    Before someone tries the above method, I am basing the result solely of my experience; I am not sure how the issue is related to warm-booting video hardware or VESA BIOS extentions never having worked on gala

    @ameyrk99 that didn't work for me unfortunately.

    @JoseExposito Do you have any idea what might be going on here?

    The steps described in https://github.com/elementary/switchboard-plug-power/issues/200 seem to consistently reproduce this problem on my machine (XPS 9500). Thanks @tomaswarynyca for pointing me at this issue.

    Experiencing the same issue with my HP Envy x360.

    But I wanted a temporary fix and found this thread regarding Freya https://elementaryos.stackexchange.com/a/591

    * Run `sudo -i vim /etc/default/acpi-support`
    
    * Find and change `POST_VIDEO=true` to `POST_VIDEO=false`
    
    * Find and change `SAVE_VBE_STATE=true` to `SAVE_VBE_STATE=false`
    
    * Restart your laptop, issue should be solved.
    

    So far, after updating the above values, I have not encountered the issue again. Hopefully, it is fixed within gala itself.

    Before someone tries the above method, I am basing the result solely of my experience; I am not sure how the issue is related to warm-booting video hardware or VESA BIOS extentions never having worked on gala

    Not working for me (X1 carbon), bug still here

    I identified an issue within the power settings pane that meant if you opened that and changed a setting within there, the next unlock would result in these symptoms. However, I'm still struggling to reproduce this issue under "normal" circumstances.

    Anyone that can reproduce this reliably, please do the following:

    • Reboot
    • Without doing anything else first, trigger the issue (i.e. try to unlock and see the blank screen with cursor)
    • Switch to a TTY with Ctrl+Alt+F1
    • Login
    • Run sudo journalctl > ~/log.txt
    • Reboot
    • Upload log.txt from your home folder to this issue.

    log.txt
    log2.txt
    Hi,

    Log1 :
    Here are my log. Opened my computer at 22:32 after a day of working. It was in sleep and crashed. Did ctrl alt F1 and ctrl alt suppr to reboot directly after. on this crash I was with this options still on : " POST_VIDEO=true to POST_VIDEO=false..."
    I changed my power settings after the clean install of the OS, but I do not remember the default settings to test.

    I have :
    *Auto brightness on,
    *sleep when closing the lid
    *when closed with external screen : no action (very clever setting!)
    *on battery and AC : 30min sleep if in active

    Log2 : after testing the brightness bug (brightness up and down till no change possible on the screen) , I closed my laptop and opened it. This reproduced the sleep bug.

    @alfredit Thanks!

    Have you cut the end of the first log in some way, or is that where it ended? From the first one, it looks like you didn't attempt to unlock? Did the system crash before you could unlock? Because that's different again.

    I also don't need logs when the bug happens immediately after changing settings/brightness in the power settings, as that will soon be fixed.

    I need logs from when you wake the system, unlock by entering password and then the screen is blank (except the mouse cursor), like the issue description.

    Hi,

    *Log1, In fact I remember telling me "oh crap" and rebooted the coputer too quickly before the big black screen. My journalctl is
    kind of big and with too much personal stuff so I grep it on the good dates.

    *log2 , did the unlock, seen the black screen with "expose" bug, exported log via journalctl and rebooted. Think log 2 is way more clean to check

    *I have installed the patch about the brightness bug released 2 min ago on my repo (the power setting update) and since those 2 are linked together, I will check if I can reproduce the sleep bug or if it is resolved.

    I can't reproduce this all the time but it does happen reasonably often. I collected the journalctl log and just limited it to the bit after Lid closed. I hadn't set gala to log debug messages so not sure if there's anything useful. Killing gala from tty1 made things mostly come back (it restarted by itself).

    Hi @davidmhewitt , for me the latest update resolved the issue (or I cannot manage to reproduce it anymore). Thanks for your help.

    @nathanaelg , can you check for the latest updates and see if it is okay now? looking for this one : switchboard-plug-power:amd64.

    I can't reproduce this all the time but it does happen reasonably often. I collected the journalctl log and just limited it to the bit after Lid closed. I hadn't set gala to log debug messages so not sure if there's anything useful. Killing gala from tty1 made things mostly come back (it restarted by itself).

    @nathanaelg Thanks, that's an interesting log. Near the top you have:

    Aug 25 13:24:19 chiron gala[1554]: ScreenShield.vala:421: Unable to set locked hint on login session: GDBus.Error:org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/c2'.
    

    So it looks like your login session has died somehow. If you still have the logs from that boot, can you scour further up for any reference to session "c2" dying or logind stopping/restarting and why it might have happened. Searching for "c2" or "logind" is probably a good start.

    This is what was happening with the Switchboard power plug. Changing settings in there was causing an issue with logind, which then broke the session, but if you hadn't done anything with the Power plug in that session, there may be another cause somewhere else that we need to track down.

    @davidmhewitt after installing the patch it doesn't happen so often, but it just happened to me, so there is another problem here too. I attach log.txt so you can see what might be going on.

    @tomaswarynyca Thanks for the log. I see the same message as what was in @nathanaelg 's log at 11:00 :

    ago 25 11:00:34 ASUS-X512DA gala[41138]: ScreenShield.vala:421: Unable to set locked hint on login session: GDBus.Error:org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/c8'
    

    logind restarts at 10:26 which is what causes the issue at 11:00.

    ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Activating service name='io.elementary.logind.helper' requested by ':1.434' (uid=1000 pid=52089 comm="/usr/bin/io.elementary.switchboard ") (using servicehelper)
    ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Successfully activated service 'io.elementary.logind.helper'
    ago 25 10:26:20 ASUS-X512DA io.elementary.s[52089]: Attempting to add a widget with type GtkGrid to a container of type PowerBehaviorView, but the widget is already inside a container of type GtkGrid, please remove the widget from its existing container first.
    ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.434' (uid=1000 pid=52089 comm="/usr/bin/io.elementary.switchboard ")
    ago 25 10:26:20 ASUS-X512DA systemd[1]: Starting Hostname Service...
    ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Successfully activated service 'org.freedesktop.hostname1'
    ago 25 10:26:20 ASUS-X512DA systemd[1]: Started Hostname Service.
    ago 25 10:26:25 ASUS-X512DA systemd[1]: Stopping Login Service...
    ago 25 10:26:25 ASUS-X512DA dbus-daemon[1287]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' requested by ':1.330' (uid=1000 pid=41138 comm="gala ")
    ago 25 10:26:25 ASUS-X512DA systemd[1]: systemd-logind.service: Succeeded.
    ago 25 10:26:25 ASUS-X512DA systemd[1]: Stopped Login Service.
    ago 25 10:26:25 ASUS-X512DA systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.
    ago 25 10:26:25 ASUS-X512DA systemd[1]: Starting Login Service...
    ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: New seat seat0.
    ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: Failed to add user by file name 1000, ignoring: Invalid argument
    ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: User enumeration failed: Invalid argument
    ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: User of session c8 not known.
    ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: User of session c1 not known.
    

    Those log lines look exactly like what would happen with the old version of the Switchboard Power plug before it was fixed. When did you install the new version and was Switchboard restarted to ensure the new version was loaded?

    Yes, install and restart
    I will reinstall and see what happens, I will keep you updated.

    Hi, case closed for my computer, I have new bugs (io.elementary.greeter not responding) but not this one ! Thanks a lot

    I reinstalled the package by doing "--purge" and so far so good @davidmhewitt
    If you agree @candiedoperation this issue is resolved and we can close it !!

    Was this page helpful?
    0 / 5 - 0 ratings

    Related issues

    Blast-City picture Blast-City  Â·  4Comments

    hanaral picture hanaral  Â·  4Comments

    peteruithoven picture peteruithoven  Â·  3Comments

    Janiczek picture Janiczek  Â·  4Comments

    techdev5521 picture techdev5521  Â·  3Comments