Comments (12)
@smcv, any ideas?
from sdl.
I don't have a Steam Deck, so I am not the right person to debug this.
The most relevant change in 2.30.4 is likely to be 361cae0, which fixes a known regression since 91f8b4d (between 2.28.x and the 2.29.1 prerelease), ValveSoftware/steam-for-linux#9571. My understanding of the regression is that when using Steam Input, Steam creates a virtual Xbox 360 controller (device ID 28de:11ff) corresponding to each physical controller that is being managed by Steam Input, and then instructs SDL and Proton (Steam's version of Wine) to ignore the physical controllers and read from the virtual controllers instead. Steam assigns controller names that encode the "slot" number, based on its UI for reordering controllers, and Proton parses the name to figure out how to assign the virtual controllers to the expected XInput slot.
This particularly matters for local multiplayer games that only support the 4 controllers in the first 4 XInput slots: if players have connected 4 external USB/Bluetooth gamepads (Xbox, Playstation, Switch) and do not want any player to be using the Deck's built-in gamepad, then they need to tell Steam to reorder the controllers so that the Deck's built-in gamepad is in slot 5 or later.
from sdl.
the Steam Deck gamepad
With SDL 2.30.3, were you using the physical gamepad device directly; or were you running Steam in the background and letting it map the gamepad to a Steam Input virtual gamepad, and then having KDE System Settings talk to that?
If you have Steam installed (it doesn't need to be running for this, only installed), then running its diagnostic tool is likely to be helpful:
~/.steam/root/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-input-monitor --once
This enumerates all the raw HID and evdev input devices that SDL could potentially access, together with the information that SDL would use to identify them. Run this in the same situation where you were trying to use game controllers in KDE System Settings and Wine, whatever that is (but please also clarify what that situation is!)
It might also be helpful to compile SDL 2's test/testgamecontroller.c
and try running that, to compare SDL's view of the game controllers with the diagnostic tool's. In some distributions this is packaged into a separate installable package (for example in Debian/Ubuntu, it can be found in /usr/libexec/installed-tests/SDL2
if you install the libsdl2-tests
package) but I think in Arch you would have to compile it yourself.
Wine is very complicated, and I don't know what patches (if any) Lutris applies to it, so it would be better to eliminate Wine from consideration to start with, and get the controller working with native Linux software first.
from sdl.
With SDL 2.30.3, were you using the physical gamepad device directly; or were you running Steam in the background and letting it map the gamepad to a Steam Input virtual gamepad, and then having KDE System Settings talk to that?
Using the physical gamepad device directly, I don't have Steam running in the background and don't have the Steam runtime initialized, though I do have the steam package installed for the udev rules. I notice this difference in KDE System Settings depending on SDL version:
With SDL 2.30.3:
Device: Steam Deck (0003:0002:02)
With SDL 2.30.4:
Device: Steam Deck (/dev/input/event11)
from sdl.
This could perhaps indicate that 2.30.3 as provided by Arch is accessing the device via raw HID, and 2.30.4 is accessing it via evdev?
from sdl.
If it's that, then 793a068 might be another commit to look at.
from sdl.
Can you build SDL3 and check what the output of testcontroller is? Switching from USB to hidraw shouldn't prevent the controller from working.
from sdl.
Actually, since this is SDL2, using test/testgamecontroller from 2.30.4 is probably an easier way to verify using the system installed SDL.
from sdl.
test/testgamecontroller output built from and using SDL 2.30.4:
2.30.4.log
test/testgamecontroller output built from and using SDL 2.30.3:
2.30.3.log
from sdl.
Oh, the USB driver is not used by default to prevent applications locking exclusive access to USB devices. If you want to override that behavior, try setting the environment variable SDL_HIDAPI_LIBUSB_WHITELIST=0
from sdl.
Overriding the behaviour with that environment variable does make the Steam Deck gamepad work again on SDL 2.30.4, which resolves the issue for me. Thanks. I'm unsure if this means the issue can be closed or if it is preferred to be left open.
from sdl.
Okay, it sounds like it's working as intended. Thanks!
from sdl.
Related Issues (20)
- WASAPI can't find requested audio endpoint: Element not found.
- SDL_CopyDirectory, SDL_RenameDirectory HOT 3
- SDL_SetSurfaceColorKey() sets wrong color HOT 4
- SDL_Init(SDL_INIT_AUDIO) randomly segfaults on init HOT 19
- NetBSD CI is down HOT 1
- SDL_GetHint does not work when not calling SDL_Init HOT 1
- main callbacks return enum values? HOT 1
- Missing Pen backends HOT 4
- SDL_AcquireCameraFrame returns frames at a higher FPS than specified on macOS 14.6.1 HOT 3
- SDL_ConvertSurfaceAndColorspace does not correctly palettize surfaces HOT 6
- SDL_Log not working on Windows with debugger attached HOT 10
- [SDL2] Gamepad Motion Sensors via Bluetooth don't work until you launch another SDL App with working Motion Sensors or swap older SDL2.dll files HOT 2
- Updates on dropping Apple frameworks not available on iOS? HOT 7
- Embed a SDL window by NativeControlHost control in AvaloniaUI, mouse cursor don't restore to default on Linux x11. HOT 1
- Feature request SDL_EVENT_FINGER_CANCELLED
- MFC window, pop a sdl window, break! HOT 1
- Decide and Document how planar data is stored in / accessed from Surfaces
- Always prefer downscaling in SDL_GetSurfaceImage HOT 3
- [SDL2] VITA: Can't create any render at all HOT 2
- [macos] HIDAPI device disconnected while opening
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sdl.