From: Arnaud Q. <aqu...@gm...> - 2008-05-02 21:56:01
|
2008/5/2 Bastien Nocera <ha...@ha...>: > > On Fri, 2008-05-02 at 14:03 +0200, Arnaud Quette wrote: > > Hi > > 2008/5/2 Bastien Nocera <ha...@ha...>: > > > > > > 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/ |