GNOME Bugzilla – Bug 662972
Brightness does not go full when you plug in a system that's idle
Last modified: 2013-01-25 21:02:10 UTC
To reproduce: unplug a laptop wait for the idle timeout to kick in plug back into AC the brightness does not go back to full, but logically, it should: there is no idle dim on AC by default, so brightness should always be 100% when the laptop's plugged in. So when the laptop's on battery and idle, and you plug it back in, brightness should go full.
it used to do this with the old g-p-m, this is a regression in the new g-s-d code. it's not terribly serious as brightness goes back full as soon as you un-idle, it's just something I always notice.
What's the logic to doing back to 100%? We still want to save power on AC if the computer is idle, even if the AC has just returned.
(In reply to comment #2) > What's the logic to doing back to 100%? We still want to save power on AC if > the computer is idle, even if the AC has just returned. Not to 100%, but I would certainly expect it to go to the non-idle brightness level, as if an event occurred.
(In reply to comment #3) > Not to 100%, but I would certainly expect it to go to the non-idle brightness > level, as if an event occurred. Is using FakeKeys to press a virtual button too much of a hack to reset the idle timer? The state machine is complicated enough already...
Sounds like a Peter question. He's been working on Sync counters recently, there might be a way to reset one without such a hack.
as Bastien says, it seems reasonable to consider plugging the computer back in to be an 'event'. Though I suppose you can't tell whether the user actually just plugged the jack back in, or if the power had gone down and just came back with no user intervention. It seems safe to assume the former is the 'normal' case.
Asked keith about this, according to him we don't really have an event when the power is plugged in.
(In reply to comment #7) > Asked keith about this, according to him we don't really have an event when the > power is plugged in. Well, we're looking for an event to generate which wouldn't have an adverse effect on whatever is already running, but would poke the idle timers. A function to poke the idle timers and reset them would be fine.
We don't have a function for this, the system idle timers can't be set by a client (BadAccess). The simplest solution for now may just be to send a xtest key event that generates XF86MonBrightnessUp and take that as a hint to re-set it. It doesn't rely on any hacks and resets the idletime counters.
Thinking about this again, I think I'm missing something here. You're looking for an event to generate to reset the idle timers. Who sends that event? Couldn't you tell the state machine to reset itself directly (DBus? whatever it uses) to the equivalent AC state? do you need to go through X here? Resetting the idle timers seems to be the wrong solution anyway. Case in point: if the machine has been idling for 1h and the screen is off, plugging the power supply in should not necessarily turn the screen on, it should instead jump to whatever the AC equivalent of the 1h behaviour is. am I missing something here?
*** Bug 681361 has been marked as a duplicate of this bug. ***
Created attachment 233702 [details] [review] power: Un-idle temporarily when plugging in AC Really incomplete patch, needs test suite backing before it's finished and gets committed.
Created attachment 234447 [details] [review] power: Un-idle temporarily when plugging in AC
Attachment 234447 [details] pushed as 253001a - power: Un-idle temporarily when plugging in AC (and test pushed too)