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

Maxim Levitsky
2009-11-28T19:16:16Z

On Sat, 2009-11-28 at 13:56 -0500, Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky <maximlevitsky@gmail.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