Ray Lee wrote: > On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls <awalls@xxxxxxxxx> wrote: >>> If decoding can *only* be sanely handled in user-space, that's one >>> thing. If it can be handled in kernel, then that would be better. >> Why does the address space in which decoding is performed make the >> decoding process better or worse? The in kernel infrastructre and >> restrictions add constraints to a decoding implementation. Userspace is >> much more flexible. > > In which case I look forward to seeing your patches to move > drivers/hid/ to userspace. Please cc: me so I can enjoy the ensuing > festival. Umm, this thread is really about several independent issues - Event delivery There's an existing input system that works, there's no need to reinvent the wheel; all remote events (usually key presses, but there are also wheels/touchpads/joysticks/etc, which don't necessarily map to buttons) should eventually arrive through it. Whether there's a userspace component somewhere on the receiver->/dev/input path doesn't change anything. - Acquisition If it isn't interrupt-driven it should to be in userspace. ADC falls into this category, but also various bitbanging approaches and probably also many serial port (ab)uses where the decoding isn't trivial. (Receivers that require accurate timestamps could be one exception) - Decoding There is "decoding" and there is "translation". With hw receivers (such as usb ir/rf dongles and HID devices mentioned above) you often only need to translate or map events sent by the hw to the correct input event and that's it. This can easily be done in-kernel (modulo complex remote/key mappings, maybe). Decoding analog input (even if it's only timing) is a different story. Would you want to worry about somebody with an IR transmitter (think phone/pda/laptop, but it could also be a modded remote) crashing your machine, just because the in-kernel decoder didn't handle some weird data? Or somebody leaving a small device around, which over time lead to OOM, cause the kernel decoder kept leaking memory? The bandwidth requirements for a remote are minimal, say <=20 events/s, and the max latency in the 100ms range would still be ok, so two, or six, context switches per key pressed shouldn't be a problem. - Configuration This isn't actually as simple as it looks at first. If you want to support multiple remotes (and you do), complex mappings (eg one->many or sequence->one), multiple modes etc then going through a userspace mapper is probably better. I looked briefly at Jon's configfs i/f and it seems it could handle the multiple-physical-remotes-with-one-receiver-and-multiple-independent-devices case, but being able to grab the receiver, process the data in userspace and reinject it back would still be needed for some setups. artur -- 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
