linux-kernel - Re: RFC: Light sensors, unifying current options?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 11 Sep 2009 10:22:16 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Zhang Rui <rui.zhang@...el.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Jean Delvare <khali@...ux-fr.org>,
	"alan@...ux.intel.com" <alan@...ux.intel.com>,
	"lenb@...nel.org" <lenb@...nel.org>, "pavel@....cz" <pavel@....cz>,
	"Cory T. Tusar" <ctusar@...eon-central.com>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	linux-acpi <linux-acpi@...r.kernel.org>
Subject: Re: RFC: Light sensors, unifying current options?

> 
> so, if there are two sensors that support visible and infrared,
> sensor 1:
> illuminance:	xxx
> infrared:	yyy
> sensor 2:
> illuminance:	xxx
> infrared:	yyy
> 
> does this mean the ambient light of these two sensors are the same?
If the values are the same, then probably up to variations in the
sensitivity of the two sensors (and things like calibration etc
afterall we don't really have a ready consistent measure for infrared
in the same way as the perception scaled illuminance)

It's entirely possible that two sensors on a given device might get
different readings, both of which are useful. e.g. one of those
phones with a screen on the outside then a flip lid with another one
underneath for example. 

> 
> If no, I can't image how the userspace app uses these attributes?
That depends if your aim is to use them to control the brightness of
a screen and similar, or for example to use them for environmental
monitoring.

I agree with Jean (next email) in many ways that it is useful to
hide some complexity within a given driver (so as to provide
consistent interfaces etc to userspace.) However, if we can
also provide device specific access to other features of the device
I see no reason not to make them available.  As already stated, there
are several applications where that infrared measurement is useful
even if only available as a raw adc count. (typically you'd have a
calibration function from measured values of what ever you care about
anyway).

As long as we have illuminance (the generally useful one that all such
sensors seem to provide) then any other values the driver wants to export
are fine as long as we maintain decent documentation of what they are.

Jonathan

--
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/