linux-kernel - Re: In-kernel IR remote control support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <493651C4.50705@redhat.com>
Date:	Wed, 03 Dec 2008 10:30:44 +0100
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	"J.R. Mauro" <jrm8005@...il.com>
CC:	Christoph Bartelmus <lirc@...telmus.de>, pavel@...e.cz,
	jonsmirl@...il.com, linux-kernel@...r.kernel.org
Subject: Re: In-kernel IR remote control support

  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/