hid_xpadneo not loaded after install+reboot

[l0b0]

Version of xpadneo

xpadneo-dkms-git 0.9.r36.gb827510-1

Severity / Impact

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

Describe the bug

After installing the very latest version on Arch Linux and rebooting the hid_xpadneo kernel module is not loaded.

Steps to Reproduce

1. Install xpadneo-dkms-git on an up-to-date Arch Linux OS with stock kernel.
2. Reboot

Expected behavior

The kernel module should be loaded after rebooting.

System information

# uname -a
Linux big 5.11.4-arch1-1 #1 SMP PREEMPT Sun, 07 Mar 2021 18:00:49 +0000 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

A possibly unrelated module called just "xpad" is loaded:

$ lsmod | grep xpad
xpad                   45056  0
ff_memless             20480  1 xpad

Additional context

sudo modprobe hid-xpadneo loads the module successfully. But even after that the path /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor does not exist. The closest I can get is this:

$ ls /sys/module/hid_xpadneo/drivers/hid:xpadneo/
bind  module  new_id  uevent  unbind

[kakra]

Did the udev rules install? According to the pkg build, they should be in /usr/lib/udev/rules.d.

[l0b0]

Looks like it:

$ find /usr/lib/udev/rules.d -iname '*xpad*'
/usr/lib/udev/rules.d/98-xpadneo.rules
$ cat /usr/lib/udev/rules.d/98-xpadneo.rules
ACTION=="add", KERNEL=="0005:045E:02FD.*|0005:045E:02E0.*|0005:045E:0B05.*|0005:045E:0B13.*", SUBSYSTEM=="hid", DRIVER!="xpadneo", ATTR{driver/unbind}="%k", ATTR{[drivers/hid:xpadneo]bind}="%k"
ACTION=="add|change", DRIVERS=="xpadneo", SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="1", TAG+="uaccess", MODE="0664"

[kakra]

There should also be a file modprobe.d/xpadneo.conf, usually it's installed in /etc but maybe in /usr/lib.

[l0b0]

Yep:

$ cat /etc/modprobe.d/xpadneo.conf
alias hid:b0005g*v0000045Ep000002E0 hid_xpadneo
alias hid:b0005g*v0000045Ep000002FD hid_xpadneo
alias hid:b0005g*v0000045Ep00000B05 hid_xpadneo
alias hid:b0005g*v0000045Ep00000B13 hid_xpadneo

[kakra]

Then it should just work when you connect the controller via Bluetooth. The module won't auto-load at boot. This is triggered by the module aliases and the udev rules. If it doesn't work, couldn't you start from a fresh reboot, run sudo udevadm monitor and then connect the controller? Maybe we can find the problem if we see what udev does (or doesn't do)...

[D33M0N]

Sounds awfully familiar to the issue I had. Ended up blacklisting hid_microsoft.

[l0b0]

You're right, I think this ended up being an X-Y problem: I tried a bunch of different things to connect the controller at all, and when I couldn't I reported this as a likely culprit. Now that I've actually connected the controller and rebooted it does indeed connect automatically after powering on, buzz as expected, and lsmod shows hid_xpadneo as loaded. Thank you for your patience!