Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

Artur Skawina
2009-11-30T09:57:57Z

Ray Lee wrote:
> On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls <awalls@radix.net> 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