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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 02 Dec 2008 23:00:45 +0100
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Christoph Bartelmus <lirc@...telmus.de>
CC:	pavel@...e.cz, jonsmirl@...il.com, jrm8005@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: In-kernel IR remote control support

  Hi,

>> Can we merge the common ones into the kernel, while still keeping the
>> obscure ones in userspace using uinput or something?
> 
> Why do you want to complicate things even more.

Reality check please.  It already is that complicated.  We have IR
kernel drivers today.

> The decision to include some IR support using the Linux input layer some  
> time ago has forced *me* to add support for this in LIRC and explain to  
> people why for some devices they need LIRC drivers, and for some they need  
> the kernel drivers, and for other configurations they have to explicitly  
> disable the kernel drivers and replace them by LIRC drivers, etc.

The only way to get out of this situation long-term is to get advanced
IR support into the mainline kernel.

It doesn't matter how that actually looks like.  Could be pretty much
like todays lirc drivers.  Could be some input layer extention for
receiving/sending raw IR codes.  Could be something completely different
such as using the tty layer for that.  That has to be discussed and
agreed on.

What *does* matter is being in mainline.  lirc not being in mainline was
*the* major reason for me to use the input layer to handle TV card IR
support.  Having a in-tree driver depending on a out-of-tree subsystem
for IR is a major pain.

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.

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/