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
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.
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.
Created attachment 120768 [details] [review] Select ExposeEvents on destination Compile-tested only...
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*
On the other, there are no corresponding DPMS events. Hmm.
Step 1: commit 082a57e6eb3b364aad681f137364a34988c4af5d Author: Chris Wilson <chris@chris-wilson.co.uk> 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 <herzog@raffael.ch> References: https://bugs.freedesktop.org/show_bug.cgi?id=93562 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.
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?
I just tend to the equivalent of "apt-get build-dep xserver-xorg-video-intel" when I set a new machine for compilation.
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).
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.
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.
That debug log doesn't contain any of the new debug messages for the screen saver. Hmm.
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.
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 <chris@chris-wilson.co.uk> 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 <herzog@raffael.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93562 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> So if you run git pull, recompile, then ./tools/intel-virtual-output <blah>
Created attachment 120835 [details] output of intel-virtual-output -v
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.
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.
-- 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.
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.