User: Password:
Subscribe / Log in / New account

Kernel support for infrared receivers

Kernel support for infrared receivers

Posted Dec 14, 2009 11:25 UTC (Mon) by incase (guest, #37115)
Parent article: Kernel support for infrared receivers

I really don't know wether I want the kernel to "just work" in the sense of generating evdev events for any IR code received.

One reason is that IR codes are not standardized, I once had a TV remote that would turn up the volume on my HiFi amplifier when hitting the key for teletext. In other words: I could have a remote that has the same keycode for the "1" key as some other remote has for the "channel up" key. So which translation should the kernel provide as an evdev event?

The other problem is which remote codes I want the Linux machine to interpret and which ones I don't want it to "see". I don't want Linux to turn up the volume if I hit the "volume up" key on my amplifiers remote (or on my universal remote when in amplifier mode).

Which all boils down to: Even if the kernel could provide a standardized evdev interface for IR events, it would still require configuration. Also I sometimes want to have some IR events routed to one application and others to a different one, which is possible with current LIRC, but I don't see too many options how this could be done with an evdev interface, especially if none of those applications run under X11 (like my VDR and some background tools I control via IR right now).

All in all, I would probably prefer to have LIRC merged mainly "as-is", unless the evdev approach can tackle my "problems" above.

(Log in to post comments)

Kernel support for infrared receivers

Posted Dec 14, 2009 18:02 UTC (Mon) by dlang (subscriber, #313) [Link]

no scheme can address those problems, but what you can get from evdev is that the application doesn't have to know about IR remotes specificly.

the app can watch for 'volume_up', and do the right thing no matter if the button pressed in on a multimedia keyboard, an IR remote, a RF remote, a USB device, etc.

wither you use LIRC or evdev, there has to be a mapping loaded to map the particular keystrokes to particular scancodes.

this is just like keyboards. different keyboards put the letters in different places without the system having any way to detect this. this doesn't prevent the system from defaulting to a common keymap, but providing the ability to load more specific ones.

Kernel support for infrared receivers

Posted Dec 15, 2009 9:28 UTC (Tue) by incase (guest, #37115) [Link]

Well, the problem with IR is that most people I know of have multiple remotes, of which only one should actually be handled by Linux. So if "all" (well, most) remotes "just work" with Linux, too many events will be handled by the Linux apps.
From the application point of view, you are right, the application should just check for "volume up" (and any other type of event it is interested in) and do the right thing.
From the user point of view however, it must be possible to ignore some "volume up" events.
The easiest way to achieve that is to actually provide
"remote_type/vol_up" events and allow the user to tell the system to ignore (or only process) "sony_tv/*" events for example (though I'm not sure how this should work, via a userspace tools, sysfs, ioctl or whatever).

The filtering/routing to different applications is a secondary concern for me. I can solve that in other ways.

Kernel support for infrared receivers

Posted Dec 15, 2009 20:26 UTC (Tue) by dlang (subscriber, #313) [Link]

it makes sense to have a default keymap that responds to all volume_up keys, but then have the option of loading a different keymap that only responds to specific volume_up keys.

it's not as simple as saying 'respond to sony_tv/* events' there are many different sony_tv mappings, some of which overlap

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds