GNOME Bugzilla – Bug 742981
No way for gnome-shell to blank the screen
Last modified: 2017-06-12 15:34:38 UTC
When screensaver is already active, there is no way to immediately blank the screen so an enforced idle timeout is the only way to do this. This becomes a problem if for example gnome-shell goes to screensaver, the user tries to enter a password, and then finally presses cancel in which case the screen shield drops down but we don't (and can't) get the blanking until the screensaver times out. https://github.com/GNOME/gnome-settings-daemon/blob/master/plugins/power/gsd-power-manager.c#L1859-L1869 I'll try to get a patch for this in the next few days.
Adding an API to blank the screen isn't the way to fix this. gnome-shell needs to export more information about its status. See screensaver_signal_cb() in that same file.
(In reply to comment #1) > Adding an API to blank the screen isn't the way to fix this. gnome-shell needs > to export more information about its status. See screensaver_signal_cb() in > that same file. Sounds good. I changed the title and I'll try to go about it that way.
Created attachment 294611 [details] [review] Proposed patch Adds a handler for ActiveResumed signal from the screensaver
Where's the ActiveResumed signal from?
Created attachment 294701 [details] [review] Gnome-shell proposed patch Since I don't have the bleeding edge dev env for the shell, this is the change that should utilize the GSD code.
I'm not sure about this. I think having the blank happen only after the timeout is fine (the timeout isn't too long anyway) and acts as a "grace period" to avoid excessive backlight on/off transitions in case the user cancels the unlock screen by mistake or just to try to clear the password field. Besides, all the state machinery is already quite complex and adding more signals to the mix just makes it worse IMO.
(In reply to comment #6) > I'm not sure about this. I think having the blank happen only after the timeout > is fine (the timeout isn't too long anyway) and acts as a "grace period" to > avoid excessive backlight on/off transitions in case the user cancels the > unlock screen by mistake or just to try to clear the password field. > > Besides, all the state machinery is already quite complex and adding more > signals to the mix just makes it worse IMO. The problem with this approach is that the user might not know how to turn their screen off (vblank) again. Why even have the "cancel" on gnome-shell's unlock dialog if gsd will take care of going back to the blanking state? It almost feels like that button is a placebo one if this change isn't implemented. Secondary concern here and the use case that I'm working on is that if you run your own non-gnome-shell screensaver that gsd listens to, there is no way to force gsd to go back to a blanked state even if possibly the user explicitly wants that to happen.
(In reply to Srdjan Grubor from comment #7) > (In reply to comment #6) > > I'm not sure about this. I think having the blank happen only after the timeout > > is fine (the timeout isn't too long anyway) and acts as a "grace period" to > > avoid excessive backlight on/off transitions in case the user cancels the > > unlock screen by mistake or just to try to clear the password field. > > > > Besides, all the state machinery is already quite complex and adding more > > signals to the mix just makes it worse IMO. > > The problem with this approach is that the user might not know how to turn > their screen off (vblank) again. Why even have the "cancel" on gnome-shell's > unlock dialog if gsd will take care of going back to the blanking state? It > almost feels like that button is a placebo one if this change isn't > implemented. That's a fair problem, but this isn't how to fix it. I've filed: https://bugzilla.gnome.org/show_bug.cgi?id=783695 about this. > Secondary concern here and the use case that I'm working on is that if you > run your own non-gnome-shell screensaver that gsd listens to, there is no > way to force gsd to go back to a blanked state even if possibly the user > explicitly wants that to happen. Right. You get to keep both pieces, this really isn't something we're interested in enabling.