Re: Fwd: [linux-usb-devel] USB IR receivers and evdev

[Jon S. <jon...@gm...>]

On 19 Feb 2007 05:01:00 +0100, Christoph Bartelmus <li...@ba...> wrote:
> Hi!
>
> Jon Smirl "jon...@gm..." wrote:
> [...]
> >> btw, is there any reason why those drivers are implemented as kernel
> >> modules? Couldn't lircd just use libusb and talk directly to the
> >> devices instead?
>
> > This is a very good question. It's not like LIRC is high speed.
> > A big reason to be in the kernel is to manipulate device register with
> > root priv, but these drivers don't need to do that.
>
> Driver deveopment started when libusb was not stable/mature enough to rely on it. Later nobody really cared to convert the drivers to userspace except for the atiusb code, where also a userspace driver is available, but it does not support all the receivers that the kernel module supports.
>
> One reason I would like to keep the drivers as kernel modules is that you can use tools like mode2 or xmode2 to easily test them.

These should be able to work with a user space library that provides
the right API.

I was already to try and merge these drivers into the kernel, but now
I am having second thoughts about doing a user space implementation
instead.

>
> > USB devices have libusb
> > parallel and serial can just open the devices
>
> The parallel and serial kernel modules need to implement an interrupt handler. You cannot use the standard devices.
>
> > how about GPIO and anything else weird?
>
> I don't know about GPIO, but for the I2C driver a userspace driver also is available, but I did not have time to integrate it into the code base yet.


All of the parallel, serial, gpio, i2c type devices probably have to
go into the kernel because they need to do accurate timings. Once you
are in user space it becomes difficult to time things.

For example the user space implementation for i2c (I2C_CHARDEV) still
bit twiddles in the kernel and then only presents you with the
results.


>
> Christoph
>


-- 
Jon Smirl
jon...@gm...