[Pico/Open-Frame1] D-pad does not work in any Mode on the Steam Deck
Closed this issue · 7 comments
I'm playing on a Steam Deck (in a dock) if it matters. I can move around and stuff in Melee Mode but then the attack buttons aren't in the right places for this kind of game. When I switch to FGC mode the attack buttons are all in the right spots (according to the inputs shown in training mode) but I can't move anymore.
Also, are the default layouts for the modes displayed anywhere? I'm not even entirely sure what each button is bound to. What is normally C-Down opens up the menu as if I'd hit the Steam button. (Maybe like a Home or something?)
If I'm in FGC mode when I start Skullgirls I can't even seem to get past the menu where you select which controller is used by which player. When I started up in another mode I was able to get past this. It seems to want me to use left/right here.
Do I need to rebind keys for this to work or have I hit a bug? I don't usually play traditional fighters so I haven't tested this mode with other games. I mostly play Smash and Rivals.
edit: in the controls screen when trying to rebind movements it doesn't detect any press from the left side's four buttons at all.
edit2: Using Open-Frame1 PCB, so I have 20 buttons.
FgcMode uses the dpad for the movement buttons. Is your movement bound to dpad in the game?
I've looked up the default Skullgirls controls[0] as well as navigated to the controls screen with a different controller, and as far as I can tell both analog stick and d-pad are bound to movement by default on the applicable platforms/controllers. I've also noticed that in the menus of SteamOS I can't use the directions in FGC Mode, but the face buttons work for pressing OK on something or going back. If I do get into the menu to rebind controls via a working mode such as Melee Mode or by using another controller and then change to FGC mode, it doesn't seem to detect any input from those buttons when trying to set the binding either. For the in-game portion I tested both with and without Steam Input enabled and got the same result.
[0] https://skullgirls.fandom.com/wiki/Controls#PC (it lists "directional keys" for PC but PlayStation and Xbox mention both analog/D-pad so I figure that likely applies to those controllers on PC)
Update: in Rivals of Aether in the Rivals Mode, Mod X + Mod Y + C-Stick directions do nothing. At this point I'm thinking I can't send D-pad signals period. If movement in FGC mode is D-pad then that would make sense.
After further testing I've found that on Windows in Dolphin the D-pad is detected fine in Melee, Rivals, and FGC Modes. On the Steam Deck in Dolphin (Slippi settings used to test) the D-pad is not detected at all. On a GNU/Linux machine that is not SteamOS, Dolphin + Melee showed that the D-pad worked (at least the up button for sure).
It's likely that this issue is specific to something with the Steam Deck / SteamOS.
I've had some success with Dinput (and Steam Input disabled) for getting the D-pad movement buttons working in Skullgirls on the Steam Deck, however most of the action buttons are wrong (verified with training mode).
- Bottom row first button shows as bottom second
- bottom second shows as bottom first
- bottom third button does nothing
- bottom fourth shows as top third
- top first matches
- top second does nothing
- top third shows as top second
- top fourth shows as a combo of top second and bottom first
- the start button does nothing.
- C-down opens the Steam menu
- some other buttons do nothing such as L, C-left/right, Mod-Y (as far as I can tell)
I'm not sure what the layout is supposed to be so not sure how many empty buttons are intentional to avoid mispresses in games that need fewer, but I'm guessing the punch/kick stuff not matching up isn't intentional since in Xinput FGC mode those buttons actually do match up with the graphic in training mode (but then my movement doesn't work).
I noticed that at the controller select with Dinput it actually displayed as a Raspberry Pico instead of some sort of Xbox controller.
Thanks to @AtomToast's research/testing we now know that DPad not working in some applications on Linux is due to a quirk of the xpad driver where DPad is treated differently depending on whether it's dealing with a wireless or wired Xbox controller. The vendor/product ID I was using is for an Xbox wireless controller adapter, because it was the only official Microsoft VID/PID that seemed to work on both Linux and Windows (without breaking the input viewer support by ignoring interfaces other than XInput, which Windows does with all of the other official Xbox VID/PIDs).
We actually have plenty of unofficial VID/PID combos to choose from here: https://github.com/paroj/xpad/blob/master/xpad.c
From testing, pretty much any of these seem to work fine. The only downside of switching is that they don't seem to work in Windows' joy.cpl gamepad tester, but that is of course much less important than the controller actually working properly on different platforms.
Probably going to settle on 0738:4726 - "Mad Catz Xbox 360 Controller". Will be fixed in next release.
This was fixed a while ago (thanks), so closing.