Xbox Series X|S controller recognized as 360 controller and no inputs detected in games #457
Comments
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 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 ( 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.
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? |
This causes bugs in some applications, seemingly Unity games, and maybe a few others. This commit introduces a new module parameter `enable_rolling_axis` defaulting to "disabled", essentially removing the axis from default installations. Enabling it will emit a deprecation warning. This is better solved in user-space. Scheduled for removal after v0.10. Maybe-affects: atar-axis#457 Maybe-affects: atar-axis#452 Fixes: atar-axis#385 Fixes: atar-axis#345 Fixes: atar-axis#334 Signed-off-by: Kai Krakow <kai@kaishome.de>
|
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. When checking the journal i get the message 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_descriptorFor "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 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: (hidraw4 taken from dmesg)
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. |
Before connecting the controller, run You can find more information about the udev rules and debugging here: #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:
|
Looks like this may be problematic because it doesn't check if the hidraw device is actually a supported device. It assigns the tag Our hidraw device is not compatible with SDL currently, see #286. Thus, we have a rule in place that assigns Maybe, if changing our mode to Monitoring the udev events should show if a previous rule also uses We could also try to use 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. |
kakra
added
0 | type: enhancement
|
I had the same issue as @WaffleLapkin with QMK on Arch Linux. I was able to resolve it with this udev rule in Setting |
|
Currently, a similar rule is at position 50. Maybe we just need to move it over to 70? |
|
I have this problem it shows up as a Xbox Series X Controller over USB but if I try to use it over bluetooth it shows up as a 360 controller and it also seems a little laggy |
|
USB: Bluetooth |
|
also I have inputs but the right stick is recognized as Axes 4 and its all so laggy Screencast_20241005_220124.mp4 |
|
I hope this will be fixed in V10 but if any of you have a clue on why this is happening over bluetooth for me I would appreciate the advice on how to fix it. for the record I'm running Arch Linux and I am using the dkms aur package. and my Bluetooth adapter is the |
|
The laggy stick probably comes from the Bluetooth chipset itself, and may be fixed by newer kernels and/or kernel firmware. Also ensure that you updated the Xbox controller to the latest firmware, you need to use a Windows or Xbox machine to do that. Also, the joystick control panel in KDE is usually very laggy. Please do not use the joystick test in KDE for testing the axis. This uses a very old kernel interface ( Also, the controller shows a Xbox360 controller because we emit an axis order and button mapping compatible with that exact model. Very early versions of xpadneo (5+ years ago) have shown that this makes the best compatibility with older SDL games, native Linux games, wine games, and applications which use joydev or evdev. Proton has later messed this up a little by using buggy controller mappings in SDL, but this has since been fixed and SDL detects all functions. Showing as Xbox360 controller doesn't mean that it has less functionality: Modern games will still see and support additional buttons if they actually can use such functionality. Also, we are not messing with the device name itself: It still sends the correct name. xpadneo just pretends to be a VID/PID for Xbox360 the same way Proton does it to provide the virtual Steam controller through Steam Input. If software shows the wrong name, it's because it looks at the PID instead of the device name. This really doesn't mean anything, it's purely cosmetic. The Xbox 360 order of axes is LX,LY,LT,RX,RY,RT (the left and right part is a "three axis joystick"). jsdev itself suggests LX,LY,RX,RY,LT,RT (left joystick, right joystick, triggers, two axes each) but that never worked that way with Xbox controllers and games actually know this (with a few exceptions like early Unity games). But since no modern game and no game running through Proton uses jsdev, you can ignore that. Calibration is also useless, don't try. Actually, the KDE control panel may mess things up if you do a calibration. Do not use it. Look at Here is an extensive list of notes I've taken: #286 - hoping that we can "fix" jsdev some day. But doing so proved futile because of Chrome. Here's a list of known and/or fixed issues for Bluetooth and compatibility: https://github.com/atar-axis/xpadneo/projects?query=is%3Aopen @OzzyHelix I'm not sure you are having the same problem. The original reporter said that there is no input at all, and it's most likely some sort of permission error, maybe due to other software messing with all input devices like OpenRGB or QMK. Your issue is that you just see one stick on a seemingly wrong axis? BTW: On my KDE system, the control panel is also laggy, and one axis of the right stick is stuck although it's fine in |
|
I didn't know why it was showing up as a 360 controller I assumed it was a bug and didn't do it for a reason sorry |
|
I also would never use the KDE control panel for calibration I just used it to confirm stuff is working |
|
I should have been using this site to test the controller it looks way better on here |
|
another problem is I don't seem to have haptics over Bluetooth. I will need to look into this. I don't want to clog up this issue is there a discord I can go to ask for help with these issues? |
|
I made the mistake of having xpad and xboxdrv installed so it didn't rumble because those drivers were loading |
Don't worry. I should probably add a hint about that to the docs. It's a question that comes up every so often again. |
Yes but depending on the browser, this can swap axes because it's using evdev to detect the button topology, then uses some hard-coded internal fixup tables to fix the differences between evdev and joydev, and in the end uses joydev to read the values. At least Chrome does this, and it's bad. I still, to this day, do not understand why Chrome does this in such a complicated way instead of solely go with evdev. |
The Discord link is in the README of the project front page. You're welcome. :-) BTW, do not clog that up so much, you can edit previous messages instead of adding a new one every few minutes. ;-) That's fine unless new replies were added. |
xpad only supports USB mode of the controller, it should not interfere. xpadneo only support Bluetooth aka HID mode (in theory we can support HID mode over USB but none of the known controllers uses HID via USB). Not sure about xboxdrv. |
I use Ablaze Floorp which is a fork of Firefox it has the benefit of not having a lot of the privacy problems newer versions of firefox has while still having a lot of the features I used in Firefox developer edition |
@bugraonal pointed out that they was able to bypass QMK messing with our hidraw permissions using another udev rule. We can probably combine the previous Steam Link fix with this change. Link: atar-axis#457 (comment) Maybe-fixes: atar-axis#457 Fixes: 5aee029 ("xpadneo, hidraw: Also work around SDL2 hidraw mode conflicts") Fixes: 2900363 ("xpadneo: Work around invalid mapping in Steam Link") Signed-off-by: Kai Krakow <kai@kaishome.de>
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:
evtestis showing issues (describe the issues below)BTN_NORTHandBTN_WESTare intentionally swappedjstestis showing issues (describe the issues below)gamepad-toolis 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.
evtestandjstestidentify 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-8
Steps 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
The text was updated successfully, but these errors were encountered: