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