GNOME Bugzilla – Bug 333290
Screen is still dimmed when entering password dialog
Last modified: 2006-05-24 13:13:32 UTC
It seems g-p-m now dims the screen (using SetLCDBrightness() on HAL) on session inactivity. However, if you use the screen locking on the screen saver the screen isn't set to full brightness until I have entered the right password. This means the screen is rather dim when I see the lock dialogue. Seen on Fedora Core Rawhide. g-p-m 2.13.92-1 g-s 2.13.92-1
I'm guessing the lock dialogue stops g-s emmitting active-state-changed signals. Could this be the issue Jon? Richard.
SessionIdleChanged and ActiveChanged are only sent when the screen is unlocked/unblanked. We shouldn't change that. My first reaction is to have g-s call a DBUS method of g-p-m to reset the brightness (and turn on monitor if necessary) when we get the dialog-up signal. And maybe set it back down when the dialog-down signal is handled. Turning on the monitor would only be an issue when the dbus poke method is used. After 2.14 I'll branch and I think we need to more tightly couple g-p-m and g-s. There was just too much politics going on this cycle to do that properly.
>SessionIdleChanged and ActiveChanged are only sent when the screen is >unlocked/unblanked. We shouldn't change that. Why? Surely if a user is trying to log back into his/her system then they are not "idle"?
Until they are actually back... they are idle (ie. aren't using the desktop). Also it isn't necessarily true that the "user is trying to log back [in]" because the dialog will come up whenever the mouse moves or the keyboard is touched.
Maybe g-s just needs to emit a third signal when X input is no longer idle. See also bug 333525 which is kinda related to this - at least this bug triggers that bug a lot more...
Jon, any reason why a two second poll was chosen in g-s for the idle state changes? There's a tiny ~1 second "lag" when i move my mouse and g-p-m un-dimming the screen that I suspect is the 2 second poll timeout. Thanks.
Nothing specific. It is a compromise between introducing overhead and a good response time. It also must well sample the 10 second slow fadeout right before the session idle signal. Anyway I think I pulled it out of the air.
David, yes, emitting a third signal might be fine too. Rather than something low level like X events I think it might be better to present it as something like AuthenticationRequestBegin and AuthenticationRequestEnd. Which might even be useful for auditing and stuff too.
Jon, whats the plan for this, now we are in the 2.15 timeframe.
AuthenticationRequestBegin should trigger the lcd resume?
g-s in CVS emits AuthenticationRequestBegin and AuthenticationRequestEnd.
Good man, I'll play with those tmw. Thanks.
Revision sucks :-): 2006-05-04 Richard Hughes <richard@hughsie.com> * src/gpm-screensaver.{c|h}: Add gpm_screensaver_auth_begin() and gpm_screensaver_auth_end() so that we can create a signal "auth-request" when gnome-screensaver shows the password dialogue. This is needed so we can undim the screen when we resume and show the password box. Needed for #333290, but still need to connect this up to the manager stuff to solve the problem.
2006-05-24 Richard Hughes <richard@hughsie.com> * src/gpm-manager.c (screensaver_auth_request_cb): Undim the screen when we have to unlock returning from resume. This should fix #333290.