On Sun, Nov 29, 2009 at 7:01 AM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> 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. > 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. > I'm having my 'LIRC maintainer' hat on mostly during this discussion and I > do understand that from Linux kernel perspective things look different. It would be interesting to split the lirc daemon. Put the protocol decoder stuff in one daemon and the scripting support in the other. The scripting daemon would then be optional. What would be the relative sizes of the two daemons? -------------- The LIRC daemon always works with timing data, right? When it reads the config files generated by irrecord it internally converts those to timing data and then matches the incoming data against it. Have you looked at the protocol engine idea? Running the protocol engines in parallel until a match is achieved. Then map the vendor/device/command triplet. The protocol engine concept fixes the problem of Sony remotes in irrecord. Various Sony remote buttons transmit in different protocols. irrecord assumes that a remote is only using a single protocol. Since it can't figure out a protocol it always records these remotes as raw. If the IR data is being decoded in a protocol engine it becomes possible to get rid of the need to configure IR in some cases. Apps like MythTV could pretend like they are a common piece of electronics hardware - say a Motorola DVR. MythTV can then look for the vendor/device/command triplet from a Motorola DVR. Set your programmable remote to send the Motorola DVR commands and everything will "just work". Button on remote programed to be Mot DVR --> protocol engine --> Mot/dev/command --> MythTV which is looking for Mot/dev/command No config files needed. Make a command in MythTV to switch to emulating a different DVR if you happen to own this one. Take this a step further and register a MythTV profile with the various IR databases. > >> 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? > > Christoph > -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
