elementary / gala

Gala Window Manager for elementary OS and Pantheon
https://elementary.io
GNU General Public License v3.0
274 stars 77 forks source link

Only Cursor Visible on Log In after suspend #1126

Open candiedoperation opened 3 years ago

candiedoperation commented 3 years ago

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:

Laptop Information: HP Pavilion x360

candiedoperation commented 3 years ago

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

davidmhewitt commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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

hanaral commented 3 years ago

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

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 commented 3 years ago

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

alfredit commented 3 years ago

Problem seen on a thinkpad x1 log.txt

sjlua commented 3 years ago

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

btazi commented 3 years ago

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

kapiljhajhria commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Happening in my Dell Inspiron-15-3573.

ameyrk99 commented 3 years ago

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

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 commented 3 years ago

@ameyrk99 that didn't work for me unfortunately.

tomaswarynyca commented 3 years ago

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

volfpeter commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

alfredit commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

davidmhewitt commented 3 years ago

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

tomaswarynyca commented 3 years ago

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

alfredit commented 3 years ago

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

tomaswarynyca commented 3 years ago

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

alx242 commented 2 years ago

This happened to me on the latest Odin release and I could fix it by doing the uninstall and then reinstall of the switchboard-plug-power package.

But why did it even happen to begin with? I might have done some modification to the settings of the power but it seems pretty fragile if that was the cause of it?

Hopefully this can be fixed to make things a bit more stable.

--edit--

Guess this issue still exists for me.

Here is my log.txt from when this happened again this morning. I should probably turn on the debug flag also but didn't have that active when I ran into the issue again. I will supply this next time I run into it :)

alx242 commented 2 years ago

Here is the full log.txt of my reproduction.

I just need to activate suspend and then this happens instantly upon resume. I have tried to reinstall the switchboard-plug-power package but that didn't fix the problem.

-- edit --

I just replicated the issue by only locking my screen. Is this handled by lightdm or? In that case it might be the culprit...

-- follow up --

Since it felt like lightdm was acting up I decided to install lightdm-settings and add myself to the lightdm group to run that tool. Now my machine can lock and suspend again without problem. Perhaps the issue is somewhere in the stack of lightdm/greeter/gala. I don't use the installed greeter by elementary any longer but at least my system isn't going bonkers with these issues atm.

abbazs commented 2 years ago

Reinstalling elementaryos fixed the issue for me.

matthiasjg commented 2 years ago

It seems I managed to "fix"(?) this for me by (finally) giving in and installing the nvidia drivers (via sudo ubuntu-drivers autoinstall). :eyes: :thinking:

I'm on a Lenovo T25 (T470) w/ NVIDIA GeForce 940MX alongside Intel HD Graphics 620.

Anyone else with dual graphics seeing this?

rreina commented 1 year ago

This issue is still happening under Elementary OS 7. Please see below for more info and a workaround:

MacBook Pro 15” mid 2015. Intel HD graphics (no dual graphics)

Tested kernels:

It is not necessary to suspend the system. It happens every time the screen locks by closing the lid or even locking from the power icon indicator. After login back to your account you get the black screen with cursor.

This bug is a duplicate of Elementary - Greeter #525. All points to Pantheon Greeter in need of a fix.

Workaround:

  1. Turn-on suspend when closing the lid in power settings: lid-closed-suspend
  2. Fully disable locking the screen in the security & privacy settings: locking-off-security

Result: your laptop suspends when closing the lid, hence saving power, and when your open it back you're logged in skipping the black screen bug.

ghost commented 1 year ago

for all apps and processeces is quited ith an quit code 1x1

ghost commented 1 year ago

gala not respoding

ghost commented 1 year ago

tru ctrl alt f2 type gala

ghost commented 1 year ago

logind not responiidng

ghost commented 1 year ago

you require factory reset

AlexFBP commented 3 months ago

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

Just in case, this just happened to me. As this happened to me some other times in the past, I found again this issue to attempt the DISPLAY=:0 gala & with no success, I also tried gala with --replace as suggested after failed, but failed too...

So i decided to just reboot but first I dumped the logs below with:

journalctl -g gala --no-pager > gala.log

gala.log - "Normal" (without sudo) gala-adm.log - With sudo

My setup: elementary OS 6.1, Intel® Core™ i7-6700T CPU @ 2.80GHz quad core, Intel® HD Graphics 530 (Skylake GT2), 31.2GiB RAM