On Fri, May 29, 2015 at 2:14 PM, JM <[email protected]> wrote: > * qcontrol service does not start. This appears to be due to the fact that > qcontrol expects a symlink "platform-gpio-keys-event" in > /dev/input/by-path, while with the 4.0 kernel it's called > "platform-gpio_keys-event" instead. As a workaround, adding the expected > symlink causes qcontrol to work correctly (warning: without qcontrol the > device is on a 5 minute watchdog, you can also interrupt it with "echo -n > g >/dev/ttyS1"). > > The qcontrol bug is still present in testing with the 4.0 kernel from unstable. It's a bit annoying as it requires to manually fix the symlink every reboot before watchdog kills the device. I don't see an obvious way to override it with udev rules, as qcontrol looks in 'by-path/'
# systemctl status qcontrold [snip] Jul 07 23:10:29 yukikaze qcontrol[1386]: qcontrol 0.5.4 daemon starting. Jul 07 23:10:29 yukikaze qcontrol[1386]: evdev: Error opening /dev/input/by-path/platform-gpio-keys-event: No such file or directory which is already static and created from the, well, kernel path that was at some point renamed from gpio-keys to gpio_keys: # ls -al /dev/input/by-path/platform-gpio_keys-event lrwxrwxrwx 1 root root 9 Jul 7 22:38 /dev/input/by-path/platform-gpio_keys-event -> ../event0 # udevadm info -q path -n /dev/input/event0 /devices/platform/gpio_keys/input/input0/event0 Should I file a bug for it? Against what, linux for renaming gpio-keys to gpio_keys or qcontrol for not catching up? Best regards, Jan
