acts weird with kernel 5.11

D33M0N commented 3 years ago

Version of xpadneo

v0.9-23-g6162dbc

Severity / Impact

[ ] I've read the docs and the bug reporting instructions
[ ] It does not work at all
[v] It used to work in a previous version
[ ] It mostly works but sometimes it doesn't
[ ] I found a work-around
[ ] I probably didn't figure it all out but it's too early to give up
[v] I don't know how to ...
[ ] It's too complicated
[ ] Fantastic work but ...
[ ] I can code and I want to help

Describe the bug

Initial connection rumble doesn't work. Also it does look like it might be using some wrong driver entirely... (and I don't know how to check which driver it uses). Also jstest-gtk shows some different device than I am used to see there ... with 15 buttons... might be due to wrong driver being used (although all the triggers and buttons on the physical device are triggering, just many buttons in jstest-gtk can't be triggered at all because they don't exist physically). Also it whines about missing signature and tainting kernel.

[   81.850787] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[   81.850792] Bluetooth: HIDP socket layer initialized
[   81.851186] hid-generic 0005:045E:02FD.0009: unknown main item tag 0x0
[   81.851248] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:045E:02FD.0009/input/input24
[   81.851300] input: Xbox Wireless Controller Consumer Control as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:045E:02FD.0009/input/input25
[   81.851331] hid-generic 0005:045E:02FD.0009: input,hidraw8: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on f8:e4:e3:00:d2:b8
[   82.003825] microsoft 0005:045E:02FD.0009: unknown main item tag 0x0
[   82.003900] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:045E:02FD.0009/input/input26
[   82.003984] microsoft 0005:045E:02FD.0009: input,hidraw8: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on f8:e4:e3:00:d2:b8
[   82.005617] hid_xpadneo: loading out-of-tree module taints kernel.
[   82.005645] hid_xpadneo: module verification failed: signature and/or required key missing - tainting kernel
[   82.006072] loaded hid-xpadneo v0.9-23-g6162dbc

Steps to Reproduce

press the controller X button to connect.

Expected behavior

Friendly connection rumble :-)

Screenshots/Gifs

System information

# uname -a
Linux Zen 5.11.1-1-MANJARO #1 SMP PREEMPT Tue Feb 23 14:26:47 UTC 2021 x86_64 GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
xxd: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor: No such file or directory
4294967295 0
$ l /sys/module/hid_xpadneo/drivers/hid\:xpadneo/
.-w------- 4.1k root  7 märts 15:34 bind
lrwxrwxrwx    0 root  7 märts 15:34 module -> ../../../../module/hid_xpadneo
.-w------- 4.1k root  7 märts 15:34 new_id
.-w------- 4.1k root  7 märts 15:12 uevent
.-w------- 4.1k root  7 märts 15:34 unbind

there aren't any numbered items at all.

Controller and Bluetooth information

xpadneo-lsusb.txt xpadneo-dmesg.txt xpadneo-btmon.txt

Additional context

kakra commented 3 years ago

Please cross-check that the module actually loaded by running lsmod. Also, you may need to sign the kernel module as described here: https://github.com/atar-axis/xpadneo/blob/master/docs/SECUREBOOT.md although I cannot help here as I'm running a kernel without module signing.

Looking at your dmesg log, this also looks like it first bound to hid-generic which then passed its control to hid-microsoft. So the gamepad is using the hid-microsoft driver but not xpadneo, thus no connection rumble, and thus the extra buttons which are dead.

Are you sure that the udev rules were installed and are working? Try udevadm monitor before switching the gamepad on to trace udev.

D33M0N commented 3 years ago

First tried temporary solution with modprobe -r hid_microsoft and instantly got xpadneo greeting rumble. Then created such file:

[deemon@Zen ~]$ cat /etc/modprobe.d/hid_microsoft.conf 
blacklist hid_microsoft

and now everything is good. :)

So instead of trying to tell my computer which driver to use by some hid matching numbers (which btw the offending kernel in-built driver also uses) I just disabled the offending driver.

kakra commented 3 years ago

Apparently, blacklisting hid-microsoft is not an option to ship with xpadneo as it would also disable all the other input devices that are covered by that driver. In some cases, hid-generic may take over but you would lose some quirk handling, lose some functionality, or such devices would just not work correctly anymore.

The udev rules are there to actually fix this and re-bind the device to hid-xpadneo. The hid matching numbers are only there to trigger loading of the module in the first place. So I still think the udev rules did not execute properly, udevadm monitor -p could tell us more.

atar-axis / xpadneo