lkml.org 
[lkml]   [2009]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    From
    On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
    <dmitry.torokhov@gmail.com> wrote:
    > On Nov 29, 2009, at 12:44 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
    >
    >> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
    >>>
    >>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at
    >>>  least?
    >>>
    >>> 2. Is there any problem with lirc kernel-user interface?
    >>
    >> Can you consider sending the raw IR data as a new evdev message type
    >> instead of creating a new device protocol?
    >
    > No, I think it would be wrong. Such events are ill-suited for consumption by
    > regular applications and would introduce the "looping" interface I described
    > in my other email.

    Regular applications are going to ignore these messages. The only
    consumer for them is the LIRC daemon. Which is just going to process
    them and re-inject the events back into evdev again in a different
    form.

    IR is an input device, what make it so special that it needs to by
    pass this subsystem and implement its own private communications
    scheme?

    >> evdev protects the messages in a transaction to stop incomplete
    >> messages from being read.
    >
    > If such property is desired we can add it to the new lirc-like interface,
    > can't we?

    Why do you want to redesign evdev instead of using it?


    >
    > --
    >>
    > Dmitry
    >



    --
    Jon Smirl
    jonsmirl@gmail.com
    --
    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/

    \
     
     \ /
      Last update: 2009-11-29 22:49    [W:3.165 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site