* [GIT PULL] Ambient Light Sensors subsystem @ 2010-03-01 19:41 Jonathan Cameron 2010-03-03 6:13 ` Dima Zavin 0 siblings, 1 reply; 43+ messages in thread From: Jonathan Cameron @ 2010-03-01 19:41 UTC (permalink / raw) To: torvalds; +Cc: LKML, Zhang Rui, Amit Kucheria, Jean Delvare Dear Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jic23/als.git for-linus to get the Ambient Light Sensors subsystem. A large part of the following consists of moving two drivers from elsewhere in the kernel to als now it is available. acpi-als will merge later through the acpi tree as it sits entirely within their directories. Both moves have been confirmed with the respective maintainers and all known users of the drivers. All changes as per linux-next branch where they have been for some weeks. Thanks, Jonathan Amit Kucheria (1): als: add unique device-ids to the als device class Jonathan Cameron (5): ALS: Add jic23 and als git tree to MAINTAINERS tsl2550: Move form i2c/chips to als and update interfaces. Remove i2c/chips in this commit to avoid build failure that results from separating that step out. als: tsl2550: Remove spurious check against a maximum lux value. Merge remote branch 'linus/master' into for-next isl29003: Move from misc to als now it is available with minimal changes Zhang Rui (1): introduce ALS sysfs class Documentation/ABI/testing/sysfs-class-als | 18 +++++ MAINTAINERS | 8 ++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/als/Kconfig | 34 +++++++++ drivers/als/Makefile | 9 ++ drivers/als/als_sys.c | 116 +++++++++++++++++++++++++++++ drivers/{misc => als}/isl29003.c | 46 ++++++++---- drivers/{i2c/chips => als}/tsl2550.c | 96 +++++++++++++++--------- drivers/i2c/Kconfig | 1 - drivers/i2c/Makefile | 2 +- drivers/i2c/chips/Kconfig | 19 ----- drivers/i2c/chips/Makefile | 18 ----- drivers/misc/Kconfig | 10 --- drivers/misc/Makefile | 1 - include/linux/als_sys.h | 35 +++++++++ 16 files changed, 314 insertions(+), 102 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-als create mode 100644 drivers/als/Kconfig create mode 100644 drivers/als/Makefile create mode 100644 drivers/als/als_sys.c rename drivers/{misc => als}/isl29003.c (90%) rename drivers/{i2c/chips => als}/tsl2550.c (82%) delete mode 100644 drivers/i2c/chips/Kconfig delete mode 100644 drivers/i2c/chips/Makefile create mode 100644 include/linux/als_sys.h ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-01 19:41 [GIT PULL] Ambient Light Sensors subsystem Jonathan Cameron @ 2010-03-03 6:13 ` Dima Zavin 2010-03-03 9:34 ` Jean Delvare ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Dima Zavin @ 2010-03-03 6:13 UTC (permalink / raw) To: Jonathan Cameron; +Cc: torvalds, LKML, Zhang Rui, Amit Kucheria, Jean Delvare Sorry if I'm jumping in a little late, but I'm concerned that adding ALS as a separate "framework" is going to set the wrong precedent. ALS is just one example of a class of sensors that are present on modern mobile devices (e.g. ALS, proximity, compass/magnetometer, accelerometer, etc.). Also, how does this deal with hybrid devices? Many ALS devices have a proximity sensor on the same package. You'll need to deal with enabling/disabling them separately, but likely share a power function at the board file level (at least for arch/arm systems). I definitely see the need for what you guys are trying to accomplish. For example, currently, we use an input device for reporting events, and a separate misc device node for control (enable/disable/configure). It's definitely suboptimal, but there currently isn't anything there would let us do things cleanly. What I would love to see is a more generic sensors framework that handles different kinds of sensor devices, and different data acquisition schemes (sampled vs. change notifications). I would love to work with you to design something more generic. Thanks. --Dima On Mon, Mar 1, 2010 at 11:41 AM, Jonathan Cameron <jic23@cam.ac.uk> wrote: > Dear Linus, > > Please pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/jic23/als.git for-linus > > to get the Ambient Light Sensors subsystem. > A large part of the following consists of moving two drivers from > elsewhere in the kernel to als now it is available. > > acpi-als will merge later through the acpi tree as it sits entirely > within their directories. Both moves have been confirmed with the > respective maintainers and all known users of the drivers. > > All changes as per linux-next branch where they have been for some weeks. > > Thanks, > > Jonathan > > Amit Kucheria (1): > als: add unique device-ids to the als device class > > Jonathan Cameron (5): > ALS: Add jic23 and als git tree to MAINTAINERS > tsl2550: Move form i2c/chips to als and update interfaces. Remove i2c/chips in this commit to avoid build failure that results from separating that step out. > als: tsl2550: Remove spurious check against a maximum lux value. > Merge remote branch 'linus/master' into for-next > isl29003: Move from misc to als now it is available with minimal changes > > Zhang Rui (1): > introduce ALS sysfs class > > > Documentation/ABI/testing/sysfs-class-als | 18 +++++ > MAINTAINERS | 8 ++ > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/als/Kconfig | 34 +++++++++ > drivers/als/Makefile | 9 ++ > drivers/als/als_sys.c | 116 +++++++++++++++++++++++++++++ > drivers/{misc => als}/isl29003.c | 46 ++++++++---- > drivers/{i2c/chips => als}/tsl2550.c | 96 +++++++++++++++--------- > drivers/i2c/Kconfig | 1 - > drivers/i2c/Makefile | 2 +- > drivers/i2c/chips/Kconfig | 19 ----- > drivers/i2c/chips/Makefile | 18 ----- > drivers/misc/Kconfig | 10 --- > drivers/misc/Makefile | 1 - > include/linux/als_sys.h | 35 +++++++++ > 16 files changed, 314 insertions(+), 102 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-class-als > create mode 100644 drivers/als/Kconfig > create mode 100644 drivers/als/Makefile > create mode 100644 drivers/als/als_sys.c > rename drivers/{misc => als}/isl29003.c (90%) > rename drivers/{i2c/chips => als}/tsl2550.c (82%) > delete mode 100644 drivers/i2c/chips/Kconfig > delete mode 100644 drivers/i2c/chips/Makefile > create mode 100644 include/linux/als_sys.h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 6:13 ` Dima Zavin @ 2010-03-03 9:34 ` Jean Delvare 2010-03-03 10:29 ` Dima Zavin 2010-03-03 10:30 ` Linus Walleij 2010-03-03 17:03 ` Linus Torvalds 2 siblings, 1 reply; 43+ messages in thread From: Jean Delvare @ 2010-03-03 9:34 UTC (permalink / raw) To: Dima Zavin; +Cc: Jonathan Cameron, torvalds, LKML, Zhang Rui, Amit Kucheria On Tue, 2 Mar 2010 22:13:21 -0800, Dima Zavin wrote: > Sorry if I'm jumping in a little late, but I'm concerned that adding > ALS as a separate "framework" is going to set the wrong precedent. ALS > is just one example of a class of sensors that are present on modern > mobile devices (e.g. ALS, proximity, compass/magnetometer, > accelerometer, etc.). Also, how does this deal with hybrid devices? Hybrid devices are common and how they can be handled is completely unrelated to the ALS subsystem. They are usually handled by the mfd subsystem, and then each separate function can go to the relevant subsystem. > Many ALS devices have a proximity sensor on the same package. You'll > need to deal with enabling/disabling them separately, but likely share > a power function at the board file level (at least for arch/arm > systems). > > I definitely see the need for what you guys are trying to accomplish. > For example, currently, we use an input device for reporting events, > and a separate misc device node for control > (enable/disable/configure). It's definitely suboptimal, but there > currently isn't anything there would let us do things cleanly. > > What I would love to see is a more generic sensors framework that > handles different kinds of sensor devices, and different data > acquisition schemes (sampled vs. change notifications). > > I would love to work with you to design something more generic. This can happen later, I see no reason to block the creation of the ALS subsystem. Having a common framework for all ambient light sensor drivers will already be a step forward compared to the current situation. If improvements are needed on top of this, this can happen later. -- Jean Delvare ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 9:34 ` Jean Delvare @ 2010-03-03 10:29 ` Dima Zavin 2010-03-03 11:02 ` Jean Delvare ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Dima Zavin @ 2010-03-03 10:29 UTC (permalink / raw) To: Jean Delvare; +Cc: Jonathan Cameron, torvalds, LKML, Zhang Rui, Amit Kucheria Jean, Thanks for the prompt reply. >> I definitely see the need for what you guys are trying to accomplish. >> For example, currently, we use an input device for reporting events, >> and a separate misc device node for control >> (enable/disable/configure). It's definitely suboptimal, but there >> currently isn't anything there would let us do things cleanly. >> >> What I would love to see is a more generic sensors framework that >> handles different kinds of sensor devices, and different data >> acquisition schemes (sampled vs. change notifications). >> >> I would love to work with you to design something more generic. > > This can happen later, I see no reason to block the creation of the ALS > subsystem. Having a common framework for all ambient light sensor > drivers will already be a step forward compared to the current Following the logic of putting the ALS subsystem under drivers/als, we would then put the proximity subsystem under drivers/proximity, and then an accelerometer subsystem under drivers/accelerometer, etc. Each with their own implementation of very similar set of interfaces. Is that what you envision? I just figured that instead of creating one-off interfaces for some subset of environmental sensors such as als, we can add a sensors subsystem of which als is just an instance. > situation. If improvements are needed on top of this, this can happen > later. I'm just concerned that instead of solving the actual problem, you are adding what is essentially a temporary solution. This will only make it harder to solve the real issue by introducing new interfaces which will need to be obsoleted unless they are designed with care. What you are proposing already needs improvements since there are plenty of drivers floating out there from many OEMs/vendors that are not ALSs, but essentially need a similar interface (e.g. proximity sensor). Furthermore, are there more patches coming for this subsystem? Based on the above tree, it just seems to be a class device (without any standard attributes) and a register/unregister function. It doesn't seem to actually be doing anything. Registering with the als subsystem at the moment buys the driver nothing. So, in its current state, I'm not sure I see what this new common framework actually provides us, and thus I'm not sure that it's actually a step forward. The drivers are still responsible to provide all their own non-standard, incompatible sysfs interfaces for exporting the sensor values. If there are other patches for the als subsys that are then used by the two drivers that got moved into drivers/als, I'd love to take a look at them. Thanks again. --Dima ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 10:29 ` Dima Zavin @ 2010-03-03 11:02 ` Jean Delvare 2010-03-03 11:10 ` Jonathan Cameron 2010-03-03 13:07 ` Linus Walleij 2 siblings, 0 replies; 43+ messages in thread From: Jean Delvare @ 2010-03-03 11:02 UTC (permalink / raw) To: Dima Zavin; +Cc: Jonathan Cameron, torvalds, LKML, Zhang Rui, Amit Kucheria On Wed, 3 Mar 2010 02:29:09 -0800, Dima Zavin wrote: > Jean, > > Thanks for the prompt reply. > > >> I definitely see the need for what you guys are trying to accomplish. > >> For example, currently, we use an input device for reporting events, > >> and a separate misc device node for control > >> (enable/disable/configure). It's definitely suboptimal, but there > >> currently isn't anything there would let us do things cleanly. > >> > >> What I would love to see is a more generic sensors framework that > >> handles different kinds of sensor devices, and different data > >> acquisition schemes (sampled vs. change notifications). > >> > >> I would love to work with you to design something more generic. > > > > This can happen later, I see no reason to block the creation of the ALS > > subsystem. Having a common framework for all ambient light sensor > > drivers will already be a step forward compared to the current > > Following the logic of putting the ALS subsystem under drivers/als, we > would then put the proximity subsystem under drivers/proximity, and > then an accelerometer subsystem under drivers/accelerometer, etc. Each > with their own implementation of very similar set of interfaces. Is > that what you envision? I just figured that instead of creating > one-off interfaces for some subset of environmental sensors such as > als, we can add a sensors subsystem of which als is just an instance. We need ALS support yesterday, so it can't build on top of a more generic framework that doesn't exist today. If you want to design such a generic framework, feel free, go ahead, and when it's ready, merge everything you want in it. But we will not wait for you. > > situation. If improvements are needed on top of this, this can happen > > later. > > I'm just concerned that instead of solving the actual problem, you are > adding what is essentially a temporary solution. This is certainly true. But you have to realize that _all_ the kernel code is a temporary solution. We change over 2000 lines of code every day on average. > This will only make > it harder to solve the real issue by introducing new interfaces which > will need to be obsoleted unless they are designed with care. What you > are proposing already needs improvements since there are plenty of > drivers floating out there from many OEMs/vendors that are not ALSs, > but essentially need a similar interface (e.g. proximity sensor). I don't care at all. I want ALS support, and I want it now. If you or others want something else, go work on it. And if several subsystems should share something, it can happen later. The point is, you won't know what they need to share exactly until they are all already there each with a decent set of drivers. So there is no real benefit in designing the big thing first, because you'd have to adjust it later anyway. > Furthermore, are there more patches coming for this subsystem? Based > on the above tree, it just seems to be a class device (without any > standard attributes) and a register/unregister function. It doesn't > seem to actually be doing anything. Registering with the als subsystem > at the moment buys the driver nothing. So, in its current state, I'm > not sure I see what this new common framework actually provides us, > and thus I'm not sure that it's actually a step forward. There are two major benefits: 1* The set of available ALS drivers become visible: just look into drivers/als and you get most of them, search for callers of the registration function and you get them all. This will avoid redundant code development, and will make adding new drivers easier. 2* All ALS devices will be reachable at the same location in sysfs. There is no way user-space can consume whatever the drivers provide without this common entry point. And we need user-space consumers, otherwise we just don't know what the real needs are. > The drivers > are still responsible to provide all their own non-standard, > incompatible sysfs interfaces for exporting the sensor values. Apparently you did not read the patches all that carefully. One of them creates a documentation file describing the standard sysfs files for ALS drivers. All ALS driver must comply with it, so they are neither non-standard nor incompatible. Note that the sysfs files are defined as a "testing ABI", because we are well aware that it might change in a near feature. We will move it to "stable ABI" when ready. > If > there are other patches for the als subsys that are then used by the > two drivers that got moved into drivers/als, I'd love to take a look > at them. Not that I am aware of. But again, it doesn't mean this won't happen later, if the need arises. How do you expect us to know what code should be common as long as we don't have a central place to store all drivers and a common interface to their devices? -- Jean Delvare ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 10:29 ` Dima Zavin 2010-03-03 11:02 ` Jean Delvare @ 2010-03-03 11:10 ` Jonathan Cameron 2010-03-03 13:07 ` Linus Walleij 2 siblings, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 11:10 UTC (permalink / raw) To: Dima Zavin; +Cc: Jean Delvare, torvalds, LKML, Zhang Rui, Amit Kucheria Hi All, > Jean, > > Thanks for the prompt reply. > >>> I definitely see the need for what you guys are trying to accomplish. >>> For example, currently, we use an input device for reporting events, >>> and a separate misc device node for control >>> (enable/disable/configure). It's definitely suboptimal, but there >>> currently isn't anything there would let us do things cleanly. >>> >>> What I would love to see is a more generic sensors framework that >>> handles different kinds of sensor devices, and different data >>> acquisition schemes (sampled vs. change notifications). >>> >>> I would love to work with you to design something more generic. >> >> This can happen later, I see no reason to block the creation of the ALS >> subsystem. Having a common framework for all ambient light sensor >> drivers will already be a step forward compared to the current > > Following the logic of putting the ALS subsystem under drivers/als, we > would then put the proximity subsystem under drivers/proximity, and > then an accelerometer subsystem under drivers/accelerometer, etc. > Each > with their own implementation of very similar set of interfaces. Is > that what you envision? I just figured that instead of creating > one-off interfaces for some subset of environmental sensors such as > als, we can add a sensors subsystem of which als is just an instance. > >> situation. If improvements are needed on top of this, this can happen >> later. > > I'm just concerned that instead of solving the actual problem, you are > adding what is essentially a temporary solution. This will only make > it harder to solve the real issue by introducing new interfaces which > will need to be obsoleted unless they are designed with care. What you > are proposing already needs improvements since there are plenty of > drivers floating out there from many OEMs/vendors that are not ALSs, > but essentially need a similar interface (e.g. proximity sensor). Actually, the reason we hived off ambient light sensors into their own subsystem was mainly that they typically have extremely simple interfaces and run at rather low rates. I'm personally extremely interested in how to support other forms of sensor. That is what my primary work at the moment on the IIO subsystem in staging is directed towards. Initially we did have light sensors within there (and there is one left at the moment). However, having said that, we concluded that IIO was massive overkill for this particular form of sensor. The typical read rate for these is a couple of Hz. IIO is intended to handle the much more sophisticated devices and right now its still a fair way from being ready for an attempt at merging with the mainline kernel. It is getting plenty of new drivers, but the core still needs some work. Basically the usual argument of do things the simple way if you can came to the fore here. There was little if any overlap with functionality or interface with other sensor types in IIO so it didn't really make sense to have them there. Note there are many other complexities in how to handle the other sensors you mention. If you have a chance to take a look at the current form of IIO (and perhaps follow the discussions on linux-iio@vger.kernel.org) we would appreciate any comments on how we are going about it. > > Furthermore, are there more patches coming for this subsystem? Based > on the above tree, it just seems to be a class device (without any > standard attributes) and a register/unregister function. It doesn't > seem to actually be doing anything. Registering with the als subsystem > at the moment buys the driver nothing. So, in its current state, I'm > not sure I see what this new common framework actually provides us, > and thus I'm not sure that it's actually a step forward. The drivers > are still responsible to provide all their own non-standard, > incompatible sysfs interfaces for exporting the sensor values. No the aren't. The sysfs interface specification is exactly the reason this subsystem exists. We could have taken the heavy weight route and done everything via callbacks etc to try and enforce naming, but instead went with the one that has been very successful for hwmon, that of a formal specification and driver review to ensure that all devices are compatible. In a sense, this subsystem is merely providing an alternative to hwmon for these devices seeing as they do not fall within the scope of hardware monitoring. > If > there are other patches for the als subsys that are then used by the > two drivers that got moved into drivers/als, I'd love to take a look > at them. The subsystem is deliberately kept simple, but there are patches for ACPI that add a further driver and a plan to move the tls2563 driver from IIO to als. Note that some of these may involve extending the sysfs specification as appropriate to provide new functionality. Thanks, Jonathan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 10:29 ` Dima Zavin 2010-03-03 11:02 ` Jean Delvare 2010-03-03 11:10 ` Jonathan Cameron @ 2010-03-03 13:07 ` Linus Walleij 2 siblings, 0 replies; 43+ messages in thread From: Linus Walleij @ 2010-03-03 13:07 UTC (permalink / raw) To: Dima Zavin Cc: Jean Delvare, Jonathan Cameron, torvalds, LKML, Zhang Rui, Amit Kucheria 2010/3/3 Dima Zavin <dmitriyz@google.com>: > there are plenty of > drivers floating out there from many OEMs/vendors Bad for them that they didn't work on integrating these to the mainline kernel and creating proper subsystems for them earlier. > that are not ALSs, > but essentially need a similar interface (e.g. proximity sensor). I have a proximity sensor driver pending here on top of GPIO, creating an input-on-top-of-GPIO driver framework. Too much to do but here is the userspace interface: diff --git a/include/linux/input.h b/include/linux/input.h index a5802c9..cbe8a98 100644 --- a/include/linux/input.h +++ b/include/linux/input.h @@ -644,6 +644,7 @@ struct input_absinfo { #define SW_RADIO SW_RFKILL_ALL /* deprecated */ #define SW_MICROPHONE_INSERT 0x04 /* set = inserted */ #define SW_DOCK 0x05 /* set = plugged into dock */ +#define SW_PROXIMITY 0x06 /* set = prox. sensor detects object */ #define SW_MAX 0x0f #define SW_CNT (SW_MAX+1) -- Comes in through /dev/input/event* something, simple. I have heard about proximity sensors returning more than a binary value, do you have one of those? Yours, Linus Walleij ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 6:13 ` Dima Zavin 2010-03-03 9:34 ` Jean Delvare @ 2010-03-03 10:30 ` Linus Walleij 2010-03-03 11:19 ` Jonathan Cameron 2010-03-03 17:03 ` Linus Torvalds 2 siblings, 1 reply; 43+ messages in thread From: Linus Walleij @ 2010-03-03 10:30 UTC (permalink / raw) To: Dima Zavin Cc: Jonathan Cameron, torvalds, LKML, Zhang Rui, Amit Kucheria, Jean Delvare 2010/3/3 Dima Zavin <dmitriyz@google.com>: > how does this deal with hybrid devices? As any hybrid device, a drivers/mfd spawns multiple sensors, als, accelerometer, voltage level, you name it. > I definitely see the need for what you guys are trying to accomplish. > For example, currently, we use an input device for reporting events, > and a separate misc device node for control > (enable/disable/configure). It's definitely suboptimal, but there > currently isn't anything there would let us do things cleanly. Are you registering your misc node from an mfd device then? > I would love to work with you to design something more generic. You can design forever, people need this now. (But we'd love to see the patches!) It's better to refactor the day something better is in place IMHO. Also I see no real clash. The userspace interface will likely be the same (input subsystem) so what's the problem? In the drivers/staging/iio in the -next tree you can find something more generic for industrial I/O including ADCs, triggers and some sensors. I pointed out sometime last month that this has the problem of exposing only userland interfaces and no kernel-internal interfaces for the actual devices (just sysfs entries), so the current ALS subsystem cannot fit into it, for example. Linus Walleij ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 10:30 ` Linus Walleij @ 2010-03-03 11:19 ` Jonathan Cameron 0 siblings, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 11:19 UTC (permalink / raw) To: Linus Walleij Cc: Dima Zavin, torvalds, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On 03/03/10 10:30, Linus Walleij wrote: > 2010/3/3 Dima Zavin <dmitriyz@google.com>: > >> how does this deal with hybrid devices? > > As any hybrid device, a drivers/mfd spawns multiple sensors, als, > accelerometer, voltage level, you name it. > >> I definitely see the need for what you guys are trying to accomplish. >> For example, currently, we use an input device for reporting events, >> and a separate misc device node for control >> (enable/disable/configure). It's definitely suboptimal, but there >> currently isn't anything there would let us do things cleanly. > > Are you registering your misc node from an mfd device then? > >> I would love to work with you to design something more generic. > > You can design forever, people need this now. (But we'd love > to see the patches!) It's better to refactor the day something > better is in place IMHO. Also I see no real clash. The userspace > interface will likely be the same (input subsystem) so what's the > problem? > > In the drivers/staging/iio in the -next tree you can find something > more generic for industrial I/O including ADCs, triggers and > some sensors. I pointed out sometime last month that this > has the problem of exposing only userland interfaces and no > kernel-internal interfaces for the actual devices (just sysfs entries), > so the current ALS subsystem cannot fit into it, for example. We welcome patches for that as well ;) (It is definitely on the todo list, but I'm afraid not terribly near the top from my point of view as I don't personally need it!) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 6:13 ` Dima Zavin 2010-03-03 9:34 ` Jean Delvare 2010-03-03 10:30 ` Linus Walleij @ 2010-03-03 17:03 ` Linus Torvalds 2010-03-03 17:51 ` Jonathan Cameron 2010-03-03 18:41 ` Dmitry Torokhov 2 siblings, 2 replies; 43+ messages in thread From: Linus Torvalds @ 2010-03-03 17:03 UTC (permalink / raw) To: Dima Zavin; +Cc: Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On Tue, 2 Mar 2010, Dima Zavin wrote: > > I definitely see the need for what you guys are trying to accomplish. > For example, currently, we use an input device for reporting events, > and a separate misc device node for control > (enable/disable/configure). It's definitely suboptimal, but there > currently isn't anything there would let us do things cleanly. I have to say, I personally don't see why something like an ambient light sensor _isn't_ just an input device. What's the difference between a physical "increase screen brightness" key, and a "ambient light sensor"? Absolutely none as far as I can tell. And for something like an X server, it sounds a lot more natural to just have another input device than to have yet abother event reporting interface. And quite frankly, the "explanations" I see in this thread for why it needs to be a subsystem of its own don't actually explain anything or make sense. They seem to boil down to "we just did it this way" without actually answering any of the issues brought up. Linus ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 17:03 ` Linus Torvalds @ 2010-03-03 17:51 ` Jonathan Cameron 2010-03-03 18:41 ` Dmitry Torokhov 1 sibling, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 17:51 UTC (permalink / raw) To: Linus Torvalds Cc: Dima Zavin, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, Dmitry Torokhov, linux-input Cc'ing Input list and maintainer. > > On Tue, 2 Mar 2010, Dima Zavin wrote: >> >> I definitely see the need for what you guys are trying to accomplish. >> For example, currently, we use an input device for reporting events, >> and a separate misc device node for control >> (enable/disable/configure). It's definitely suboptimal, but there >> currently isn't anything there would let us do things cleanly. > > I have to say, I personally don't see why something like an ambient light > sensor _isn't_ just an input device. > > What's the difference between a physical "increase screen brightness" key, > and a "ambient light sensor"? Absolutely none as far as I can tell. > > And for something like an X server, it sounds a lot more natural to just > have another input device than to have yet abother event reporting > interface. > > And quite frankly, the "explanations" I see in this thread for why it > needs to be a subsystem of its own don't actually explain anything or make > sense. They seem to boil down to "we just did it this way" without > actually answering any of the issues brought up. > > Linus > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 17:03 ` Linus Torvalds 2010-03-03 17:51 ` Jonathan Cameron @ 2010-03-03 18:41 ` Dmitry Torokhov 2010-03-03 18:52 ` Linus Torvalds 1 sibling, 1 reply; 43+ messages in thread From: Dmitry Torokhov @ 2010-03-03 18:41 UTC (permalink / raw) To: Linus Torvalds Cc: Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On Wed, Mar 03, 2010 at 09:03:16AM -0800, Linus Torvalds wrote: > > > On Tue, 2 Mar 2010, Dima Zavin wrote: > > > > I definitely see the need for what you guys are trying to accomplish. > > For example, currently, we use an input device for reporting events, > > and a separate misc device node for control > > (enable/disable/configure). It's definitely suboptimal, but there > > currently isn't anything there would let us do things cleanly. > > I have to say, I personally don't see why something like an ambient light > sensor _isn't_ just an input device. > > 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... > > And for something like an X server, it sounds a lot more natural to just > have another input device than to have yet abother event reporting > interface. > 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. -- Dmitry ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 18:41 ` Dmitry Torokhov @ 2010-03-03 18:52 ` Linus Torvalds 2010-03-03 19:07 ` Dmitry Torokhov 2010-03-03 19:20 ` Jonathan Cameron 0 siblings, 2 replies; 43+ messages in thread From: Linus Torvalds @ 2010-03-03 18:52 UTC (permalink / raw) To: Dmitry Torokhov Cc: Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare 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_. 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. > 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. 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. Linus ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 18:52 ` Linus Torvalds @ 2010-03-03 19:07 ` Dmitry Torokhov 2010-03-03 19:33 ` Jonathan Cameron ` (3 more replies) 2010-03-03 19:20 ` Jonathan Cameron 1 sibling, 4 replies; 43+ messages in thread From: Dmitry Torokhov @ 2010-03-03 19:07 UTC (permalink / raw) To: Linus Torvalds Cc: Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On Wed, Mar 03, 2010 at 10:52:43AM -0800, 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_. > > 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. -- Dmitry ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:07 ` Dmitry Torokhov @ 2010-03-03 19:33 ` Jonathan Cameron 2010-03-03 20:08 ` Jonathan Cameron ` (2 more replies) 2010-03-03 21:38 ` Dima Zavin ` (2 subsequent siblings) 3 siblings, 3 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 19:33 UTC (permalink / raw) To: Dmitry Torokhov Cc: Linus Torvalds, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare 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. 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:33 ` Jonathan Cameron @ 2010-03-03 20:08 ` Jonathan Cameron 2010-03-03 22:02 ` Jean Delvare 2010-03-05 7:38 ` Amit Kucheria 2 siblings, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 20:08 UTC (permalink / raw) To: Jonathan Cameron Cc: Dmitry Torokhov, Linus Torvalds, Dima Zavin, LKML, Zhang Rui, Amit Kucheria, Jean Delvare 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 > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:33 ` Jonathan Cameron 2010-03-03 20:08 ` Jonathan Cameron @ 2010-03-03 22:02 ` Jean Delvare 2010-03-03 23:08 ` Dima Zavin 2010-03-05 7:38 ` Amit Kucheria 2 siblings, 1 reply; 43+ messages in thread From: Jean Delvare @ 2010-03-03 22:02 UTC (permalink / raw) To: Jonathan Cameron Cc: Dmitry Torokhov, Linus Torvalds, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria Hi Jonathan, all, On Wed, 03 Mar 2010 19:33:51 +0000, Jonathan Cameron wrote: > 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. 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. 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. -- Jean Delvare ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 22:02 ` Jean Delvare @ 2010-03-03 23:08 ` Dima Zavin 2010-03-04 9:22 ` Jean Delvare 2010-03-07 20:49 ` Dmitry Torokhov 0 siblings, 2 replies; 43+ messages in thread From: Dima Zavin @ 2010-03-03 23:08 UTC (permalink / raw) To: Jean Delvare Cc: Jonathan Cameron, Dmitry Torokhov, Linus Torvalds, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria > 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 23:08 ` Dima Zavin @ 2010-03-04 9:22 ` Jean Delvare 2010-03-07 20:49 ` Dmitry Torokhov 1 sibling, 0 replies; 43+ messages in thread From: Jean Delvare @ 2010-03-04 9:22 UTC (permalink / raw) To: Dima Zavin Cc: Jonathan Cameron, Dmitry Torokhov, Linus Torvalds, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria On Wed, 3 Mar 2010 15:08:29 -0800, Dima Zavin wrote: > > 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/...). I don't disagree. > 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. The light sensor I have (TSL2550) is stupid and doesn't offer anything other than slow polling. Not thresholds, no interrupts, nothing. This is where the sysfs interface originates from. The very point of grouping light sensor drivers together is to get a better view of what the devices offer, and from there, of what interfaces make sense. > > 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. Sure I know. -- Jean Delvare ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 23:08 ` Dima Zavin 2010-03-04 9:22 ` Jean Delvare @ 2010-03-07 20:49 ` Dmitry Torokhov 2010-03-08 6:29 ` Dima Zavin 1 sibling, 1 reply; 43+ messages in thread From: Dmitry Torokhov @ 2010-03-07 20:49 UTC (permalink / raw) To: Dima Zavin Cc: Jean Delvare, Jonathan Cameron, Linus Torvalds, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria 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. -- Dmitry ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-07 20:49 ` Dmitry Torokhov @ 2010-03-08 6:29 ` Dima Zavin 0 siblings, 0 replies; 43+ messages in thread From: Dima Zavin @ 2010-03-08 6:29 UTC (permalink / raw) To: Dmitry Torokhov Cc: Jean Delvare, Jonathan Cameron, Linus Torvalds, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria On Sun, Mar 7, 2010 at 12:49 PM, Dmitry Torokhov <dmitry.torokhov@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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:33 ` Jonathan Cameron 2010-03-03 20:08 ` Jonathan Cameron 2010-03-03 22:02 ` Jean Delvare @ 2010-03-05 7:38 ` Amit Kucheria 2010-03-05 10:58 ` Jonathan Cameron 2 siblings, 1 reply; 43+ messages in thread From: Amit Kucheria @ 2010-03-05 7:38 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Dima Zavin, Jonathan Cameron, LKML On 10 Mar 03, Jonathan Cameron wrote: > > > > 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 I suspect you are pointing to the tsl2563 driver here. It's rework (iio->als) has been languishing in my tasklist for a couple of months now. I haven't had time for testing. I guess I'll wait some more to see where this discussion goes. -- ------------------------------------------------------------------------- Amit Kucheria, Kernel Developer, Verdurent ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-05 7:38 ` Amit Kucheria @ 2010-03-05 10:58 ` Jonathan Cameron 0 siblings, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-05 10:58 UTC (permalink / raw) To: Dima Zavin, Jonathan Cameron, LKML On 03/05/10 07:38, Amit Kucheria wrote: > On 10 Mar 03, Jonathan Cameron wrote: >>> >>> 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 > > I suspect you are pointing to the tsl2563 driver here. It's rework (iio->als) > has been languishing in my tasklist for a couple of months now. I haven't had > time for testing. > > I guess I'll wait some more to see where this discussion goes. > Very wise! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:07 ` Dmitry Torokhov 2010-03-03 19:33 ` Jonathan Cameron @ 2010-03-03 21:38 ` Dima Zavin 2010-03-03 21:51 ` Linus Torvalds 2010-03-03 21:56 ` Mike Chan 2010-03-10 20:46 ` Pavel Machek 2010-03-22 0:13 ` Jan Engelhardt 3 siblings, 2 replies; 43+ messages in thread From: Dima Zavin @ 2010-03-03 21:38 UTC (permalink / raw) To: Dmitry Torokhov Cc: Linus Torvalds, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare >> 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 21:38 ` Dima Zavin @ 2010-03-03 21:51 ` Linus Torvalds 2010-03-04 11:19 ` Jonathan Cameron 2010-03-07 20:42 ` Dmitry Torokhov 2010-03-03 21:56 ` Mike Chan 1 sibling, 2 replies; 43+ messages in thread From: Linus Torvalds @ 2010-03-03 21:51 UTC (permalink / raw) To: Dima Zavin Cc: Dmitry Torokhov, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 21:51 ` Linus Torvalds @ 2010-03-04 11:19 ` Jonathan Cameron 2010-03-07 12:34 ` Jean Delvare 2010-03-08 9:58 ` Dima Zavin 2010-03-07 20:42 ` Dmitry Torokhov 1 sibling, 2 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-04 11:19 UTC (permalink / raw) To: Linus Torvalds Cc: Dima Zavin, Dmitry Torokhov, LKML, Zhang Rui, Amit Kucheria, Jean Delvare Hi Linus, > 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. True enough if you want relatively low rate data either polled or from an internally clocked accelerometer. So yes, if your application is input and you are using an accelerometer for such a job, then it makes sense to be in input. That is exactly why Dmitry has taken some accelerometers in there. It isn't true if you are dealing with higher spec devices. There are devices out there that will throw data at many KHz with lot of different channels, these are totally different from what input was designed for. The deepest discussions of these points that I know of are those that IIO grew out of: http://lkml.org/lkml/2008/5/20/135 onwards. These in conjunction with ADC's etc were why we got into writing IIO in the first place + the entirely reasonable point that they fell out of the scope of input and hwmon. 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. 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? 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. 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.) 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. 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. Thanks, Jonathan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-04 11:19 ` Jonathan Cameron @ 2010-03-07 12:34 ` Jean Delvare 2010-03-07 12:57 ` J.I. Cameron 2010-03-08 9:58 ` Dima Zavin 1 sibling, 1 reply; 43+ messages in thread From: Jean Delvare @ 2010-03-07 12:34 UTC (permalink / raw) To: Jonathan Cameron Cc: Linus Torvalds, Dima Zavin, Dmitry Torokhov, LKML, Zhang Rui, Amit Kucheria Hi Jonathan, 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. > > 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. > 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. > 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. -- Jean Delvare ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-07 12:34 ` Jean Delvare @ 2010-03-07 12:57 ` J.I. Cameron 0 siblings, 0 replies; 43+ messages in thread From: J.I. Cameron @ 2010-03-07 12:57 UTC (permalink / raw) To: Jean Delvare Cc: Linus Torvalds, Dima Zavin, Dmitry Torokhov, LKML, Zhang Rui, Amit Kucheria 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-04 11:19 ` Jonathan Cameron 2010-03-07 12:34 ` Jean Delvare @ 2010-03-08 9:58 ` Dima Zavin 2010-03-08 10:24 ` Jonathan Cameron 1 sibling, 1 reply; 43+ messages in thread From: Dima Zavin @ 2010-03-08 9:58 UTC (permalink / raw) To: Jonathan Cameron Cc: Linus Torvalds, Dmitry Torokhov, LKML, Zhang Rui, Amit Kucheria, Jean Delvare 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-08 9:58 ` Dima Zavin @ 2010-03-08 10:24 ` Jonathan Cameron 0 siblings, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-08 10:24 UTC (permalink / raw) To: Dima Zavin Cc: Linus Torvalds, Dmitry Torokhov, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, Andrew Morton Hi Dima, >> 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? That would work for me though it kind of breaks what I think misc is for. It's Andrew Morton's domain though... (cc'd) > >> 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. Adding polling (here anyway) isn't actually a part of the subsystem. Just write a driver which has some internal caching fed by relevant interrupt. Then call sysfs_notify with parameters relevant to the attribute in question. So for an illuminance0 reading say: sysfs_notify(&device->dev.kobj, NULL, "illuminance0"); This covers any cases of the device notifying of new values. You can always add 'alarm' type attributes and poll on them. The only kicker here, is that userspace that polls on a device not supporting polling will never get a response. If you need 'alarm' type parameters feel free to add them as long as they are suitable documented. > >> 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. Excellent, I'd suggest waiting till the current round of API changes are in there. Right now you'd just end up getting it working and I'd go break the interface. Hopefully, once that's in place those elements of the userspace side of things will be more or less stable. Jonathan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 21:51 ` Linus Torvalds 2010-03-04 11:19 ` Jonathan Cameron @ 2010-03-07 20:42 ` Dmitry Torokhov 2010-03-08 10:00 ` Jonathan Cameron 2010-03-18 14:34 ` Jon Smirl 1 sibling, 2 replies; 43+ messages in thread From: Dmitry Torokhov @ 2010-03-07 20:42 UTC (permalink / raw) To: Linus Torvalds Cc: Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-07 20:42 ` Dmitry Torokhov @ 2010-03-08 10:00 ` Jonathan Cameron 2010-03-18 14:34 ` Jon Smirl 1 sibling, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-08 10:00 UTC (permalink / raw) To: Dmitry Torokhov Cc: Linus Torvalds, Dima Zavin, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, linux-iio 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-07 20:42 ` Dmitry Torokhov 2010-03-08 10:00 ` Jonathan Cameron @ 2010-03-18 14:34 ` Jon Smirl 1 sibling, 0 replies; 43+ messages in thread From: Jon Smirl @ 2010-03-18 14:34 UTC (permalink / raw) To: Dmitry Torokhov Cc: Linus Torvalds, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On Sun, Mar 7, 2010 at 4:42 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 pretty 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. > Sorry for the late reply, but this is a recurring theme. Remote controls (IR and radio) have the same problem and this was the core of my objection to their drivers being merged. Input devices need to communicate their human oriented events to user space using the input subsystem period. If you don't do this things like the xserver/apps have to implement custom drivers for every new user event interface that is dreamed up and that destroys backwards compatibility. Drivers can always be split into two modules. A core module could provide a sysfs or kernel internal interface. An add-on module can optionally redirect events from the core module into the input subsystem. I'm also not a fan of having a custom interface on the sensor/input devices that reports device specific events to user space. Then those events are massaged by a tiny user space app and reinjected into the input subsystem. That does work but it leads to the kernel requiring external apps in order to function. I believe converting device specific events to a common device protocol is the work of the device driver. -- Jon Smirl jonsmirl@gmail.com ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 21:38 ` Dima Zavin 2010-03-03 21:51 ` Linus Torvalds @ 2010-03-03 21:56 ` Mike Chan 2010-03-03 22:05 ` Jean Delvare 1 sibling, 1 reply; 43+ messages in thread From: Mike Chan @ 2010-03-03 21:56 UTC (permalink / raw) To: Dima Zavin Cc: Dmitry Torokhov, Linus Torvalds, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On Wed, Mar 3, 2010 at 1:38 PM, Dima Zavin <dmitriyz@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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 21:56 ` Mike Chan @ 2010-03-03 22:05 ` Jean Delvare 0 siblings, 0 replies; 43+ messages in thread From: Jean Delvare @ 2010-03-03 22:05 UTC (permalink / raw) To: Mike Chan Cc: Dima Zavin, Dmitry Torokhov, Linus Torvalds, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:07 ` Dmitry Torokhov 2010-03-03 19:33 ` Jonathan Cameron 2010-03-03 21:38 ` Dima Zavin @ 2010-03-10 20:46 ` Pavel Machek 2010-03-22 0:13 ` Jan Engelhardt 3 siblings, 0 replies; 43+ messages in thread From: Pavel Machek @ 2010-03-10 20:46 UTC (permalink / raw) To: Dmitry Torokhov Cc: Linus Torvalds, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare Hi! > > > 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. Well, I seen people covering light sensor by hand to change screen brightness :-). > 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. Yep. > > 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. At least on android, accelerometers are primarily human interaction device -- for screen rotation. And biggest use of magnetometer+accelerometer on android is actually looking around in streetview... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:07 ` Dmitry Torokhov ` (2 preceding siblings ...) 2010-03-10 20:46 ` Pavel Machek @ 2010-03-22 0:13 ` Jan Engelhardt 2010-03-22 4:27 ` Dmitry Torokhov 3 siblings, 1 reply; 43+ messages in thread From: Jan Engelhardt @ 2010-03-22 0:13 UTC (permalink / raw) To: Dmitry Torokhov Cc: Linus Torvalds, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On Wednesday 2010-03-03 20:07, Dmitry Torokhov wrote: >On Wed, Mar 03, 2010 at 10:52:43AM -0800, Linus Torvalds wrote: >> On Wed, 3 Mar 2010, Dmitry Torokhov wrote: >>> >>> 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. Power failure is also usually not caused by an action of a human, and yet, (some brands/models of) uninterruptible power supplies present these events through USBHID/input. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-22 0:13 ` Jan Engelhardt @ 2010-03-22 4:27 ` Dmitry Torokhov 0 siblings, 0 replies; 43+ messages in thread From: Dmitry Torokhov @ 2010-03-22 4:27 UTC (permalink / raw) To: Jan Engelhardt Cc: Linus Torvalds, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare On Mon, Mar 22, 2010 at 01:13:29AM +0100, Jan Engelhardt wrote: > > On Wednesday 2010-03-03 20:07, Dmitry Torokhov wrote: > >On Wed, Mar 03, 2010 at 10:52:43AM -0800, Linus Torvalds wrote: > >> On Wed, 3 Mar 2010, Dmitry Torokhov wrote: > >>> > >>> 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. > > Power failure is also usually not caused by an action of a human, and > yet, (some brands/models of) uninterruptible power supplies present > these events through USBHID/input. USBHID - yes, input - no. Let's not confuse transport with subsystem. As we witnessed in another thread some vendors used HID for industrial sensors (temperature IIRC) and write applications using joystick interface (/dev/input/jsX). It does not mean this is the best approach. Same goes for laptop vendors using 'free' scancodes to deliver additional events via i8042. The fact that they "extend" KBC data stream still does not make them input events. -- Dmitry ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 18:52 ` Linus Torvalds 2010-03-03 19:07 ` Dmitry Torokhov @ 2010-03-03 19:20 ` Jonathan Cameron 2010-03-03 19:29 ` Manu Abraham 1 sibling, 1 reply; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 19:20 UTC (permalink / raw) To: Linus Torvalds Cc: Dmitry Torokhov, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, Greg KH, Andrew Morton 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!) > > 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. > >> 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. > > 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. In principle I agree, but the current situation was also causing problems. Within the mainline and other incoming trees there were 4 drivers for light sensors. Each one was in a different 'subsystem' (one was in misc) and each was exporting data to userspace via different interface causing all sorts of fun for userspace developers. The core of the subsystem is really just a small amount of documentation and a class to give a common location (which we could drop; it is merely a convenience for userspace). Perhaps we just provide the documentation and move the lot into misc? Jonathan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:20 ` Jonathan Cameron @ 2010-03-03 19:29 ` Manu Abraham 2010-03-03 19:45 ` Jonathan Cameron 0 siblings, 1 reply; 43+ messages in thread From: Manu Abraham @ 2010-03-03 19:29 UTC (permalink / raw) To: Jonathan Cameron Cc: Linus Torvalds, Dmitry Torokhov, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, Greg KH, Andrew Morton On Wed, Mar 3, 2010 at 11:20 PM, Jonathan Cameron <kernel@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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:29 ` Manu Abraham @ 2010-03-03 19:45 ` Jonathan Cameron 2010-03-03 20:08 ` Manu Abraham 0 siblings, 1 reply; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 19:45 UTC (permalink / raw) To: Manu Abraham Cc: Linus Torvalds, Dmitry Torokhov, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, Greg KH, Andrew Morton, linux-iio 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) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 19:45 ` Jonathan Cameron @ 2010-03-03 20:08 ` Manu Abraham 2010-03-03 20:37 ` Jonathan Cameron 0 siblings, 1 reply; 43+ messages in thread From: Manu Abraham @ 2010-03-03 20:08 UTC (permalink / raw) To: Jonathan Cameron Cc: Linus Torvalds, Dmitry Torokhov, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, Greg KH, Andrew Morton, linux-iio On Wed, Mar 3, 2010 at 11:45 PM, Jonathan Cameron <kernel@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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [GIT PULL] Ambient Light Sensors subsystem 2010-03-03 20:08 ` Manu Abraham @ 2010-03-03 20:37 ` Jonathan Cameron 0 siblings, 0 replies; 43+ messages in thread From: Jonathan Cameron @ 2010-03-03 20:37 UTC (permalink / raw) To: Manu Abraham Cc: Linus Torvalds, Dmitry Torokhov, Dima Zavin, Jonathan Cameron, LKML, Zhang Rui, Amit Kucheria, Jean Delvare, Greg KH, Andrew Morton, linux-iio 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2010-03-22 4:27 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-01 19:41 [GIT PULL] Ambient Light Sensors subsystem Jonathan Cameron 2010-03-03 6:13 ` Dima Zavin 2010-03-03 9:34 ` Jean Delvare 2010-03-03 10:29 ` Dima Zavin 2010-03-03 11:02 ` Jean Delvare 2010-03-03 11:10 ` Jonathan Cameron 2010-03-03 13:07 ` Linus Walleij 2010-03-03 10:30 ` Linus Walleij 2010-03-03 11:19 ` Jonathan Cameron 2010-03-03 17:03 ` Linus Torvalds 2010-03-03 17:51 ` Jonathan Cameron 2010-03-03 18:41 ` Dmitry Torokhov 2010-03-03 18:52 ` Linus Torvalds 2010-03-03 19:07 ` Dmitry Torokhov 2010-03-03 19:33 ` Jonathan Cameron 2010-03-03 20:08 ` Jonathan Cameron 2010-03-03 22:02 ` Jean Delvare 2010-03-03 23:08 ` Dima Zavin 2010-03-04 9:22 ` Jean Delvare 2010-03-07 20:49 ` Dmitry Torokhov 2010-03-08 6:29 ` Dima Zavin 2010-03-05 7:38 ` Amit Kucheria 2010-03-05 10:58 ` Jonathan Cameron 2010-03-03 21:38 ` Dima Zavin 2010-03-03 21:51 ` Linus Torvalds 2010-03-04 11:19 ` Jonathan Cameron 2010-03-07 12:34 ` Jean Delvare 2010-03-07 12:57 ` J.I. Cameron 2010-03-08 9:58 ` Dima Zavin 2010-03-08 10:24 ` Jonathan Cameron 2010-03-07 20:42 ` Dmitry Torokhov 2010-03-08 10:00 ` Jonathan Cameron 2010-03-18 14:34 ` Jon Smirl 2010-03-03 21:56 ` Mike Chan 2010-03-03 22:05 ` Jean Delvare 2010-03-10 20:46 ` Pavel Machek 2010-03-22 0:13 ` Jan Engelhardt 2010-03-22 4:27 ` Dmitry Torokhov 2010-03-03 19:20 ` Jonathan Cameron 2010-03-03 19:29 ` Manu Abraham 2010-03-03 19:45 ` Jonathan Cameron 2010-03-03 20:08 ` Manu Abraham 2010-03-03 20:37 ` Jonathan Cameron
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.