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: J.I. Cameron on 7 Mar 2010 08:00 Hi Jean, >On Thu, 04 Mar 2010 11:19:03 +0000, Jonathan Cameron wrote: >> Anyhow, the way this conversation is going there appear to be several >> options and we need to make a decision before anyone wastes much more >> time. >> >> 1) ALS as is. It's extremely light weight and can always be merged with >> a better >> option at a later date. If people prefer we can always stick it in a >> subdirectory >> called sensors or similar. > >This would be fine with me. > >> Perhaps move hwmon in there as well. > >I doubt it, especially if the interface to other sensors changes to >treat them as input devices. At any rate, the hwmon interface is >standardized since kernel ~2.6.5 and widely used, we're not going to >change it now. So the benefit of sitting with other sensor type drivers >is thin, probably thinner than the cost of the move. Agreed. Though all I had in mind was some organization in Kconfig, not actually changing hwmon in any real way. >> >> 2) Input. I agree with Dmitry here. These devices are not within the >> scope as it >> currently exists. It can be done and there have been numerous >> discussions about >> doing so in the past (with various sensor types) and each time it has >> been decided >> that it isn't the right option. Perhaps opinion on this has changed? > >I can't comment on this. It would seem reasonable to let the users >(user-space applications) describe their needs and build the interface >on top of that rather than the other away around. For this purpose, >LKML doesn't seem like the right place to discuss. And I won't be the >one driving the discussion anyway, I'm just a tourist here. A fair point. Can anyone suggest a suitable approach to getting opinions here? My use for these probably isn't terribly common (as it has nothing to do with screens or input in the conventional sense given it is on a small wireless mote.) > >> 3) Leave as is. Perhaps move all such drivers to misc and introduce >> some documentation >> in an attempt to standardize the interface they export. To all >> intents and purposes >> this is the core of als anyway. What we loose is a consistent >> location and device >> naming for userspace usage. > >No. I don't think it makes any sense. As you underline it yourself, it >has all the issues ALS has, without the main benefit. > >> 4) Move them into IIO. They are within the scope we are covering. I >> agreed >> with the ALS subsystem when it was proposed as it was clean small and >> ready now >> not because I particularly wanted them out of IIO (there is still one >> there.) > >Fine with me as well. > >> Two comments on option 4: a) If we do it now rather than taking one of >> the other options and moving them later, >> then we are moving two perfectly good drivers out of the main tree >> into staging. >> Doesn't matter to me, may to others. > >Doesn't matter to me either, FWIW. Cool. If it is still homeless post merge window I'll pull the tsl2550 into IIO. The isl20009 driver was originally going to go in there before als came about, so shouldn't be any problem with that one. For acpi it's up to Zhang Rui. If we can keep all the naming in new drivers as per ALS it will simplify an eventual grouping of these device. > >> b) If anyone comes back later and says, 'IIO is a massively overweight >> subsystem for >> such simple drivers', then I reserve the right to get rather >> somewhat annoyed. >> We have always kept the core driver requirement (that needed for >> these drivers) >> as slim as possible. Of course suggestions on how to make it slimmer >> without >> breaking other functionality are welcome. >> >> Please can anyone who feels like suggesting another general sensors >> subsystem at least taking a look at IIO (and keeping in mind we are in >> the middle of a big API cleanup). If you disagree with how we have done >> things, then contribute to the discussions and they may change. > >4 days left before I take care of driver tsl2550 myself. Short of Linus changing his mind about ALS as is, I don't think any of the other options are going to happen in time to merge this time round. (what with testing any of the other options etc). As you can do the tsl2550 as a simple move, I suggest you go ahead, and we'll lift it from misc at a later date. Thanks, 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: Dmitry Torokhov on 7 Mar 2010 15:50 On Wed, Mar 03, 2010 at 01:51:07PM -0800, Linus Torvalds wrote: > > > On Wed, 3 Mar 2010, Dima Zavin wrote: > > > > Actually, accelerometers fit into that model fine. They have some > > variable number of absolute axes (3, 6, etc.). > > In fact, they obviouslya also do end up being used exactly like joysticks > in real life, and joysticks are commonly starting to have accelerometers > in them (ie any modern game console controller). > > So treating an accelerometer like a joystick - regardless of whether it > happens to be internal to the device or happens to be external in a > separate controller - is not all that far-fetched anyway. > But the point is that not every accelerometer is a joystick. We have hdaps and friends that have accelerometers inside but that is not their main purpose (they do export a secondary joystick-like interface and that is fine), and I am pretty sure that there are other users of accelerometers in various systems. I am retty sure that once we settle on the proper interface for such sensors we should be able to write a bridge to input layer so they can be easily used as [human] input devices in cases whether it is desired. -- Dmitry -- 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: Dima Zavin on 8 Mar 2010 01:30 On Sun, Mar 7, 2010 at 12:49 PM, Dmitry Torokhov <dmitry.torokhov(a)gmail.com> wrote: > On Wed, Mar 03, 2010 at 03:08:29PM -0800, Dima Zavin wrote: >> >> As it came up earlier in the thread, adding an ABS_AMBIENT_LIGHT_LEVEL >> or equivalent is much simpler and provides a clean, concise, and >> useful interface to userspace. >> >> Note that for many applications, you actually get configurable >> threshold levels, and the hardware triggers an interrupt when the >> light level crosses those thresholds. This makes using an input device >> very useful, and that is in fact how we use ALS devices today. I have >> several pieces of hardware that do this, and I don't see how this new >> als subsystem helps me handle that problem. With the suggested API, >> I'll have to poll the sysfs files manually to see if they've changed >> (which is suboptimal), or still add a non-standard input device to do >> what I want. >> > > OK, so from what you are saying it looks you just like the _interface_, > or transport, that input subsystem provides, not the fact that you > considering the device to be a HID-type device. If this is the case then > this indicates that we need to take another look at the proposed > interface and make sure that it allows proper poll() support. Yes, you are right. Though, the filtering that the input subsystem provides can also be useful. --Dima -- 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: Dima Zavin on 8 Mar 2010 05:00 Jonathan, > Anyhow, the way this conversation is going there appear to be several options > and we need to make a decision before anyone wastes much more time. > > 1) ALS as is. It's extremely light weight and can always be merged with a better > �option at a later date. If people prefer we can always stick it in a subdirectory > �called sensors or similar. �Perhaps move hwmon in there as well. If your plan is to integrate with iio when it's ready, then there will be a drivers/iio, so creating top-level als or even drivers/sensors at this point wouldn't really make sense. Perhaps putting them into drivers/misc/als is more appropriate? > 2) Input. �I agree with Dmitry here. �These devices are not within the scope as it > �currently exists. �It can be done and there have been numerous discussions about > �doing so in the past (with various sensor types) and each time it has been decided > �that it isn't the right option. �Perhaps opinion on this has changed? As Dmitry correctly distilled from my ramblings, what we really need is support for poll() on sensor devices. If you guys add a poll interface to als, then we can probably get by until iio gets merged. Otherwise, we will still need to hack up an input device exporting ABS_MISC. If we had ABS_AMBIENT_LIGHT_LEVEL, then it'd be slightly less hacky. > Please can anyone who feels like suggesting another general sensors subsystem > at least taking a look at IIO (and keeping in mind we are in the middle of a big > API cleanup). �If you disagree with how we have done things, then contribute > to the discussions and they may change. I looked into IIO (sorry for the delay), and it does look promising. I'll try to participate in future discussions, and will provide some more feedback in a more appropriate forum as it is likely out of scope here. When I get a chance, I'll try moving one of our drivers to iio and see how it goes. Thanks. --Dima -- 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 8 Mar 2010 05:00
On 03/07/10 20:42, Dmitry Torokhov wrote: > On Wed, Mar 03, 2010 at 01:51:07PM -0800, Linus Torvalds wrote: >> >> >> On Wed, 3 Mar 2010, Dima Zavin wrote: >>> >>> Actually, accelerometers fit into that model fine. They have some >>> variable number of absolute axes (3, 6, etc.). >> >> In fact, they obviouslya also do end up being used exactly like joysticks >> in real life, and joysticks are commonly starting to have accelerometers >> in them (ie any modern game console controller). >> >> So treating an accelerometer like a joystick - regardless of whether it >> happens to be internal to the device or happens to be external in a >> separate controller - is not all that far-fetched anyway. >> > > But the point is that not every accelerometer is a joystick. We have > hdaps and friends that have accelerometers inside but that is not their > main purpose (they do export a secondary joystick-like interface and > that is fine), and I am pretty sure that there are other users of > accelerometers in various systems. > > I am retty sure that once we settle on the proper interface for such > sensors we should be able to write a bridge to input layer so they can > be easily used as [human] input devices in cases whether it is desired. > I agree, this should certainly be possible. In IIO's case (as that is what I am familiar with), polled input devices would effectively supply a software trigger that would in turn lead to the device pushing data into an IIO buffer. In this case the buffer would just be a direct hook into input. At the moment, the only complex case I can think of is passing events (in IIO terminology, these are things like crossing of thresholds) as they are not pushed out via an interface that currently has any hooks for in kernel use. It should be easy enough to add such hooks though. Devices where the data flow is interrupt driven effectively supply their own trigger anyway and are even simpler to handle. The one remaining thing I'm trying to work out is whether to support switching the buffer type at runtime (rather fiddly) or just make it a compile time option (probably what will happen first in any case). We'll also need some userspace magic to set up the linkage but that should be fairly straight forward. 1) Request an input-iio-bridge (this will probably involve also identifying what sort of data is coming in so as to add the relevant 'header' type information to the input events, 2) Link up the poll route (done by name) 3) link up the buffer route (also done by name) 4) Attach the currently non existent 'event' hooks between the two event systems (again this will need to deal with translation and attaching the 'header' information that input expects.) So not too bad. I'll hack together a proof of concept together at some point. Jonathan I've cc'd linux-iio to see if anyone else has thoughts on how we would do it. -- 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/ |