Open QuickArgentum opened 4 months ago
evtest
andjstest
identify the controller and recognize its inputs correctly, howevergamepad-tool
, Steam settings, Retroarch and other software identifies it as an "Xbox 360 Controller" and does not react to any of its buttons or axis.
gamepad-tool
correctly sees the controller here, the "Xbox 360 Controller" is not meaningful, the only thing that counts is the features SDL detects.
Steam settings also works correctly here, although what you see here is only meaningful to Steam Input.
This covers all the usual input layers: joydev, evdev, SDL2 (Steam Input is actually SDL2 for Proton games, mapped via a virtual controller ID).
So I wonder what the difference is on your computer. It looks like the SDL2 layer is broken for you.
Please check the permissions of /dev/hidraw6
(taken from your dmesg, it changes every time you re-connect the controller), it should look like this:
getfacl /dev/hidraw6
# file: dev/hidraw6
# owner: root
# group: root
user::rw-
group::---
other::---
If it doesn't and assigns ownership to a different user or group, or assigns different read/write permissions, or adds ACLs for your desktop user, then your udev rules are broken because they ignore xpadneo's own rules. We've seen issues like that in the past with OpenRGB and QMK which happily assign write permissions to "other" for all hidraw devices, no matter if they manage it or don't.
If this is the case, try revoking any permissions from the device and test again (chmod a-rwx /dev/hidraw6
). If this fixes the problem for you, we need to figure out which udev rules are causing the problem.
OTOH, even if SDL2 uses the hidraw device, you should still see input although some buttons may be swapped or not working - but at least some buttons would work. Without hidraw, SDL2 uses the evdev device.
evdev
works (and for that matter, joydev
does too because the kernel builds it from the evdev device), so it's not a kernel issue and not an xpadneo issue, there's a problem in user-space on your system.
Chances are that gamepad-tool found some broken legacy mappings. You didn't post the terminal output of the tool, so I cannot say what the difference may be. Using xpadneo with SDL2 expects that no custom mapping has been defined, unfortunately, there have been many forum guides in the past which suggested exactly this without even asking if the controller works properly without any mappings.
Can you retry with the latest git version?
I stumbled over this since my "share" button doesn't seem to work as it should (doesn't take screenshots). Steam also claims it is a 360 Pad though i have the pad working. I ran getfacl and would get
# file: dev/hidraw6
# owner: root
# group: root
user::---
group::---
other::---
When checking the journal i get the message
linux (udev-worker)[15843]: 0005:045E:0B13.0007: /usr/lib/udev/rules.d/60-xpadneo.rules:1 Failed to write ATTR{/sys/devices/virtual/misc/uhid/0005:045E:0B13.0007/[drivers/hid:xpadneo]bind}>
I have ignored this for a long time since i thoughtt it wouldn't really matter. Is this still related?
I have ignored this for a long time since i thoughtt it wouldn't really matter. Is this still related?
This warning is okay if the kernel automatically binds the driver to xpadneo... Then binding won't work because the device is already bound to the correct driver.
If this shows a result, binding worked correctly:
ls -ald /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor
For "F12" to work, you need the Git version of xpadneo. The v0.9 branch reports the button in a way which is not compatible with Steam, and games will probably ignore it.
You can use evtest
to check if the button works and how it works. With v0.9.x, you will see a single device for your controller, and the button reports as a gaming button. With upcoming v0.10 (git master), evtest
will see three devices for your gamepad, one is a keyboard. Choose the keyboard device, press "Share", it should say "F12" in the log.
pre-v0.10 is mostly stable, you can use it, if your distribution offers a git version of xpadneo. But some more time is needed for code redesign and some feature integration (mouse mode, to use your controller on desktop from the couch). But you can already use the functions that are there.
Hello! I am facing the same issues. The only difference being that I run Arch and not Debian. How would I find out what is causing problems ?
I'm also an Arch Linux and since a couple months I seem to be getting wrong permissions on the hidraw file:
: ~; getfacl /dev/hidraw4
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw4
# owner: root
# group: root
user::---
user:waffle:rw-
group::---
mask::rw-
other::---
(hidraw4 taken from dmesg)
sudo chmod a-rwx /dev/hidraw4
indeed fixes the issue.
If this fixes the problem for you, we need to figure out which udev rules are causing the problem.
How would one do at?
@WaffleLapkin This may be caused by OpenRGB... Try uninstalling it and see if the issue persists. OpenRGB is one known software which overrides our udev rule fixing permissions. But this seems to be different from the previous comments, so you're likely seeing a different issue if driver binding works for you.
How would one do at?
Before connecting the controller, run udevadm monitor -p
, then connect the controller. You'll see which parameters get changed during the udev enum process. You should try it with and without the xpadneo module already loaded.
You can find more information about the udev rules and debugging here: https://github.com/atar-axis/xpadneo/issues/461
@kakra sadly those debugging suggestions did not help (I couldn't see anything suspicions). In the end I did find out that it was QMK's udevrules -- disabling those fixed the permission issue (sorry for spamming in an unrelated issue and thanks for help 💜 ).
Yeah, QMK is a known suspect. I actually thought they've fixed that meanwhile by looking at the device with a udev helper... I'd still be interested if we could find a way to override their rules for the devices we support.
I just checked with a fresh checkout of qmk, and the rules they suggest to copy still cause problems with the controller. If it helps here is the file they suggest to add:
/etc/udev/rules.d/50-qmk.rules
``` # Atmel DFU ### ATmega16U2 SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2fef", TAG+="uaccess" ### ATmega32U2 SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", TAG+="uaccess" ### ATmega16U4 SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff3", TAG+="uaccess" ### ATmega32U4 SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", TAG+="uaccess" ### AT90USB64 SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff9", TAG+="uaccess" ### AT90USB162 SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffa", TAG+="uaccess" ### AT90USB128 SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", TAG+="uaccess" # Input Club SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", ATTRS{idProduct}=="b007", TAG+="uaccess" # STM32duino SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", TAG+="uaccess" # STM32 DFU SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess" # BootloadHID SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", TAG+="uaccess" # USBAspLoader SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", TAG+="uaccess" # USBtinyISP SUBSYSTEMS=="usb", ATTRS{idVendor}=="1782", ATTRS{idProduct}=="0c9f", TAG+="uaccess" # ModemManager should ignore the following devices # Atmel SAM-BA (Massdrop) SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="6124", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" # Caterina (Pro Micro) ## pid.codes shared PID ### Keyboardio Atreus 2 Bootloader SUBSYSTEMS=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="2302", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ## Spark Fun Electronics ### Pro Micro 3V3/8MHz SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9203", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ### Pro Micro 5V/16MHz SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9205", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ### LilyPad 3V3/8MHz (and some Pro Micro clones) SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9207", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ## Pololu Electronics ### A-Star 32U4 SUBSYSTEMS=="usb", ATTRS{idVendor}=="1ffb", ATTRS{idProduct}=="0101", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ## Arduino SA ### Leonardo SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ### Micro SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0037", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ## Adafruit Industries LLC ### Feather 32U4 SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="000c", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ### ItsyBitsy 32U4 3V3/8MHz SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="000d", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ### ItsyBitsy 32U4 5V/16MHz SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="000e", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ## dog hunter AG ### Leonardo SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0036", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" ### Micro SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0037", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1" # hid_listen KERNEL=="hidraw*", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl" # hid bootloaders ## QMK HID SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2067", TAG+="uaccess" ## PJRC's HalfKay SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0478", TAG+="uaccess" # APM32 DFU SUBSYSTEMS=="usb", ATTRS{idVendor}=="314b", ATTRS{idProduct}=="0106", TAG+="uaccess" # GD32V DFU SUBSYSTEMS=="usb", ATTRS{idVendor}=="28e9", ATTRS{idProduct}=="0189", TAG+="uaccess" # WB32 DFU SUBSYSTEMS=="usb", ATTRS{idVendor}=="342d", ATTRS{idProduct}=="dfa0", TAG+="uaccess" ```
Maybe xpadneo could override them with more specific rules...
# hid_listen KERNEL=="hidraw*", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl"
Looks like this may be problematic because it doesn't check if the hidraw device is actually a supported device. It assigns the tag uaccess
(and I'm not sure what udev-acl
does), and this probably allows read/write access to your session for the device. Also, it assigns the plugdev
group to the device which should not be needed at all for session access: udev handles this via ACLs nowadays.
Our hidraw device is not compatible with SDL currently, see #286. Thus, we have a rule in place that assigns MODE:="0600"
(allowing only root to access the device, preventing later overrides).
Maybe, if changing our mode to 0000
, it could prevent any ACLs from working?
Monitoring the udev events should show if a previous rule also uses :=
for mode, thus preventing xpadneo from setting it the way we need it.
We could also try to use TAG-="uaccess
and/or TAG-="udev-acl"
to actually remove those tags again.
If you find a proper way around it that we can implement in our rules, let me know. I'm planning another 0.9 release (currently mostly to finalize documentation), it would be nice if we could deploy such a fix.
Version of xpadneo
0.9.5
Controller Model
Connection mode
Installed Software
Protocol Information
Please help us identify at which layer the problem can be found if you want to report mapping errors or if the controller fails to be detected:
evtest
is showing issues (describe the issues below)BTN_NORTH
andBTN_WEST
are intentionally swappedjstest
is showing issues (describe the issues below)gamepad-tool
is showing issues (post console output below)Please describe how it is failing below in the next sections.
Severity / Impact
Describe the Bug
Xbox Series X|S controller with updated firmware is connected via a Bluetooth adapter.
evtest
andjstest
identify the controller and recognize its inputs correctly, howevergamepad-tool
, Steam settings, Retroarch and other software identifies it as an "Xbox 360 Controller" and does not react to any of its buttons or axis. Steam Input is disabled for everything. In fact, the only game that works that I've tried is PICO-8Steps to Reproduce
Turn on, pair and connect an Xbox Wireless Controller (with up to date firmware) via a Bluetooth adapter. Launch a game or software which supports controllers.
Expected Behavior
Games and software which support controllers identify the controller as the proper model and/or at least recognize its inputs (so you can navigate the interface, play the game, etc.)
Would really appreciate any help, thank you
Screenshots / GIFs / Videos
System Information
Controller and Bluetooth Information
xpadneo-btmon.txt xpadneo-dmesg.txt xpadneo-lsusb.txt