On Sat, 2009-11-28 at 13:56 -0500, Jon Smirl wrote: > On Sat, Nov 28, 2009 at 1:45 PM, Maxim Levitsky <maximlevitsky@xxxxxxxxx> 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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
