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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux