-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xbox Elite Series 2 back paddles not configurable with wired connection #8463
Comments
Xbox Elite 2 does not yet have support in Linux for the back paddles via its built-in driver |
To whom it may concern... I've built out a new PR for paddle support in the The faster we can test this and work out the kinks, the sooner this PR can make its way upstream and someday make paddles in Linux's Steam Input a reality! |
I have the same issue with steam on windows, so it's not os related, maybe they messed something up in last upgrade... |
@Gurkoel I'm not really sure if these have the same root cause, since Elite controller paddle support has never worked on Linux. This is a known limitation of the Linux-included driver, whereas the Windows Steam client actually installs its own custom driver. If it's not working for you, you should try troubleshooting this custom driver. First, make sure that advanced XB controller support is enabled in settings (this installs the driver) -- try toggling it if you already had it enabled. If the issue still persists, try restarting your machine to hopefully reload the driver. |
Tried to do some debugging, I used the paroj/xpad repo and have the module loaded (@chaorace, thanks for the work on it). I can use jstest and see the paddles triggering just fine. In Windows, I can see the paddles and rebind them happily. I have the "Xbox Configuration Support" set in Controller Settings, and I am on the older 4.8.xxx firmware. I've been trying to figure out how to continue debugging in Steam, since it sees it as an Elite controller, it just doesn't see the paddles in Linux. Is there something I can do to continue debugging Steam's view of my controller? I did find the
|
@Esras I believe this is now in Valve's hands. The buttons are exposed on the driver-level, but Steam Input doesn't yet know to listen for them. Even if you tinker with the SDL vdfs in Steam to have knowledge of the paddle inputs, the binding UI still won't make the paddles available for binding on Linux. This leads me to think that there must be some kind of basic OS check happening in the Steam client which can probably now be changed to instead gate behind a kernel version check once the next kernel version drops. The supporting commit is still in the next branch at the moment: e23c69e3324892f7420686b3aaa0403df6cf152c. |
probably SDL needs an update too. See https://github.com/gabomdq/SDL_GameControllerDB you can generate the according entry by building SDL from source and using edit: forget this - steam is supposed to generate this by itself |
@paroj, No, you're right! I did a controller map from building SDL tests from source (current master,
Dropping that in place in the
But, more importantly, it let me bind things in the Controller config. I haven't tested it out with too many things (the first thing I tried was not great with the combo of keyboard and controller bindings), but Steam totally translated the buttons correctly. My only request at this point would be for there to just be more arbitrary "controller buttons" that could be bound to things, rather than having stuff think it's a specific key, but I think that's asking to rewrite 40+ years of input history. |
Oh! I get what's going on now... I was using the stable Steam client when I tested the SDL thing. I switched over to the beta client just now and it's now showing the paddles after manually setting the SDL config. Huzzah! For those looking for the quick solution, follow these steps:
Using the |
FWIW: I don't know if the variable method works on the flatpak version of Steam. Also, the given config string is for the Elite 2 controller. It'd be cool if someone with the OG Elite controller could generate and share their controller map string as well. |
@chaorace I'm stoked about this so thanks for taking the time to open the PRs to get this in. Is there anything I can help with? |
@maverick1872 In terms of help, the last thing we really need is for the Linux Steam client to generate SDL game controller configs that include the new buttons exposed by the new xpad change on the Elite & Elite 2 controllers. It's not currently clear to me how we can achieve this, however. It's possible this either needs to be resolved in an upstream dependency or in Steam itself. IMO, it's likely that Steam is just using the community SDL_GameControllerDB project, which would mean that a PR needs to be submitted there updating the Elite controller entries to include paddles. (Pinging @kisak-valve for confirmation if this is the right route to take) Assuming that's how this works, we should update While I'd like to get bluetooth working as well, I don't believe that editing the Elite bluetooth bindings will have any tangible effect because the only bluetooth driver that supports paddles -- xpadneo -- always reports Elite controllers as GUID |
One more note regarding bluetooth paddles via xpadneo since it may turn up in Google searches: Just like with the wired SDL mapping, you can make paddles work by manually setting a variable when launching steam. This specifically worked for me with an Elite 2 controller on bluetooth (haven't tested if I got the exact paddle order right yet, though): Keep in mind that this workaround will probably cause normal Xbox One controllers to also think that they have paddle buttons when connected via Bluetooth, which is a consequence of the issue noted in the previous comment. |
Hello @chaorace, I don't have insight into the internals, but I'd expect the right course of action here is to see if the upstream SDL project can be made to work as intended, and Steam should pick up the changes at some point as a downstream project. If xpadneo needs to be more accurate with the controller ID, then that's something to discuss with that project's maintainer(s). |
It would be nice to have Bluetooth support, but I don't know for sure where changes have to be made. xpad driver is just for when you are using cable. |
Understood. Who can we reach out to for more input? (Pun intended). Even if we know it's an upstream project, it's not necessarily guaranteed to be SDL_GameControllerDB (which is not included with SDL library by default and is, as mentioned, a community project). Since the Steam client is closed source, we're completely blind on this and need to rely on an insider to be sure we're not wasting effort on updating the wrong library.
That would be kakra, who has been pinged. IIRC, there's a very good reason for the controller ID thing that may be impossible to work around at the driver layer. This is why I brought up the possibility of a bespoke workaround at the application layer, even if only to understand the cost/benefit. FWIW: I do believe there is already precedent for Steam Input doing such bespoke workarounds for the generic bluetooth controller driver. |
Upstream SDL: https://github.com/libsdl-org/SDL |
Thanks Kisak. I'm going to assume that means you're not currently touching the bindings for the Elite controllers in a custom "gameccontrollerdb.txt" file and that you're using the bindings 100% as-is from the stock SDL controller DB. In that case... @maverick1872 if you're interested in contributing, the place to make the change is roughly here in the SDL project. I believe both the OG Elite and Elite 2 will require new lines for their respective wired GUIDs. These should basically be the same as their respective bluetooth versions (The ones starting with |
@chaorace The general problem with SDL is that it re-implements kernel driver logic in user-space but using fixed hardware description tables (controllerdb) instead of HID descriptors (which it could easily obtain at least from xpadneo). I wish SDL would prefer HID descriptors if available. This also has the downside of people submitted SDL button layouts before paddles were even a thing in SDL - and we ended up with GUIDs that are missing those paddles. The current implementation of using one single fixed GUID is a work-around for early SDL versions. I'm in the process of redoing that but lacking some time (xpadneo HID reports aren't compatible with SDL expectations, xpadneo GUIDs should not be submitted to SDL controllerdb at all). The best course of action is probably submitting updated GUIDs with paddles to SDL - once the kernel implementation settled so we don't end up with incompatible bitmaps across different models and devices. As written before, I'd prefer if SDL would make HID descriptors a first class citizen and only fall back to controllerdb if it is not a HID device. One other thing is that SDL doesn't support all the proper device fixups we have, e.g., in xpadneo (like the rumble crash adapted for newer firmwares). But things are probably like things are and it's too late to change anything or hope anything. It's just duplicate efforts, and things are partially incompatible between what SDL expects and what low-level joydev expects so we always end up with fitting either the one or the other. BTW: Chrome does a similar thing as SDL but in a completely messed up way. Currently, the best way is to disable Steam Input when using xpadneo: The wine layer of Proton with its new HID implementation should properly support the paddles of xpadneo. Of course, this will disable the remapping feature of Steam. Also, xpadneo is incompatible with the overlay hotkey feature of Steam currently as we don't expose the guide button as a gamepad button (we rather use it as a shift button for mode switching). But I'm planning to change a lot of details during v0.10 and v0.11, so don't put too much effort in adjusting any application layer to xpadneo. Just disable Steam Input, or disable hidraw access permissions, and don't add controllerdb entries - the latter one will only add to the mess that's been there since the beginning around 5 years ago. Take note that, when wired, these controllers are not HID devices. Using the controller wired will completely remove xpadneo from the supply chain as xpadneo is a HID-only driver (it's not a Bluetooth driver). |
Good to know. For now I suppose we'll stick to working on making SDL play nice with the paddles on a wired connection via xpad. It's definitely worth addressing SDL someday down the line once you revisit xpadneo's GUID reporting, though. That's not a pressing concern in the meantime, of course, since most people who really want wireless paddle binding in Steam Input can get by through manually tweaking the Good point regarding delaying the SDL PR until those xpad changes are in a numbered kernel release, by the way! I was probably being a little overeager to suggest otherwise... though I don't see any harm in submitting a draft PR in the meantime, just to get the gears turning. |
Switching to PID 0x028E seems to successfully evade the mappings in Proton, and thus probably SDL. Proton seems to do the same for Steam virtual controllers, and it seems to also fix gamepad handling in Chrome. Maybe-fixes: atar-axis#379 Maybe-affects: atar-axis#385 Maybe-affects: ValveSoftware/steam-for-linux#8463 (comment) See-also: atar-axis#283 See-also: ValveSoftware/wine@7ea1cc2 Fixes: atar-axis#373 Signed-off-by: Kai Krakow <kai@kaishome.de>
Switching to PID 0x028E seems to successfully evade the mappings in Proton, and thus probably SDL. Proton seems to do the same for Steam virtual controllers, and it seems to also fix gamepad handling in Chrome. Maybe-fixes: atar-axis#379 Maybe-affects: atar-axis#385 Maybe-affects: ValveSoftware/steam-for-linux#8463 (comment) See-also: atar-axis#283 See-also: ValveSoftware/wine@7ea1cc2 Fixes: atar-axis#373 Signed-off-by: Kai Krakow <kai@kaishome.de>
Switching to PID 0x028E seems to successfully evade the mappings in Proton, and thus probably SDL. Proton seems to do the same for Steam virtual controllers, and it seems to also fix gamepad handling in Chrome. Maybe-fixes: #379 Maybe-affects: #385 Maybe-affects: ValveSoftware/steam-for-linux#8463 (comment) See-also: #283 See-also: ValveSoftware/wine@7ea1cc2 Fixes: #373 Signed-off-by: Kai Krakow <kai@kaishome.de>
In big picture mode I seem to be able to map all four paddles to any other controller button, including use of gestures such as double-press, long press, chords, etc. Not sure about outside of big picture, tbh I never use Steam's browser-like windowed mode and have no idea where the Steam Input config is in there (if it even is there).
Steam info;
This is on an Xbox Elite Series 2 which was delivered this moring. No additional config beyond turning it on and pairing via bluetooth (settings UI, uses After confirming I can map P1-4, I installed xpadneo by atar-axis as SkyrimSE wasn't picking up my trigger button presses (may be possible to solve this with just Steam Input, I didn't bother to check as I've read a lot of good things about xpadneo beyond just trigger button fixes). Would be really nice if P1-4 were exposed as generic other buttons like with keyboard keys, but I don't know enough about game dev to know if that's possible (I'm just a web dev). Could be done by lying to the computer about the nature of the device to map P1-4 to F20-24 at the driver level? I'm not smart enough to tinker with that. |
Your system information
Please describe your issue in as much detail as possible:
I cannot map back paddles on my Xbox Elite Series 2 controller via Steam Input when using a direct USB connection, even though Steam is correctly detecting the controller type.
(with Bluetooth, the controller is merely recognized as a generic 360 gamepad)
Something seems to be missing from the Linux client's Steam Input driver, because the same computer booted to the same OS using the same Steam client does allow binding the back paddles when connecting the controller via Steam Link for Android.
Note the difference between the below screen captures
Direct USB connection to the computer:
Connected via Steam Link for Android, direct USB connection to the phone:
Steps for reproducing this issue:
The text was updated successfully, but these errors were encountered: