> > 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
