On 02/03/15 19:03, Kevin Tsai wrote: > Hi Daniel, > > Ambient light sensor is trying to match the brightness sensitivity of human visual system. Please see the following links: > http://en.wikipedia.org/wiki/Color_vision#mediaviewer/File:Eyesensitivity.svg > http://en.wikipedia.org/wiki/Color_vision > > You can compare the spectrum with the datasheet. The green channel is matched with ALS spectrum. It's close (ish) to the right measurement, but it isn't the right measurement. As such I'd argue we leave it up to userspace to make the jump and use Green if a true estimate if illuminance isn't available, but don't suggest it is available from the kernel. > > Kevin Tsai > 03/02/15 > > -----Original Message----- > From: daniel.baluta@xxxxxxxxx [mailto:daniel.baluta@xxxxxxxxx] On Behalf Of Daniel Baluta > Sent: Monday, March 02, 2015 1:57 AM > To: Daniel Baluta > Cc: Jonathan Cameron; Kevin Tsai; Hartmut Knaack; Lars-Peter Clausen; Peter Meerwald; linux-iio@xxxxxxxxxxxxxxx; Linux Kernel Mailing List > Subject: Re: [PATCH] iio: light: Add support for Capella CM3323 color/light sensor > > On Sun, Jan 25, 2015 at 12:50 PM, Daniel Baluta <daniel.baluta@xxxxxxxxx> wrote: >> On Sun, Jan 25, 2015 at 12:27 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: >>> On 22/01/15 10:10, Daniel Baluta wrote: >>>> Minimal implementation providing raw light intensity and illuminance >>>> readings. For illuminance user can compute lux values using raw >>>> readings and scale. >>>> >>>> This driver also supports CM3323E sensor chip. >>>> >>>> Cc: Kevin Tsai <ktsai@xxxxxxxxxxxxxxxx> >>>> Signed-off-by: Daniel Baluta <daniel.baluta@xxxxxxxxx> >>> >>> Hi Daniel, >>> >>> My only real question on this one is whether using the 'green' >>> channel and pretending it is a measure of illuminance is a good idea >>> or whether we are better leaving that decision to userspace... >>> >>> I'm guessing the reason it is green rather than clear is that the >>> clear is letting infrared through and we don't have an additional >>> infrared sensor available to allow that component to be removed? >> >> Hi Jonathan, >> >> <snip> >>>> +#define CM3323_COLOR_CHANNEL(_color, _addr) {\ >>>> + .type = IIO_INTENSITY, \ >>>> + .modified = 1, \ >>>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \ >>>> + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME), \ >>>> + .channel2 = IIO_MOD_LIGHT_##_color, \ >>>> + .address = _addr, \ >>>> +} >>>> + >>>> +/* >>>> + * CM3323's GREEN channel is used for reading illuminance >>> That's impressively random and unlikely to be anywhere near correct >>> pretty much all the time! >>> >>> I'd personally prefer just not providing an illuminance channel and >>> leaving it up to userspace to make the decision on whether the green >>> channel is good enough... >> >> Datasheet says that the GREEN channel should be used for getting >> illuminance readings. I'm not sure if this is totally random. >> >> I understand your worries, perhaps Kevin could 'enlighten' us here. >> >> I would prefer to have the illuminance channel exported from IIO >> because there are already userspace applications/frameworks written >> and tested for ALS that use IIO illuminance channel. >> We want to use this driver without modifying user space. >> >> Of course, one option for the moment would be to only export the >> INTENSITY channels as per your recommendation and to decide later what >> to do for the LIGHT channel. > > Hi Kevin, > > Could you tell us how reliable is using the GREEN channel for getting illuminance readings? > > If no objection, I will resend this driver exposing only INTENSITY channels for the moment. > > thanks, > Daniel. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
