Hi all, I've been struggling with an odd udev problem. Any udev experts
on here?
Some background: My 13-year-old HTPC finally kicked the bucket. After
looking around, stock levels of PC parts around here are close to
nonexistant. I had a newer donor board/ram/cpu around that's 5-7 years
old. I have set up gentoo from scratch on this device (not using any old
stage4-esque backups.)
This HTPC case has an iMon device:
Bus 001 Device 003: ID 15c2:0038 SoundGraph Inc. GD01 MX LCD Display/IR
Receiver
It has worked well over the last 13 years but it has had problems with
its driver early on. I tried to recover the SSD that was from the dead
PC and it worked exactly twice (the third time I tried to get some
configs from it the SSD failed completely.)
It has a bit of a strange setup compared to other IR devices: it creates
two separate input devices. During boot, udev used to automatically
create a third device (an infrared device) that chains the two separate
devices together so the kernel IR can receive all remote events.
The problem I'm having is this: When booting, udev triggers the events
from the kernel and sets up the two devices:
# ls -l /dev/input/by-id
total 0
lrwxrwxrwx 1 root root 10 Aug 23 12:44 usb-15c2_0038-event-mouse ->
../event10
lrwxrwxrwx 1 root root 9 Aug 23 12:44 usb-15c2_0038-mouse -> ../mouse1
The kernel IR sees this as well:
# ir-keytable
Found /sys/class/rc/rc0/ with:
Name: iMON Remote (15c2:0038)
Driver: imon
Default keymap: rc-imon-pad
Input device: /dev/input/event10
LIRC device: /dev/lirc0
Supported kernel protocols: rc-6 imon
Enabled kernel protocols: imon
bus: 3, vendor/product: 15c2:0038, version: 0x0001
Repeat delay = 500 ms, repeat period = 125 ms
The problem is, this is missing the device that chains them together.
It's usually postpended with 'if00' or something similar to indicate
it's the infrared device.
On boot, it does not create a device for it under /dev/input/by-id like
it used to, so making lircd chain to it becomes difficult, especially if
you plug in another USB input device.
The kernel does indeed report the device to udev:
# dmesg | grep "iMON Remote"
[ 1.423629] rc rc0: iMON Remote (15c2:0038) as
/devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/rc/rc0
[ 1.423734] input: iMON Remote (15c2:0038) as
/devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/rc/rc0/input10
This IR receiver also supports multiple protocols and keymaps. As I use
Microsoft's remote keymaps, I do change this as a part of the
/etc/init.d/lircd startup (I load the keymap and change the receiver's
protocol before starting lircd.) Note that during testing I've removed
this for testing thinking that perhaps it was changing something in the
kernel - no dice, no new events or anything of the sort. It has nothing
to do with this problem.
Now here's the really strange part: If I drop to bash and issue `udevadm
trigger` it is created and appears correctly! This only happens
modifying the keymap/protocol (changing it to RC-6 compatibility):
# ls -l /dev/input/by-id/
total 0
lrwxrwxrwx 1 root root 10 Aug 23 13:03 usb-15c2_0038-event-if00 ->
../event10
lrwxrwxrwx 1 root root 9 Aug 23 13:03 usb-15c2_0038-event-mouse ->
../event9
lrwxrwxrwx 1 root root 9 Aug 23 13:03 usb-15c2_0038-mouse -> ../mouse0
As you can see, the infrared device is created.
This device should be created at boot time, regardless or not if it has
had the protocol changed and/or custom keymap applied.
I tried something quick in /etc/udev/rules.d/70-remote-control.rules:
KERNEL=="event*",ATTRS{name}="iMON Remote
(15c2:0038)",SYMLINK="input/remote"
But it does not work, even after reloading the rules and forcing the
trigger event.
I've kind of worked around this for now by adding a manual `udevadm
trigger` command in /etc/init.d/lircd after modifying the protocol and
keymap. However, there must be a way to make this work as intended with
an udev rule. The issue being that this device doesn't have anything
unique identifying it other than its name.
Anyone have any insight on how to solve this problem?
Dan
