All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corentin Chary <corentin.chary@gmail.com>
To: alan-jenkins@tuffmail.co.uk
Cc: Darren Salt <linux@youmustbejoking.demon.co.uk>,
	linux-kernel@vger.kernel.org,
	acpi4asus-user@lists.sourceforge.net,
	Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH 2.6.29] eeepc-laptop: report brightness control events via  the input layer
Date: Sat, 13 Jun 2009 10:55:11 +0200	[thread overview]
Message-ID: <71cd59b00906130155u2757ade3t3378685846b80410@mail.gmail.com> (raw)
In-Reply-To: <9b2b86520906080824i134ee546v33990176b0d3e618@mail.gmail.com>

On Mon, Jun 8, 2009 at 5:24 PM, Alan
Jenkins<sourcejedi.lkml@googlemail.com> wrote:
> On 4/4/09, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> On Fri, Apr 03, 2009 at 06:57:50PM +0100, Darren Salt wrote:
>>> This maps the brightness control events to one of two keys, either
>>> KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP, as needed.
>>>
>>> Some mapping has to be done due to the fact that the BIOS reports them as
>>> <base value> + <current brightness index>; the selection is done according
>>> to
>>> the sign of the change in brightness (if this is 0, no keypress is
>>> reported).
>>>
>>> (Ref.
>>> http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-April/002001.html)
>>>
>>> Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
>>
>> The reason I didn't do this is that the Eee changes the input brightness
>> in hardware, which means reporting it via the input layer as well can
>> cause a single keypress to raise the brightness by two steps - one in
>> hardware and one triggered by userland's response to the key press. I'd
>> be a little bit wary of this causing problems.
>>
>> On the other hand, the default behaviour of the acpi video driver is to
>> change the brightness itself and then also to send the even to
>> userspace, so I guess if it was going to break things it probably would
>> have done already...
>
> Actually, I think userspace has learnt to hack around it but it
> doesn't work perfectly.  I would like to request that this change be
> reverted, or otherwise improved.
>
> Before this patch (2.6.29.4), gnome-power-manager doesn't interfere
> with the brightness keys, and they work smoothly.
>
> After this patch (2.6.30-rc7), g-p-m produces a "nice" popup in the
> middle of my tiny netbook screen.  Unfortunately it can't be disabled,
> but that's not your fault :-).  The brightness controls generally work
> ok.  It doesn't jump two steps in response to one brightness keypress.
>  But:
>
> 1) If I'm thrashing the SSD.  I get jerky after-effects, where g-p-m
> seems to take too long to "catch up" with the brightness change.

There is the same "lag" problem with sound :/

> 2) If I go all the way down from full (holding down the "brightness
> down" key), and then back up a few steps.  I get a noticable flash
> where the brightness looks to go up two steps, then down one.  It's
> probably most noticable here because the step change between the
> lowest and the second lowest brightness is much more visible than any
> of the other steps.
>
I tried to install gnome-power-manager to test that, but there is no "popup".
What do I have to install to test that ? entire gnome desktop :/ ?

Thanks


-- 
Corentin Chary
http://xf.iksaif.net - http://uffs.org

  reply	other threads:[~2009-06-13  8:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-03 17:57 [PATCH 2.6.29] eeepc-laptop: report brightness control events via the input layer Darren Salt
2009-04-04  4:18 ` Matthew Garrett
2009-04-04  8:33   ` Corentin Chary
2009-04-04 12:20     ` Darren Salt
2009-04-04 12:35       ` Corentin Chary
2009-04-04 22:10         ` Darren Salt
2009-04-05  8:22           ` Corentin Chary
2009-06-08 15:24   ` Alan Jenkins
2009-06-13  8:55     ` Corentin Chary [this message]
2009-06-13  9:33       ` Alan Jenkins
2009-06-13 10:06         ` Corentin Chary
2009-06-13 12:55           ` Darren Salt
2009-06-13 17:51             ` Alan Jenkins
2009-06-14 19:26               ` Corentin Chary
2009-06-15  8:09                 ` Alan Jenkins
2009-06-15  8:12                   ` Alan Jenkins
2009-06-16  8:33                   ` [gpm] " Richard Hughes
2009-06-16  8:34                     ` Alan Jenkins
2009-06-16  8:47                       ` Richard Hughes
2009-06-16  9:44                         ` Corentin Chary
2009-06-16 10:04                           ` Richard Hughes
2009-06-18 13:33                             ` Alan Jenkins
2009-06-18 22:44                               ` Corentin Chary

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=71cd59b00906130155u2757ade3t3378685846b80410@mail.gmail.com \
    --to=corentin.chary@gmail.com \
    --cc=acpi4asus-user@lists.sourceforge.net \
    --cc=alan-jenkins@tuffmail.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@youmustbejoking.demon.co.uk \
    --cc=mjg59@srcf.ucam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.