Christoph Bartelmus wrote: > Hi Jon, > > on 27 Nov 09 at 12:49, Jon Smirl wrote: > [...] >> 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?). >> 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. -- 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
