[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1248881499.2289.137.camel@dax.rpnet.com>
Date: Wed, 29 Jul 2009 16:31:39 +0100
From: Richard Purdie <rpurdie@...ys.net>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: Pavel Machek <pavel@....cz>, Zhang Rui <rui.zhang@...el.com>,
"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 Wed, 2009-07-29 at 16:20 +0100, Matthew Garrett wrote:
> On Wed, Jul 29, 2009 at 05:05:24PM +0200, Pavel Machek wrote:
> > > 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.
> >
> > How would that be done? Wake up userspace 100times a second so it can
> > read an integer and ardd it to running average?
>
> I don't think you'd need more than once a second, possibly modified by
> the size of the change since the last measurement. Response doesn't need
> to be immediate.
It depends how fancy your algorithm is really. If its not that complex
and not floating point etc. then you probably could have some basic
kernel implementation in a few lines of code which used a timer callback
to smooth things out. I agree that userspace should be able to run the
show if it wants to or its some horrible complex calculation though.
Assuming no complaints I'll queue the patches from this series in the
backlight tree in the next could of days. I'll probably include the ACPI
bits since they're more backlight than APCI unless Len has an objection.
Cheers,
Richard
--
Richard Purdie
Intel Open Source Technology Centre
--
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