[lkml]   [2009]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    Ray Lee wrote:
    > On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls <> wrote:
    >>> If decoding can *only* be sanely handled in user-space, that's one
    >>> thing. If it can be handled in kernel, then that would be better.
    >> Why does the address space in which decoding is performed make the
    >> decoding process better or worse? The in kernel infrastructre and
    >> restrictions add constraints to a decoding implementation. Userspace is
    >> much more flexible.
    > In which case I look forward to seeing your patches to move
    > drivers/hid/ to userspace. Please cc: me so I can enjoy the ensuing
    > festival.

    Umm, this thread is really about several independent issues

    - Event delivery
    There's an existing input system that works, there's no need to
    reinvent the wheel; all remote events (usually key presses, but
    there are also wheels/touchpads/joysticks/etc, which don't necessarily
    map to buttons) should eventually arrive through it. Whether there's a
    userspace component somewhere on the receiver->/dev/input path doesn't
    change anything.

    - Acquisition
    If it isn't interrupt-driven it should to be in userspace. ADC falls
    into this category, but also various bitbanging approaches and probably
    also many serial port (ab)uses where the decoding isn't trivial.
    (Receivers that require accurate timestamps could be one exception)

    - Decoding
    There is "decoding" and there is "translation". With hw receivers
    (such as usb ir/rf dongles and HID devices mentioned above) you often
    only need to translate or map events sent by the hw to the correct input
    event and that's it. This can easily be done in-kernel (modulo complex
    remote/key mappings, maybe).
    Decoding analog input (even if it's only timing) is a different story.
    Would you want to worry about somebody with an IR transmitter (think
    phone/pda/laptop, but it could also be a modded remote) crashing your
    machine, just because the in-kernel decoder didn't handle some weird
    data? Or somebody leaving a small device around, which over time lead to
    OOM, cause the kernel decoder kept leaking memory?
    The bandwidth requirements for a remote are minimal, say <=20 events/s,
    and the max latency in the 100ms range would still be ok, so two, or six,
    context switches per key pressed shouldn't be a problem.

    - Configuration
    This isn't actually as simple as it looks at first. If you want to support
    multiple remotes (and you do), complex mappings (eg one->many or sequence->one),
    multiple modes etc then going through a userspace mapper is probably better.
    I looked briefly at Jon's configfs i/f and it seems it could handle the
    case, but being able to grab the receiver, process the data in userspace and
    reinject it back would still be needed for some setups.


     \ /
      Last update: 2009-11-30 11:01    [W:0.048 / U:90.392 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site