search

nickbclifford / gkeybind

A Linux utility for binding custom behavior to Logitech keyboards.
GNU General Public License v3.0
19 stars 0 forks source link

G910 - Unhandled exception: feature not found on device (Keyleds::Error) #1

Closed frostworx closed 3 years ago

frostworx commented 3 years ago

First thanks for this promising project! I have a G910 with gkeys working very fine with g910-gkeys on my Arch Linux system, but I'd prefer to not use python for the gkeys if possible. I tried both gkeybind-0.1.1 and gkeybind-0.1.2 from AUR, but unfortunately the binary exits with the error:

Unhandled exception: feature not found on device (Keyleds::Error) When built with debug flags I get this trace from gdb:

Unhandled exception: feature not found on device (Keyleds::Error)
  from lib/keyleds/src/device.cr:113:5 in 'gkeys_count'
  from src/daemon.cr:46:31 in 'initialize'
  from src/daemon.cr:34:3 in 'new'
  from src/gkeybind.cr:33:10 in '__crystal_main'
  from /usr/lib/crystal/crystal/main.cr:110:5 in 'main_user_code'
  from /usr/lib/crystal/crystal/main.cr:96:7 in 'main'
  from /usr/lib/crystal/crystal/main.cr:119:3 in 'main'
  from __libc_start_main
  from _start
  from ???

Edit: directly setting device_path: /dev/input/by-id/usb-Logitech_Gaming_Keyboard_G910_106F385D3833-event-kbd in /etc/gkeybind.yml didn't fix this.

nickbclifford commented 3 years ago

Very interesting, I've never seen this issue come up before. Thank you very much for bringing it to my attention!

Would you mind running the following script for me and posting the output?

#!/bin/bash

for h in /dev/hidraw*
do
    cat /sys/class/hidraw/${h:5}/device/uevent
    echo
done
frostworx commented 3 years ago

Thank you for the quick support! The output of the above script is:

DRIVER=hid-generic
HID_ID=0003:00002516:0000014D
HID_NAME=Cooler Master Technology Inc. ARES
HID_PHYS=usb-0000:0c:00.2-2/input1
HID_UNIQ=
MODALIAS=hid:b0003g0001v00002516p0000014D

DRIVER=hid-generic
HID_ID=0003:00000B05:000018F3
HID_NAME=AsusTek Computer Inc. AURA LED Controller
HID_PHYS=usb-0000:07:00.3-4/input2
HID_UNIQ=9876543210
MODALIAS=hid:b0003g0001v00000B05p000018F3

DRIVER=hid-generic
HID_ID=0003:00002516:0000014D
HID_NAME=Cooler Master Technology Inc. ARES
HID_PHYS=usb-0000:0c:00.2-2/input2
HID_UNIQ=
MODALIAS=hid:b0003g0001v00002516p0000014D

DRIVER=hid-generic
HID_ID=0003:00002516:0000014D
HID_NAME=Cooler Master Technology Inc. ARES
HID_PHYS=usb-0000:0c:00.2-2/input0
HID_UNIQ=
MODALIAS=hid:b0003g0001v00002516p0000014D

DRIVER=corsair-psu
HID_ID=0003:00001B1C:00001C0C
HID_NAME=                                                
HID_PHYS=usb-0000:07:00.3-5/input0
HID_UNIQ=
MODALIAS=hid:b0003g0001v00001B1Cp00001C0C

DRIVER=hid-generic
HID_ID=0003:0000046D:0000C335
HID_NAME=Logitech Gaming Keyboard G910
HID_PHYS=usb-0000:07:00.1-4.3/input0
HID_UNIQ=106F385D3833
MODALIAS=hid:b0003g0001v0000046Dp0000C335

DRIVER=hid-generic
HID_ID=0003:0000046D:0000C07E
HID_NAME=Logitech Gaming Mouse G402
HID_PHYS=usb-0000:07:00.1-4.4.3/input0
HID_UNIQ=499345623133
MODALIAS=hid:b0003g0001v0000046Dp0000C07E

DRIVER=hid-generic
HID_ID=0003:0000046D:0000C07E
HID_NAME=Logitech Gaming Mouse G402
HID_PHYS=usb-0000:07:00.1-4.4.3/input1
HID_UNIQ=499345623133
MODALIAS=hid:b0003g0001v0000046Dp0000C07E
nickbclifford commented 3 years ago

Can you try adding device_path: /dev/hidraw5 to your config? The path needs to point to a hidraw node, not a /dev/input node.

frostworx commented 3 years ago

Ah ic, sorry haven't checked it too closely apparently. With device_path: /dev/hidraw5 in the config, the error is identical though.

nickbclifford commented 3 years ago

Strange, does specifying any of the /dev/hidraw paths change the error at all?

frostworx commented 3 years ago

No, the error is always the same, where strace clearly shows that the device_path is read from the config.

What might be intereresting is that when using hidraw5 it also opens hidraw4 and hidraw8 afterwards.

...
201968 06:35:44 newfstatat(8, "", {st_mode=S_IFDIR|0755, st_size=4740, ...}, AT_EMPTY_PATH) = 0
201968 06:35:44 openat(AT_FDCWD, "/dev/hidraw5", O_RDWR) = 8
201968 06:35:44 openat(AT_FDCWD, "/dev/hidraw4", O_RDWR) = 8
201968 06:35:44 openat(AT_FDCWD, "/dev/hidraw8", O_RDWR) = 8
201968 06:35:44 readlink("/proc", 0x7ffe128bbd30, 1023) = -1 EINVAL (Das Argument ist ungültig)
...

and when not defining device_path at all hidraw5 isn't touched:

...
343782 06:42:27 newfstatat(8, "", {st_mode=S_IFDIR|0755, st_size=4740, ...}, AT_EMPTY_PATH) = 0
343782 06:42:27 openat(AT_FDCWD, "/dev/hidraw4", O_RDWR) = 8
343782 06:42:27 openat(AT_FDCWD, "/dev/hidraw4", O_RDWR) = 8
343782 06:42:27 openat(AT_FDCWD, "/dev/hidraw8", O_RDWR) = 8
343782 06:42:27 readlink("/proc", 0x7ffd69171690, 1023) = -1 EINVAL (Das Argument ist ungültig)
...
nickbclifford commented 3 years ago

What does keyledsctl info return?

frostworx commented 3 years ago

good catch - looks like it only sees my mouse:

$ keyledsctl info 
Name:           G402 Hyperion Fury FPS Gaming Mouse
Type:           mouse
Model:          000000000000
Serial:         00000000
Firmware[0000]: application U   v190.3.20
Firmware[0000]: bootloader BOT v115.0.5
Firmware[0000]: hardware HW  v100.0.0
Features:       [0001, 0003, 0005, 00c1, 1300, 1801, 1802, 1850, 18a1, 1e00, 1eb0, 2201, 2400, 8060, 8100, 8110]
Known features: feature version name dfu-control reportrate
Report rates:   [1ms] 2ms 4ms 8ms
frostworx commented 3 years ago

I never used keyleds before, because I don't care about the leds (WASD is hilighted and that's it). Looks like the bug is in keyleds and not in gkeybind and as the gkeys should be independent of the leds, it might be a good idea to make the led support in gkeybind optional (which would safe you some time for supporting issues which are not even your bug :)) Looks like they have some open issues which might be related. I'll look around if I find something useful later and report back.

frostworx commented 3 years ago

Yay, success:

I'd say it's time to uninstall at least g910-led and clean up some configs here. Thanks for your friendly help again and keep up the good work!

(If you do not want to test anything else, I'd close this issue here)

Edit: Everything works fine now (device_path needs to be set manually though). Looks like you woke my interest in keyboard leds. Thanks for pointing me to keyleds, seems to be a great software! (I even already starred the project, and forgot it again - getting old)

nickbclifford commented 3 years ago

Glad you could figure it out!

One of the known issues with g910-gkeys is that it essentially prevents any other programs from accessing the keyboard, so I suspect the issue may have been that despite the service being disabled, the daemon was still running.

gkeybind itself should not require keyledsd to be active (I've personally test it with just g910-led and it works fine), so would you mind trying it without that?

frostworx commented 3 years ago

I can confirm that gkeybind works fine without keyledsd running (I like it though, so will keep both ;)) but I explicitly checked before that g910-gkeys was no longer running! In fact, I still get the same error as above when device_path is not defined in /etc/gkeybind.yml (g910-gkeys is already uninstalled!), so the autodetection of my keyboard seems to be broken. I can easily live with "hardcoding" /dev/hidraw6 as device_path, but if you want to fix this, I'd be glad to help. (I'm pretty busy with my own project, but when I find the time I'll try to find the issue on my own as well)

frostworx commented 3 years ago

Similar as mentioned in https://github.com/nickbclifford/gkeybind/issues/1#issuecomment-820091245 the autodetection seems to use /dev/hidraw4 (which is my 1b1c:1c0c Corsair RM850i Power Supply) and then /dev/hidraw8 (046d:c07e Logitech, Inc. G402 Gaming Mouse) and does not even try /dev/hidraw6 (046d:c335 Logitech, Inc. G910 Orion Spectrum Mechanical Keyboard). No idea if this is important, but unlike as in above test, strace only shows one openat(AT_FDCWD, "/dev/hidraw4", O_RDWR) = 8now though and not two.

nickbclifford commented 3 years ago

I'll close this for now, but in the future I'll work on making the auto detection a bit smarter. Thanks for all the useful information!

frostworx commented 3 years ago

Thanks, I can confirm that autodetection works fine with gkeybind-0.1.3!