GNOME Bugzilla – Bug 707570
New designs don't allow me to turn off monitors
Last modified: 2013-09-25 12:46:50 UTC
As summary says (or maybe it's allowed, but I don't find it) This is a problem in part for testing, in part for power saving (think dock but without closing the lid), but most important for when the HW limits force us to turn off one monitor (and we should let the user choose which one)
As far as I know this is by design. The idea was that you can close the lid for laptops, and for other kinds of displays you can unplug them.
A few use cases for having the option in GUI: 1. If I am required to close the laptop lid, my laptop unnecessarily heats up more. 2. If I am required to close the laptop lid, I can't access multimedia (or other function) keys. 3. If I am required to close the laptop lid, I can't access the power button. 4. I have two user accounts - "kparal" and "gamer". I use "kparal" for serious work, where I use spanned displays with a lot of work space. I use "gamer" account with one display turned off, so that my games run faster (it's a big difference; also I assume a composition unredirection doesn't work with multiple displays, which is slowing down games even more). Without a GUI option, I will be required to physically close or open the display every time I switch between accounts. Really? Guys, in your fight for zero configuration options, you're really going too far. Please stay with us in the sane world, where your userbase is. Thanks a lot.
*** Bug 707726 has been marked as a duplicate of this bug. ***
Utterly agree with Kamil Páral
It is probably worth noting that it is still possible to use the shortcut keys on the keyboard to turn on or off the displays.
Thomas, you are assuming that all laptops have those shortcut keys. The reallity is that the majority of laptops has not them
Hi folks, with the old Display settings I had configured that my external display is primary and my build-in display is disabled. Whenever I docked my Thinkpad this was automatically applied and I had only my 30" screen active. After undocking the internal screen was reactivated. That is what I call easy :) I have a T61 Thinkpad and I really can't use both monitors at the same time. The graphics card is not strong enough. Anyway it worked very well with the old settings, so I consider this a regression and would encourage you to bring the feature back. Toward closing the lid: * That currently has the effect that the internal monitor is still on, although display settings says Lid closed. Noticed that a short while ago when one of my started applications just was missing, but appeared on the overview. It was open on the "Lid closed" Screen. I understand that this is not the planned behaviour, right? * Another point is that my machine has according to specs a 45W processor and a graphics card that has about the same power consumption. If the lid is open the graphics card runs a lot cooler. Please restore the disabled option in the Display settings. Thank you, Michael
I think we should perhaps consider this for a last minute fix for 3.10
*** Bug 708413 has been marked as a duplicate of this bug. ***
I apologize for opening the duplicate bug. Apparently I didn't search well enough. I would like to add a few points to the list of reasons expressed above for fixing this regression. If I close my laptop's lid as a work-around, I no longer have access to my laptop's keyboard and touchpad (which I use). Also, my laptop does not seem to have a function button on the keyboard that allows me to disable the laptop's screen. Finally, my laptop's wireless antenna is located in its lid so I get better reception when the lid is open.
(In reply to comment #2) ... > Guys, in your fight for zero configuration options, you're really going too > far. Please stay with us in the sane world, where your userbase is. Thanks a > lot. Kamil, you clearly haven't understood the motivation behind this aspect of the design, nor the attitude of those of us who are working on it. This comment is pretty rude. Try and stick to the issues please.
The omission of the power off option was motivated by a number of factors: * I was hoping that physical controls (laptop lids, power buttons on monitors) already provided the required functionality, and that we could reduce the complexity of what is already a complex UI by relying on those instead. * Power off has a fairly poor relationship with user intent. The most common case for powering off a display is probably going to be to power off a laptop display while using an external monitor. In that case the intention is better described as "use the external only" rather than "turn off laptop display" (especially since you are implicitly changing the primary display). * Having power off creates some tricky interaction situations which I had hoped to avoid. That said, this was a fairly speculative design move and I think we probably do have an enough evidence to say that some kind of option is required for powering off a display. Of these, the most compelling case is the one where someone wants to use an external display with a laptop that isn't connected to the power. While it isn't ideal, adding a power off option to the list of modes is probably the best solution for now (the description read can read something like "Don't use this display"). A couple of notes about this: If there is only one powered-on display, the mode should not be visible in its settings dialog (since we essentially force it to be the primary display). The settings dialog for the powered off display should still display the list of modes.
I agree that 'don't use this' is better than 'off'
(In reply to comment #11) > Kamil, you clearly haven't understood the motivation behind this aspect of the > design, nor the attitude of those of us who are working on it. This comment is > pretty rude. Try and stick to the issues please. Allan, I've always felt that emotions are an integral part of bug reports. I've very much tried to avoid any offensive language. There are lots of subtleties in English language, so if I failed, I'm sorry. I have to admit that my frustration from some past decision definitely played its role (but that brings us back to emotions). As for motivation, the drive for eliminating options (truly eliminating, not just hiding from UI) is the main theme of several past GNOME releases, so it's easy to consider this yet another example. Explanation is always welcome, thank you. And now to the point... (In reply to comment #12) > In that case the intention is better > described as "use the external only" rather than "turn off laptop display" I believe having this option would solve most of the use cases mentioned here. I still think that per-display toggle is a better solution, but having at least this option would definitely help. > While it isn't ideal, adding a power off option to the list of modes is > probably the best solution for now (the description read can read something > like "Don't use this display"). In so many places I've read that using negative expressions in on-off toggles is very counter-intuitive. And my personal experience confirms that. My brain works much better with: Use this display... ✔ rather than: Don't use this display... ✘ The latter is double negative for me, and I spend a second more translating the meaning.
(In reply to comment #14) > > As for motivation, the drive for eliminating options (truly eliminating, not > just hiding from UI) is the main theme of several past GNOME releases, so it's > easy to consider this yet another example. Explanation is always welcome, thank > you. This one paragraph of yours already makes me want to dismiss your whole point again. I can only recommend that you keep your emotions and your interpretations of our motives out of your bug reports. We will have a much more positive interaction, and you'll achieve more. > Use this display... ✔ > > rather than: > > Don't use this display... ✘ > > The latter is double negative for me, and I spend a second more translating the > meaning. But those are not the alternatives here. I'll be Use as primary [ ] Use as secondar [ ] Mirror [ ] Don't use this display [ ]
Created attachment 255397 [details] [review] display: add an option to turn off the display
Review of attachment 255397 [details] [review]: Works nicely in my testing. Would be slightly nicer to break this up into two patches - first introduce priv->config_grid, then add the off option. But not a big deal
There seems to be some other unrelated changes in the patch; like, why: - cairo_set_source_rgb (cr, 0.7, 0.7, 0.7); + cairo_set_source_rgb (cr, 0.3, 0.3, 0.3); ? I'm not fully parsing some of the logic, like it seems that we add the "Turn off" only when !active? Not sure. Anyways...if Matthias is +1 on this then I have a tenative +1, but would be happier with a less intrusive patch. Or sign off from another gnome-c-c maintainer.
Attachment 255397 [details] pushed as 34c4320 - display: add an option to turn off the display
(In reply to comment #14) > (In reply to comment #11) > > Kamil, you clearly haven't understood the motivation behind this aspect of the > > design, nor the attitude of those of us who are working on it. This comment is > > pretty rude. Try and stick to the issues please. > > Allan, I've always felt that emotions are an integral part of bug reports. I've > very much tried to avoid any offensive language. There are lots of subtleties > in English language, so if I failed, I'm sorry. I have to admit that my > frustration from some past decision definitely played its role (but that brings > us back to emotions). If you are interested in best practices when reporting bug reports, I would strongly recommend this presentation from GUADEC 2013: http://www.superlectures.com/guadec2013/how-to-not-report-your-ux-bug > As for motivation, the drive for eliminating options (truly eliminating, not > just hiding from UI) is the main theme of several past GNOME releases, so it's > easy to consider this yet another example. Explanation is always welcome, thank > you. That's absolutely not the case - something which is clear if you read the release notes. It's your assumption about our motivations that I find rude - you have no evidence about what motivated this specific design decision, and yet you criticise us based on what you think those motivations are (and yes, you got them wrong). Whether you realise it or not, those assumptions belittle the work we do.
Just went back here to say thanks for getting this setting back. I've missed it in beta stage and having it in the final version is very handy.
(In reply to comment #20) > If you are interested in best practices when reporting bug reports, I would > strongly recommend this presentation from GUADEC 2013: > > http://www.superlectures.com/guadec2013/how-to-not-report-your-ux-bug I am, I've been there in person. Even though it was not covered in the talk, I believe that question "How do you feel" should be a part of a bug report. Also, it might have been interesting if the talk covered both parties - reporters and also developers. The right approach has to be applied by both sides. > That's absolutely not the case - something which is clear if you read the > release notes. It's your assumption about our motivations that I find rude - > you have no evidence about what motivated this specific design decision, and > yet you criticise us based on what you think those motivations are (and yes, > you got them wrong). Whether you realise it or not, those assumptions belittle > the work we do. It would be great to more transparent design and development process, e.g. frequent blog posts about these controversial decisions. People would not then make wrong assumptions. Máirín Duffy (also a designer) has put it nicely here: https://lists.fedoraproject.org/pipermail/desktop/2013-September/008197.html That being said, I don't think that there's too little communication in term of blog posts. I read quite often about some new apps and Matthias's change summaries and it's great. But I do feel that many potential friction areas are missing in there. Like this, or shield, or suspend, or password fields, or X clipboard... it would be great to read about it in advance, from gnome developers, with thoughts, ideas, explanations, ... and a possibility of discussion in blog comment section.