Screen partially darkened after suspend and resume in Xubuntu

Strangely, I had not enabled the fglrx proprietary driver when this happened (even though for some reason the reported system information says it was installed). I ran jockey after the fact, finding both fglrx and fglrx-updates grayed out and not activated, and I installed the non-updated version (when I try to install the fglrx-updates I get error messages) and continued to have the same problem. Either the fglrx driver was installed when I installed Ubuntu and wasn't reported as installed, or I'm experiencing this bug with both the free and proprietary driver. Only now that I've installed fgrlx, the dark layer over the screen is more like 95% dark, almost completely invisible, rather than 40% or so, even though the mouse cursor is still 100% white.

Apparently others are experiencing this same bug with XFCE:

http://unix.stackexchange.com/questions/38921/graphics-dim-but-mouse-cursor-not-dim
http://ubuntuforums.org/showthread.php?t=1934193

Status changed to 'Confirmed' because the bug affects multiple users.

Toshiba Satellite Pro L510. ATI Radeon HD 4500/5100 Series. FGLRX enabled (not updates; I also get errors).

I can also confirm this bug, kinda! The description of what happens is exactly the same; a sheet of black across the screen when I come out of suspend (lift laptop lid). The difference for me is that it is totally random, or seems that way. There is no way I can replicate it intentionally.

When this happens I can see enough to close all apps and logout. This gives a bit of a flash as if the screen is kicking into gear again and when I get to the login screen all is back to normal. I login and all is fine. Until the random anomoly eventually occurs again, as it does/will, in a day, a few, a week.

It happens maybe one in ten times when I open the lid. But the problem is the same. Adjusting brightness does nothing to remedy the issue.

Confirmed on Xubuntu, after latest kernel update.

Resume from suspend leaves the brigthness reduced.
Mouse cursor remains bright.
Log-out/in restores brightness.

Forgot to mention:

Lenovo T420s, nvidia, 3.2.0-32-generic

Confirming that this affects me also and I'll do some investigating to get to the bottom of it. At first I thought my Dell Vostro 1500 had a faulty monitor and I would just have to deal with it but now I suspect it's the power manager because that controls screen dimming.

Here comes another "me too" message.

I'm experiencing the same bug. Dell Studio 1558 (AMD Radeon HD standalone graphics adapter) with (K/X/L)ubuntu 12.04. I'm currently using proprietary drivers.

This bug had occurred on this machine before (I think in 11.04 or 11.10), but I figured it was a one-time bug. Now it's happening again for no discernible reason. Like others, it's happening when opening the laptop's lid (in my case to resume, though it sounds like it's not limited to resuming). Mouse is still at full brightness. I haven't tried logging off yet (my screen's still dimmed right now); I'm putting that off so I can save all my work.

I don't think the card specifically is the issue (since it's affecting AMD and Nvidia chipsets alike), but I'm going to test things like compositing and what not to see if I can force some kind of workaround.

And amazingly I do have a workaround! Well, for AMD/ATI users at least.

If you have the proprietary AMD drivers installed, open up the Catalyst Control Center and switch over to the "Color" screen. Tweak the "Gamma" setting (make sure "All(locked)" is selected under "Select Color Channel:") and the screen should pop back into full brightness. Hit the reset button for that slider (off to the right-end of it) and it should stick.

I'm not sure if this is applicable to Nvidia users, or users without proprietary drivers. Nvidia users should definitely try this if they have their proprietary drivers and have access to their equivalent of AMD's CCC (don't remember what it's called for Nvidia cards). Non-proprietary driver users should look into installing Redshift (run "sudo apt-get install gtk-redshift") to graphically tweak the gamma settings.

I have a bit more information. Same symptoms, different desktop managers.

I've noticed that this is *not* happening in Unity or KDE. However, it *does* occur with both Xfce (known) and LXDE. Not sure if that helps, but it might help find a common factor.

> I've noticed that this is *not* happening in Unity or KDE. However, it *does* occur with both Xfce (known) and LXDE.

That indeed sounds related to 2D vs. 3D, but all of these desktops use a different window manager. So the bug could be anywhere between the Mesa and Linux layer.

Alex mentioned that this could be a pm-utils bug. At least the original bug reporter is using fglrx, that should disable all pm-utils quirks. However, to make double sure that it's not that, can you please try the following:

 - Reboot your computer so that we are starting from a clean slate.
 - Open a terminal window.
 - Type "sync" and Enter
 - Type "echo mem | sudo tee /sys/power/state" and Enter; this should trigger a suspend
 - Wake the computer up again.

Do you see the problem now? If so, please do the following:

 - Reboot your computer again.
 - Trigger a suspend by closing the lid or from the menu, etc.
 - Resume
 - Verify that you see the screen corruption now.
 - Attach /var/log/pm-utils.log

Thanks!

Running xubuntu 12.10 (xfce 4.10) with nvidia binary driver (304.51). I noticed something similar to this when using the redshift utility. After a suspend, my screen in the morning would retain the gamma correction from the previous night.

Using xrandr manually:

~$ xrandr --query
(...)
DVI-I-1 connected 1680x1050+1680+0 (normal left inverted right x axis y axis) 474mm x 296mm
(...)
DVI-D-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 433mm x 271mm
(...)

~$ xrandr --output DVI-I-1 --gamma 1.0:1.0:1.0

doesn't produce any visible results immediatly, but WILL after you switch to another VT and back to X (say alt-F1 then alt-F7).

Using the nvidia-settings utility to set the gamma values shows the same behavior, the settings are only applied after a VT switching.

Very strange bug. I don't get this at all using Unity and it's always bright on that DM. I followed Martins instructions and was unable to reproduce the effect in XFCE 4.10. However when I let the computer go idle by itself and allowed the xfce4-power-manager turn the screen off I noticed slight dimming. I'm attaching the logs from pm-suspend.log and pm-powersave.log because I couldn't find pm-utils.log in the logs folder.

I've also scouted launchpad.net for similar bug reports and am finding some that - on the surface - seem related but I will need to send a list to Martin to confirm if these are in fact related. Some of these relate to the screen losing it's original user defined brightness level and jumping to another while others include the back-light being non-functional and the brightness controls not working...

The attached pm-suspend.log shows that quirks were not applied because it detected the NVidia binary driver. Can you double-check with /sys/power/state (see comment 12) to double-check?

But anyway, this was reported with the FGLRX and nvidia driver on several systems, so this doesn't seem very hardware specific, and most likely not a bug in pm-utils.

There was a slight gamma shift downwards and I'm attaching the log, it tends to be more severe when the suspend is left to be triggered by inactivity and the system is suspended for an extended period...

AG Restringere [2013-01-02 23:36 -0000]:
> Martin, in your opinion do you think that this bug #921321 is a
> duplicate?

I don't think so. Bug 921321 is a specific bug against the Nouveau
driver, and there is no evidence of it being XFCE specific. This
bug seems XFCE specific and happens with both the proprietary NVidia
and FGLRX drivers (and possibly others).

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

According to http://ubuntuforums.org/showthread.php?t=2038250 xscreensaver's fading effect might be the cause of the darkened screen.

Just added Xscreensaver to the list of "possible candidates" as per comment #22. Seems interesting because XFCE does indeed use Xscreensaver and possibly the bugs on the duplicates list for older Ubuntu versions prior to 12.04 are due to Xscreensaver being used by default on Ubuntu systems then. This would also possibly explain why the bug affects so many different video drivers and card types.

According to Xscreensaver documentation if you can reproduce the bug type the following into the Terminal and try to retest the problem...post your log file here...

http://www.jwz.org/xscreensaver/bugs.html

$ xscreensaver-command -exit
$ xscreensaver -verbose -log log.txt

I believe you can disable the fading out in xscreensaver, please see its settings (run xscreensaver-demo) or the man page and try it out.

Yes, I can confirm this bug (XFCE, Ubuntu 12.04, ATI 4200HD, fglrx non-updates). And it seems that it is a bug in XScreenSaver as according to http://ubuntuforums.org/showthread.php?t=2038250 when dim effect turned off ("Navigate to Settings Manager > Screensaver > Adavnced > Fading and Colormaps and untick Fade to Black when Blanking"), the problem does not seem to occure anymore... I will try to post this bug to XScreenSaver guys with details...

This bug started with the update to Xubuntu 18.04. I regularly get a screen where only the password prompt is shown, but the black part of the screensaver is missing, which discloses the full content of the application currently running.
I had also the problem that the screen was black but the password prompt was missing.