Re: [gpm] Changing Backlight



On Wed, 2008-04-09 at 19:57 -0700, Ted Gould wrote:
> I like the way that you split the XRandR stuff and HAL stuff into it's
> own subclasses, I think that'll help to support a lot more cards --
> which is exciting.

Yup, it also allows us to do things quicker, and get a property changed
callback; well, when we've fixed XOrg to report the events properly...
https://bugs.freedesktop.org/show_bug.cgi?id=15437

> But, I do disagree with the changes to the brightness logic.  I think
> that it still works on the assumption that the user always want to go
> back to the point where the brightness was.  I don't think that's the
> common case.  For me, a common use case is that I'll take my laptop
> and do some work; and let's say that it's gotten dark while I was
> working.

Can you try again with svn from today pls? The brightness now does the
right thing for me - which is is probably the first time I can say that
about g-p-m...

> On a more practical level I don't think (and I may have read this
> wrong)
> take into account "dual changes."  For instance if you unplug the AC
> and then go idle, and the plug back in the AC and then move the mouse.
> I'm not quite sure that through that round trip you'd get the expected
> result.

Yes, this should work - the users preference "how much light do I need"
is _scaled_ when pulling the plug, and then scaled back up when plugging
back the AC. The same happens when idle and non-idle.

> Lastly, on a very practical level, I think that scale can get reset to
> 1.0 after being set by battery but action is disabled on idle.

Sure, but scale is only used by the printf:

gpm_debug ("2. battery scale %f, brightness %f", scale, brightness);

It's the 'brightness' value that is propagated on in the evaluation.

Richard.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]