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

[Artur Skawina]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/