From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: hal@lists.freedesktop.org,
Corentin Chary <corentin.chary@gmail.com>,
linux acpi <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] laptop_panel.brightness_in_hardware: add all Asus laptops
Date: Thu, 16 Jul 2009 23:27:03 +0100 [thread overview]
Message-ID: <20090716222703.GA24437@srcf.ucam.org> (raw)
In-Reply-To: <4A5FA837.9050300@tuffmail.co.uk>
On Thu, Jul 16, 2009 at 11:22:47PM +0100, Alan Jenkins wrote:
> I just saw the patch to generate uevents for the acpi video driver. It
> looks like it still generates KEY_BRIGHTNESSDOWN. Are you planning a
> followup patch, to suppress the input events when
> brightness_switch_enabled == 1?
I didn't want to change the behaviour of the driver with existing
userspace, but yes, I agree that that's the correct behaviour. To make
it consistent with everything else it should probably also default to
brightness_switch_enabled = 0 (and we ship it that way in Fedora), but
again, compatibility.
> Equally, w.r.t patch 3, I don't think eeepc-laptop, should generate
> brightness events on the *input* device anymore.
Right.
> The rationale is that KEY_BRIGHTNESSDOWN is a user request to increase
> brightness. In these cases, the firmware/driver has already increased
> the brightness. We've notified userspace via the backlight device. So we
> shouldn't pass the request on to userspace; it has already been acted
> upon. If we still generate KEY_BRIGHTNESS*, userspace has to guess
> whether or not the change has already been applied. If there is too much
> latency, it guesses wrong :-(.
Absolutely. The other thing that needs doing is for dell-laptop to
consume the brightness keys, or alternatively for us to remap them on
Dells. Right now (in the worst case) we're getting two sets of them.
--
Matthew Garrett | mjg59@srcf.ucam.org
prev parent reply other threads:[~2009-07-16 22:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A49D305.1040703@tuffmail.co.uk>
[not found] ` <71cd59b00906300231yf2d3657tb5c5945f5aae0e7b@mail.gmail.com>
[not found] ` <20090708095111.GA8471@srcf.ucam.org>
[not found] ` <61b223ba0907080336i313232cco216c9c647a2e9247@mail.gmail.com>
[not found] ` <20090708104300.GA10269@srcf.ucam.org>
2009-07-16 22:22 ` [PATCH] laptop_panel.brightness_in_hardware: add all Asus laptops Alan Jenkins
2009-07-16 22:27 ` Matthew Garrett [this message]
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=20090716222703.GA24437@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=alan-jenkins@tuffmail.co.uk \
--cc=corentin.chary@gmail.com \
--cc=hal@lists.freedesktop.org \
--cc=linux-acpi@vger.kernel.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.