Retroarch: Xbox One Left Analog Stick (Inverted) up-down, can not remap

[Darkspectrem]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

Xbox One Left Analog Stick (Inverted) up-down, can not remap.

Expected behavior

Expect for left analog stick should work as intended. Push Up (moves up) Push Down (moves down).

Actual behavior

Push Up (moves down) Push Down (moves up)

Steps to reproduce the bug

1. This is the default settings when starting retroarch.
2. Turn on Xbox One Controller.
3. [and so on...]

Bisect Results

Started when using current stable version 1.7.0.

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.7.0

Environment information

• OS: Windows 7 Pro
• Compiler: [In case you are running local builds]

[Darkspectrem]

Had to change Driver/Joypad Driver from xinput to sdl2 to get the invert to go away.

[jas722]

I ran into this issue today as well when in Retroarch, any solutions? I have to see if I can setup sdl2 (not sure exactly what that is).

[RobLoach]

I've had to use x.

Could you check https://github.com/libretro/retroarch-joypad-autoconfig for the configs?

[BarbzYHOOL]

same in linux, this is horrible to configure, nothing makes sense, nothing works, can't reset to default "auto config", wth is a joypad, etc etc

I have set "B button (down) 0, key: z" but it's still using the inverted mechanisms

Can't even change it in the quick menu, nothing can be edited there

EDIT: ok i inverted the buttons myself, so now it's logic (inverted the inverted even though it's written everywhere with schemas that A/B are inverted by default, so I put A = A and B = B) and it works, i still don't understand one bit but it works

[michellabbe]

Ran into this issue recently, still happens with Retroarch 1.9.0.

The source of this issue seems to be the NVIDIA Shield.cfg xinput autoconfig file, at least when streaming using NVIDIA GameStream (with Moonlight client in my case).

If you delete the autoconfig\xinput\NVIDIA Shield.cfg file and restart Retroarch, then xbox 360 and xbox one controller works perfectly. However, the file (and issue) will come back when updating controller profiles.

Comparing this file with Xbox_One_Controller.cfg in same folder clearly shows the input_l_y_axis (and other things) are inverted in NVIDIA Shield.cfg.

Also note the NVIDIA_GeForce_Experience_Virtual_Controller.cfg file which is set properly, but has input_vendor_id and input_product_id commented out because they are the same as in NVIDIA Shield.cfg.

I don't have a NVIDIA Shield Controller so I can't tell if the NVIDIA Shield.cfg config file is working fine or inverted as well with the real controller, but it's definitely conflicting with the MUCH more popular xbox 360 and xbox one controllers, and alot of people seem to have been complaining about inverted axis for the last couple years.

[Crimsom13]

Trying to fix this broken mess for 5 hours and people are just telling me I'm the only one with this issue... LMAO... This issue is causing multiple profiles to invert other profiles its not even just the xbox controller also A and B buttons switch regularly... its absolutely mental, but aparntly I'm the only one with the issue.

[michellabbe]

Do you also have NVIDIA streaming involved?

On my side everything is working fine (so far) after I deleted NVIDIA Shield.cfg and uncommented the VID/PID lines in NVIDIA_GeForce_Experience_Virtual_Controller.cfg. I'll have to do it again after every controller profiles update though, until this broken NVIDIA Shield.cfg is removed from sources.

I believe A/B and X/Y button inversion is normal in most situations. Nintendo has them inverted compared to Sega, XBox and others so while it sucks to have to press B when game says "press A", it's usually more convenient to have the buttons match their up/down/left/right positions.

Also make sure you didn't accidentally save input remaps which would oveeride default input mappings for some cores/directories/games.

[hizzlekizzle]

@michellabbe I believe your issue different but rather easily resolved. We should probably just uncomment the virtual gamepad vid/pid and comment out the shield controller profile instead, which looks to be old and incomplete (and incorrect, from what you're saying) anyway.

However, this would not be related to the xbone pad issue(s) described in this thread because when streaming over moonlight/gamestream/parsec/etc, it uses a virtual gamepad vid/pid provided by the software (hence the use of the nvidia virtual controller profile) instead of the one for whatever controller you're currently using, xbone or otherwise.

[michellabbe]

@hizzlekizzle Thanks for your reply. Should I open a separate issue to have the two NVIDIA cfg files properly fixed then?

I was thinking maybe others were also streaming and didn't think about mentioning it. That would explain why xbone ctrl is
working fine for most people, and those trying to troubleshoot this issue are going crazy.

What also really didn't help troubleshooting in my case:

1. The (broken) NVIDIA Shield.cfg file doesn't include a input_device_display_name so the RetroArch input autodetect notification says Controller (XBOX 360 for Windows) configured in port #1 which leads me to look anywhere but something named "NVIDIA".
2. The online doc says the log file should tell if a profile has been selected, but that part doesn't work (even with debug log level). Not sure if I missed something here or if this is also a bug.

So for others facing this issue with a xbone ctrl connected directly, I suggest renaming the autoconfig\xinput folder (even whole autoconfig folder if needed) and relaunching Retroarch to quickly confirm if the issue comes from one of the cfg files.

There is also the autoconfig\xinput\Retro-Bit Tribute64 - USB (D-Input).cfg that might conflict. Note the (D-Input) part in filename/display name, doesn't seem right with xinput driver/folder. It has the same VID as xbone ctrl but no PID (and input_l_y_axis is also inverted with xbone ctrl). This one does have a input_device_display_name though, so the autodetect notification should make it pretty obvious (except the misleading D-Input part).

[bbbradsmith]

I have this problem with the Xinput drivers ever since the last few versions of RetroArch. (I'm not sure which version I had before, unfortunately, I just know it happened after I updated it. I didn't notice for a while because I play most games with d-pad only.)

Switching to SDL2 or Dinput drivers corrects the issue, but with Xinput being the default it's still wrong out of the box. Left analog stick has up/down swapped with Xinput.

My controller is a Logitech F310. I've seen the same problem happen on 2 different computers, one is Windows 10, one is Windows 7.

Was Xinput always the default, or did that change in the last while? If it wasn't the default before it's possible the problem would have been there long before.

[hizzlekizzle]

@bbbradsmith it was the default, but the xinput driver would--until recently--pull from the dinput driver's autoconfig profiles whenever it felt like it. So, yeah, the problem likely existed for a long time but just wasn't noticed because of the promiscuous driver/autoconfig behavior.

So, are you getting it with a profile that identifies your pad correctly as the F310? Or is it from the generic xinput profile(s)?

[bbbradsmith]

It seems like each driver is identifying it differently:

1. With Xinput driver it says "Logitech Gamepad F310 configured in port 1". (incorrect behaviour, left analog stick Y is inverted)
2. With Dinput it says "Controller (Gamepad F310)" (correct behaviour)
3. With SLD2 it says "Xbox 360 controller" (correct behaviour)
4. With HID it doesn't find a controller