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

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:	Sun, 29 Nov 2009 13:19:10 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andy Walls <awalls@...ix.net>, Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <lirc@...telmus.de>,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	maximlevitsky@...il.com, mchehab@...hat.com,
	stefanr@...6.in-berlin.de, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR 
	system?

On Sun, Nov 29, 2009 at 7:40 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> BTW, circa 1995 my serial mouse "Just Worked" in Linux.  Sometime around
>
> Correct X11 just talked to the serial ports. In fact that is still the
> way to configure it if you want any sanity in life.
>
>> and serial connected IRs.  It's also too convenient to access USB IR
>> hardware from existing userspace drivers to bother porting into the
>> kernel.
>
> Userspace needs a way to identify IR hardware and to interface with it
> using the right protocol. It's not clear the kernel needs to provide
> anything more than minimal hardware interfaces in most case - be that
> serial, libusb, ...

That's a description of the current system and it is driver chaos.

Half of the drivers are in user space and there are two different
classes of kernel driver - LIRC and V4L.
A lot of the hardware doesn't identify itself.
There are two types of IR data in use - pulse timing and decoded protocol.

IR is an input device. We have a nice evdev input subsystem and it has
been demonstrated that IR can work with it.

Everybody keeps complaining that they want IR to "just work".
Consolidating all of this (under 50K of code)  driver support in the
kernel is the way to make it "just work".

For example. Some IR devices only record pulse timing data. There are
various protocols - RC5, RC6, etc for turning these pulse timing into
a decode IR command. This is about 20K of code. Does it really make
sense to create a device, push this data out into user space, decode
it there, then inject the results back into the kernel (uinput) for
further processing by the input subsystem?

This decoding is getting done in user space because half of the IR
drivers are in user space. But the other half of them aren't in user
space and that set can't work in user space.  Most of the user space
drivers can be pushed into the kernel where they'll automatically load
when the device is detected.

Some of the drivers can't be moved like the IR over ALSA. But is
attaching an IR diode to the mic input of your sound card really a
device or is it a hack that should be dealt with in user space?
Another type is IR hardware that toggles the DTR output of a serial
port at 40Khz to make a signal. Same thing is done with parallel
ports. Those force the system into a bit-banging timing loop for
1/10th second.

-- 
Jon Smirl
jonsmirl@...il.com
--
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/