[lkml]   [2010]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] Ambient Light Sensors subsystem
    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.


    I've cc'd linux-iio to see if anyone else has thoughts on how we would do it.

     \ /
      Last update: 2010-03-08 11:01    [W:0.036 / U:1.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site