Re: Brief report: QNAP TS-212P with linux-image-kirkwood 4.0.0-2

[JM <fijam@archlinux.us>]

On Fri, May 29, 2015 at 2:14 PM, JM <fijam@archlinux.us> 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