All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.