[GIT PULL] Ambient Light Sensors subsystem

[GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dima Zavin]

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/
>

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dima Zavin]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Linus Walleij]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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!)

Re: [GIT PULL] Ambient Light Sensors subsystem

[Linus Walleij]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Linus Torvalds]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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
> 

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dmitry Torokhov]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Linus Torvalds]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dmitry Torokhov]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Manu Abraham]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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)

Re: [GIT PULL] Ambient Light Sensors subsystem

[Manu Abraham]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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
> 

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dima Zavin]

>> 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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Linus Torvalds]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Mike Chan]

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/
>

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dima Zavin]

> 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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Amit Kucheria]

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
-------------------------------------------------------------------------

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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!

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[J.I. Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dmitry Torokhov]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dmitry Torokhov]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dima Zavin]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dima Zavin]

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/

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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.

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jonathan Cameron]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Pavel Machek]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jon Smirl]

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

Re: [GIT PULL] Ambient Light Sensors subsystem

[Jan Engelhardt]

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.

Re: [GIT PULL] Ambient Light Sensors subsystem

[Dmitry Torokhov]

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