1 |
Hi all, I've been struggling with an odd udev problem. Any udev experts |
2 |
on here? |
3 |
|
4 |
Some background: My 13-year-old HTPC finally kicked the bucket. After |
5 |
looking around, stock levels of PC parts around here are close to |
6 |
nonexistant. I had a newer donor board/ram/cpu around that's 5-7 years |
7 |
old. I have set up gentoo from scratch on this device (not using any old |
8 |
stage4-esque backups.) |
9 |
|
10 |
This HTPC case has an iMon device: |
11 |
|
12 |
Bus 001 Device 003: ID 15c2:0038 SoundGraph Inc. GD01 MX LCD Display/IR |
13 |
Receiver |
14 |
|
15 |
It has worked well over the last 13 years but it has had problems with |
16 |
its driver early on. I tried to recover the SSD that was from the dead |
17 |
PC and it worked exactly twice (the third time I tried to get some |
18 |
configs from it the SSD failed completely.) |
19 |
|
20 |
It has a bit of a strange setup compared to other IR devices: it creates |
21 |
two separate input devices. During boot, udev used to automatically |
22 |
create a third device (an infrared device) that chains the two separate |
23 |
devices together so the kernel IR can receive all remote events. |
24 |
|
25 |
The problem I'm having is this: When booting, udev triggers the events |
26 |
from the kernel and sets up the two devices: |
27 |
|
28 |
# ls -l /dev/input/by-id |
29 |
total 0 |
30 |
lrwxrwxrwx 1 root root 10 Aug 23 12:44 usb-15c2_0038-event-mouse -> |
31 |
../event10 |
32 |
lrwxrwxrwx 1 root root 9 Aug 23 12:44 usb-15c2_0038-mouse -> ../mouse1 |
33 |
|
34 |
The kernel IR sees this as well: |
35 |
|
36 |
# ir-keytable |
37 |
Found /sys/class/rc/rc0/ with: |
38 |
Name: iMON Remote (15c2:0038) |
39 |
Driver: imon |
40 |
Default keymap: rc-imon-pad |
41 |
Input device: /dev/input/event10 |
42 |
LIRC device: /dev/lirc0 |
43 |
Supported kernel protocols: rc-6 imon |
44 |
Enabled kernel protocols: imon |
45 |
bus: 3, vendor/product: 15c2:0038, version: 0x0001 |
46 |
Repeat delay = 500 ms, repeat period = 125 ms |
47 |
|
48 |
The problem is, this is missing the device that chains them together. |
49 |
It's usually postpended with 'if00' or something similar to indicate |
50 |
it's the infrared device. |
51 |
|
52 |
On boot, it does not create a device for it under /dev/input/by-id like |
53 |
it used to, so making lircd chain to it becomes difficult, especially if |
54 |
you plug in another USB input device. |
55 |
|
56 |
The kernel does indeed report the device to udev: |
57 |
|
58 |
# dmesg | grep "iMON Remote" |
59 |
[ 1.423629] rc rc0: iMON Remote (15c2:0038) as |
60 |
/devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/rc/rc0 |
61 |
[ 1.423734] input: iMON Remote (15c2:0038) as |
62 |
/devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/rc/rc0/input10 |
63 |
|
64 |
|
65 |
This IR receiver also supports multiple protocols and keymaps. As I use |
66 |
Microsoft's remote keymaps, I do change this as a part of the |
67 |
/etc/init.d/lircd startup (I load the keymap and change the receiver's |
68 |
protocol before starting lircd.) Note that during testing I've removed |
69 |
this for testing thinking that perhaps it was changing something in the |
70 |
kernel - no dice, no new events or anything of the sort. It has nothing |
71 |
to do with this problem. |
72 |
|
73 |
Now here's the really strange part: If I drop to bash and issue `udevadm |
74 |
trigger` it is created and appears correctly! This only happens |
75 |
modifying the keymap/protocol (changing it to RC-6 compatibility): |
76 |
|
77 |
# ls -l /dev/input/by-id/ |
78 |
total 0 |
79 |
lrwxrwxrwx 1 root root 10 Aug 23 13:03 usb-15c2_0038-event-if00 -> |
80 |
../event10 |
81 |
lrwxrwxrwx 1 root root 9 Aug 23 13:03 usb-15c2_0038-event-mouse -> |
82 |
../event9 |
83 |
lrwxrwxrwx 1 root root 9 Aug 23 13:03 usb-15c2_0038-mouse -> ../mouse0 |
84 |
|
85 |
As you can see, the infrared device is created. |
86 |
|
87 |
This device should be created at boot time, regardless or not if it has |
88 |
had the protocol changed and/or custom keymap applied. |
89 |
|
90 |
I tried something quick in /etc/udev/rules.d/70-remote-control.rules: |
91 |
|
92 |
KERNEL=="event*",ATTRS{name}="iMON Remote |
93 |
(15c2:0038)",SYMLINK="input/remote" |
94 |
|
95 |
But it does not work, even after reloading the rules and forcing the |
96 |
trigger event. |
97 |
|
98 |
I've kind of worked around this for now by adding a manual `udevadm |
99 |
trigger` command in /etc/init.d/lircd after modifying the protocol and |
100 |
keymap. However, there must be a way to make this work as intended with |
101 |
an udev rule. The issue being that this device doesn't have anything |
102 |
unique identifying it other than its name. |
103 |
|
104 |
Anyone have any insight on how to solve this problem? |
105 |
|
106 |
Dan |