On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus <christoph@xxxxxxxxxxxx> wrote: > Hi Mauro, > > on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote: >> Christoph Bartelmus wrote: > [...] >>> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just >>> because I'm not familiar at all with input layer toolset. > [...] >> I hope it helps for you to better understand how this works. > > So the plan is to have two ways of using IR in the future which are > incompatible to each other, the feature-set of one being a subset of the > other? Take advantage of the fact that we don't have a twenty year old legacy API already in the kernel. Design an IR API that uses current kernel systems. Christoph, ignore the code I wrote and make a design proposal that addresses these goals... 1) Unified input in Linux using evdev. IR is on equal footing with mouse and keyboard. 2) plug and play for basic systems - you only need an external app for scripting 3) No special tools - use mkdir, echo, cat, shell scripts to build maps 4) Use of modern Linux features like sysfs, configfs and udev. 5) Direct multi-app support - no daemon 6) Hide timing data from user as much as possible. What are other goals for this subsystem? Maybe we decide to take the existing LIRC system as is and not integrate it into the input subsystem. But I think there is a window here to update the LIRC design to use the latest kernel features. We don't want to build another /dev/mouse and have to rip it out in five years. > > When designing the key mapping in the kernel you should be aware that > there are remotes out there that send a sequence of scan codes for some > buttons, e.g. > http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159 This is good input. -- 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
