GNOME Bugzilla – Bug 654482
Screen stays almost black for a long time after unblanking
Last modified: 2011-08-08 14:53:39 UTC
I'm on gnome-shell 3.0.2. Sometimes, after the screen has been blanked for a long time (e.g. after I leave the machine idle for a long time, or after I unsuspend it), the screen stays black except for this in the top panel: Old date/time [lock] Federico Mena Quintero That is, it shows the date/time before I suspended the machine, a lock icon, and my username. The rest of the screen is black. There are no other icons in the top panel. I can move the mouse. At first it just shows the arrow cursor; after some time, the cursor may change to an I-beam as it hovers over what may be text fields - but the screen stays black for a long time. Pressing keys does nothing. It is only after a couple of minutes that my desktop's contents get really shown again, and the clock gets updated. I have screensaver password locking disabled.
(In reply to comment #0) > Old date/time [lock] Federico Mena Quintero Those are part of the screen lock (i.e. gnome-screensaver), not gnome-shell ... (yet)
Originally, I thought it might be gnome-screensaver too, but it seems to me that the process gnome-screensaver is functional. and one can perceive screen lock activation and deactivation indirectly though the mouse cursor. Killing gnome-shell currently is the only way out. Also, this does not happen in gnome-panel fallback mode. See more info on https://bugzilla.redhat.com/show_bug.cgi?id=705609 Key features of this bug * Definitely known that black screen state time proportional to number of hours in sleep state. Possibly worsens with uptime as well. * on wake up black screen, functional mouse cursor, clock frozen at sleep time. * mouse cursor changes shape when moved over GUI elements not visible in the blackness. It is possible to group in the blackness, findthe password entry textbox, enter the password and login, but still be faced with the same black screen, only now GUI elements are all over the place after login, like if a browser were open you can see the mouse change shaper over hyperlinks. * Audio works, OpenGL apps work (but can't see them) * no high processor usage Basically, it feels like a frozen screenshot f a black screen with panel on top, clock at sleep time, is placed on top of all windows, However, it is transparent to mouse events.
What's in ~/.xsession-errors? Really sounds like the invalid wireless access points bug to me (bug 651378).
I can confirm that bug 651378 is present. The question now is whether the black screen bug and the wireless access bug are two independent issues, or the former is a side-effect of the latter. It seems really odd to me that wireless access is holding up the GUI update of the whole screen. Even as a side-affect, wireless access issues should not hold up screen updates. You can leave the laptop on at a place where the wireless APs are less likely to change like a secure office, and still return in the morning to find the issue. So it might not have to do with mobility and seeing different APs as at a residence or on the train. One way to test this is to disable wireless and stay on ethernet and see if black screen issue persists.
* In case of resume from sleep Internet can be accessed on the Ctrl-Alt-F2 Console, meaning existing wireless connection is not disrupted. ping, elinks work, during blacks screen freeze. * Software button toggle causes complete screen freeze for a few seconds. * Hardware button toggle also causes screen freeze, * The AP-list never seems to purge, and populated with unkown APs * The file .xsession-errors, gets longer with uptime similarity: * mouse cursor can move, changes shape over gui elements. difference: * During this type of screen-freeze, though mouse can move and change shape while hovering over gui elements, The gui elements cannot be activated, like clicking on another window does not bring it to the foreground, assuming foregrounding happens but that the screen is not being drawn. In the blacks screen issue, I think the gui elements are functional, and can be clicked, and on clicking the guis on the screen change accordingly, only that visually there are no difference and the same black screen remains. It feels like being blindfolded, rather than being unresponsive. Alternately: Maybe on resuming from sleep the login-screen is the only functioning gui, albeit the black screen, and upon logging in maybe things are frozen and I have not thoroughly made sure if say a browser link can be clicked. Need to check next time.
My .xsession-errors has a *ton* of these: Window manager warning: Log level 16: _nm_object_get_property: Error getting 'Ssid' for /org/freedesktop/NetworkManager/AccessPoint/177: (19) Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist Window manager warning: Log level 16: _nm_object_get_property: Error getting 'Mode' for /org/freedesktop/NetworkManager/AccessPoint/177: (19) Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
Confirming that disabling wireless (by pressing hardware button) encounters no black screen delay when screen unblanks.
So that's really a duplicate. *** This bug has been marked as a duplicate of bug 651378 ***
yes, but one can argue that such dependency should not even exist. fixing bug 651378 is one way to make bug 654482 go away. There could be two issues here. 1) determining cause of bug 651378 so that unknown APs are quickly handled, purged or prevented. unknown APs should not accumulate, and if they do, they must be dispensed of quickly. 2) remove needless dependency between applet and screen update. Perhaps its the logging thats freezing the screen. or maybe its the indicator applets handling of the APs thats freezing the screen. i.e. The xsession logging or the wireless indicator applet should run asynchronous, In either case a malfunctioning indicator applet should not hold screen update. So if another day some other problem were to happen with the wireless applet, screen freezes should not happen again. This kind of dependency is completely unexpected, and few will suspect wireless to be cause. There may be a general problem, in that maybe if there is similar malfunction causes holdup in another indicator applet, like power indicator, or bluetooth or language and volume, maybe gnome-shell might freeze up then too ? The black screen state freeze is much longer when slept for a long time, like 10 minutes. Screen Freezes due to wireless AP update via hardware toggle usually under a minute, 5-10 seconds. It could be that with increasing uptime and sleep time, these AP freezes are accumulating up. An hour of sleep might cause over 5 minutes of screen lockup.