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 for Android: free password hash cracker in your pocket

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

Message-ID: <3aaafc130812021659x36701b19vc0d22f3c38471b65@mail.gmail.com>
Date:	Tue, 2 Dec 2008 19:59:57 -0500
From:	"J.R. Mauro" <jrm8005@...il.com>
To:	"Gerd Hoffmann" <kraxel@...hat.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

On Tue, Dec 2, 2008 at 5:00 PM, Gerd Hoffmann <kraxel@...hat.com> wrote:
>  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.

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.

>
> 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.

Agreed. And we need to make sure the discussion part actually happens
because once a decision is made, it's hard to correct bad choices.

I would think that an input layer extension would be best because,
e.g. Apple remotes are changed around all the time and, while
functioning the same and having the same form, they send very very
slightly different codes, and I think we would want a way to keep this
really flexible so we just update a quirks table or something to that
effect. I don't know if we're already trying to do that (if we are,
hooray, I'll go away now) but I think it's a good idea.

>
> 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.

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. I would think it could
be both and still be clean.

>
> 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/