we're aggressively blanking the screen when it is locked, to conserve power.

I agree with you that it is a good thing to conserve however:
- if the laptop is on AC I don't want to conserve power
- if it is a design question to keep this time-to-turn-off-display variable low, no problem, but it would be nice if there were an option for it in dconf
- any lock screen info and controls (which I have not tested) are useless this way because when I lock the screen it blanks instantly.
- Sorry, bad link the previous time, this is the good one: https://bbs.archlinux.org/viewtopic.php?id=171750

(In reply to comment #2)
> I agree with you that it is a good thing to conserve however:
> - if the laptop is on AC I don't want to conserve power

Why?

Because I think you have created something beautiful which deserves to be seen by others as well (marketing!). If I study I like to keep track of time on my monitor. I would like to see which track is currently being played or if I have received any emails.

When you receive a new notification, the screen will unblank.

But then it is dimmed again even if I don't read it. I know it is a matter of habit and user preference, but it would be nice to configure it to one's needs.

The other issue is with external monitors it can take them a few seconds to wake up from a sleep state, if I'm just locking the screen for a minute or two I would appreciate being able to unlock instantly without waiting for the monitor to wake up.

Also +1 aesthetic reasons for it, I like showing off the wallpaper on the lock screen for a few minutes before the screen goes to sleep. I second the idea of having a configurable timeout in dconf.

I have multiple devices hooked up to my Samsung monitor, however if the active input loses signal it will autoswap to an active input. This means every time I lock my screen it changes (even if I am just locking for a couple seconds while I walk to another desk) This is extremely irritating to constantly change and I would appreciate the ability to delay/disable the monitor shutdown function (at least on AC power, come on)

I also would like the ability to delay turning off the screen.

Hear, hear! I know there are good reasons to kill the screen but ever since lock screen notifications were introduced I have also yearned for the option of a delayed blanking.

I wouldn't consider this normal priority bug, though. Rather an enhancement.

I(In reply to comment #7)
> The other issue is with external monitors it can take them a few seconds to
> wake up from a sleep state, if I'm just locking the screen for a minute or two
> I would appreciate being able to unlock instantly without waiting for the
> monitor to wake up.

This. 

My brand new 144Hz Acer monitor takes around 20s to wake up.

+1 on the functional requirement - My secondary monitor at work is an old CRT, and it takes a LONG time to be useful after it is shut off.

+1 also on the aesthetic view.

Default behavior can stay as is.  Just give us a setting someplace (even in the tweak tool) to let us change it, please!

On Fedora 19, the screen turns off immediately after the curtain drops, which looks very poor.  Either there should be a significant delay between the curtain drop and when the screen goes black, or the curtain drop should be removed so that the lock screen is not shown at all before the screen goes blank, as is already the case when the screen fades to black after a period of inactivity.  (Though I guess the fade animation does not make sense in the context of a user-initiated lock.)

Anyway, I think we do need to seriously reassess the configuration options we are providing here.  To be clear, I'm talking about three interrelated settings: Blank Screen and Dim Screen when Inactive on the Power panel, and Screen Lock on the Privacy panel.

The Blank Screen option (default: 5m) can be set to Never, but this option only controls the how much inactivity is required before the screen blanks: locking the screen manually will always blank the screen, even if Blank Screen is set to Never. Surely if the screen is set to never blank, it should not blank [when the screen is locked]. That would solve this bug for the users who want it to never blank, but not for the users who want a delay.

The Never option silently turns off screen locking, because the Screen Lock setting in the Privacy panel is defined in terms of how long to wait after blanking the screen before locking (default: no delay). But since these closely-related settings are in different panels, a reasonable user who wants to turn off screen blanking but still have his screen automatically lock (i.e. most of the people who have commented above) can accidentally turn off screen locking with a seemingly-unrelated setting and not realize what he has done.

Moreover, when Screen Lock is set to anything other than the default, i.e. when there is a delay between the screen blanking and locking, the screen shield still lowers, so it seems like the screen is locked, and there is no way to visually verify that it actually is not. Since the screen appears to be locked, I naturally begin to unlock it with my password... only to find that the first keypress raises the shield, and the rest of my password has gone into the form where I was writing this post.  This is confusing and unimpressive; the screen shield should not be displayed when the screen is not actually locked. (Or if it is displayed, it should actually eat your input for a second or two while it is being raised.)

I don't understand why we provide configuration to allow blanking the screen without locking it - indeed precise configurations for exactly how long there should be between a blank and a lock! - but no configuration for locking the screen without blanking it.  (At first I was going to add "why would anyone ever want the screen to blank but not lock," but I guess the obvious answers are "I live alone" or "shared computer with one user account.")

Lastly, there's Dim Screen when Inactive.  I simply cannot figure out what this controls, even after experimenting with it.  Back in olden days (GNOME 3.4?) the screen would dim after a few minutes of inactivity, then blank completely a few minutes later. That doesn't happen anymore. My guess is either this setting is simply broken, or, since it's a boolean toggle, perhaps it takes effect after the screen blanks when the default screen blank duration is used?  E.g. this guess is that the screen blanks after 5m, then dims after 6m, and nobody knows because Dim is a toggle rather than a combo of durations.

Note that I'm commenting based on GNOME 3.8 in Fedora 19, but as far as I can tell, there haven't been major changes in this area.

Rereading that comment, I apologize that that was a LOT of marginally-related stuff in one long post.  I can file separate control-center bugs for those issues if that would be more helpful than discussing them all in the same place.  My point was intended to be: "I think we do need to seriously reassess the configuration options we are providing here."

I believe that Michael is right, we really need to think about this and handle this from the perspective of energy management and design. I am not a developer, but I don't think this should be handled across different bug reports as that would lead to untrackability. Would it be possible to create an area for discussion about this topic here: https://wiki.gnome.org/ThreePointEleven/Features (I don't know about dev. cycles and freezing dates., but it would be great to be able to discuss this widely.)

*** Bug 704601 has been marked as a duplicate of this bug. ***

The user in Bug #704601 wants to disable this behavior because "Monitors with CCFL backlight will wear faster when turned off and on too often."

I see your point in aggressive power saving, and this is surely the right way to go on modern devices with LED backlight.

However, Gnome is also used on desktop machines (and older laptops) with other monitor types. Monitors with CCFL backlight will wear faster and thus need to be replaced sooner (causing more electronic waste), while CRT monitors need a considerable time for heating up and degaussing.

A dconf switch (and maybe a tweak tool option) would be sufficient.

(In reply to comment #18)
> A dconf switch (and maybe a tweak tool option) would be sufficient.

I think your argument points more in the direction of UI in gnome-control-center, not a hidden option.

Or of making use of the existing options: there is already a Blank Screen option, you can set it to Never, and it works until you decide to lock your screen.

(In reply to comment #19)

> I think your argument points more in the direction of UI in
> gnome-control-center, not a hidden option.

Personally, I would like this even better. On the other hand, it would clutter the control center. Either way, it would be great to have it configurable.

> Or of making use of the existing options: there is already a Blank Screen
> option, you can set it to Never, and it works until you decide to lock your
> screen.

Cannot do that. It's a company directive to lock the screen when leaving the workplace.

My LCD monitor takes about 10 seconds to power-on. IMHO we should make this option configurable in either Tweak Tool or through a hidden dconf property.

At the very least, user initiated Lock (Super+L) should NOT immediately turn off display.

Piling on my request for this to be configurable. 

Every new Gnome release, there are less settings and more annoyances. Stop forcing users into your own paradigms. Do whatever you want to defaults, but give us options.

As a workaround, I edited the file /usr/share/gnome-shell/js/ui/screenShield.js
and commented out these lines:

//        if (prevIsActive != this._isActive)
//            this.emit('active-changed');

After restarting gnome-shell, the monitor stays on when the screen is locked.

It's working with Gnome 3.8 and 3.10. Of course it's a hack, and I don't know if it has any side effects. However, I am using this hack for 6 months now (I reported this issue in July 2013).

Does the screen eventually turn off? Cuz I do want it to turn off after a long time.

I also find the default behavior to be simply WRONG.  Like others have said, please keep the default behavior if that's what you want but, at least, give us an option.

BTW, is an option currently being considered?  Please give us an update.

Thanks.

(In reply to comment #25)
> I also find the default behavior to be simply WRONG. 

I disagree not using the screen -> turn it off is a logical thing to do.

> Like others have said,
> please keep the default behavior if that's what you want but, at least, give us
> an option.
> 
> BTW, is an option currently being considered?  Please give us an update.

If you really want a longer timeout for whatever reason I don't mind having a gsettings option that you can set (it wont be exposed in g-c-c unless you convince the designers).  I'll review patches. Shouldn't be that hard to do.

(In reply to comment #26)
> I disagree not using the screen -> turn it off is a logical thing to do.

Do we really need to go through this discussion again? I think all the arguments on both sides have been pointed out. Have you at least tried to understand the arguments against powering the monitors off?

> If you really want a longer timeout for whatever reason I don't mind having a
> gsettings option that you can set (it wont be exposed in g-c-c unless you
> convince the designers).  I'll review patches. Shouldn't be that hard to do.

So you say that there is no Gnome developer ever going to patch it, but it's up to the community?

(In reply to comment #27)
> > If you really want a longer timeout for whatever reason I don't mind having a
> > gsettings option that you can set (it wont be exposed in g-c-c unless you
> > convince the designers).  I'll review patches. Shouldn't be that hard to do.
> 
> So you say that there is no Gnome developer ever going to patch it,

Didn't say nor imply that I just said *I* just don't have time to work on it (or anything else in the coming weeks).

> but it's up to the community?

Developers are part of the community (I don't get paid for working on GNOME if that's what your implying).

(In reply to comment #28)
> > So you say that there is no Gnome developer ever going to patch it,
> Didn't say nor imply that I just said *I* just don't have time to work on it
> (or anything else in the coming weeks).

OK, thank you for pointing that out.

Who of the Gnome developer team would be actually in charge of this issue? It's still unconfirmed. Maybe it's time to assign it to someone who is actually able to fix it or decide about its fate.

> > but it's up to the community?
> Developers are part of the community (I don't get paid for working on GNOME if
> that's what your implying).

I'm sorry if I was ambiguous. Actually, I meant the community as in "Gnome users who are not involved in Gnome development".

Hi All,

I'm just wondering what is the status for this "bug"?
Has anyone found a solution already? Is there a gnome extention perhaps?

Seems like both sides of the argument has been covered, so I'm here to give some momentum/weight on the please-fix-this side of the discussion. I'm working on a desktop computer with two monitors and always locks the screen for a cup of coffee or a short chat with my colleagues. Being met with both monitors off when I'm back is counter-productive and doesn't make any sense in a desktop environment.

Yes, this should be configurable, yes it should be possible to set the timeout for monitor off after it is locked, and yes coming from nowhere as an ordinary gnome user I have no right to demand anything from an open source project. On the opposite I'm glad and humble that you devs are working on this.

This is just another confirmation of this bug and that it gives me a bad UX.

(In reply to comment #31)
> Seems like both sides of the argument has been covered, so I'm here to give
> some momentum/weight on the please-fix-this side of the discussion. I'm working
> on a desktop computer with two monitors and always locks the screen for a cup
> of coffee or a short chat with my colleagues. Being met with both monitors off
> when I'm back is counter-productive and doesn't make any sense in a desktop
> environment.

It *does* make sense as already covered in the comments above.

> Yes, this should be configurable, yes it should be possible to set the timeout
> for monitor off after it is locked, and yes coming from nowhere as an ordinary
> gnome user I have no right to demand anything from an open source project. On
> the opposite I'm glad and humble that you devs are working on this.
> 
> This is just another confirmation of this bug and that it gives me a bad UX.

Comment 26 still stands.

This discussion moves in circles, and there is still no one assigned to it. I doubt that it will be fixed by Gnome developers some day.

@Kåre Slettnes: All you need is to realize that users with elevated demands on a configurable desktop environment are not the target audience of Gnome 3. Just move to another environment, like I did. Luckily there are many alternatives to choose from.

A "Lock Screen" and "Notifications" doesn't make sense, if the screen is blanked immediately after it was locked. For saving power we have Suspend-To-RAM (also an issue since 3.0), Hibernate-To-Disk and Display-Dimming.

Just like many others here I work with two screens on my workstation and at home with my laptop in a docking-station. See comment 31.

Solution:
Please just dim the display after a configurable amount of time, default should be a sane value (30 minutes).


Examples:
* Co-Workers should see that I locked my computer, this shows them that I'm at work but currently not at my desk.
* I want see myself that I received 10 mails during my five minute pause and should immediately unlock it, because Nagious is freaking out - caused by a network outage. PANIC!
* Unlocking and starting to work needs a lot of time, because the typical desktop-display needs ages for starting/unblanking (actually my to displays at work need even longer than a full suspend and resume cycle on my laptop).
* Everyone should see that I work with GNU/Linux and GNOME, but they are locked-out and not allowed to enjoy this :p
* Blanking the display shouldn't save much power on a current system, especially if dimming is used instead.

Workarounds:
Don't lock the screen (bad!). Turn off "org.gnome.settings-daemon.plugins.power" (bad!). Both is clearly not desired, it doesn't save my work and neither the environment. Enforcing things on people seldom works...

(In reply to comment #34)
> A "Lock Screen" and "Notifications" doesn't make sense, if the screen is
> blanked immediately after it was locked. 

Given that that we unblank the screen when displaying notifications most of your comment is pointless.

For saving power we have
> Suspend-To-RAM (also an issue since 3.0), Hibernate-To-Disk and
> Display-Dimming.

No suspending when the computer is idle is to harsh. But simply powering off the monitor is a sensible thing to do see comments above. A locked screen means that the computer is not being used currently.

> 
> Solution:
> Please just dim the display after a configurable amount of time, default should
> be a sane value (30 minutes).

30 minutes would be *way* to much. As I stated above if someone cares enough to write a patch to add a configure able delay I'd be fine with it.

I would also like to add my voice to this debate. I'm another user who would like this to be configurable or at least to respect my choice when I set "Blank Screen" to "Never". Never is pretty unambiguous and I would expect anything that does something when I've told it "never" to be a bug. I don't quite see why there's a debate on that point.

My problem is I have my laptop attached to 2 external monitors (which was painful enough to set up) when I'm at work. I'm connected to the AC and power isn't a concern. What is a concern is that when I lock my screen it automatically shuts off the monitors. This is bad for all of the other reasons mentioned above (especially since it's ignoring my "never" preference) but it also causes my monitors to go crazy when I come back and unlock them. They all dance around turning on and off at random times and it continues to do this until I reboot.

This means I can't lock my screen without also having to reboot. Plus, if I haven't said it enough, Gnome already asks me if I want to "Blank Screen" in the power settings and I've already give my answer as "Never". Why should some parts of Gnome respect this but others ignore it?

So in summary:

+1 to making the length of time configurable before blanking the screen after locking.
+1 to respecting the "Never" setting wrt to blanking the screen.

I think it is pretty clear now, that the real world of the users look different and this should be changed.

I'm a Linux user since 2006 and I simply love Gnome, for it's reliability and ease of use orientation.
So... I really think it's ridiculous that a simple option like this is missing. Let the users choose their preferred mode. Isn't this you one of your most importarnt rules ? 
You heard me? RI DI CU LOUS !!

It is truly incredible that not a single stroke was typed to solve this. I know it is free software, I know I should do it if it bothers me.
But:
-I am not that comfortable with git yet (I could google the necessary things)
-I don't know where the necessary things are in the sources.
-I don't know the language gnome-shell or dconf uses for this.

Honestly why is this such a great job to solve for someone who is involved with the daily development in gnome? A simple papercut that's what it would be to put a variable there -.-

(In reply to comment #39)
> Honestly why is this such a great job to solve for someone who is involved with
> the daily development in gnome? A simple papercut that's what it would be to
> put a variable there -.-

Extacly. Not all Linux/Gnome users have to be developers to find the parameters that suit their needs. It's like being a developer and saying: Hi, I do love music at maximum volume and so I don't give you the choice to low the volume.
One thing is your personal believes, another thing is giving a product (even if free) to please the maximum number of users.
Moreover the first answers from the "developers" are truly irritating, there's no really need be on the defensive, it's just enough to say: We're sorry, we hadnt' thought about that....

Suggesting that any inaction can only be explained that the developer is out to annoy users is not very helpful.

I think we need design review here. The relevant settings are split between the Power and Privacy panels, so it's not at all obvious what the desired fix is. We also need to make sure that setting Blank Screen to Never does not silently prevent the screen from ever locking (which I think it currently does -- not at all obvious if you're only visiting the Power panel).

The only thing we seem to have agreement on is that setting screen blank to Never should prevent the screen from blanking when locked, in the absence of some other setting to control this. But I suspect that most users in this bug DO want the screen to blank, just after it has already locked.

(In reply to comment #39)
> It is truly incredible that not a single stroke was typed to solve this. 

There's a lot of other bugs, and this one is only really annoying to users with old monitors, so I don't think it's incredible, just unfortunate.

(In reply to comment #42)

> But I suspect that most users in this bug
> DO want the screen to blank, just after it has already locked.

No. If I say "Never blank" then I would assume it means "Never" and that's what I want to happen. If I didn't want "Never" why would I pick it?

> (In reply to comment #39)

> There's a lot of other bugs, and this one is only really annoying to users with
> old monitors, so I don't think it's incredible, just unfortunate.

My monitors are brand new.

(In reply to comment #42)
> There's a lot of other bugs, and this one is only really annoying to users with
> old monitors, so I don't think it's incredible, just unfortunate.

Old monitors aren't the problem. I also have two brand sparkling new monitors which is part of my daily work environment. I leave the workstation all the time and always locks it before I leave.

This is the paper cut part.

(In reply to comment #42)
> I think we need design review here. The relevant settings are split between the
> Power and Privacy panels, so it's not at all obvious what the desired fix is.
> We also need to make sure that setting Blank Screen to Never does not silently
> prevent the screen from ever locking

The split is indeed a problem - basically, the "Blank Screen" setting controls after how much time of user inactivity the screen should be blanked, the "Automatic Screen Lock" settings whether to lock the screen after blanking. Neither setting has anything to do with what happens after an explicit lock.
So there is definitively some confusion here that needs addressing (in Settings).

Screen Lock != Blank Screen

(In reply to comment #39)
> Honestly why is this such a great job to solve for someone who is involved with
> the daily development in gnome? A simple papercut that's what it would be to
> put a variable there -.-

Extacly. Not all Linux/Gnome users have to be developers to find the parameters that suit their needs. It's like being a developer and saying: Hi, I do love music at maximum volume and so I don't give you the choice to low the volume.
One thing is your personal believes, another thing is giving a product (even if free) to please the maximum number of users.
Moreover the first answers from the "developers" are truly irritating, there's no really need be on the defensive, it's just enough to say: We're sorry, we hadnt' thought about that....

Annoying is the arrogance of some developers. As M.Peters said a few comments before, if I choose "never blank" in power settings this personal choice is not respected by "someone" else. That's the problem.
So, fortunately, there some other develpers that, more honestly are wondering about a design review.
Listen to users needs, or you remaing alone, soon or later.

(In reply to comment #48)
> Annoying is the arrogance of some developers. As M.Peters said a few comments
> before, if I choose "never blank" in power settings this personal choice is not
> respected by "someone" else. That's the problem.

No, this is what *you* think the problem is. A different point of view would be that the wording in Settings is unclear, so users (quite rightfully I should add) can get confused about what the setting does.

So let me try to explain again how those settings currently work:

If the user is not using the computer, the screen is turned off. There is no option to control this behavior, neither in the UI nor in GSettings.[0]

Now there are two ways to determine when the user is inactive:

 (1) there is no mouse/pointer input for a certain amount of time, which is 
     configurable in Settings' power panel ("Blank screen").

 (2) the user explicitly performs an action that signals inactivity (i.e.
     locks the screen)

As it stands, (1) and (2) are completely unrelated. And adding uncontructive comments here is unlikely to change anything (quite the contrary actually); adding use cases that have not been mentioned before for changing this (or the premise of always turning off the screen on user inactivity) might.


[0] Let me be clear here - it is OK to bring up use cases why such a setting should be added, and to be fair, some comments in this bug have done so constructively instead of just ranting about how arrogant and stupid we are

Both of my desktop monitors take 10 seconds or so to come out of DPMS Off state. Combine that with the fact that the shield raises at the touch of any button, and sometimes there's no unlock dialog under the shield, so I pretty much have to press a non-action button like dialog, wait 10 seconds, see if there's a dialog, and then type my password to unlock the screen to make sure it doesn't go into IRC.

I never explicitly lock the screen, so I just set the option to Never, and that fixes it for me. But I understand the frustration of the users.

Nobody said "stupid". Arrongat for sure, just have a look at the first answers from developers.
Someone is asking to add an option for something that a lot of users find useful, and the reply is: "we're aggressively blanking the screen when it is locked, to conserve power" (1st personal point of view, to which can be answered that when on AC, or not on a laptop, this is not required).
Or: "When you received and email the screen will unblank" (2nd personal point of view, and also a bit stupid answer, this surely was).
The problem is avoiding to meet users' needs. But one thing is for structural problems that would require a deep design review. Another thing is refuse to add a very simple option to avoid screen blanking, all for personal believings.

Anyway, a workaround exists, it's enough to install XScreen-saver and purge Gnome-screensaver. But I can surely live without this option, even if in previous versions of Gnome there was, and you should explain why the behaviuor is changed. For power conservation? Please.... don't take us for fools.

(In reply to comment #51)
> Nobody said "stupid". Arrongat for sure, just have a look at the first answers
> from developers.
[..]
> previous versions of Gnome there was, and you should explain why the behaviuor
> is changed. For power conservation? Please.... don't take us for fools.

I understand that you want this fixed, but please refrain from venting frustration. It doesn't help. Developers aren't out to get anyone. It would've been much nicer if this was fixed and/or more priority was given. Unfortunately that's not the case.

(In reply to comment #52)
> (In reply to comment #51)

> I understand that you want this fixed, but please refrain from venting
> frustration. It doesn't help. Developers aren't out to get anyone. It would've
> been much nicer if this was fixed and/or more priority was given. Unfortunately
> that's not the case.

As gnome enthusiastic user since many years, I'm just a bit disappointed by some haughty answers. That's all.
If gnome-shell developers want to add it we'll be happy. If not, we'll be happy too, but a little less.

(In reply to comment #51)
> Nobody said "stupid". Arrongat for sure, just have a look at the first answers
> from developers.
> Someone is asking to add an option for something that a lot of users find
> useful, and the reply is: "we're aggressively blanking the screen when it is
> locked, to conserve power" (1st personal point of view, to which can be
> answered that when on AC, or not on a laptop, this is not required).

This is not arrogant this is explaining why things are currently done this way. While conversing power is not *required* (really a strong word its not even required on laptops) it is nevertheless nice to have. Or where can I have the free electricity? ;)

Anyway there are better ways to convince other people to do something for you for free then attacking them. (Actually this is what I'd call arrogant but whatever).

When the gnome-shell developers say that the behavior of the "blank-screen: never" configuration is not broken but works like intended, we probably have to accept it, if we like it or not.

However, I don't understand why not even a dconf option for turning off DPMS is provided. It would not clutter a configuration GUI, but would help those people who don't want their monitors being turned off (for whatever reason). This would be a minimal concession.

Does discussing about this bug really mean less effort than just adding a dconf option, then close this issue for good and have some more happy Gnome users?

The workaround is just that: a workaround. When the Gnome packages are updated, it is gone and need to be applied again.

This bug has crossed the 50 comment threshold - at that point it gets increasingly unlikely that any developer is going to wade through the backlog of comments to do anything about it.

Please keep that in mind while discussing arrogance, annoyance and other irrelevant stuff here.

(In reply to comment #45)
> The split is indeed a problem - basically, the "Blank Screen" setting controls
> after how much time of user inactivity the screen should be blanked, the
> "Automatic Screen Lock" settings whether to lock the screen after blanking.
> Neither setting has anything to do with what happens after an explicit lock.
> So there is definitively some confusion here that needs addressing (in
> Settings).

And in particular, the Blank Screen setting should not secretly disable screen lock, which I guess it does if set to "Never." After setting it to "Never" you can visit the Privacy panel and see that screen lock is on, but since it's defined in terms of time after the screen blanks, I guess that has to be a lie....

So I've thinking about this little issue, of remote developers deciding for us when to dim the screens.

I've ran this test:
1-Open a terminal
2-Following http://www.semicomplete.com/projects/xdotool/xdotool.xhtml; run

sleep 10; xdotool key F2

3-Lock the screen

Expected: The screen will lock, then dim to black and the screens will sleep.
After some seconds, xdotool will send F2 to the screensaver, and it will turn on the screens and show the background image.


Therefore, what you can do is write a little script that will:

1-See if the screen saver is running. If it's not, exit. You can easily do this with DBus (ScreenSaver.getActive())
2-Store the timestamp when the screen saver was first detected as running.
3-Have a loop that will send F2 every X amount of time, X times.
4-After X period of time since the screen saver start, end the loop, leaving the screen to actually dim and stay off.


I hope you like the idea.

(In reply to comment #58)
> So I've thinking about this little issue, of remote developers deciding for us
> when to dim the screens.
> 
> I've ran this test:
> 1-Open a terminal
> 2-Following http://www.semicomplete.com/projects/xdotool/xdotool.xhtml; run
> 
> sleep 10; xdotool key F2
> 
> 3-Lock the screen
> 

Doesn't work - nothing happens after locking.

Unfortunately, this issue isn't just cosmetic: for those using HDMI TVs/monitors with sound, the music shuts off abruptly right after the screen is locked because sound does not get through if the screen has been blanked.

+1 to obadz's comment.  Experiencing this myself.

(In reply to comment #60)
> Unfortunately, this issue isn't just cosmetic: for those using HDMI
> TVs/monitors with sound, the music shuts off abruptly right after the screen is
> locked because sound does not get through if the screen has been blanked.

Then the fix for this particular bug is not to add an option (that's not a fix) but to never turn off a monitor connected through hdmi if sound is playing.

The issue is that HDMI doesn't really have a proper DPMS control. Either you cut everything or you leave it scanning out pixels with the backlight on.

It's clearly a horrible solution, but telling X to set DPMS off really shouldn't cut the power. We're looking into better ways to handle DPMS in the kernel for the new KMS API.

I've stopped posting comments as I understood that was useless.. anyway I've continued following the issue, and I can see a lot of people is claiming for a solution for this annoying problem.
Someone told me that the monitor turning off it's mandatory for saving energy power, even when connected to AC. Well, what about if having a solar plant for electric power at home (like my case)? My plant is overproducing power, that I sell through the net, and I don't need that someone decides for me where is better to save power and where not. I would like to have, for example, my laptop playing Youtube videos all day long while I'm at home, and this could be just my decision, not by someone else.
We would like just to have a simple option: TURN ON/OFF MONITOR (ALMOUST) WHEN ON AC.
Thanks.

(In reply to comment #64)
> I've stopped posting comments as I understood that was useless.. anyway I've
> continued following the issue, and I can see a lot of people is claiming for a
> solution for this annoying problem.
> Someone told me that the monitor turning off it's mandatory for saving energy
> power, even when connected to AC. Well, what about if having a solar plant for
> electric power at home (like my case)? My plant is overproducing power, that I
> sell through the net, and I don't need that someone decides for me where is
> better to save power and where not. I would like to have, for example, my
> laptop playing Youtube videos all day long while I'm at home, and this could be
> just my decision, not by someone else.
> We would like just to have a simple option: TURN ON/OFF MONITOR (ALMOUST) WHEN
> ON AC.
> Thanks.

https://bugzilla.gnome.org/show_bug.cgi?id=710904#c26

This is still very much a real problem.

1) Screen blanks instantly, hiding the gorgeous wallpaper and demoing how gorgeous gnome3 and fedora 21 look.

2) It looks like I've been away from my desk a long time to my coworkers (or worse, like I'm not even in the office) as opposed to just taking a quick break.

3) Screens - even LCD screens - can take a LONG time to power back on, and mine do just that. It's a pain having to wait every time after sitting down just to enter my password. Especially since I have to wait to make sure I'm not entering my password into the office irc or some other IM window that was last up on my screen.

4) I think the gnome developers need to have a serious hard think about things. They are writing software to the USERS of their software, and should LISTEN to what the users are saying - there's a lot of very constructive arguments above - and actually take ON BOARD what users are saying instead of DICTATING what the users will get. Stop being damn nazi's. That is NOT how you write a software project.

Right now, the gnome3 lockscreen is very horribly broken.

Please fix it and stop the madness.

(In reply to comment #66)
> Please fix it and stop the madness.

Please read previous comments (like comment 63) before adding even more comments. Comment 63 explains that the actual problem is way lower in the stack.

It's more a problem of the consumer electronics industry. Using HDMI, there's no way to cut video and turn the backlight off without also cutting audio. There's no solution that will make everybody happy here.

Either we keep the backlight on, and people complain about wasted power, or we turn the backlight off, and people complain about no audio. I don't see any other great solution than an option, to be honest.

Well, I do see a solution. Add an opportunity for the user to decide if we want to turn the screen off:
a - instantly
b - with a timeout specified by the user
c - not at all
One timeout parameter could take care of it all. *This* is what the thread has been about - to give the user an opportunity instead of hardwiring and deciding what is best for him/her. It can be hidden in dconf we don't really care but make it customizable.

Obviously the correct solution is to let the user configure it, but taking the advice of Comment 58 I made a script for all the people who don't know how to do it themselves. Just put this in a .sh file, chmod +x and add it to your log in items.

while true; do
    if test "$(qdbus org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.GetActive)" == "true"; then
        xdotool key F2
    fi
    sleep 10
done

This one will only keep the computer alive for 300 seconds (5 minutes)

#!/usr/bin/env bash
i=0
while true; do
    if test "$(qdbus org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.GetActive)" == "true"; then
        if test "$i" -lt 30; then
            xdotool key F2
        fi
        i=$(($i+1))
    else
        i=0
    fi
    sleep 10
done

Just adding my voice to the want for the option to customize the default behavior.  I dislike the fact that I cannot listen to music through my HDMI connected monitor when I lock the screen.

Also, when the screen turns off I am unable to see any notifications that come in.

Thanks for the above scripts; however I believe that this is one area where Gnome should give the user a few options.

It's embarrassing that this still hasn't been taken seriously even after people have posted legitimate use cases where we need it changed.

Oddly I have the inverse problem that others have described.  Instead of it taking forever to get my monitors to wake up, as my monitors wake fairly quickly (2-3 seconds), my issue is having my Kerberos login can take somewhere around 30-40 seconds to complete.  The result here is before the login can complete the screen blanks, locking the console again, and canceling the login attempt.  It is _extremely_ frustrating to have to enter my password, and then wiggle the hell out of my mouse/trackball to keep the screen from falling back asleep WHILE attempting to login.  Seriously, one botched password and/or looking away from the console can result in a delay of login in the range of minutes.

The issue with the Kerberos auth is on my end, and I'm not holding anyone here responsible for that, because seriously that's not your doing. I squarely hold the key to that cluster of woe.  But, the lock screen issue is. This issue is a colossal underplaying of user experience for screen locking and logging back in.  From a users' perspective, it seem that the devs for Gnome simply turned their collective backs on them in regards to screen savers and screen locking. Screen savers (which were available in the past) are/would be a great feature.  But lock screen management (e.g. curtain/diming timing, "idle-delay" to return to screen blanking, additional auth-method support), is far beyond a simple "feature request" and is a missing component.  These options aren't even available in dconf.

It's been almost 2 years since this ticket was opened, and during that time several revisions have been released.  What's the roadmap for getting the lock-screen control surfaces squared away?

After two years we're still here discussing for this... it could be normal here in Italy, and we would be politicians. But, we're simply Gnome users and lover and we would like it to be the best desktop environment ever made, as it is for a lot of things.
If you want an example of what it should be, please have a look at Mac OS power and display management. I know you hate that world, me too, but for this aspect it's just perfect:
- Computer sleeps after: from 1 min up to 3 hrs or never
- Display sleeps after: the same as above
- Screen saver: choose one and start after 'X' mns/hrs, with or without password asking at wake up
- stop HDs, and all other options about energy saver

A simply and integrated power/display management, with the user that can decide to save energy and how.

(In reply to Jasper St. Pierre from comment #68)
We realize that yes there are downsides to having the backlight control not disabling the backlight on blanking.  But that should be a choice the user makes.  Having that control there and defaulted to "always turn off backlight" is a sane default.  Having that control there, for a function that already exists, would allow users that wish to not use this feature to do so. The usage for this function, simply because backlight control is not supported on HDMI, is using the wrong edge and user experience case.

This is slightly off-topic but still relevant: DisplayPort, LVDS, DVI, and VGA all send DDC/CI commands to disable the screen, and/or put the display into a power save mode.  So this functionality (regardless of display type) shouldn't be any different for HDMI.

Having the user experience be lacking the ability to disable this functionality seems absurd.  By claiming the reasoning for not disabling it being because of the HDMI standard not having blanking is equally absurd. Yes, leaving on your monitor can be wasteful of electricity, but the last time I checked this was a desktop environment not a political platform.

My HTPC runs KODI/XBMC as the desktop environment and blanks and kills the audio. It's no biggie, I learned to suspend the machine when I'm not watching anything. My desktops and servers, on the other hand, need a longer delay so my login sessions don't get clobbered by the lock screen blanking. The later IS a serious problem, because beyond doing a basic code review and hacking in a change that will get clobbered on the next version, I and the rest of the community have no other choices beyond stop using Gnome3.

The features/functions we're looking for:
- Backlight control
     Defaulting to enable is a completely sane UX, and having the control
     accessible via dconf or dconf_editor is also. Dictating it being enabled
     and no option to disable it shouldn't, that's creating a poor user 
     experience for a feature that is available on almost every other desktop
     environment (even XFCE).


- User definable time for screen blanking
     Having the dconf control is great, but having to dig into dconf or 
     dconf_editor to set the blanking time to anything larger than 15 mins
     is also poor user experience.  Changing a pull down to slider or
     incremental number should be a trivial UI change.  Watching a video, that
     is greater than 15 mins, results me needing to perform some action to
     keep the machine from being "idle".  Begin able to set the value to a
     large number would resolve that. But having to set it via dconf or
     dconf_editor, perform what ever task I need a long screen blanking for,
     and then setting it back after I'm done is not an acceptable UX.

- Login/Lock screen control
     The same functional settings for the desktop should either also take effect
     on login/lock screen, or allow for atomic control of the login/lock screen.
     These setting can be buried in dconf, as they are an atomic control.
     Customization here would only be done by power users or administrators
     setting defaults for large installations.

Comment #26 states that there is an option for gsettings controls. This would be a good first step, was this ever done? Also, if designer wrangling is needed, what email address do I need to start spamming requests to?

Bringing in words like 'embarrassing' or 'absurd' usually means the end of meaningful discussion in bugzilla. It is not likely to help you achieve your goals.

(In reply to Matthias Clasen from comment #77)
> Bringing in words like 'embarrassing' or 'absurd' usually means the end of
> meaningful discussion in bugzilla. It is not likely to help you achieve your
> goals.

This might be due to the goals and road map for the resolution of this issue have never been made completely clear to those that have shown interest in resolving this issue? If I personally was capable of fixing it and submitting a patch I would, but I'm a python and php guy not a C/C++ dev. My skill set can't directly help resolve this problem. With the roll out of v3.18.x, getting a conversation about resolving an issue since that was reported in v3.10.x seems like the constructive thing to do. This issue isn't a "by design" issue, it's a poorly executed user experience that's been around for almost 3 years and passed over for the last 3 revisions.

And Matthias, you're completely correct. Usage of words like 'embarrassing' or 'absurd' does normally mean discussion has ended. The difference here being a meaningful and constructive discussion between developers and user about this bug hasn't happened over the last two years. I've been watching this thread for over a year and seen no movement. As an affected user you might understand my and other's frustration on a lack of communication or discussion on this issue.

Time cost wise how hard would it be to resolve this issue? A guess of 4 hours for some config flag inserts plus some light testing? Hell, I'd be more than willing to put my own time in for Q&A on this to close this issue. Milestone 1 for this fix would be a simple add of dconf/gconf controls. Whereas milestone 2 would put in some UI updated controls. Can anyone give a more accurate time cost for just milestone 1 in this instance?

Just for the record ... the code that does the blanking isn't in gnome-shell but in gnome-settings-daemon: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c#n1913

So that's the place where you want to add any changes (all that gnome-shell does is to lock the screen).

Additional use case for this functionality: A user wishes to have her desktop in a public area of the house, displaying a slideshow of pictures, while the screen is locked to prevent unauthorized access. She sets the lockscreen wallpaper to a slideshow with an extension [1], then locks her screen, but it turns off after 15 seconds and she has no setting to keep it on.

[1] https://extensions.gnome.org/extension/1000/random-walls/

(In reply to Matthias Clasen from comment #56)
> This bug has crossed the 50 comment threshold - at that point it gets
> increasingly unlikely that any developer is going to wade through the
> backlog of comments to do anything about it.
> 
> Please keep that in mind while discussing arrogance, annoyance and other
> irrelevant stuff here.

(In reply to Matthias Clasen from comment #77)
> Bringing in words like 'embarrassing' or 'absurd' usually means the end of
> meaningful discussion in bugzilla. It is not likely to help you achieve your
> goals.

Would it make sense to close this bug and create a new one that isn't so clogged up with irrelevant discussion?

Please do not close this bug as this has not been solved. There is still no option for the user to influence the timeout of the screen blanking after locking the screen.

Agreed with Szebenyi Bálint. Please do not close this. In a corporate\business setting having the lock screen show is extremely important as it gives us the ability to display information for those that might not be using the machine but might be in vicinity of the machine. Just because some users are not using the computer at that moment does not mean they want to wait for my monitors to "wake up" or go back to my original point displaying a screen saver picture that is helpful (help desk number, emergency information, etc).

Lastly, let us just be honest with ourselves, as a desktop user, if there is an option to set a lock screen wallpaper, by gosh, I want to be able to see that wallpaper.

I was not proposing that we give up on this feature. I was proposing that we track it in a different bug report. Almost all useful discussion on this report happened by comment #28. At comment #40, discussion takes a turn towards hostile and irrelevant, dramatically decreasing the chance this will EVER be fixed. Now we're up to #84.

I want this setting as much as you do. I don't have ANY other agenda, and if the other agendas that surface between #40 and here are keeping this from being acted on, I want to fix that.

Completely agreed Stephen and you are absolutely right. I read up to comment 30 and started skipping down towards the bottom. Name calling and temper tantrum stomping is not going to help.

If changing to a new ticket helps bring change, then I am all for it. Overall there is a desire (or need). There are other discussions outside of here asking for assistance on this and those users are being told to use other options instead.

+1 for moving to a new ticket.

Hey all,

basically the situation is:
- since 3 years (or 12 gnome-versions), there is feature-request/bug that is still in discussion
- during this time we are argumenting why this feature is nice to have or absolutely not nescessary
- We are collecting over 80 comments on this topic
- Nobody wants to gather the thanks from the community for this nice addition? A feature which is highly debatted and wanted from some usergroup?

Currently I am not able to see, where the problem is here.

Is it, because of ressources?
Or is it to hard to implement (I assume not, regarding the comments)?
Is it, because of a design guideline (haven't found one, which addresses this)?
Do we need a bounty for this?

Maybe we can help to find a way. But for now I don't think, that a discussion about pros and cons of a wanted feature with such minimal impact should take 3 years.

In comment 35, it was stated from drago01@gmail.com, that "someone" should write a patch and gnome-development will be fine with it. Is this still valid?

In comment 79, we even have the correct place for the implementation. Thanks to drago.

Is it really nescessary to open a new bug for this? Or is it enough to propose a patch?

Hi, I created account just for this annoying "bug". I think I found a workaround for this. Just disable DPMS, you can do it with "xset -dpms" in console. You need to put it in some startup script, because it is only active during current session.
Unfortunately, screensaver is still on (in my case it's default blank one), so lock screen is still black, I'm looking for solution ATM.

(In reply to Daniel from comment #86)
> Hey all,
> 
> basically the situation is:
> - since 3 years (or 12 gnome-versions), there is feature-request/bug that is
> still in discussion
> - during this time we are argumenting why this feature is nice to have or
> absolutely not nescessary
> - We are collecting over 80 comments on this topic
> - Nobody wants to gather the thanks from the community for this nice
> addition? A feature which is highly debatted and wanted from some usergroup?
> 
> Currently I am not able to see, where the problem is here.
> 
> Is it, because of ressources?
> Or is it to hard to implement (I assume not, regarding the comments)?
> Is it, because of a design guideline (haven't found one, which addresses
> this)?
> Do we need a bounty for this?
> 
> Maybe we can help to find a way. But for now I don't think, that a
> discussion about pros and cons of a wanted feature with such minimal impact
> should take 3 years.
> 
> In comment 35, it was stated from drago01@gmail.com, that "someone" should
> write a patch and gnome-development will be fine with it. Is this still
> valid?

Yes .. I have less time than I used to have when I wrote that but the comment is still valid yes ... submit a patch and I will review it.

> In comment 79, we even have the correct place for the implementation. Thanks
> to drago.
> 
> Is it really nescessary to open a new bug for this? Or is it enough to
> propose a patch?

Just propose a patch.

(In reply to rob.mackinnon from comment #78)
> Time cost wise how hard would it be to resolve this issue? A guess of 4
> hours for some config flag inserts plus some light testing? Hell, I'd be
> more than willing to put my own time in for Q&A on this to close this issue.
> Milestone 1 for this fix would be a simple add of dconf/gconf controls.
> Whereas milestone 2 would put in some UI updated controls. Can anyone give a
> more accurate time cost for just milestone 1 in this instance?

tl;dr, gnome devs may not have done the best job of user focus in this thread, but suggesting that they are lazy for not implementing the lowest-effort fix to this issue is simply false.

Yes, developers (and not just GNOME's) can take a small amount of time, add a preference, and implement the bugfix or enhancement. The problem is, if you do that over and over again, you end up with a product so bloated that it's no longer easy to use. **Adding a setting is often (arguably, usually) an excuse to skip the (design) work to figure out the right way to do things.**

That's not user focus, it's a cop out.

Users are great at pointing out problems. They're also great at coming up with solutions to those problems. They're not as great at coming up with multiple different solutions and  analyzing the pros and cons of each (especially relating to the product as a whole, not just this particular part of it).

User focus is listening to users and empathizing with them, so they know their problems are valid and heard. It's having a dialog soliciting feedback so you can design the best solution to their problems. And then it's ultimately delivering that solution. That's very different from blindly implementing whatever users demand.

IMO, the gnome devs have not done the best job at those things, here.  I think it would have been much more productive if they had acknowledged people's issues with the current functionality off the bat and asked for clarification instead of defending the current position -- that turns the discussion cooperative, rather than making it increasingly confrontational.

@Devs, please remember that the tag next to your name means your words carry a lot of weight; you have a lot of influence over the direction and tone of the conversation, and people will mimic your attitude.

Apologies for the wall of text, this is a bit of a pet peeve of mine.

Lest I be all talk and no action, here's some more talk:

I spent a couple hours this afternoon going through this thread and doing the aforementioned design work for it. I put it in bug #773645. I'd like to keep that focused on the solution so if you want to continue discussion from this thread or give feedback on why this feature is important to you, please keep it in this thread. Comment in that thread on whether or not the specific design theory works for you.

Thanks to jurf from the #gnome-design irc room (don't know your name in this thread, sorry) for reminding me of this bug and making a mockup which helped inspire my solution: http://i.imgur.com/BTY8aYS.png

You'll notice a few things missing from that thread. I left out two issues which are bugs, that should be fixed separately. (my proposal will help with those bugs since it lets you keep the screen on while locked, but it's a workaround, not a proper fix -- see my comment above about finding the right solutions). I've created bug #773648 to track real solutions to those bugs.

This issue, then, can be closed as a duplicate of one or the other -- but I would personally leave it open to allow off-topic conversation to wrap up (so it doesn't overflow into either of those issues).

Hey, thanks for the write up Stephen. I'll leave the feedback to your proposal on the other issue. Personally I would close this issue, we do not need off-topic conversation, if anyone has anything valuable to add they can do so on the new issues. Btw I'm jurf from irc, if you need any help just shoot me a message.

3 years? Wow. This annoyed ever since I installed GNOME3. 
 
First of all, turning screen off on lockscreen to preserve power is not a good feature. Standalone screens have a power button for that, and if you lock your screen you probably will have time to push that button, and make it a routine. Most of them don't handle turning on/off well, it takes time, and it is hellishly annoying. Laptop displays should IMO follow the rest of the "turn display off after x amount of time" settings. Windows 10 does this, I don't see any reason why GDM shouldn't. If the user want's to preserve laptop's power so aggressively, then that's what the lid is for. Just close lid, dammit.

Secondly, if you really wan't to preserve this feature, then let users parameterize it through GConf. At least until a dedicated solution is implemented. Adding a key in GConf for that shouldn't be that much of a hassle, should it?

Can anyone point me to the place in the source code where the screen is being turned off? I'm new to this code base.

I add a switch in Screen Lock dialog which can turn display on after locking screen. Patches is attached in https://bugzilla.gnome.org/show_bug.cgi?id=773645

*** This bug has been marked as a duplicate of bug 773645 ***

English isn't my first language, so sorry if I come out wrong, but I didn't move from Windows to Linux to be told how I need to use my device. Sadly comment's like "we're aggressively blanking the screen when it is locked, to conserve power.", "I disagree not using the screen -> turn it off is a logical thing to do." and so on do exactly that.

"An easy and elegant way to use your computer, GNOME 3 is designed to put you in control and get things done."

That said, I'm also affected by this bug.

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 2013 leaves little room for hope though I guess.

Rob: This ticket is closed as a duplicate. 
See bug 773645 instead (where you already commented).