Re: In-kernel IR remote control support

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

>> The only way to get out of this situation long-term is to get advanced
>> IR support into the mainline kernel.
> 
> We at least need a unified place for drivers, or unified support for
> those drivers that must be put in userspace, a la usbfs and libusb.

That isn't good enougth.  That unified place must be mainline (for the
kernel stuff).  Userland bits can continue to live in the lirc package,
that isn't a problem.

>> It is certainly a good thing to have only *one* way to handle IR
>> remotes.  But the kernel side of that way *must* be in mainline.
>> Everything else simply isn't going to fly.
> 
> One way or a hybrid way to address everyone's concerns. I don't see
> why this has to be ALL kernel or ALL userspace.

It hasn't to be all kernel or all userspace.
But all kernel bits must be in mainline.

> I would think it could
> be both and still be clean.

Sure.  We can even support both ways in the very same driver.  I'll grab
a piece of hardware I know of as example: cx88-based TV cards:

 * The hardware gives you the raw IR samples.
 * The kernel takes them, decodes them and sends the input layer way
   to user.  The remote bundled with the TV card works fine.  Which
   is what probably 95% of the users need.
 * In theory you can decode *any* remote IR codes.  In practice you
   can't because there is no way to get the raw IR samples to userspace
   where lircd can handle them.

Ok, what are the options to fix the latter?

 * lirc would do the trick.  Doesn't fly though due to cx88 being
   mainline and lirc (kernel drivers) being out-of-tree.
 * input layer extension for raw IR codes.  Doesn't exist (yet?).
 * something completely different ...

Then you can have cx88 register both within the input layer (for the
bundled remote) and in the new raw-ir-codes subsystem.  Someone (say
lircd) opening the raw IR interface will make the in-kernel decoding
stop.  You are done ;)

cheers,
  Gerd