linux-kernel - Re: [PATCH 2.6.29] eeepc-laptop: report brightness control events via the input layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Jun 2009 16:24:01 +0100
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Darren Salt <linux@...mustbejoking.demon.co.uk>,
	Corentin Chary <corentincj@...aif.net>
Cc:	linux-kernel@...r.kernel.org, acpi4asus-user@...ts.sourceforge.net,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH 2.6.29] eeepc-laptop: report brightness control events via 
	the input layer

On 4/4/09, Matthew Garrett <mjg59@...f.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@...mustbejoking.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.

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.

Both seem realistic use cases on this hardware.  It's obviously a
cheap SSD which is prone to latency during large writes.  And when I
move between rooms, I often adjust the brightness this way, to find
the minimum brightness which is comfortable.

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