linux-kernel - Re: [PATCH 2/2] iio: cros_ec_light: Add support for RGB sensor

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]

Message-ID: <20200502185615.74db5af1@archlinux>
Date:   Sat, 2 May 2020 18:56:15 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Gwendal Grignou <gwendal@...omium.org>
Cc:     Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Benson Leung <bleung@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-iio <linux-iio@...r.kernel.org>
Subject: Re: [PATCH 2/2] iio: cros_ec_light: Add support for RGB sensor

On Thu, 30 Apr 2020 14:07:03 -0700
Gwendal Grignou <gwendal@...omium.org> wrote:

> On Sat, Apr 25, 2020 at 10:31 AM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Wed, 22 Apr 2020 17:02:30 -0700
> > Gwendal Grignou <gwendal@...omium.org> wrote:
> >  
> > > Add support for color sensors behind EC like TCS3400.
> > > The color data can be presented in Red Green Blue color space (RGB) or
> > > the CIE 1931 XYZ color space (XYZ).
> > > In XYZ mode, the sensor is configured for auto calibrating its channels
> > > and is the "normal" mode.
> > > The driver tells the EC to switch between the 2 modes by using the
> > > calibration command.
> > > When the sensor is in calibration mode, only clear and RGB channels are
> > > available. In normal mode, only clear and XYZ are.
> > > When RGB channels are enabled, the sensor switches to calibration mode
> > > when the buffer is enabled.
> > >
> > > When reading trhough sysfs command, set calibration mode and then read
> > > the channel(s). A command will be issue for each read, so the channels
> > > may come from different sensor sample.
> > > When using the buffer, after setting the mask, when the buffer is
> > > enabled, the calibration will be set based on the channel mask.
> > >
> > > libiio tools can be used to gather sensor information:
> > > iio_readdev -s 10 cros-ec-light \
> > > illuminance_clear illuminance_x illuminance_y illuminance_z  
> > Illuminance is not defined for color channels.  It's units are LUX which
> > is only defined wrt to a model of the human eye's response to
> > 'brightness' (kind of).  
> Looking at "Calculating Color Temperature and Illuminance " from AMS
> [https://ams.com/documents/20143/80162/TCS34xx_AN000517_1-00.pdf/1efe49f7-4f92-ba88-ca7c-5121691daff7]
> page 5, equation 2, the illuminance (Y) is a derived from the vector
> (X, Y, Z) with coefficient applied. Doesn't it mean
> in_illumincance_[X,Y,Z,R,G,B,clear ...]_raw have all the same unit,
> lux?

Unfortunately not.   Lux is only defined as brightness as measured
with a very specific sensitivity profile across the bands. It has no
meaning as a unit for the various elements added up to get to it.
(somewhere good old dimensional analysis breaks down)

Fun corner case of units :)

I have seen data sheets that get this wrong btw.
It's a complex mess because RGB channels are not separable
either.  They all have overlapping frequency sensitivities.
Generally the sensors are designed to have some linear combination
of curves that is close to the curve used for illuminance as they
want to match human eye view of what bright is.

If you can provide enough info to the driver to do the calculation
that would be ideal as then we could provide a standard measure of
brightness to userspace.

Jonathan