After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773645 - [ui-review] Add a way to keep the display turned on during lock
[ui-review] Add a way to keep the display turned on during lock
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: Privacy
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: Rui Matos
Control-Center Maintainers
triaged
: 710904 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-10-28 20:55 UTC by Stephen Michel
Modified: 2021-06-09 16:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Mockup covering the changes. (76.07 KB, image/png)
2016-10-30 15:01 UTC, Juraj Fiala
  Details
Mockup v2 (75.11 KB, image/png)
2016-10-30 15:42 UTC, Juraj Fiala
  Details
Mockup v2 - source (46.29 KB, image/svg+xml)
2016-10-30 15:42 UTC, Juraj Fiala
  Details
Screen Lock new switch (42.80 KB, image/png)
2016-12-01 07:02 UTC, xiaoguang wang
  Details
power: Keep display on after locking screen (2.67 KB, patch)
2016-12-01 07:05 UTC, xiaoguang wang
needs-work Details | Review
lock-screen: Keep display on after locking screen (1.86 KB, patch)
2016-12-01 07:07 UTC, xiaoguang wang
none Details | Review
privacy: Keep display on after locking screen (3.05 KB, patch)
2016-12-01 07:08 UTC, xiaoguang wang
needs-work Details | Review
Keep display on after locking screen (1.27 KB, patch)
2016-12-01 07:09 UTC, xiaoguang wang
needs-work Details | Review
gnome-shell-not-fadeto-blank-when-lock-screen.patch (3.56 KB, patch)
2017-03-13 01:22 UTC, xiaoguang wang
none Details | Review

Description Stephen Michel 2016-10-28 20:55:10 UTC
This is a duplicate of bug #710904, but it is cluttered to the point where it will be hard to actually discuss my proposed changes here.

## Summary of that bug:

### Things that people would like to be able to do:

- Info always displayed (clock, notifications, controls)
- Screen Saver / slide show / aesthetics
- Turning off after a short delay (as if you'd wiggled the mouse) is a much better UX than turning off *immediately* on lock.

### Reasons why they want to do this with the screen locked:

- Company requirement to lock the screen when leaving desk
- Long wait for monitor to turn on
  - If the user starts typing the password immediately they never got to see any of the info on the shield
- Bad for lifespan of older monitors
- Lock screen while having a short conversation, wants screen to be on upon return -- a common (recurring) occcurance at work

## Design - Theory:

When should the screen lock? Boils down to security vs convenience of not having to type a password. Influences:
- "Am I in a secure environment?"
- "Does my work have a policy about this?"
When should the screen blank? Boils down to power savings vs functionality. Influences:
- "Do I want the screen to turn off when I am away from the computer?"
- "After how long of inactivity should I be assumed to be away from the computer?"
- "If I lock the screen, is that an indication that I am away from the computer?"

If a user goes afk, then there's one of two scenarios:
    A. They have walked away from the computer entirely and therefore it's OK to blank the screen (and possibly lock it).
    B. They are still nearby, in which case they might want the screen on or they might want it off.

If a user locks their screen manually, we don't know whether they are going to walk away or stay nearby. I think it is most reasonable to assume they are going to walk away (or that they are nearby and want the screen off), but to immediately assume that they want the screen on if they move the mouse at any time while the screen is locked.

## Design - Suggested implementation:

Power / Dim screen after inactive for [1m, 5m, ..., 3h, never]

Power / Blank screen after dim for [Immediately, 1m, ..., 3h, never]

Privacy / Screen lock / Lock when screen turns off [Never, Screen dims, Screen turns off]

When the screen locks (manually or automatically), blank the screen after 3 seconds. If the user moves the mouse at any time while the screen is locked (including those 3 seconds), wait "Blank screen after dim for" amount of time to blank it again.

## Next Steps

I hope to receive feedback on this proposal so we can continue to polish it. If you disagree with a design decision, it would be great if you'd note whether you disagree with the theory or whether you think the implementation doesn't fit the theory well.

Then we can make mockups and hopefully at that point with the design work out of the way it will be low time/effort for someone (gnome dev or otherwise) to implement this.
Comment 1 Juraj Fiala 2016-10-30 13:47:31 UTC
I have to say I really like how your design ended. However:

> When the screen locks (manually or automatically), blank the screen after 3 seconds. If the user moves the mouse at any time while the screen is locked (including those 3 seconds), wait "Blank screen after dim for" amount of time to blank it again.

This should only happen we locked manually, as it defeats the option of having the screen lock and dim and the same time (which is an idea I really love, as it both save energy and shows information).

I also think we should introduce another option:

Power / Energy saving in lock screen [Always (default), on battery, never]:
 - always would be the current behaviour - turning the screen off immediately after lock and a few seconds after interaction
 - on battery would only do the above on battery, and use your proposed behaviour otherwise
 - never would use your proposed behaviour all the time

We could explain this with a short description underneath, e.g. "Turn screen off as soon as possible in the lock screen".

This comes off a real life example. When I'm on battery, and I want the screen to be on I want it to stay on (like when you're reading notes in class) and eventually turn off (and suspend after some time to save energy). But when I lock the screen I want the computer to stay on but the screen to be off, and only turn it on if I need to and even so for a limited time. This is very useful for playing music or downloading something.


Some other suggestions:

 - we should rename the "Privacy" section to "Privacy & Security", which is more intuitive (locking is more associated with security than privacy imho), solving the problem from the user testing paper

 - "Blank screen" should be "Turn screen off" to prevent confusion

 - "Lock when screen turns off" should be "Lock" [Never, When screen dims, When screen turns off"
Comment 2 Juraj Fiala 2016-10-30 15:01:22 UTC
Created attachment 338793 [details]
Mockup covering the changes.

This should cover all the changes, please point out if I missed something and/or provide feedback, I am very new to UI design.

If someone wants the source feel free to ping me.
Comment 3 Stephen Michel 2016-10-30 15:16:17 UTC
## Revised Design

Power / Dim screen after inactive for [5s, 25s, 1m, 5m, ..., 3h, never]

Power / Turn off screen after dim for [Immediately, 5s, 25s, 1m, ..., 3h, never]

Privacy / Screen lock / Lock [Never, When screen dims, When screen turns off]

When the screen locks (manually), blank the screen after 3 seconds. If the user moves the mouse at any time while the screen is locked (including those 3 seconds), wait "Blank screen after dim for" amount of time to blank it again.

---

(In reply to Juraj Fiala from comment #1)
> > When the screen locks (manually or automatically), blank the screen after 3 seconds. If the user moves the mouse at any time while the screen is locked (including those 3 seconds), wait "Blank screen after dim for" amount of time to blank it again.
> 
> This should only happen we locked manually, as it defeats the option of
> having the screen lock and dim and the same time.

You are correct. This was something I missed updating when I changed it from a boolean, "lock screen when it turns off" to the current 3-state version.

> I also think we should introduce another option:
> 
> Power / Energy saving in lock screen [Always (default), on battery, never]:
> -snip-
> When I'm on battery, and I want the screen to be on I want it to stay on (like
> when you're reading notes in class) and eventually turn off (and suspend after
> some time to save energy). But when I lock the screen I want the computer to
> stay on but the screen to be off, and only turn it on if I need to and even so
> for a limited time. This is very userful for playing music or downloading
> something.

I think features that selectively save power on battery are out of the scope of this issue and would be better addressed by power profiles or something like that.

1. Is there a configuration that works for 100% of my *on battery* use cases?
2. Is there a configuration that works for 100% of my *on AC* use cases?

If the answers to both of those questions are "yes", then that's all we need to get out of this bug, even if the configurations in question are different. FWIW this is a really, really hard pitfall to avoid. I keep typing things, then realizing "wait, that's really only an issue if you have to share profiles between battery and AC power."

So, for your example, would setting the screen dim timer to 10 minutes and screen off timer to 5 seconds solve your issue?

> Some other suggestions:
> 
>  - we should rename the "Privacy" section to "Privacy & Security", which is
> more intuitive (locking is more associated with security than privacy imho),
> solving the problem from the user testing paper

Although I agree, I think think is out out of scope.

>  - "Blank screen" should be "Turn screen off" to prevent confusion
>
>  - "Lock when screen turns off" should be "Lock" [Never, When screen dims,
> When screen turns off"

+1. Definitely a lot of opportunities for wording improvements here.

(In reply to Juraj Fiala from comment #2)
> Created attachment 338793 [details]
> Mockup covering the changes.

Nice!

> This should cover all the changes, please point out if I missed something
> and/or provide feedback, I am very new to UI design.

Any reason you chose a slider for "dim screen after" and a drop-down for "turn screen off after?" If not, I'd suggest using the same picker, for consistency.

> If someone wants the source feel free to ping me.

I'd err on the side of including the source, if you want others to play around with it. It removes a barrier to contributing.
Comment 4 Juraj Fiala 2016-10-30 15:32:52 UTC
(In reply to Stephen Michel from comment #3)
> ## Revised Design
> 
> Power / Dim screen after inactive for [5s, 25s, 1m, 5m, ..., 3h, never]
> 
> Power / Turn off screen after dim for [Immediately, 5s, 25s, 1m, ..., 3h,
> never]

Do we have a use case for such small values?

> > I also think we should introduce another option:
> > 
> > Power / Energy saving in lock screen [Always (default), on battery, never]:
> > -snip-
> I think features that selectively save power on battery are out of the scope
> of this issue and would be better addressed by power profiles or something
> like that.
> 
> 1. Is there a configuration that works for 100% of my *on battery* use cases?
> 2. Is there a configuration that works for 100% of my *on AC* use cases?
> 
> If the answers to both of those questions are "yes", then that's all we need
> to get out of this bug, even if the configurations in question are
> different. FWIW this is a really, really hard pitfall to avoid. I keep
> typing things, then realizing "wait, that's really only an issue if you have
> to share profiles between battery and AC power."
> 
> So, for your example, would setting the screen dim timer to 10 minutes and
> screen off timer to 5 seconds solve your issue?

Yeah, you're right, I suggest removing the switch and just applying the proposed changes when on AC.

However I don't think those two values should work like that. See below.
 
> Any reason you chose a slider for "dim screen after" and a drop-down for
> "turn screen off after?" If not, I'd suggest using the same picker, for
> consistency.

Yes, the problem is that when you have two drop-downs you could make the screen dim after it blacks out, which would be very confusing and useless. This way the slider is relative to the option below, see the note beside it.

> > If someone wants the source feel free to ping me.
> 
> I'd err on the side of including the source, if you want others to play
> around with it. It removes a barrier to contributing.

I looked elsewhere and I only saw uploaded PNG's, but yeah, it's a good idea.

I'll upload an updated mockup in a mo.
Comment 5 Juraj Fiala 2016-10-30 15:42:13 UTC
Created attachment 338794 [details]
Mockup v2

New mockup sans the powersave switch and some minor fixes.
Comment 6 Juraj Fiala 2016-10-30 15:42:49 UTC
Created attachment 338795 [details]
Mockup v2 - source
Comment 7 Stephen Michel 2016-11-08 17:42:28 UTC
## Revised Design

Power / Consider me inactive after [1m, 5m, ..., 3h, never]
        (or when screen is locked)
        
Power / Dim screen when inactive [switch]

Power / Turn off screen after inactive for [15s, 1m, ..., 3h, never]

Privacy / Screen lock / Lock when screen turns off [switch]

When the screen locks (manually), blank the screen after 3 seconds. If the user moves the mouse at any time while the screen is locked (including those 3 seconds), wait "Turn off screen after inactive for" amount of time to blank it again.
Comment 8 xiaoguang wang 2016-12-01 07:02:36 UTC
Created attachment 341112 [details]
Screen Lock new switch

Add a switch in Screen Lock dialog.

When switch turns on, and power is plugged in, display will not turn off.

When switch turns on, and power is on battery, display will turn off like before.

Default is off.
Comment 9 xiaoguang wang 2016-12-01 07:05:17 UTC
Created attachment 341113 [details] [review]
power: Keep display on after locking screen

Add a switch in "Screen Lock" dialog. When switch turns on, display

keep on after locking screen with power plugged in.
Comment 10 xiaoguang wang 2016-12-01 07:07:36 UTC
Created attachment 341114 [details] [review]
lock-screen: Keep display on after locking screen

Add a switch in "Screen Lock" dialog. When switch turns on, display

keep on after locking screen with power plugged in.
Comment 11 xiaoguang wang 2016-12-01 07:08:29 UTC
Created attachment 341115 [details] [review]
privacy: Keep display on after locking screen

Add a switch in "Screen Lock" dialog. When switch turns on, display

keep on after locking screen with power plugged in.
Comment 12 xiaoguang wang 2016-12-01 07:09:18 UTC
Created attachment 341116 [details] [review]
Keep display on after locking screen

Add a switch in "Screen Lock" dialog. When switch turns on, display

keep on after locking screen with power plugged in.
Comment 13 Ariel 2016-12-11 21:14:48 UTC
Spent a long time poking around GDM settings, X11 settings, logind settings, dconf etc to find the timer that makes the gnome lock-screen to timeout and turn off the display so fast.

Eventually landed here: https://unix.stackexchange.com/questions/272005/change-gdm-display-timeout/329672#329672

and then https://bugzilla.gnome.org/show_bug.cgi?id=710904,
and in this bug. 

I'm not so annoyed by the immediate turn-off of the display when invoking screen lock (in fact at work I created a powershell script so windows does the same as gnome), but I do agree this should be controllable to a reasonable degree. What I do find annoying is that when waking up the display to log back in, the 5-second (or so) timeout still applies, and often (in my typical use case), it takes me more than 5 seconds to start typing after moving the mouse, so the backlight of the display is turned off again and then on again. This doesn't really save any power and it doesn't seem good for the display either. 

Great to see there is a patch with a setting and new UI and looking forward to seeing this included in gnome 3.24
Comment 14 Joshua Austill 2017-02-07 19:30:38 UTC
I'm so annoyed by this bug.  I have 2 monitors hooked up that go to sleep and take a LONG time to turn back on.  I am required by work policy to lock my screen, so I loose a lot of time to just get a soda, etc.  This proposal looks great to me.  I'd like my lock screen to stay up for 2 hours, and THEN go to sleep on AC power.  On battery power, I'd like it to be about 5 minutes.  

If there is anything I can do to help test this let me know.  I am a software developer for a living so I have a very good understanding of how to help out if needed.

Thanks y'all for putting this together!
Joshua
Comment 15 Florian Müllner 2017-02-07 20:24:28 UTC
Review of attachment 341114 [details] [review]:

This is an extremely lazy patch ("Add a switch in "Screen Lock" dialog? No such thing in gnome-shell) which doesn't even use the setting added to gsettings-desktop-schemas/gnome-control-center. So no, not in this form.
Comment 16 Florian Müllner 2017-02-07 20:25:59 UTC
Given that a great deal of the mockups/patches deal with exposing a setting in gnome-control-center, let's move this there for design review.
Comment 17 Michael Catanzaro 2017-02-07 23:18:40 UTC
*** Bug 710904 has been marked as a duplicate of this bug. ***
Comment 18 Bastien Nocera 2017-02-14 02:25:13 UTC
Review of attachment 341116 [details] [review]:

::: schemas/org.gnome.desktop.screensaver.gschema.xml.in
@@ +24,3 @@
+      <default>false</default>
+      <summary>Unblank lock screen</summary>
+      <description>Unblank lock screen when power plugged in.</description>

This sounds like an action to unblank the screen when somebody plugs in their charger. We already do that, look for set_temporary_unidle_on_ac() in gnome-settings-daemon.
Comment 19 Bastien Nocera 2017-02-14 02:25:58 UTC
Review of attachment 341115 [details] [review]:

This isn't hooked up anywhere, and this has the same incorrect grammar as the original gsettings-desktop-schemas patch.
Comment 20 Bastien Nocera 2017-02-14 02:26:45 UTC
Review of attachment 341113 [details] [review]:

This isn't going in without a test to add to the test suite. The test suite currently doesn't work. The test suite and the test will need to work before we even consider adding this.
Comment 21 xiaoguang wang 2017-03-13 01:22:05 UTC
Created attachment 347779 [details] [review]
gnome-shell-not-fadeto-blank-when-lock-screen.patch
Comment 22 xiaoguang wang 2017-03-13 01:30:44 UTC
(In reply to Bastien Nocera from comment #18)

> This sounds like an action to unblank the screen when somebody plugs in
> their charger. We already do that, look for set_temporary_unidle_on_ac() in
> gnome-settings-daemon.

set_temporary_unidle_on_ac is used when some events happen, monitor become light temporarily, after 15 seconds monitor will be blank again. That is not we need.
Comment 23 xiaoguang wang 2017-03-13 01:35:04 UTC
(In reply to Bastien Nocera from comment #19)
> Review of attachment 341115 [details] [review] [review]:
> 
> This isn't hooked up anywhere, and this has the same incorrect grammar as
> the original gsettings-desktop-schemas patch.

This key is used in gnome-settings-daemon patch and gnome-shell patch.

Could you show me the grammar error? Then I can improve it.
Comment 24 Jesse 2017-09-06 13:12:04 UTC
Has this patch been merged or has it been left to die?

I'll pitch in writing tests if it means this getting done.
Comment 25 Lev Popov 2017-10-11 23:23:00 UTC
I have another use case for this option: in an office I connect my laptop to an external display via Thunderbolt over USB-C, the display has an embedded USB hub and a bunch of devices connected to it; when the screen goes blank the display goes to a power save mode and unpowers USB hub with all devices there including NIC which is not a desirable behaviour.
Comment 26 Lev Popov 2017-10-11 23:33:18 UTC
(In reply to xiaoguang wang from comment #23)
> (In reply to Bastien Nocera from comment #19)
> > Review of attachment 341115 [details] [review] [review] [review]:
> > 
> > This isn't hooked up anywhere, and this has the same incorrect grammar as
> > the original gsettings-desktop-schemas patch.
> 
> This key is used in gnome-settings-daemon patch and gnome-shell patch.
> 
> Could you show me the grammar error? Then I can improve it.

I've applied a part of your patches (not a configuration part, just to never blank screen when power is plugged in) and it works for me. Thanks.
Comment 27 Matt Turner 2017-10-21 02:28:01 UTC
This would be a nice workaround for bug 768204...
Comment 28 Iain 2018-02-01 16:02:31 UTC
My use case is to extend the timeout at the initial login screen under the GDM user, so that when the computer boots, it stays showing the login screen for more than 10 seconds after waking up the display (which itself takes several seconds).

When testing a lab of machines, it's easier to twitch the mouse on a row of computers then look back, than do each individually, wait for the screen to come on, and move to the next. The first way takes around 20 seconds to check a dozen computers; the second makes that row take over a minute. Multiply by a dozen rows and multiple labs, and these times really take a chunk out of the morning routine.

Will these patches help to keep the screen from turning off again until a configurable limit? Thanks.
Comment 29 xiaoguang wang 2018-06-10 07:37:09 UTC
I create a extension to unblank screen when screen saver is active.

https://extensions.gnome.org/extension/1414/unblank/
Comment 30 Thomas Alexander Ewald 2018-06-11 12:23:44 UTC
(In reply to xiaoguang wang from comment #29)
> I create a extension to unblank screen when screen saver is active.
> 
> https://extensions.gnome.org/extension/1414/unblank/

You sir, are a hero!
Comment 31 Rob 2018-08-23 11:32:52 UTC
Similar use-case as described by Iain;

I have my laptop connected to a monitor with speakers over HDMI. Every time I lock my laptop, my music turns off cause the monitor instantly goes into standby mode.

Sure, power saving is a noble cause, and we're all grateful. But making it a choice, rather than shoving it down our throats, isn't too much to ask for I hope?

This ticket dating back to 2016 leaves little room for hope though I guess.
Comment 32 André Klapper 2021-06-09 16:26:27 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new bug report at
  https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/

Thank you for your understanding and your help.