From: Pavel Machek <pavel@ucw.cz>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>,
LKML <linux-kernel@vger.kernel.org>,
Jean Delvare <khali@linux-fr.org>,
"alan@linux.intel.com" <alan@linux.intel.com>,
"lenb@kernel.org" <lenb@kernel.org>,
"Cory T. Tusar" <ctusar@videon-central.com>,
"Trisal, Kalhan" <kalhan.trisal@intel.com>,
linux-acpi <linux-acpi@vger.kernel.org>
Subject: Re: RFC: Light sensors, unifying current options?
Date: Thu, 10 Sep 2009 10:23:12 +0200 [thread overview]
Message-ID: <20090910082312.GG7248@elf.ucw.cz> (raw)
In-Reply-To: <1252546449.3483.476.camel@rzhang-dt>
Hi!
> > Perhaps we might do it via sysfs naming instead.
> >
> > illuminance[n] - defined to be visible (which is what term means anyway)
> >
> > infrared[n] - hmm.. will be in different units to illuminance - perhaps we leave
> > these raw with suitable documentation?
> >
> > illuminance_and_infrared[n]
> >
> what's the unit of this?
> what does the value of this file mean?
> I think we should make sure that there are more sensors need this and
> the same "visible + infrared" reading on different sensors stands for
> the same ambient light environment.
Are you sure that makes sense? And is that even possible? I'd be
afraid that the sensors are not nearly accurate enough to give precise
values, and each sensor is going to take different parts of spectrum,
etc.
Yes, we should aim at having similar interface with similar values on
all the sensors, but lets not overdo it.
> But maybe there are some other sensors that don't have this asynchronous
> notification so that the cached values don't have a chance to get
> updated.
> then we need to read the sensor every time the sysfs I/F is poked.
I bet most sensors are like that. And no, we don't have to reread from
hw every time, we can just read and cache it once per second or
something.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2009-09-10 8:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 13:51 RFC: Light sensors, unifying current options? Jonathan Cameron
2009-09-07 5:26 ` Trisal, Kalhan
2009-09-07 7:28 ` Pavel Machek
2009-09-07 7:32 ` RFC: " Zhang Rui
2009-09-07 8:10 ` Corentin Chary
2009-09-07 11:42 ` Jonathan Cameron
2009-09-09 3:41 ` Zhang Rui
2009-09-09 11:28 ` Jonathan Cameron
2009-09-10 1:34 ` Zhang Rui
2009-09-10 8:23 ` Pavel Machek [this message]
2009-09-10 10:10 ` Jonathan Cameron
2009-09-10 10:05 ` Jonathan Cameron
2009-09-11 1:55 ` Zhang Rui
2009-09-11 7:20 ` Jean Delvare
2009-09-11 9:05 ` Jonathan Cameron
2009-09-11 9:22 ` Jonathan Cameron
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=20090910082312.GG7248@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=alan@linux.intel.com \
--cc=ctusar@videon-central.com \
--cc=jic23@cam.ac.uk \
--cc=kalhan.trisal@intel.com \
--cc=khali@linux-fr.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rui.zhang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox