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

Dmitry Torokhov
2009-11-29T22:48:31Z

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

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

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