Only Cursor Visible on Log In after suspend

[candiedoperation]

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,

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

On closing multitasking view (three finger down),

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

[candiedoperation]

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

[davidmhewitt]

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

[candiedoperation]

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.

[candiedoperation]

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

[davidmhewitt]

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

3. Reboot the computer
4. Reproduce the issue
5. Gather logs again with journalctl | grep gala

[candiedoperation]

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

[davidmhewitt]

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.

[candiedoperation]

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

[candiedoperation]

@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:

[hanaral]

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)

[tomaswarynyca]

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

[alfredit]

Problem seen on a thinkpad x1 log.txt

[sjlua]

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

[btazi]

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

[kapiljhajhria]

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)

[shawn1thompson]

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.

[joajimenez]

Happening in my Dell Inspiron-15-3573.

[ameyrk99]

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~~

[btazi]

@ameyrk99 that didn't work for me unfortunately.

[tomaswarynyca]

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

[volfpeter]

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.

[alfredit]

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

[davidmhewitt]

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.

[alfredit]

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.

[davidmhewitt]

@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.

[alfredit]

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.

[nathanaelg]

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).

[alfredit]

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.

[davidmhewitt]

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.

[tomaswarynyca]

@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.