lkml.org 
[lkml]   [2009]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2.6.29] eeepc-laptop: report brightness control events via the input layer
From
On Sat, Jun 13, 2009 at 7:51 PM, Alan
Jenkins<sourcejedi.lkml@googlemail.com> wrote:
> On 6/13/09, Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
>> I demand that Corentin Chary may or may not have written...
>>
>>> On Sat, Jun 13, 2009 at 11:33 AM, Alan
>>> Jenkins<alan-jenkins@tuffmail.co.uk>
>>> wrote:
>> [snip]
>>>> The firmware still changes the brightness immediately.  It seems
>>>> that when g-p-m gets delayed, it responds _wrongly_. It doesn't realize
>>>> that the firmware already changed the brightness, so it changes the
>>>> brightness again.
>>
>> Should it be changing the brightness at all? I ask because every laptop
>> which
>> I've used will change the brightness without userspace being involved.
>> (Although it's possible that g-p-m might get brightness-change events from
>> some source other than that which is used to report the laptop's own
>> brightness controls...)
>
> Good point.  Google suggests it may be necessary on some other systems though.
>
> <https://lists.ubuntu.com/archives/kubuntu-bugs/2009-February/067008.html>
>
> And I was wrong before when I said g-p-m should watch the generic
> backlight interface.  It doesn't generate uevents, and in one way
> that's good, because uevents are relatively heavyweight.  So the
> brightness up / down "keypress" events are the only generic way that
> g-p-m can use to detect changes :-(.
>
> But I don't think it's important to be able to show a brightness
> pop-up.  So I'm less confident, but I still think this change should
> be reverted.
>
>> [snip]
>>> Version: 2.24.2-2ubuntu8
>>> Ok I can reproduce [the brightness being changed inappropriately from
>>> userspace].
>>
>>> I want to check if we can't fix g-p-m before reverting the patch. If
>>> there is no way to fix it, I'll revert.
>>
>> I don't see that it can ever be reliable in the face of the brightness
>> having
>> already been changed without userspace involvement short of being able to
>> tell it to report only on some/all events from some input devices.
>
> Hmm.  I think I could accept it if it only played up when thrashing
> the SSD.  So I'll try to work out exactly what happens in the other
> case I reported, in case they're not the same problem.  (This other
> problem is where I hold down "brightness down", then tap "brightness
> up" a couple of times; the first couple of taps casue a flash as the
> brightness goes first up and then down).
>
> Alan
>

CCed gnome-power-manager, as it seems to be the only userspace program
concerned.
You may be able to help us here.

You can find the complet discussion here:
http://groups.google.com/group/linux.kernel/browse_thread/thread/a7bef6cffb7c2d6b/c732f616555d5180?#c732f616555d5180


--
Corentin Chary
http://xf.iksaif.net - http://uffs.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-06-14 21:29    [W:1.687 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site