Jon Smirl wrote: > 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. This makes sense to me. Yet, I think that, on some specific cases, we'll need a raw interface. > 2) plug and play for basic systems - you only need an external app for scripting Yes. > 3) No special tools - use mkdir, echo, cat, shell scripts to build maps I don't think this is relevant. As we already have ioctls for building maps, and while all in-kernel drivers can handle scancodes with up to 32 bits, I don't see any reason to use anything different than what's currently available. > 4) Use of modern Linux features like sysfs, configfs and udev. sysfs/udev is a need for hot-plugging. I wouldn't use configfs for it. There aren't many places using it and afaik some distros are not compiling their kernels with configfs enabled. Also, as we have already ioctl's for keycode maps, I think we shouldn't be migrating to controlfs. > 5) Direct multi-app support - no daemon For multi-app support usage like your example (e. g. different IR keys mapped into the same evdev keycode and sent to different applications), I think we should need a daemon for handling it. > 6) Hide timing data from user as much as possible. I agree. Porting the IRQ/gpio pollings to userspace on a system with a high workload may mean that the keycode will be badly interpreted. 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
