[PATCH] preliminary LIRC integration in HAL

[Arnaud Quette]

2008/5/2 Bastien Nocera <hadess at hadess.net>:
>
>  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.

you're talking about loading a kernel module, and I'm talking about
having lirc up and running (kernel / userland module and daemons
loaded): 2 different things.

>  > - 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.

have I said such a thing?
this point deals with having all lirc remote definitions using the
same namespace (ie same names for all keys), not about using hal as a
placeholder to give the key mapping!
the side point of using hal for event signaling, iirc was not the
latest path followed by hal/xorg and friends.

>  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.

lirc is about IR remote controls, ie the bundle of a transceiver and a receiver.
we wouldn't gain anything considering your receiver only approach...
finally, I only expose this device as having such a capability
(input.remote_control).

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/