Hi! Jon Smirl "[EMAIL PROTECTED]" 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 known. Handling this in userspace is a lot easier. It is of course possible to do the mapping in kernel space and it seems like it makes configuration for the user easier, but from my experience users simply don't want that their remotes act like a normal keyboard. >From time to time your will see requests on the LIRC mailing list like "Help, when I press buttons on my remote, some weird symbols appear in my terminal. How do I disable this?" If users want that their remote works like a keyboard this is still possible using uinput. Actually you can use kbdd [1] to do exactly this already. If there was enough interest I could easily integrate this in lircd without having to use an additional program and having to do additional configuration. lircd could convert remote signals automatically to uinput events using the remote's button name. E.g. a button called "1" 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/ decoding, then look at a device like the Streamzap remote or the Windows Media Center remote. These devices do not decode the IR signals themselves but just deliver the signal waveform to the host PC. The signal waveform is decoded by lircd. I know dozens of different IR protocols with countless variations. Trying to decode these protocols in kernel space is out of question for me. It would mean putting most parts of lircd into kernel space. I know that there are currently some TV card IR drivers that decode RC5 in kernel space. These drivers prevent the user from choosing a different remote control which uses a different protocol. Additionally the Windows Media Center can be used as IR blaster. The input layer cannot be used to make use of this feature. Now look at the IR devices that are handled by LIRC completely in userspace. For example you can connect an IR receiver to your soundcard and let lircd use ALSA to receive the signals. Or look at the receivers that connect to the serial port and use standard 1200 8N1 communication through the kernel's serial port driver. There's no way for these 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 being the uniform interface for applications. If the user wants his remote to act like a keyboard he could configure lircd to enable this feature independent of how the hardware is working internally. The only drawback of this approach I can see is that for some devices there is additional overhead as the input events have to be routed through lircd although the drivers could generate the input events directly. But the advantages of the current LIRC approach outweigh this drawback by far IMHO. Christoph 1: http://www.handhelds.org/moin/moin.cgi/kbdd ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
