[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] Ambient Light Sensors subsystem
    On Sun, Mar 7, 2010 at 4:42 PM, 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 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

    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

    Jon Smirl

     \ /
      Last update: 2010-03-18 15:37    [W:0.035 / U:19.572 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site