Retroarch: [linux] SDL2 driver does not "see" the hat on wired XBOX 360 Controller

[mmatis]

The SDL2 driver can't "see" the hat on a Microsoft wired Xbox 360 controller (1118/654). When binding the controls, RA does not respond to any presses of the dpad buttons. The hat works fine with other drivers/programs. I have reproduced this issue on two very different linux setups:

• Linux Mint 18.1 x86_64 with RA 1.5 from the stable ppa repo
• Valve's Steam Link streaming device, running a custom linux on an arm hard float cpu. Compiled RA from current master with the steamlink-sdk.

Steps to reproduce the bug

1. Set SDL2 for input and joypad driver
2. Plug in controller
3. Start RA and either do "bind all" or individually select the d-pad bindings
4. Press the controller's corresponding d-pad directions and stare at screen in bewilderment as RA doesn't respond.

Bisect Results

It did the same thing with 1.4.1 as well. That's the earliest I've tried it.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[mmatis]

I've poked around with this some more, granted I have no idea what I'm doing, and found a little more info that may or may not be helpful. I compiled sdl2-jtest and confirmed that the d-pad does respond in sdl2. If it helps, this is the SDL2 game controller api mapping:
"030000005e0400008e02000014010000,Microsoft X-Box 360 pad,platform:Linux,x:b2,a:b0,b:b1,y:b3,back:b6,guide:b8,start:b7,dpleft:h0.8,dpdown:h0.4,dpright:h0.2,dpup:h0.1,leftshoulder:b4,lefttrigger:a2,rightshoulder:b5,righttrigger:a5,leftstick:b9,rightstick:b10,leftx:a0,lefty:a1,rightx:a3,righty:a4,"

I tried forcing some environmental variables on retroarch, like SDL_LINUX_JOYSTICK="'Microsoft X-Box 360 pad' 8 0 0" in hopes that would make RA treat the hat as two axes, but it turns out SDL2 does not support this env var anymore. I set SDL_GAMECONTROLLER env var to the mapping string above. Only change was RA used the name string I set in the var in the overlay notification, instead of its usual "XInput Controller".

RA is seeing all the pad's controls, as evidenced by the terminal output:
RetroArch [INFO] :: [SDL]: Device #0 (045e:028e) connected: XInput Controller. RetroArch [INFO] :: [SDL]: Device #0 supports game controller api. RetroArch [INFO] :: [SDL]: Device #0 has: 6 axes, 11 buttons, 1 hats and 0 trackballs.
So I think the problem is somewhere in /input/drivers_joypad/sdl_joypad.c. I don't know C or the SDL api, but I noticed some "TODO" comments where it looks like controller hats are set up:

Line 74: /* TODO: see if a LUT like xinput_joypad.c's button_index_to_bitmap_code is needed. */ Line 93: /* TODO: see if a rarch <-> sdl translation is needed. */

In between those two lines is where it looks like the hat is set up...

[mmatis]

FYI, managed to get the hat working on the Steam Link with the input driver set to sdl2 and the joypad driver set to linuxraw. This is fine, though it feels...twitchy or slow. Hard to describe.

[flibitijibibo]

Took a look at this briefly after finding that my DualShock 4's right d-pad button wasn't responding. From what I can tell, the reason this happens is because SDL_GameController maps the d-pad actions to GameControllerGetButton, so you get a situation where num_buttons is smaller than the full list of buttons, so the last couple d-pad entries (depending on how many buttons you have) get ignored:

https://github.com/libretro/RetroArch/blob/master/input/drivers_joypad/sdl_joypad.c#L324

The fix should be to simply pull that check into the SDL_Joystick path and always poll the SDL_GameController APIs no matter what; we do these kinds of checks in SDL2 anyway so the RA driver doesn't need to be doing that redundantly.

(Sidenote: What platforms are still using SDL 1.2...? We might be able to simplify this backend immensely and reduce the surface area for weird bugs like this if we can just cut out all the old SDL_Joystick cruft.)

[flibitijibibo]

Patch made: https://github.com/libretro/RetroArch/pull/5035

[twinaphex]

Well, our program takes a quite different approach to most software in that we try to be backwards compatible to a fault. So supporting both SDL 1.2 and SDL 2 under specific ifdefs is something we consider important so that people could make use of SDL 1.2 and 2 regardless of which platform or libraries they have installed on their computer.

We support some nutty old platforms still like DOS and Windows 9x and unlike most projects, we like being able to support such outdated configurations. So it's a project culture thing. One of the design goals is to make RetroArch as easy to compile/setup on random PC software with as little needed dependencies or dev tools as possible.

BTW, right now the native 'gl' and 'vulkan' video drivers are still superior to our 'sdl' video driver because there is native menu support for XMB/MaterialUI for the native GL/Vulkan drivers (we wrote menu display drivers for them), and because it allows for native hardware contexts (which we need for libretro GL/Vulkan cores). An SDL menu display driver could theoretically be written, same for possibly allowing GL/Vulkan hardware contexts over SDL, but so far we were lacking the devs who could do these things justice. So just thought I should mention that in case you're using the SDL video driver, you can only use the RGUI menu driver for now, which looks quite lo-fi.

[flibitijibibo]

I'm using gl/vulkan as well; SDL_Render/SDL_Surface aims pretty low so for my setup using the modern stuff is nicer. In practice I've only ever shipped with those APIs when the sysreqs were along the lines of "OpenGL 1.1 or lower" :P

As long as someone's using it, doesn't matter to me! For all I know someone somewhere is making excellent use of SDL for a Dreamcast version. It's just been a while since I've seen 1.2, so it caught me off guard.

In any case, glad this is fixed, will see if I can't get whoever is maintaining the SteamOS package to include this in the next update.

[mmatis]

I'm so psyched this is fixed! It stopped my little SteamLink project in its tracks, since I ONLY had a 360 controller to test with and the Link will only do SDL and linuxraw, the latter of which was too twitchy. I'll test this weekend and report back. Haven't done a fresh build since before the 1.5.1 release, so there's a bunch of things to test.