[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090919232424.GA15200@khazad-dum.debian.net>
Date: Sat, 19 Sep 2009 20:24:24 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Matthew Garrett <mjg@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
rpurdie@...ys.net, lenb@...nel.org, rui.zhang@...el.com,
corentincj@...aif.net
Subject: Re: [PATCH 1/3] backlight: Allow drivers to update the core, and
generate events on changes
On Tue, 14 Jul 2009, Matthew Garrett wrote:
> Certain hardware will send us events when the backlight brightness
> changes. Add a function to update the value in the core, and
> additionally send a uevent so that userspace can pop up appropriate
> UI. The uevents are flagged depending on whether the update originated
> in the kernel or from userspace, making it easier to only display UI
> at the appropriate time.
Ok. I have it working (event-based AND poll-based) in thinkpad-acpi,
although it needs to be tested by dual-GPU, ACPI-based and OpRegion-based
owners.
Should the driver notify of *any* changes, even when the user is hitting the
"ceiling" or the "floor" and the backlight value didn't really change?
If the answer is no, shouldn't the backlight class filter these out itself,
to guarantee a consistent experience?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
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/
Powered by blists - more mailing lists