FGLRX DPMS support totally broken, fails to wake up the monitor after putting it to sleep.

I had this problem too, sporadically, for a very long time. Recently it got quite a bit worse with a new release of fglrx, so I undertook to solve it. What was happening for me is that the X server used the dpms settings specified in the ServerFlags section (BlankTime, etc.) of xorg.conf to put the display to sleep after 10 minutes, then when KDE's power management daemon tried to put the display to sleep after 20 minutes, it caused some kind of race condition in the X server and required a reboot.

My solution was to *add* the following to the ServerFlags section of my xorg.conf:

        Option "BlankTime" "0"
        Option "StandbyTime" "0"
        Option "SuspendTime" "0"
        Option "OffTime" "0"

to turn off xset's dpms handling entirely, and leave it up to KDE to blank the display. Note that all four values default to 600 (ten minutes) if they're not specified! (My feeling is that as long as KDE and GNOME are set to handle display blanking by default in the distribution, then the above values should ship with the default xorg.conf.)

I hope this helps anyone else with this problem. For the OP: you might want to dispable display dimming as well in case fglrx can only handle one kind of power saving request at a time.

Hi,

I can confirm the same problem with Catalyst 12.2 and Radeon HD3200. I have HDMI connection to my TV and after switching the TV off and on the driver fails to recover the desktop. The applications stay active in the background. Looks like the driver fails to probe or initiate the connected output and/or read the EDID data from the connected TV.

Have tried everything possible solution/suggestion I could find for this problem including disabling DPMS and Composite extension to no avail.

Igor

Hi,

* I leave a low voltage LED display plugged in to the card using the DisplayPort connection and that's permanently turned on.
*I'm using Debian packaged fglrx version 12-6-2/8.98.2.
* DPMS (thank you for that tip), KDE (4.8.4)'s power management and screen saver are turned off.

About 50% of the time the LED screen is still showing my desktop when I get up in the mornings or come home from work; the rest of the time it's blank. Sometimes you can turn your back on the screen for just a few minutes and its blank.

Of those blank screens 20% of them don't recover; so far I'm on a winning streak betting with myself if the display is going to work. Similarly, if my house mate turns of the LED display then the Radeon HD 6950 goes in to deep sleep without recovering.

I can connect through SSH with my Android phone or tablet and "sudo shutdown"; as sometimes a reboot isn't enough to bring the card out of sleep.

It takes 2-5mins for the xorg process to finish, during that time the process hits 100% of single threaded CPU utilization. The .xsession-errors log file often has lots of DBus errors. Mostly I issue a "kill -9" just to speed the up the shutdown.

Getting rid of the Debian package "firmware-linux-nonfree" which contains the BIOS blobs for these cards for the Radeon driver made a significant improvement from the almost always doesn't recover to now if the LED display is sleeping and I turn the projector (HDMI) on, more often than not both displays will work.

There's nothing worse than a black screen of doom!

Kim

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

Just wanted to say thanks. I disabled DPMS, added a ServerFlags section as mentioned above and rebooted. I can now resume from suspend without a problem.

For reference, my system info:
`uname -a`
Linux envy 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

`xdpyinfo | grep version`
version number: 11.0
X.Org version: 1.11.3

HP Envy 14 with Ubuntu 12.04 with ATI Mobility Radeon HD 5000. Using ATI driver `amd-driver-installer-12-6-x86.x86_64.run`.

You can improve the situation by installing xautolock and xdotool. Using these two tools you can have the mouse move every x minutes of no activity. 5 days with no black screen of death!

e.g. run the following in a terminal window and the task is put in the background:
xautolock -time 1 -locker "xdotool mousemove 10 10" &

I have a problem with similar with 12.10 and fglrx version 2:12.100-0ubuntu1.

After resume, one of my monitors is disabled and cannot be reenabled from Catalyst without reboot. Another loses its resolution setting. The third is still in good shape.

I too am experiencing this issue. I'm running catalyst 13.1 on Kubuntu 12.10. Also, if I run "xset dpms force standby" it will instantly cause the issue, leading me to believe that it does in fact have to do with xset handling display sleep.

ServerFlag options did not solve the problem.

same problem with 13.2beta7, I can ssh in and see that xorg cpu usage is at 100% since in kde I mapped an key to do xset dpms force on to try and manually turn on the monitor with no luck. I use displayport

I had this issue if I installed via the sh script. However, if I build the deb package I was told that I was missing some dependencies (which I was not told about if I did a straight install). Once the deps were satisfied and the package built, I have not had this issue. Seems like an issue with the install script (perhaps with x86_64?). Try building the ubuntu package and installing that.

I have this issue as well.

Ubuntu 12.04, 3.2.0-53-generic-pae kernel
Catalyst Driver Packaging Version 8.96
AMD Radeon HD 7660D (A10 5700 APU)

I put this APU in two new builds, totally identical except that one has ASRock FM2A85 and the other ASRock FM2A75. Only the build with the ...A85 mobo is affected.

Using 'xset dpms force off' to activate energy star power saving funtions, or 'xset s activate' to blank screen will sooner or later (often sooner) leave me with a running computer where i can not return from the blank screen (and it is not just that I can not see the screen, the keyboard is not responding, i have tried to safely shutdown using keybindings, but it does not work).

Does not fix the issue:
'aticonfig --acpi-services=off'

Setting this option in xorg.conf does not fix the issue:
"Option "DPMS" "false"

All these things in combination does prevent the issue:
Put in my login script:
'xset -dpms &'
'xset s off &'
Put in xorg.conf:
"Option "DPMS" "false"

But it does not fix the issue, because I only avoid screen freeze because I never enable the screen blanking/saving functions.
Right now I am using 'feh -FNY ~/.black.png' as a simple screen-blanking function instead.

Regards
Mikael

Refering my last post above;

Using xscreensaver (without using 'Display Power Management') works fine for me, so if you encounter issues with the xorg screensaver freezing, disabling the 'xset' screensaving features and installing/using xscreensaver instead might be a workaround for you as well:

Install package 'xscreensaver'.

Add these two lines to "~/.xinitrc" (or whatever gnome/unity/xfce/kde startup script you have):
xset -dpms &
xset s off &

Set this option in "/etc/X11/xorg.conf":
 Option "DPMS" "false"

Configure xscreensaver with cmd 'xscreensaver-demo' and set it to use "Mode: Blank Screen Only" and do NOT enable any "Display Power Management".

If you sometimes want to manually start the screen saver, use cmd "xscreensaver-command -activate'.

/Mikael

This bug is driving me crazy.

I'm literally going to throw my PC against the wall in a minute and apply for Windows licence just so that I can have my monitor wake up once in a ******* while.

How many years has Ubuntu had this issue for now????

Hello everybody

I'm experiencing this bug too , I'm running Kubuntu 14.04 lts 64bit and using fglrx-updates (Radeon HD 7790)
I don't know if this applies to other setups... distros... different window-managers etc ... This is the only scenario
in which I could test and have this problem.

The steps I've taken to reproduce this behaviour are the following:

1 - Install fglrx-updates drivers

2 - Wait for the display to be switched off by the power-manager

3 - After the screen has fully switched off and entered stand-by mode, trying to move the mouse
or hitting any of the keys on your keyboard simply does not wake up the screen. Your display is permanently
stuck in sleep mode and you have to reboot your computer.

There's "just" something wrong with the computer telling the screen to wake up because
while the display is off, the system is still running I guess as I managed to avoid hard-resetting my computer
by using the terminal and issuing a shutdown command (going by memory, since the display is OFF).

I haven't tested the workarounds suggested above but I'll keep this post updated as soon as I try.

Referring to my post above...
I confused one for another , I actually had to enter a TIMED shutdown command to reboot my system while testing the display switch-on/off because the system was running but not responding my inputs at all after my screen was going off.

I also have tested some of the solutions I've read above and found some odd things.

-- So , after installing fglrx-updates I had no xorg.conf file by default (which is ok..) ;

-- I generated one with sudo amdconfig --initial and set DPMS to false , then rebooted ... this workaround actually "worked" for me in the sense that it basically prevented the system to send a standby/switch-off signal to the monitor ... instead, it was just blanking and keeping it powered on. (so far so good)

-- Then out of curiousity I tried setting the DPMS back to true, after rebooting the system I noticed it was working,
the display was correctly entering and exiting the standby mode. Thus, my problem was that I had no xorg.conf file by default.
So yay, everything worked fine ... no, not everything actually.

-- I don't know why but having an xorg.conf file somehow affects my graphic effects , for example when I'm in the KDE system-settings panel there's a fade-out effect when moving the mouse-pointer from one icon to another ... well that one graphic effect is now broken, the fading effect is glitchy and makes some artifacts when fading ... this does not happen when I have no xorg.conf file.

Both ways I have something malfunctioning ... either graphics-ok + screen standby not working or the other way around.
I guess I'll be keeping my /etc/X11 without an xorg.conf file and just disable the powermanagement option for display standby

Ubuntu 14.04 here, Radeon HD 8490. The bug has bit me once (fail to wake up from DPMS screen off). What happens frequently is that, with DPMS on (I use "xset dpms 0 0 600"), it behaves for a while, then keeps blanking the screen so often that it becomes unusable. I also have "xset -s" (no screensaver). If I do "xset -dpms" then the machine is fine but of course the display stays on. I use i3wm, am not using any desktop environment that would blank the screen for me. I have now generated an xorg.conf as suggested in the previous comment, and will wait and see how it does.