Messages in this thread | | | Date | Sun, 29 Nov 2009 16:47:18 -0500 | Subject | Re: [RFC] What are the goals for the architecture of an in-kernel IR system? | From | Jon Smirl <> |
| |
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?
>> 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@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |