Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Dmitry Torokhov]

On Nov 29, 2009, at 1:47 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:

> On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> wrote:
> > On Nov 29, 2009, at 12:44 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
> >
> > > On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa <khc@xxxxxxxxx>  
> > > 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?

So are HID devices (both USB and BT), PS/2 and so on. You are not  
arguing for sending unprocessed data from these devices through evdev.

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

I just said why in my previous email: looping is a mark of badly  
designed interface.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/