[gentoo-user] udev and IR receiver problem

[gentoo-user] udev and IR receiver problem

[Daniel Frey]

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