Christoph Bartelmus wrote:

Hi Jon,

on 27 Nov 09 at 12:49, Jon Smirl wrote:
[...]

quoted

Christoph, take what you know from all of the years of working on LIRC
and design the perfect in-kernel system. This is the big chance to
redesign IR support and get rid of any past mistakes. Incorporate any
useful chunks of code and knowledge from the existing LIRC into the
new design. Drop legacy APIs, get rid of daemons, etc. You can do this
redesign in parallel with existing LIRC. Everyone can continue using
the existing code while the new scheme is being built. Think of it as
LIRC 2.0. You can lead this design effort, you're the most experience
developer in the IR area.

This is a very difficult thing for me to do. I must admit that I'm very  
biased.
Because lircd is the only userspace application that uses the LIRC kernel  
interface, we never had any problems changing the interface when needed.
I can't say there's much legacy stuff inside. I'm quite happy with the  
interface.

It makes sense currently, but, once added at kernel, you won't be able
to change it again, without huge efforts. So, if the interface has any 
trouble, we need to correct it before adding at the kernel. You should
remember that a kernel driver shouldn't be bound to an specific userspace
application. So, the same kernel interface should work with all lircd's
starting from the version where the interface was added. In other words,
it should be possible to use let's say a 5 year-old lirc with a brand 
new kernel.

Also, some non lirc applications may arise, using the same kernel interface.
So, the API stability needs to be kept.

The other thing is that I can't really move the decoder from userspace to  
kernel because there are way too many userspace drivers that do require a  
userspace decoder. LIRC also is running on FreeBSD, MacOS and even Cygwin.  
So letting the userspace drivers take advantage of a potential Linux in- 
kernel decoder is not an option for me either.

You can take advantage of a in-kernel decoder. Instead of receiving raw
pulse/space, you'll be receiving keystrokes (or scancodes).

Probably, it doesn't make sense to port every single IR protocol decoder
to kernel. We need there support for the protocols that come with the IR shipped
with the devices (I think that currently we have RC5, RC4, NEC and pulse-distance), 
and the most used procolos at the universal IR's (RC5 may be enough?).

quoted

Take advantage of this window to make a
design that is fully integrated with Linux - put IR on equal footing
with the keyboard and mouse as it should be.

That's a question that I have not answered for myself concludingly.
Is a remote control really on exactly the same level as a keyboard or  
mouse?

On some devices like STB and TV sets (most of modern LCD/Plasma TV's run Linux),
they are at the same level. I'd say that the same applies to PC's that
the user has dedicated to work as an MCE.

Cheers,
Mauro.