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:	Sat, 28 Nov 2009 21:16:14 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	Krzysztof Halasa <khc@...waw.pl>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Christoph Bartelmus <christoph@...telmus.de>,
	jarod@...sonet.com, awalls@...ix.net, dmitry.torokhov@...il.com,
	j@...nau.net, jarod@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

On Sat, 2009-11-28 at 13:56 -0500, Jon Smirl wrote: 
> On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky <maximlevitsky@...il.com> wrote:
> > On Sat, 2009-11-28 at 11:45 -0500, Jon Smirl wrote:
> >> What are other examples of user space IR drivers?
> >>
> >
> > many libusb based drivers?
> 
> If these drivers are for specific USB devices it is straight forward
> to turn them into kernel based drivers. If we are going for plug and
> play this needs to happen. All USB device drivers can be implemented
> in user space, but that doesn't mean you want to do that. Putting
> device drivers in the kernel subjects them to code inspection, they
> get shipped everywhere, they autoload when the device is inserted,
> they participate in suspend/resume, etc.
> 
> If these are generic USB serial devices being used to implement IR
> that's the hobbyist model and the driver should stay in user space and
> use event injection.
> 
> If a ft232 has been used to build a USB IR receiver you should program
> a specific USB ID into it rather than leaving the generic one in. FTDI
> will assign you a specific USB ID out of their ID space for free,  you
> don't need to pay to get one from the USB forum. Once you put a
> specific ID into the ft232 it will trigger the load of the correct
> in-kernel driver.

If we could put *all* lirc drivers in the kernel and put the generic
decoding algorithm, then it might be begin to look a bit more sane.
And write  tool to upload the existing lirc config files to kernel.
This would essentially we same as porting the lirc to the kernel.
I don't see much gains of this, and this way or another, alsa input
won't be possible.

Christoph Bartelmus, Jarod Wilson, what do you think?

Regards,
Maxim Levitsky









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