Thread (7 messages) 7 messages, 6 authors, 2009-11-27

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

From: Krzysztof Halasa <khc@pm.waw.pl>
Date: 2009-11-25 16:53:51
Also in: linux-media, lkml

Possibly related (same subject, not in this thread)

Jarod Wilson [off-list ref] writes:
The bulk of breakage in lirc I've personally had to deal with has
mostly come in the form of kernel interface changes, which would
definitely be mitigated by not having to maintain the drivers
out-of-tree any longer.
Certainly.
Now, I'm all for "improving" things and integrating better with the
input subsystem, but what I don't really want to do is break
compatibility with the existing setups on thousands (and thousands?)
of MythTV boxes around the globe. The lirc userspace can be pretty
nimble. If we can come up with a shiny new way that raw IR can be
passed out through an input device, I'm pretty sure lirc userspace can
be adapted to handle that.
Lirc can already handle input layer. Since both ways require userspace
changes, why not do it the right way the first time? Most of the code
is already written.
If a new input-layer-based transmit interface is developed, we can
take advantage of that too. But there's already a very mature lirc
interface for doing all of this. So why not start with adding things
more or less as they exist right now and evolve the drivers into an
idealized form? Getting *something* into the kernel in the first place
is a huge step in that direction.
What I see as potentially problematic is breaking compatibility multiple
times.
-- 
Krzysztof Halasa
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help