[PATCH] preliminary LIRC integration in HAL

Bastien Nocera hadess at hadess.net
Fri May 2 06:09:49 PDT 2008


On Fri, 2008-05-02 at 14:03 +0200, Arnaud Quette wrote:
> Hi
> 2008/5/2 Bastien Nocera <hadess at hadess.net>:
> >
> >  On Fri, 2008-05-02 at 09:00 +0200, Arnaud Quette wrote:
> >  > Hi all,
> >  >
> >  > The attached patch adds a preliminary support of LIRC and IR remote
> >  > controls into HAL, through LIRC.
> >
> >  Could you explain what it would be used for exactly? Should we be
> >  expecting changes to gnome-lirc-properties to take advantage of that new
> >  code for example?
> 
> as suggested in the mentioned doc (the html bits), this patch only
> helps in detecting USB remotes, without having to embed and maintain a
> list of USB IDs to match against.
> 
> so yes, it can be used in gnome-lirc-properties.
> 
> Now remember that it's not complete, and that it's part of a bigger
> set of useful changes, including:
> - a parseable LIRC hardware database, to help configuration,

That's a good thing.

> - a udev helper, to automatically configure and load everything when
> plugging a USB remote,

That's the wrong thing to do. USB receivers already have module aliases.
For example, I recently bought a streamzap remote, and the module got
loaded automatically thanks to:
$ modinfo /lib/modules/`uname -r`/kernel/drivers/input/lirc/lirc_streamzap.ko | grep alias
alias:          usb:v0E9Cp0000d*dc*dsc*dp*ic*isc*ip*

The udev helper shouldn't exist.

> - a standardized namespace for lirc keys, to address the key mapping easilly.

Putting the key configuration in HAL is not what HAL was meant to do.

Finally, you're using the "input.remote_control" string to match lirc
remotes. A Bluetooth remote, seen by the system as an input device, is a
real "input.remote_control". You'd be better off using your own
namespace, especially as the device isn't a remote control, but a
receiver.

Cheers



More information about the hal mailing list