infra-red remotes in GNOME 3

gnome-lirc-properties has served its purpose. It will probably carry on working on GNOME 3 desktops, but you won't be happy when it drags in GTK+ 2.x Python bindings, HAL or doesn't integrate into the new control-center.

But things have changed since gnome-lirc-properties was first written, and the way to handle IR remotes has changed as well:

• A large majority of receivers are now supported in the kernel using rc-core (né ir-core).
• Some receivers aren't supported (iguanaIR amongst others), and some need porting from pure input drivers to rc-core. Some functionality for the ATI Remote Wonder remotes is also not supported by the new drivers. If you're interested in working on this, drop a mail to the LIRC list.
• Mauro Chehab is making progress at propagating the key events from the kernel up to the stack to X11 applications. There's some patches in that direction on the Red Hat Bugzilla.

This means that:

• Event delivery would still need a broker in the session, to get to unfocused applications. gnome-settings-daemon can step in that role (and step out of the way when the application is focused, so the app can bring context dependent behaviour). gnome-settings-daemon already handle some of the more common multimedia keys in its media-keys plugin.
• The only configuration one would need to do is selecting the type of remote for the receiver, eventually tweaking the keymap for that remote.

So to write a replacement for gnome-lirc-properties that would fit into GNOME 3, one would need:

• A way to enumerate receivers on the machine
• A way to change the remote configuration (changing the keymap) for that receiver
• Eventually a way to tweak the keymap

This could all be handled through a D-Bus version of ir-keytable. If Mauro's patches reach X.org mainstream, then a kernel/GNOME summer of code project could be had for this work. Best to start writing some kernel patches, or laying some code if you want to get a headstart.

PS: For completeness' sake, there are also "pure" input devices that are remotes that wouldn't be handled through this. Those would need to be blacklisted in the input layer, and handled through rc-core instead.