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

[<li...@ba...>]

Hi!

Jon Smirl "jon...@gm..." wrote:
> LIRC folks, there is an on-going discussion about possible future
> designs for IR support in the kernel. What's your take on how to do
> this?

Pass all events to userspace and let lircd do the mapping/decoding.

In case of the atiusb device there are currently 17 different remotes =20
known. Handling this in userspace is a lot easier.
It is of course possible to do the mapping in kernel space and it seems =20
like it makes configuration for the user easier, but from my experience =20
users simply don't want that their remotes act like a normal keyboard.
From=20time to time your will see requests on the LIRC mailing list like =20
"Help, when I press buttons on my remote, some weird symbols appear in =20
my terminal. How do I disable this?"
If users want that their remote works like a keyboard this is still =20
possible using uinput. Actually you can use kbdd [1] to do exactly this =20
already.
If there was enough interest I could easily integrate this in lircd =20
without having to use an additional program and having to do additional =20
configuration. lircd could convert remote signals automatically to =20
uinput events using the remote's button name. E.g. a button called "1" =20
could generate a KEY_1 event or "MUTE" could generate a KEY_MUTE event.

If you are still not convinced that lircd should handle mapping/=20
decoding, then look at a device like the Streamzap remote or the Windows =20
Media Center remote. These devices do not decode the IR signals =20
themselves but just deliver the signal waveform to the host PC. The =20
signal waveform is decoded by lircd. I know dozens of different IR =20
protocols with countless variations. Trying to decode these protocols in =20
kernel space is out of question for me. It would mean putting most parts =20
of lircd into kernel space.
I know that there are currently some TV card IR drivers that decode RC5 =20
in kernel space. These drivers prevent the user from choosing a =20
different remote control which uses a different protocol.

Additionally the Windows Media Center can be used as IR blaster. The =20
input layer cannot be used to make use of this feature.

Now look at the IR devices that are handled by LIRC completely in =20
userspace. For example you can connect an IR receiver to your soundcard =20
and let lircd use ALSA to receive the signals. Or look at the receivers =20
that connect to the serial port and use standard 1200 8N1 communication =20
through the kernel's serial port driver. There's no way for these =20
drivers to use the kernel's input system other than using uinput.

That's why I suggest using the LIRC driver system like it is with lircd =20
being the uniform interface for applications. If the user wants his =20
remote to act like a keyboard he could configure lircd to enable this =20
feature independent of how the hardware is working internally.

The only drawback of this approach I can see is that for some devices =20
there is additional overhead as the input events have to be routed =20
through lircd although the drivers could generate the input events =20
directly. But the advantages of the current LIRC approach outweigh this =20
drawback by far IMHO.

Christoph

1: http://www.handhelds.org/moin/moin.cgi/kbdd