[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090716024057.GA2461@srcf.ucam.org>
Date: Thu, 16 Jul 2009 03:40:57 +0100
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Zhang Rui <rui.zhang@...el.com>
Cc: Richard Purdie <rpurdie@...ys.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"lenb@...nel.org" <lenb@...nel.org>,
"corentincj@...aif.net" <corentincj@...aif.net>
Subject: Re: [PATCH 1/3] backlight: Allow drivers to update the core, and
generate events on changes
On Thu, Jul 16, 2009 at 10:39:34AM +0800, Zhang Rui wrote:
> On Wed, 2009-07-15 at 21:58 +0800, Matthew Garrett wrote:
> > On Wed, Jul 15, 2009 at 10:11:29AM +0100, Richard Purdie wrote:
> >
> > > So there are basically two values we're ever interested in at a given
> > > point in time. The current ambient light reading and the corresponding
> > > display luminance adjustment. Both of those could just be exposed as an
> > > input device really?
> >
> > The alternative would be hwmon, I guess.
>
> you mean convert an ACPI ALS device to a hwmon device?
Yes.
> > You want smoothing even in a default policy, and doing that well might
> > be a bit much for the kernel?
> >
> sorry, I don't understand.
> do you mean that there should be a default policy in the kernel?
No, I mean that the only default policy you could reasonably have in the
kernel would be tying the backlight directly to the ALS. And that sucks.
You need some degree of smoothing, and that's a job better left to
userspace.
--
Matthew Garrett | mjg59@...f.ucam.org
--
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