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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 13 Jun 2009 18:51:12 +0100
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Corentin Chary <corentin.chary@...il.com>,
	Alan Jenkins <alan-jenkins@...fmail.co.uk>,
	linux-kernel@...r.kernel.org, acpi4asus-user@...ts.sourceforge.net,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Darren Salt <linux@...mustbejoking.demon.co.uk>
Subject: Re: [PATCH 2.6.29] eeepc-laptop: report brightness control events via 
	the input layer

On 6/13/09, Darren Salt <linux@...mustbejoking.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@...fmail.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
--
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/