Ambient Light Sensors subsystem
in [Kernel]
|
Prev: linux-next: build failure after merge of the driver-core tree
Next: linux 2.6.32 and 2.6.26 nat with pppoe throughput is very different.
From: Manu Abraham on 3 Mar 2010 14:40 On Wed, Mar 3, 2010 at 11:20 PM, Jonathan Cameron <kernel(a)jic23.retrosnub.co.uk> wrote: > On 03/03/10 18:52, Linus Torvalds wrote: >> >> >> On Wed, 3 Mar 2010, Dmitry Torokhov wrote: >> >>> On Wed, Mar 03, 2010 at 09:03:16AM -0800, Linus Torvalds wrote: >>>> >>>> What's the difference between a physical "increase screen brightness" key, >>>> and a "ambient light sensor"? Absolutely none as far as I can tell. >>> >>> Because in general ambient light sensor may have nothing to do with the >>> screen brightness. The fact that all current uses are tied to >>> controlling screen brightness is coincidential. You could use it as well >>> to turn on the lights in the kitchen if it is getting too dark... >> >> But my point is, it acts pretty much like a key on a keyboard >> _regardless_. > Just one small clarification here. �It behaves a lot more like the axis of > a joystick. �These sensors report illuminance, not merely a binary result. > Some of them do have sophisticated threshold type logic, but > all of them we have seen so far allow direct reading of the value. �Typical > uses include things like long term environmental monitoring as > well as screen brightness. �I have at least one Mote on my desk that has a > ambient light sensor and no ability whatsoever to drive a screen. > (Not that this effects whether input would make sense anyway!) Maybe it make sense to put all Generic sensors into one whole lot, where an application can - read the value from the driver (eg: 0 - 65535) - read from device static information (to identify how the application should treat the values read back.) - report what type of device it is (Light, Voltage, Acceleration and what not, simple enumeration will help, mayeb you can even have bitwise OR the types, so that you can have a driver with multiple capabilities) - the max value it can go - the min value it can go - the number of steps (gradient) that the driver can do. Maybe such a simplistic interface does help ? The application can simply read the static information from the driver and decide whether it should really handle that driver class. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 3 Mar 2010 14:50 Hi Manu, .... > Maybe it make sense to put all Generic sensors into one whole lot, > where an application can > > - read the value from the driver (eg: 0 - 65535) > > - read from device static information (to identify how the application > should treat the values read back.) > > - report what type of device it is (Light, Voltage, Acceleration > and what not, simple enumeration will help, mayeb you can even have > bitwise OR the types, so that you can have a driver with multiple > capabilities) > - the max value it can go > - the min value it can go > - the number of steps (gradient) that the driver can do. > > > Maybe such a simplistic interface does help ? > > The application can simply read the static information from the driver > and decide whether it should really handle that driver class. The more generic sensors are covered by IIO (in staging) There is a lot more there as well as an equivalent of what you describe. The simplest equivalent to this is the hwmon subsystem (from which IIO has borrowed a lot of interfaces, as has ALS). You have a sysfs file per channel, so taking als api as an example: illuminance0 - Value of illuminance in lux. If you want your other elements (though no driver provides them at the moment). illuminance0_max illuminance0_min illuminance0_values For slow devices this is all you need. If you are interested in fast devices, take a look at the recently posted IIO ABI spec. That uses sysfs files to describe the data that can be read from a character device that is fed from a buffer (either hardware or software). It also supports fairly advanced event handling (similar to input, but without cross device aggregation) and triggering of data capture from various 'interrupt' sources. It is still somewhat unclear how exactly to marry the high speed data acquisition requirements with other 'client' subsystems such as input. All suggestions on that are welcome! Jonathan (cc'd linux-iio) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 3 Mar 2010 15:10 On 03/03/10 19:33, Jonathan Cameron wrote: > Hi Dmitry, >>>>> What's the difference between a physical "increase screen brightness" key, >>>>> and a "ambient light sensor"? Absolutely none as far as I can tell. >>>> >>>> Because in general ambient light sensor may have nothing to do with the >>>> screen brightness. The fact that all current uses are tied to >>>> controlling screen brightness is coincidential. You could use it as well >>>> to turn on the lights in the kitchen if it is getting too dark... >>> >>> But my point is, it acts pretty much like a key on a keyboard >>> _regardless_. >>> >>> Sure, you migth use it to turn up the lights too. But how is that >>> different from having a switch to do the same? Again, it doesn't sound >>> that different from a key to me. >> >> I guess for me the distinction is that the event was not caused by an >> action of a human being but by change in environment. >> >> Also, if we decide that input layer is the best place for such devices, >> it should not be a key but absolute event, ABS_LIGHT_LEVEL or something. >> >>> >>>> Yes, it is easier, but it is not necessarily the right interface. I >>>> still believe in using input layer for human iteraction events, and not >>>> as generic transport a-la netlink or uevent. Voltage measurements, >>>> network cable presence notifications, ambient light/temperature sensors, >>>> and so forth do not belong here. >>> >>> The thing is, if the choice is about a whole new subsystem just for some >>> silly light sensor logic, I'd _much_ rather see the much simpler - and >>> more useful - approach of just considering it an input event. >>> >>> It happens in the same kind of situations, it has the same kinds of timing >>> issues (ie we're not talking streaming megabytes of data), and it has the >>> same kind of users (ie a lightsensor really would be used along with >>> something that cares about input). >>> >>> I agree that that's not true in many other situations. A cable insertion >>> event is about the networking, not about some independent input. The kind >>> of application that cares about network cable presense is _not_ the kind >>> of app that would care about keyboard input. Same goes for voltage. >> >> What about magnetometers, accelerometers and so forth? I still do not >> think they are pure input layer devices although it is possible to build >> a bridge modules so they could plug into input framework if desired. >> >>> >>> That said, I'm not married to the whole "it has to be input layer". But I >>> _do_ think that it's crazy to start doing new subsystems for every little >>> thing. That way lies madness. >>> >> >> I was hoping IIO would fill the niche of framework for generic data >> acquisition devices, regardless of how fast or slow they are. > We are working on it, but unfortunately the 'fast' end of the scale is > making it rather complex beast and there is still a fair bit of work > to be done before we suggest merging into the main tree. We allow > for 'simple' drivers that do have very similar functionality to ALS as > proposed. (i.e. they just handle some sysfs interfaces and device > registration). > > I certainly have no objection to taking light sensors back into IIO. > (one never moved out!) Obviously I'll want opinions from the individual > driver developers before doing this. As things currently stand it involves > moving drivers out of mainline into staging. Whilst we have numerous drivers > being developed against the subsystem as is, elements of it (including the > userspace api) are still changing. Just to clarify, I'm not overly keen on taking them into IIO now. There is clearly a demand for these drivers and I tend to agree with Jean's earlier posting. It is better to get things people need out there and refactor as needed to share functionality as and when it makes sense in the future, particularly in cases like this where we are effectively already taking steps in that direction by grouping these existing drivers. > > ALS actually grew out of ACPI and as Zhang Rui was proposing a subsystem > that got a positive response on LKML, quick discussions amongst IIO devs > came to the conclusion that these particular drivers actually overlap hardly > at all in terms of functionality with the rest of our devices set so there > would be no loss in moving them out and considerable gain in giving them > a stable user interface etc. > > Jonathan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Manu Abraham on 3 Mar 2010 15:10 On Wed, Mar 3, 2010 at 11:45 PM, Jonathan Cameron <kernel(a)jic23.retrosnub.co.uk> wrote: > Hi Manu, > > ... >> Maybe it make sense to put all Generic sensors into one whole lot, >> where an application can >> >> - read the value from the driver (eg: 0 - 65535) >> >> - read from device static information (to identify how the application >> should treat the values read back.) >> >> � �- report what type of device it is (Light, Voltage, Acceleration >> and what not, simple enumeration will help, mayeb you can even have >> bitwise OR the types, so that you can have a driver with multiple >> capabilities) >> � �- the max value it can go >> � �- the min value it can go >> � �- the number of steps (gradient) that the driver can do. >> >> >> Maybe such a simplistic interface does help ? >> >> The application can simply read the static information from the driver >> and decide whether it should really handle that driver class. > > The more generic sensors are covered by IIO (in staging) > There is a lot more there as well as an equivalent of what you describe. > > The simplest equivalent to this is the hwmon subsystem (from which IIO > has borrowed a lot of interfaces, as has ALS). > > You have a sysfs file per channel, so taking als api as an example: > > illuminance0 - Value of illuminance in lux. > > If you want your other elements (though no driver provides them at the moment). > > illuminance0_max > illuminance0_min > illuminance0_values Just as i thought: A Class with values to define floor and ceiling and the gradient in which the driver can provide such an information in a generic way, rather than limiting to Ambient Light Sensor. to make it a bit more stylistic, you could provide static information, such as driver name also alongwith. But in any case, i guess you wouldn't need more than these device_name max_val min_val gradient/steps as static information and a simple value that could be read back. In (some remote thought) addition, some devices could "possibly" have levels that you could set the levels at which the device could set of a trigger, in which case, you might want to write to the driver to set the value at which you want to trigger of some event. (Don't really know whether this is applicable, but I have seen it in some temperature sensors, such a feature) > For slow devices this is all you need. > If you are interested in fast devices, take a look at the recently posted IIO ABI spec. > That uses sysfs files to describe the data that can be read from a character device > that is fed from a buffer (either hardware or software). It also supports fairly > advanced event handling (similar to input, but without cross device aggregation) > and triggering of data capture from various 'interrupt' sources. > > It is still somewhat unclear how exactly to marry the high speed data acquisition > requirements with other 'client' subsystems such as input. All suggestions on that > are welcome! I don't know how fast is "fast". "I think", (based on quick thought) all you might need is a trigger, whether the userspace application needs to be triggered to read the value from the driver, or do something exotic. ie the trigger is a binary only event, as I understand, right ? But in any case, you define the trigger mechanism in any way, similar to an interrupt The data to be read back could be just as generic, in any case, rather than defining a subsystem per device category.. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 3 Mar 2010 15:40
Hi, >> ... >>> Maybe it make sense to put all Generic sensors into one whole lot, >>> where an application can >>> >>> - read the value from the driver (eg: 0 - 65535) >>> >>> - read from device static information (to identify how the application >>> should treat the values read back.) >>> >>> - report what type of device it is (Light, Voltage, Acceleration >>> and what not, simple enumeration will help, mayeb you can even have >>> bitwise OR the types, so that you can have a driver with multiple >>> capabilities) >>> - the max value it can go >>> - the min value it can go >>> - the number of steps (gradient) that the driver can do. >>> >>> >>> Maybe such a simplistic interface does help ? >>> >>> The application can simply read the static information from the driver >>> and decide whether it should really handle that driver class. >> >> The more generic sensors are covered by IIO (in staging) >> There is a lot more there as well as an equivalent of what you describe. >> >> The simplest equivalent to this is the hwmon subsystem (from which IIO >> has borrowed a lot of interfaces, as has ALS). >> >> You have a sysfs file per channel, so taking als api as an example: >> >> illuminance0 - Value of illuminance in lux. >> >> If you want your other elements (though no driver provides them at the moment). >> >> illuminance0_max >> illuminance0_min >> illuminance0_values > > > Just as i thought: > > A Class with values to define floor and ceiling and the gradient in > which the driver can provide such an information in a generic way, > rather than limiting to Ambient Light Sensor. > > to make it a bit more stylistic, you could provide static information, > such as driver name also alongwith. But in any case, i guess you > wouldn't need more than these > > device_name > max_val > min_val > gradient/steps Except that we actually gain by using specific naming of the type of input. It's the same approach used very successfully in hwmon which actually covers quite a few different channel types. > > > as static information and a simple value that could be read back. > > > In (some remote thought) addition, some devices could "possibly" have > levels that you could set the levels at which the device could set of > a trigger, in which case, you might want to write to the driver to set > the value at which you want to trigger of some event. (Don't really > know whether this is applicable, but I have seen it in some > temperature sensors, such a feature) A lot of this is covered by the IIO ABI. If we don't currently have specific static parameters (and there are lots there!) then it is simply because we haven't yet encountered a device needing them. >> For slow devices this is all you need. >> If you are interested in fast devices, take a look at the recently posted IIO ABI spec. >> That uses sysfs files to describe the data that can be read from a character device >> that is fed from a buffer (either hardware or software). It also supports fairly >> advanced event handling (similar to input, but without cross device aggregation) >> and triggering of data capture from various 'interrupt' sources. >> >> It is still somewhat unclear how exactly to marry the high speed data acquisition >> requirements with other 'client' subsystems such as input. All suggestions on that >> are welcome! > > I don't know how fast is "fast". That one keeps coming up and I keep deliberately being vague on this as it is very dependent on what your host platform actually is. If you have a slow embedded device then we might be talking a few 10's of Hz, but if you have a high end machine, perhaps many Khz before the overheads matter enough. Thus if a developer has a requirement for the more complex features of IIO in an existing driver, they can be added without breaking the simpler (higher overhead) interfaces that are already in place. As an example of how this works, there are quite a few adc drivers and similar in the blackfin tree. These are currently mostly of the simplest variety, just giving direct access (as in ALS) to the individual channels via sysfs. Some of these are (I think) capable of relatively high speeds, and so at somepoint a developer may well add the character device accessed ring buffer support if there is demand. > > "I think", (based on quick thought) all you might need is a trigger, > whether the userspace application needs to be triggered to read the > value from the driver, or do something exotic. > > ie the trigger is a binary only event, as I understand, right ? But in > any case, you define the trigger mechanism in any way, similar to an > interrupt The event can be passed up to userspace. Typically we are using a buffer of some type (ideally filled directly by dma from the device). The trigger usually simply causes this to be started. For performance reasons it tends to occur entirely in kernel. There are then events passed to userspace to give information on how fall the buffer is etc. (so in essence as you describe but with an intermediate buffer). > > The data to be read back could be just as generic, in any case, rather > than defining a subsystem per device category.. I agree to a certain extent. The issue comes in the complexity that the subsystem gains as one starts to handle faster and more complex devices. The motivation for ALS was that (so far) all these devices are ludicrously simple and are very slow so we simply didn't need the weight of IIO or similar. Whilst we are keeping the minimum driver requirements as slim as possible, it still isn't as clean and simple as ALS is. A lot of what you are suggesting is very similar to elements of IIO and I would certainly appreciate any comments you have on that! Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |