The current git head on my Intel HD 5500 is broken with respect to blanking/DPMS. If I do xset s activate, screen goes blank and unblanks immediatelly (even with sleep 1 before xset), the same for xset dpms force off. Also automatic blanking/DPMS only shortly flashes with black screen and returns display back. xset q looks like: Screen Saver: prefer blanking: yes allow exposures: yes timeout: 600 cycle: 600 DPMS (Energy Star): Standby: 180 Suspend: 180 Off: 300 DPMS is Enabled Monitor is On
Quick test locally doesn't suggest anything wrong. Are you sure this a ddx issue? Is it a regression? If so a quick bisect would be very, very useful.
(In reply to Chris Wilson from comment #1) > Quick test locally doesn't suggest anything wrong. Are you sure this a ddx > issue? Is it a regression? If so a quick bisect would be very, very useful. the older driver (about march?) worked better. It blanked, turned on, blanked again and stood blanked. So, still not perfect but usable. I'll check it and try to provide a bisect.
In the meantime, it would be useful to attach your Xorg.0.log. If you --enable-debug=full, you would be able to see what happens in response to the SetSaver calls (but not what triggers them). That would be useful to double check that the unblank is from a higher layer in X, and not a bug in the ddx.
(In reply to Lukas Hejtmanek from comment #2) > (In reply to Chris Wilson from comment #1) > > Quick test locally doesn't suggest anything wrong. Are you sure this a ddx > > issue? Is it a regression? If so a quick bisect would be very, very useful. > > the older driver (about march?) worked better. It blanked, turned on, > blanked again and stood blanked. So, still not perfect but usable. > > I'll check it and try to provide a bisect. bisected to this commit: bc59d3fc76047bcdd20e9750591e06227b9cf39e is the first bad commit commit bc59d3fc76047bcdd20e9750591e06227b9cf39e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 7 19:44:12 2015 +0000 sna: Differentiate between disabling CRTC and turning off DPMS
(In reply to Chris Wilson from comment #3) > In the meantime, it would be useful to attach your Xorg.0.log. If you > --enable-debug=full, you would be able to see what happens in response to > the SetSaver calls (but not what triggers them). That would be useful to > double check that the unblank is from a higher layer in X, and not a bug in > the ddx. attached (too big for b.fd.o) https://www.dropbox.com/s/t5c0tqy3xeplnxo/Xorg.0.log.old.bz2?dl=0
The unblank is in response to SaveScreen(mode=1). Looks like the earlier behaviour was buggy and wasn't responding to the DPMS change correctly. If you grep the log for sna_save_screen() do they (at least the latter pairs) correspond with your calls to xset and subsequent glitch? There's another issue buried in there in that the kernel fails to set DPMSModeOff on the eDP panel.
(In reply to Chris Wilson from comment #6) > The unblank is in response to SaveScreen(mode=1). Looks like the earlier > behaviour was buggy and wasn't responding to the DPMS change correctly. If > you grep the log for sna_save_screen() do they (at least the latter pairs) > correspond with your calls to xset and subsequent glitch? providing another log which was created only by Xserver + a single xterm. I run sleep 1; xset s activate for 3 times which was: blank, quick unblank. > There's another issue buried in there in that the kernel fails to set > DPMSModeOff on the eDP panel. so, do I need kernel update?
Created attachment 115332 [details] xorg log
(In reply to Lukas Hejtmanek from comment #7) > > There's another issue buried in there in that the kernel fails to set > > DPMSModeOff on the eDP panel. > > so, do I need kernel update? Not sure what's wrong here yet. I'm going to sleep on it! If you would like to grab a drm.debug=6 dmesg of the xset/glitch, it may explain the error (or it may not).
This is video of bad behavior (really quick flash of blank): https://www.dropbox.com/s/85902qwf9u7tiyw/2015-04-26%2000.14.57.mov?dl=0 This is video of "good" behavior (quick flash of unblank): https://www.dropbox.com/s/b7ifgw2tci77vd7/2015-04-26%2000.16.15.mov?dl=0
Created attachment 115338 [details] [review] Disable CRTC if DPMS fails Ok, that looks consistent with the kernel failing to disable the output (and not the following SaveScreen(unblank)). Can you please test the following patch? Having a debug log (like the last with just X + xterm) in any case would be very useful, thanks.
(In reply to Chris Wilson from comment #11) > Created attachment 115338 [details] [review] [review] > Disable CRTC if DPMS fails > > Ok, that looks consistent with the kernel failing to disable the output (and > not the following SaveScreen(unblank)). > > Can you please test the following patch? Having a debug log (like the last > with just X + xterm) in any case would be very useful, thanks. well, this one fail on assertion (sna_crtc->flags & CRTC_ON) in __sna_crtc_disable. I work arounded this. However, I get no screen at all, just turned off display with error message on console: sna_output_dpms: failed to set DPM mode [3->0] on output eDP1: 22 sna_output_dpms: failed to set DPM mode [0->3] on output eDP1: 22 I created dmesg with drm.debug=6 as requested, but not sure whether it is usable right now as I didn't reach xset test.
Sorry for the delay, I tweaked the initial patch until I was able to start up and blank/restore the outputs with DPMS on/off. That patch is commit 7d9a74622e5a936e4860fcef8358619bf59adae8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jun 15 14:16:34 2015 +0100 sna: Be robust in handling DPMS failures If we fail to turn off an output via DPMS, disable the entire CRTC in order to blank the output and save the screeen/power. Reported-by: Lukas Hejtmanek <xhejtman@fi.muni.cz> References: https://bugs.freedesktop.org/show_bug.cgi?id=90179 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> I still haven't worked out where the EINVAL is coming from that's triggering the failure in the first place, but now it should be behaving itself even if we cannot set the DPMS mode on individual outputs.
Well, maybe some update of kernel fixed the issue for me. I.e., kernel no longer fails to set DPMS and DPMS works OK now. Thanks for support anyway.
Thanks for the report. *fingers crossed it keeps on working*
I've traced a regression to this commit. On my Intel 4400 system when an X server quits the display is turned off and doesn't seem to re-enable [1]. This is triggered by switching from a user session to a greeter (thus starting a second X server) then returning to the session by authenticating (closing the second X server). [1] https://bugs.launchpad.net/bugs/1501941
Opened bug 92457 to track this regression issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.