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
