Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turn off screen saver in default configuration. #679

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Abnaxos
Copy link

@Abnaxos Abnaxos commented Aug 1, 2015

I noticed this issue while trying to calibrate a second screen connected using intel-virtual-output unattendedly. The screen kept going black after 10 minutes without any keyboard/mouse input, while ArgyllCMS/dispcalGUI was trying to measure colors. Disabling the screen saver on display :8 fixes this.

Probably, the same thing should be done for the nouveau, but I can't test this.

I noticed this issue while trying to calibrate a second screen connected using
intel-virtual-output unattendedly. The screen kept going black after 10
minutes without any keyboard/mouse input, while ArgyllCMS/dispcalGUI was trying
to measure colors. Disabling the screen saver on display :8 fixes this.

Probably, the same thing should be done for the nouveau, but I can't test this.
@Lekensteyn
Copy link
Member

The BlankTime setting affects the X screensaver (and can apparently be set via the -s option to Xorg). The others are only relevant if there is actually a monitor connected to the output (your case?). (See man xorg.conf and Xorg -help).

For your specific case you can achieve it with DISPLAY=:8 xset -dpms s off which is (I think) more suitable than setting it globally.

@Abnaxos
Copy link
Author

Abnaxos commented Aug 3, 2015

Yes, I did connect an external monitor. I don't think, these settings are relevant for the standard usecase of Bumblebee, being able to use NVidia's GPU for 3D rendering on the laptop's built-in display. But these lines also don't hurt, AFAICS.

Then again, I just noticed that Option "UseDisplayDevice" "none" must to be specified for using Bumblebee for 3D acceleration on the main display – X will exit otherwise because no monitor found.

Many Laptops have their DisplayPort hard-wired to the NVidia card, so it's unusable while only using the integrated GPU. intel-virtual-output now provides a proper solution to this: It starts a bumblebeed (if necessary), reads the info from the connected monitor, creates a virtual display for it and redirects all output to this virtual display to :8.

So, the Intel driver tools now do their job in enabling the use of the DP even if it's wired to the NVidia card. It works flawlessly: Connect the monitor to DP, start intel-virtual-output and set the external monitor as second display in your desktop settings.

We're now just a small step from having Bumblebee working in flawlessly in both usage scenarios. There's just one edit to /etc/bumblebee/Xorg.conf.nvidia that I have to do depending on what I'd like to do next: (Un)Comment Options "UseDisplayDevice" "none". It would be great to find a solution to eliminate that last edit, too.

As of this pull request: I suggest to drop it because it's incomplete. However, this should be documented as this effect may confuse people. The built-in screen saver of display :8 isn't the first thing you think of, when your external monitor suddenly turns black even though you thought you turned off the screen saver (on display :0).

Shall I raise a new issue for the wrapping up of this new usage scenario? As I outlined above, using Bumblebee to enable the DisplayPort, additionally to enabling 3D acceleration, is almost ready for every-day use. It would be great, if we could wrap this up.

@amonakov
Copy link
Contributor

amonakov commented Aug 3, 2015

@Abnaxos, UseDisplayDevice can be more usefully replaced with AllowEmptyInitialConfiguration on sufficiently new drivers; please see 327ddfc

@Abnaxos
Copy link
Author

Abnaxos commented Aug 4, 2015

Thanks, that works perfectly. No touching the xorg.conf.nvidia anymore while both scenarios just work.

That leaves us at the core of my pull request: Turn off any built-in screen savers. It seems to be just irrelevant when using Bumblebee for 3D acceleration, but fixes the issue that the monitor connected to the DisplayPort turns black after 10 minutes without any user input (because the user's watching a movie or calibrating the monitor or something).

We could also add it as comment with an explanation of the issue, so people can just uncomment it.

@amonakov
Copy link
Contributor

amonakov commented Aug 4, 2015

This issue is specific to Bumblebee, correct? I mean, normally software such as dispcalgui can (and probably will) just turn off the screen saver on their own, but in this specific situation it doesn't work, because intel-virtual-output does not forward it to the secondary X server.

If that's the case, I wonder how hard would be to fix that in intel-virtual-output (which would seem to be the correct place for the fix).

That said, it might still make sense for us to merge a change that adds commented-out options to turn off blanking.

@Abnaxos
Copy link
Author

Abnaxos commented Aug 4, 2015

Exaktly. dispcalGUI turns off the screen saver, but the external monitor (via display :8) still turns black after 10mins without input, while the monitor connected to the Intel GPU doesn't.

And yes, you're right, it's probably rather an issue of intel-virtual-output, it should forward that correctly.

But still, this is a viable workaround when anyone runs into this problem.

@ArchangeGabriel
Copy link
Member

@Abnaxos Could you rebase your pull request against develop? We don’t merge things in master. Also, I’m not sure whether this should be commented by default or not (since for now on you still have to edit to change UseDisplayDevice).

@ArchangeGabriel
Copy link
Member

Also, have you reported against intel-virtual-output?

@Abnaxos
Copy link
Author

Abnaxos commented Dec 28, 2015

Things changed, it doesn't work at all anymore. :(

I tried openSuSE Tumbleweed for a short period, now I'm on Leap 42.1. Both have in common that they upgrade to X.org 1.17 (13.2 uses 1.16), it seems that intel-virtual-output doesn't work at all with these, although the issue is closed at freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=89172

I'm now playing around with X.org 1.18.0 from Factory (repo X11:XOrg for Leap). This looks a bit better: intel-virtual-output doesn't exit with "fatal IO error 11", xrandr can see the connected monitor, but I'm unable to add it. I'm currently investigating this further.

Anyway, this particular issue seems obsolete to me, as things have moved on. I'll have a look at it again when the DisplayPort is once again usable at all. There are some much more fundamental issues right now — huge regressions, actually.

@ArchangeGabriel
Copy link
Member

OK, I’m closing this then, feel free to report any progress here though.

@Abnaxos
Copy link
Author

Abnaxos commented Dec 28, 2015

Works fine with X.org 1.18.0 now. Unless this X server package keeps crashing (never did by now), I'm happy with this setup. intel-virtual-output flickers the gamma of the main screen for a while, but this stops after a few seconds — I can live with that. It didn't work when I tried a TV and HDMI (which I can't test right now, will try again), but works fine with a computer monitor and a DisplayPort connection. Good enough for my needs.

About the screen saver problem:

  • Mouse and keyboard events are forwarded just fine
  • Screensaver suppression from applications like dispcalGUI is not forwarded to :8
  • If :8 is configured to blank/suspend/off after 1 minute without any input, it will do so
  • If :0 turns the display off, this won't have any effect on :8
  • If :8 wakes up, the compositor (I guess) isn't informed about that and the second screen stays black until you force a repaint somehow (moving a window works works with kwin); partial repaints happen when an application repaints something in its window

intel-virtual-output should take care of these things, I agree. But I still think, adding a (commented out?) section to xorg.conf.* is the right thing to do, additionally. As I wrote, there are more fundamental issues right now and those have priority (as intel developer, I'd currently acknowledge the issue but continue working on the fundamental stuff), so I don't think this will be fixed soon.

Simply turning the screen saver off on :8 is an acceptable workaround. Being able to configure power saving of both screens separately might even be considered a feature. But most importantly, there's an explanation of what exactly happened when the screen turned black, and how to fix/configure it, right in the configuration file.

I'll still report an issue to the Intel driver developers.

@Abnaxos
Copy link
Author

Abnaxos commented Dec 28, 2015

Note: That flickering I described is being caused by Oyranos (KDE's color management). It seems to be resetting color profiles repeatetly, maybe due to some superfluous updates. Without Oyranos, intel-virtual-output probably still does whatever it's doing, but it's not visible.

@ArchangeGabriel
Copy link
Member

OK, so please redo this PR against develop branch with more comments about those added lines, and comment them by default. Also add a link to upstream bug report.

@ArchangeGabriel
Copy link
Member

Reopening in the meantime in order not to forget this.

This also adds a comment that describes the issue that these options fix.
@Abnaxos
Copy link
Author

Abnaxos commented Jan 2, 2016

Report against intel-virtual-output at https://bugs.freedesktop.org/show_bug.cgi?id=93562

I'm still convinced that under no circumstances screen blanking on Bumblebee's X-server makes sense. These options should not be commented out.

@ArchangeGabriel
Copy link
Member

OK, from this point of view that’s right. But could you redo this PR against develop?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants