RemoteControls

Summary

This specification describes how to improve the support for infrared (IR) remote controls in Debian and Ubuntu.

Rationale

Robust support for remote controls is needed in both Debian and Ubuntu, and is a must for the UbuntuMediaCenter.

Though there is an excellent software base through LIRC, it is generally too difficult to setup and configure for most users. Moreover, it's not easy for most users to find information on hardware compatibility.

This is clearly not in the Ubuntu spirit, and there is room for improvement.

Through several actions, we will leverage the full power of LIRC and improve Debian and Ubuntu users' experience with remote controls.

Use Cases

  • Ethan owns an Ubuntu desktop computer. He wants to buy a remote control to manage it, but lacks information about compatibility in Ubuntu.
  • Sooba has a laptop provided with a remote control, but she is not able to configure it to control her Debian PC and gets frustrated.
  • The Ubuntu Media Center Team wants to provide such software for Ubuntu. But it is facing the two above major issues.

Scope

This specification covers both technical and non-technical (marketing, certification) issues, all related to improving remote control support in Debian and Ubuntu.

Design

LIRC improvements

LIRC is mostly configured through 2 files:

  • the "lircd.conf.<remote-name>" file, which describes the hardware bindings, e.g. pressing this key generates that signal. There is one file per supported remote.

  • the ".lircrc" configuration file, which describes the user's binding: receiving this signal generates that action.

a. LIRC signal naming

Problem: LIRC doesn't provide a common signal/key naming scheme read this, point a) As an example, the "play" function can be called:

  • "PLAY" (streamzap),
  • "PLAY_DOWN" and "PLAY_UP" (animax),
  • "Play" (mceusb), ...

This has the major drawback to force each user to create a new lircrc file which matches his remote's signal names and desired actions. This also make it really hard to create configuration GUIs for LIRC, and to use remote controls in applications.

Solution: standardize a common key naming, to have the same signal names used in every "lircd.conf.*".

The Linux input.h naming will be used, and discussed for extension with Vojtech Pavlik (Linux input layer leader) and the LKML.

b. Parseable compatibility list

Problem: LIRC doesn't provide a parseable compatibility list. This would help in:

  • creating configuration wizard, for selecting easily the right remote from a graphical list
  • feeding Ubuntu Hardware Database.

There is now an HTML table, generated at compile time by the lirc/doc/table.sh script.

Solution: modify the table.sh script to also generate a flat mode parseable text file.

c. Complete remote support at runtime

Problem: some driver need to be recompiled to get the support for a specific kind of remote. For example, lirc_serial can be built for Animax (#ifdef LIRC_SERIAL_ANIMAX), Irdeo (#ifdef LIRC_SERIAL_IRDEO). This so exclude support for some remotes, and forces one to recompile LIRC.

Solution: provide ie lirc_serial1 with IRDEO defines, lirc_serial2 with ANIMAX defines, ... or better, to have a param "type" that allows runtime switching.

FIXME(AQU): Discussion to be finished with Christoph Bartelmus on that point.

d. Drivers recompilation

Problem: the LIRC drivers (lirc-modules-source package) need to be recompiled before use, according to the user's need. This is an unusual step and these drivers should be supported out-of-the-box.

Solution: find a way to provide all the needed drivers for supported remotes. This will be achieved by merging the LIRC kernel drivers into the Linux mainline. The userspace drivers would then be shipped without the kernel version dependency issue.

Some drivers are currently available both as kernel and userspace drivers. Since the former is generally more complete, but the latter more easy to distribute, the best would be to complete the userspace drivers. Jon Smirl has started to work on this, along with the kernel integration.

FIXME(AQU): Discussion to be finished with Christoph Bartelmus and Jon Smirl on that point.

Ubuntu improvements

a. Configuration

Problem: there is no graphical tool in Ubuntu to easily choose and configure your remote. You need to copy the good lircd.conf file and create a lircrc file matching your application choice and the name of its options.

Solutions:

  • short run: provide a basic ".lircrc" file, suited for general purpose usage. This would only define keys which are always supported. For example, pressing the remote's Music key would launch Banshee on Ubuntu, AmaroK on Kubuntu, ...
  • long run: each application, that can be used with a remote, provides a LIRC capabilities file. This last describes the mapping between LIRC event names and the application's functions. The short run solution is applied, but with some dynamic management using the user's favorite applications.
  • in both case: create a smart configuration GUI, allowing to easily:
    • select you remote from a list. This would copy the right lircd.conf file and fills the needed files (/etc/modules, /modprobe/aliases, /etc/lirc/hardware.conf, ...)
    • (long run only): tune the configuration by presenting the keys available for the current remote, and the current / possible bindings with application.

b. IR Launcher applet

Problem: Generally, user will need to launch someway the irexec program. This need some shell scripting or Session Configuration that could be avoided by proposing an IR Launcher applet. This last would simply launch irexec (maybe re implement it?!) and add a systray icon for showing IR activity.

spec here

Hardware compatibility and recommendation

Ubuntu should provide a hardware compatibility list and recommend some remote controls based upon the following criterion:

  • the remote control can be easily found worldwide (the list must be updated on a frequent basis),

  • And the remote control can be autodetected by Ubuntu (preferably USB),

  • And the remote control is built (or sold) by an ubuntu friendly manufacturer (or reseller), ie:

    • which provides official support to LIRC,
    • which bundles or provides an Ubuntu sticker (lobbying with the Marketing Team),

    • which has certified its hardware with Ubuntu (to be discussed with Malcom Yates)

The HWDB should acquire its compatibility data from the Parseable compatibility list mentioned above.

In the short run, Ubuntu should at least reference all the existing Hardware Compatility Lists for its bundled applications (Reference 2).

Other improvements (to be completed)

  • udev: automatically configure autodetected remotes (USB, and ?i2c?)

  • bridge LIRC with HAL so that USB remotes can be available on the fly (no config. needed). There seems to be some Xorg work on using HAL to detect (and use?) input devices through it. If all input devices reports to HAL, we would have a uniform way to manage inputs.

Implementation

Every improvements has to be made in coordination with the upstream team:

Milestone 1 (target: Gutsy)

Implement the following solutions:

  • all of the "LIRC improvements" section,

    • Task name

      Task status

      Assignee

      Comments

      a. LIRC signal naming

      underway (60 %)

      LoicDardant

      light and full namespace analysis

      b. Parseable compatibility list

      Done (100 %)

      LoicDardant, ArnaudQuette

      the lirc.hwdb file will be generated as of lirc 0.8.2

      c. Complete remote support at runtime

      not started (0 %)

      ArnaudQuette

      under investigation

      d. Drivers recompilation

      not started (0 %)

      ArnaudQuette

      under investigation

    • It seems there is already some work underway here and here.

  • and possibly the udev or HAL improvements.

These represents the Ubuntu Media Center requirements.

Notes:

  • Once validated, this naming must be applied to all the LIRC bundled

    files (called "light analysis" above), and committed upstream. A second step will be to apply it to the LIRC remotes archive (called "full" analysis above),

  • When the new LIRC release and Debian packages are available, including the above changes,

    bug the LIRC ubuntu package for an update.

  • the minimum set of supported remotes is equal to LIRC's commercially supported remote. These should be the most commonly used devices among the Ubuntu Community.

Milestone 2 (possible target: Gutsy)

Implement the remaining solutions:

Milestone 3 (possible target: ?)

Implement the remaining solutions:

  • points a) (long run) of the "Ubuntu improvements" section. I'm thinking of a directory (/usr/share/lirc/lircrc/) where each application stores its capabilities file (called appname.capabilities) along with a base lircrc file (using lirc [section] mechanism). The configuration system would then use some "include" in the user's lircrc file.

Outstanding Issues

BoF agenda and discussion

References

CategorySpec UbuntuMediaCenter

RemoteControls (last edited 2008-08-06 16:27:22 by localhost)