|Summary:||intel-virtual-output doesn't sync built-in X11 screensaver|
|Product:||xorg||Reporter:||Raffael Herzog <herzog>|
|Component:||Driver/intel||Assignee:||Chris Wilson <chris>|
|Status:||RESOLVED MOVED||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|i915 platform:||i915 features:|
Description Raffael Herzog 2016-01-02 17:22:58 UTC
On the X-server :8 started by Bumblebee, the screensaver is turned on by default. After 10 minutes without any input, :8 turns black. If an application running on :0 suppresses the screensaver, this doesn't get forwarded to :8, it still blanks. I noticed this while trying to calibrate my external monitor using dispcalGUI in a multi-monitor setup using intel-virtual-output. Also, when :8 unblanks, there are no damage events on :0, the image on :8 stays black and gets only partially repainted (on kwin, moving a window repaints everything). Current behaviour: X-server :8 uses its own settings for the options BlankTime, StandbyTime, SuspendTime and OffTime. An application running on :8 that suppresses the screensaver (like a video player) has no effect on :8 (actual keyboard and mouse input works fine). Expected behaviour: The on, blank, standby, suspend and off states of :0 get forwarded to :8. :8 does not change these states on its own. This goes back to the following issue/pull request on the Bumblebee project: https://github.com/Bumblebee-Project/Bumblebee/pull/679
Comment 1 Chris Wilson 2016-01-02 20:40:07 UTC
Hmm, responding to Expose events on :8 seems sensible and doable. Not sure how to handle the screensaver though since there is no general inhibit mechanism. If you have any ideas, please do forward them.
Comment 2 Raffael Herzog 2016-01-02 21:05:08 UTC
Well, I don't know X in-depth. My idea was to simply do the same as :0 does: - On connect, set BlankTime, StandbyTime, SuspendTime, OffTime to 0. - When :0 goes blank: xset -display :8 s activate - The same for DPMS: xset -display :8 dpms standby/suspend/off So, :8 simply does the same as :0 does. That way, intel-virtual-output doesn't have to care about any fake events or something. If :0 doesn't go blank, neither does :8. I don't know whether :0 reports the events needed, however. Or if there are any other pitfalls.
Comment 3 Chris Wilson 2016-01-02 21:35:08 UTC
Created attachment 120768 [details] [review] Select ExposeEvents on destination Compile-tested only...
Comment 4 Chris Wilson 2016-01-02 21:47:37 UTC
Ok, screen blanking seems to be communicated through the XScreenSaverNotifyEvent, which should be enough to turn off the remote display in conjunction with the local display. *crosses fingers*
Comment 5 Chris Wilson 2016-01-02 21:54:09 UTC
On the other, there are no corresponding DPMS events. Hmm.
Comment 6 Chris Wilson 2016-01-03 09:56:48 UTC
Step 1: commit 082a57e6eb3b364aad681f137364a34988c4af5d Author: Chris Wilson <firstname.lastname@example.org> Date: Sat Jan 2 21:29:58 2016 +0000 tools/intel-virtual-output: Respond to expose events on target displays If the destination screen is exposed (for example screensavers), we need to redraw. So enable the ExposeEvent on the target and synthesize damage to any clones on that display in order to trigger a redraw. Reported-by: Raffael Herzog <email@example.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=93562 Signed-off-by: Chris Wilson <firstname.lastname@example.org>
Comment 7 Chris Wilson 2016-01-03 10:59:56 UTC
Created attachment 120773 [details] [review] Propagate screen blanking Can you please test this (pass -v and capture the debug output)? At the very least it should disable the automatic screen blanking on the target.
Comment 8 Raffael Herzog 2016-01-04 13:16:06 UTC
Uff. I don't have any devel packages installed … :( Is there any other way to test it? A precompiled version? Or what -devel packages do I need?
Comment 9 Chris Wilson 2016-01-04 13:35:56 UTC
I just tend to the equivalent of "apt-get build-dep xserver-xorg-video-intel" when I set a new machine for compilation.
Comment 10 Raffael Herzog 2016-01-04 15:19:16 UTC
patch -p1 --dry-run <0001-tools-intel-virtual-output-Propagate-screen-blanking.patch checking file configure.ac Hunk #1 succeeded at 285 (offset -6 lines). checking file tools/virtual.c Hunk #5 succeeded at 1236 (offset -24 lines). Hunk #6 succeeded at 1625 (offset -35 lines). Hunk #7 succeeded at 1642 (offset -35 lines). Hunk #8 succeeded at 2388 (offset -73 lines). Hunk #9 succeeded at 3358 (offset -109 lines). Hunk #10 succeeded at 3438 (offset -110 lines). Hunk #11 FAILED at 3627. Hunk #12 FAILED at 3652. 2 out of 12 hunks FAILED Using 2.99.917 (from the openSUSE source package from factory (X11:XOrg) for Leap 42.1).
Comment 11 Chris Wilson 2016-01-04 15:31:24 UTC
Checking out http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ shouldn't take 2 minutes :) Anyway, you can ignore the last 2 chunks rejected - it should function without those.
Comment 12 Raffael Herzog 2016-01-04 16:42:08 UTC
Created attachment 120798 [details] output of intel-virtual-output -v In my /etc/bumblebee/xorg.conf.nvidia: Section "ServerLayout" Identifier "Layout0" Option "AutoAddDevices" "true" Option "AutoAddGPU" "false" # turn off integrated screen saver Option "BlankTime" "1" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection Section "Device" Identifier "DiscreteNvidia" Driver "nvidia" VendorName "NVIDIA Corporation" Option "ProbeAllGpus" "false" Option "NoLogo" "true" Option "UseEDID" "true" # Option "UseDisplayDevice" "none" Option "AllowEmptyInitialConfiguration" "true" EndSection $ make ... $ ./tools/intel-virtual-output -v >ivo.out & $ xrandr --output VIRTUAL6 --right-of LVDS1 --mode VIRTUAL6.642-1920x1200 The external monitor still went blank after one minute.
Comment 13 Chris Wilson 2016-01-04 16:51:58 UTC
That debug log doesn't contain any of the new debug messages for the screen saver. Hmm.
Comment 14 Raffael Herzog 2016-01-04 17:05:32 UTC
Created attachment 120799 [details] output of intel-virtual-output -v Oops, I didn't apply the patch, just cloned the git repo and compiled master. The same thing again, this time, I applied the patch. The output looks very much the same, though. The repaint works fine, BTW. Note that I'm not installing the driver, I just run make and use that intel-virtual-output binary.
Comment 15 Chris Wilson 2016-01-04 18:17:39 UTC
Still nothing. Ok, I've pushed the patch (since I'm fairly confident it didn't break anything at least): commit 8e987511f0f190115e2587a94922b766d4f8719a Author: Chris Wilson <email@example.com> Date: Sat Jan 2 21:29:58 2016 +0000 tools/intel-virtual-output: Propagate screen blanking When attaching to a target display, disable the builtin screen blanking (equivalent to xset -d :8 s off, or setting Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" in the target xorg.conf). Then listen to the ScreenSaver notify events on the host and forward the activations/resets to the targets. This should then keep all the screen blanking in sync. Reported-by: Raffael Herzog <firstname.lastname@example.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93562 Signed-off-by: Chris Wilson <email@example.com> So if you run git pull, recompile, then ./tools/intel-virtual-output <blah>
Comment 16 Raffael Herzog 2016-01-06 15:59:10 UTC
Created attachment 120835 [details] output of intel-virtual-output -v
Comment 17 main.haarp 2017-06-26 17:14:09 UTC
Created attachment 132259 [details] i-v-o log This doesn't appear to work for me. While the i-v-oed display does not blank on its own (good), it also doesn't blank when the Intel display does (bad). Attached is an i-v-o log. It was started, then the screen was blanked manually (xset dpms force off) and unblanked shortly thereafter.
Comment 18 main.haarp 2017-06-26 17:16:01 UTC
Addendum: Sorry, I was using wrong terms. What I meant is that the i-v-oed display blanks, but doesn't switch off using dpms.
Comment 19 Martin Peres 2019-11-27 13:41:44 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/82.