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: Dima Zavin on 3 Mar 2010 16:40 >> 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. Agreed, a key is not the best approach. We currently have been hacking around it by using ABS_MISC, which I know is wrong. >> 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. Actually, accelerometers fit into that model fine. They have some variable number of absolute axes (3, 6, etc.). --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: Linus Torvalds on 3 Mar 2010 17:00 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. Linus -- 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: Mike Chan on 3 Mar 2010 17:00 On Wed, Mar 3, 2010 at 1:38 PM, Dima Zavin <dmitriyz(a)google.com> wrote: >>> 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. > > Agreed, a key is not the best approach. We currently have been hacking > around it by using ABS_MISC, which I know is wrong. > >>> 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. > > Actually, accelerometers fit into that model fine. They have some > variable number of absolute axes (3, 6, etc.). > Slightly off topic here, but with the introduction of an als subsystem, wouldn't you want to unify how the kernel export lux values? Currently it seems the driver can export whatever they want to export, lux or lumen, whatever they want. -- Mike > --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/ > -- 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: Jean Delvare on 3 Mar 2010 17:10 On Wed, 3 Mar 2010 13:56:45 -0800, Mike Chan wrote: > Slightly off topic here, but with the introduction of an als > subsystem, wouldn't you want to unify how the kernel export lux > values? Currently it seems the driver can export whatever they want to > export, lux or lumen, whatever they want. Would you mind reading the patches that are being discussed here before you comment? Thank you very much, -- Jean Delvare -- 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 3 Mar 2010 18:10
> Honestly, I don't care. The light sensor drivers can live wherever you > want and use whatever interface you want, I don't give a damn. What I > really want is that: > 1* All light sensor drivers live at the same place in the kernel tree, > � so that people looking for them know where to look. > 2* drivers/i2c/chips dies. Meaning that, if the tsl2550 driver has not > � moved away from drivers/i2c/chips by rc1, I'll move it myself, manu > � militari, to drivers/misc. Please do kill i2c/chips. I've tried to follow suite with your campaign and have been pushing vendors on my end to not dump their drivers in there. However, wanting to clean up the directory structure is not a good reason to create a new interface to userspace. And furthermore, the proposed directory structure changes are not really that scalable imho (e.g. drivers/sensors/als would make a lot more sense to me than to pollute the top level drivers/...). 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. > I am a little sad to see two discussions about the ALS subsystem right > in the middle of the merge window, one about what the interface should > be and one about what the subsystem should include, while discussions > about these two points have been ongoing publicly for 5 months now. I > really want things (whatever they are) happen now and not in another 5 > months. I'm sorry I missed the previous discussion, so please accept my apologies. I was very busy with work at that time, I'm sure you know how that goes. --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/ |