This weekend, I had quite a journey supporting the "CyberLink" remote
with which some Dell desktops have come equipped. It comes with a USB
IR receiver. In some ways, I was distracted by its similarity to the
StreamZap remote, but eventually I came to understand that the Linux USB
driver could natively support this IR receiver as a HID device. With
the use of "evdev.o", Linux creates events on /dev/input/event*. (I'm
using debian unstable w/ 2.4.25.)
Now the kicker: this cyberlink device has two USB interfaces, naturally
mapping to two HID devices, ultimately leading to events appearing on
"/dev/input/event0" and "/dev/input/event1". This apparently does not
fit into the lircd architecture.. but I'm not sure why this wasn't so.
Wouldn't it have made sense to accept events simultaneously from both
UDP/IP and/or X-10 radio and/or a serial-based IR receiver?
With a bit of ugly hacking, I was able to clone hw_input.c into
multiplexing between multiple hardware descriptors, but it is hacky. I
would rather lircd read a configuration file for its expected hardware
driver(s) and e.g. network authorization keys to populate a linked list
of "struct hardware".
I've placed the patch at:
You'd apply the patch to a fresh cvs checkout and configure with
"--with-driver=multi". When using the "hotplug" package, the system
incorrectly identified this these HIDDEV devices as "usb keyboard" and
"usb mouse" devices. I was able to circumvent this interpretation by
removing the mouse and keyboard kernel modules from /lib/modules/*. I
had to modprobe hiddev and evdev on the machine where I am not using
Any thoughts or common experiences?
James Jurach "muaddib@..." wrote:
> "/dev/input/event0" and "/dev/input/event1". This apparently does not
> fit into the lircd architecture.. but I'm not sure why this wasn't so.
> Wouldn't it have made sense to accept events simultaneously from both
> UDP/IP and/or X-10 radio and/or a serial-based IR receiver?
> Any thoughts or common experiences?
You can run multiple instances of lircd and let them talk to each other
with --listen and --connect.
Multiplexing from multiple devices might be easy for /dev/input like
devices, but the compexity of reading two separate streams of raw CIR
data is nothing I would like to handle in one single process.