linux ppsspp interface not recognizing default xboxdrv/xbox360 keymap

[cdelorme]

I'm running debian jessie, with ppsspp-sdl built from source using the v1.0.1 release-tag.

I have xpad blacklisted, and xboxdrv is set with the mimic-xpad flag for support with various games running through steam.

I am using an xbox360 wireless controller.

I was able to remap the controls to work in ppsspp games, but they do not work with the ppsspp interface. Instead my A, B, X, Y buttons are interpretted as dpad, and the dpad is also interpretted as dpad, but there is no confirmation button so I can't navigate the menu purely by controller.

Is there a way to tell ppsspp to use the remapped input for its own interface?

[hrydgard]

Currently no, the intention is so that you can't get yourself in a bad situation by unmapping all controls and then being completely unable to do anything. Of course, if you also have a mouse or touch interface it's easy to get out of the situation...

It's strange that the controls are weirdly mapped in the first place, we only use very basic and standard buttons for the interface that should be available on almost any controller.

[Joelgp83]

Might as well state that this is similar to #7300, where I mentioned the same thing is happening in moga mode B, via bluetooth to my linux mint install. So this is not isolated to specific vendors, methinks.

[cdelorme]

@hrydgard thanks for the quick reply. Do you know whether this something I can troubleshoot and patch in ppsspp, or is it an SDL issue?

I would love to troubleshoot it and submit a patch, but I'm not entirely sure what the scope of the problem is. I'm guessing the maps are specific to linux. What I don't know is if all linux users with xbox360 wireless controllers are having this problem, or if I'm just lucky.

Are there any notes on which driver & controller combination(s) were used to create the current default mapping(s)?

@Joelgp83 thanks for sharing a similar problem; I'm guessing I can search for SDL_JoystickName() to find the mappings.

I'll see what I can do to get started tonight; sorry if the answers to my questions will be obvious once I start diving into the source history.

[FireyFly]

I noticed this issue just now.. it looks similar to the problem I've been having with a generic USB controller, where the "ABXY" buttons' keyCodes correspond to those of a keyboard's arrow keys.

My issue boiled down to two things:

1. This piece of code in native dealing with D-pad repetition, where deviceId is ignored. This seems to cause issues when the controller uses the same keyCode as keyboard arrow keys.
2. UpdateConfirmCancelKeys in PPSSPP, and the corresponding code for Confirm/Cancel/TabLeft/TabRight keys in native. This one seems relatively straightforward to fix--the problem is that again, only the keyCode is stored and not the deviceId, so if we simply keep track of both it shouldn't be a problem anymore.

---

I created branches for PPSSPP and native that tackle the second issue by moving KeyDef and AxisPos to native. I'm not sure if this is the best solution, but it doesn't seem too unreasonable to me.

[cdelorme]

A quick follow-up; I just built and tested against master and v1.1.1 (both include @FireyFly's patches). The A,B,X,Y on my controller are still awkwardly mapped to directional inputs, while the D-Pad and shoulders (LB/RB) work as expected.

[FireyFly]

Do they act as d-pad, or merely show up as d-pad in the config interface? I think I did a quick test with my roommate's 360 controller, and it seemed to work just fine. The main issue was that any d-pad keys were treated as directional keys regardless of device (for Ouya controller compatibility), but now they should be mappable separately as any other key.

[cdelorme]

No, I tested it, quite a bit actually. The controller works great in game, it's only the ppsspp menu that's got the mapping wrong.

Things that work as expected:

• DPad up/down/left/right
• LT/RT move

The behavior of my A,B,X,Y are:

• A moves up
• B moves down
• X moves left
• Y moves right, then opens the right click menu (unless moving left reaches the side menu)

I don't recall the Y button opening screen in v1.0.1, but I already removed it so I can't confirm without rebuilding again.

The joysticks are ignored, which I suspect is normal behavior (eg. I can't navigate the menu using the L-stick as opposed to the dpad).

I never had a problem with the dpad though, so maybe I misunderstood the problem.

I just tried building and using the latest xboxdrv release (1.8.8), but nothing changed.

I can try to capture a video with jstest output if that'd help.

[cdelorme]

I verified today that if I remove my ~/.config/ppsspp/PSP/SYSTEM/controls.ini the games no-longer work and suffer the same invalid mapping as the UI does, so I'm fairly confident something is not working as far as linux detecting an xbox360 controller.

I began reading Common/KeyMap.cpp, and hope to see if I can figure out the cause and a solution later this week.

Edit: I forgot to include the controls.ini for reference (pretty sure I copied my entire save folder from a windows system several months ago):

[ControlMapping]
Up = 1-19,10-4033
Down = 1-20,10-4032
Left = 1-21,10-4031
Right = 1-22,10-4030
Circle = 1-52,10-20
Cross = 1-54,10-19
Square = 1-29,10-21
Triangle = 1-47,10-22
Start = 1-62,10-193
Select = 1-66,10-192
L = 1-45,10-197
R = 1-51,10-196
An.Up = 1-37,10-4003
An.Down = 1-39,10-4002
An.Left = 1-38,10-4001
An.Right = 1-40,10-4000
Analog limiter = 1-60
RapidFire = 1-59
Unthrottle = 1-61
SpeedToggle = 1-68
Pause = 1-111
Rewind = 1-67
Save State = 10-195
Load State = 10-109

[cdelorme]

The build system was very fast for testing minor logging changes so I was able to gather more information. Please have mercy on my stupidity as I ask what may be obvious.

First I noticed that UpdateNativeMenuKeys gets called a grant total of 81 times at boot, where 78 of them are from SetKeyMapping looped for two default mappings which I assume is 39 keys each. Would there be any benefit to creating a private SetKeyMapping that is used by initialization, or maybe updating the function signature to include bool reload to decide when to call UpdateNativeMenuKeys and updating the two calls from UI/ControlMappingScreen.cpp?

I noticed that X360 is not in the list, but I tried adding it, removing PAD, and removing both, and the input behavior remained the same. So now I am pretty sure the problem is exactly what @FireyFly had previously mentioned about the device id not being checked, but I thought his patches fixed that and had been accepted.

While I found it was possible to add log messages to UpdateInputState I could not find out how to extract the device id from an InputState struct. I am still searching for a good entry point with KeyDef, but any tips would be super.

[unknownbrackets]

UpdateNativeMenuKeys() could probably just be moved to the bottom of the callers of SetDefaultKeyMap() instead.

Anyway, it's important to understand that PPSSPP currently very intentionally ignores the user configuration for the UI. The goal here is to make it so you can't cut your arms off by misconfiguring the controls, and be unable to fix it. An idea we threw around at one point was a confirmation message, but it's not entirely trivial to get the UX right.

The problem on Linux is that different devices will use the same interface, but different buttons. Your device may be quite certain that the Up key only makes any sense as "button 5", but maybe some other device thinks it should be "up." We sorta rely on the platform (SDL in this case) to provide us with a sane mapping of the keys for defaults, and do some limited detection of mappings based on device id for certain very common devices.

On Windows and other platforms, we're provided with a mostly sane setup. Usually arrows are in the right place, and at most confirmation buttons might be a bit awkward. The story simply isn't as good on Linux. There's more variety. At least as far as I've seen.

-[Unknown]

[siulman]

Hello guys,

I've just installed the PPSSPP 1.1.1 on my macbook air. Already have it running on my IPAD & on windows laptop working great with my dualshock 4 gamepad.

But in macbook there is the same issue described on this topic.

Ex: cross is "pad down", circle is "pad up", etc...

The dualshock works on mac with other games so it's just an issue with the emulator.

Is there a known solution or at least something that I can do to play on ppsspp with my dualshock 4 ?

That would be really appreciated!

Thanks

[siulman]

Hello??? :-(

[cdelorme]

Unfortunately I haven't had much time to tinker since my last post. Since it appears to be working on other linux distributions I was hoping to try a few others out on a spare system and compare SDL versions.

[siulman]

Understood.

If I could do something on my side I will! unfortunately, I don't have the skills... :-(

I am using macbook air.

Waiting for someone to solve it to play to the best emulator...

[Asuna99]

+siulman
i am new and i am just a random 16 years old video gamer, i been use the ppsspp for quite awhile now. i use mac version of ppsspp since version v0.9.7, it had the same issue. what i did was back you file then open ppsspp control and clear all, and remapping the d-pad with either left or right analog or right analog depends on your game, it will reset the key board mapping too that is why i suggest you make a back up of every thing just in case. it worked for me and i am play yu-gi-oh arc v special. hope this helped, i been research this online but there is no answer but is it didn't help i will help you by doing some more research. have a nice day!

[siulman]

@Asuna99

Thanks for your answer man, appreciated!
You gave me an idea, I already tryed to reset the mapping but this time I tryed without re-maping the keyboard and exiting and re-entering to ppsspp.
I don't know why but as this, I can't manage the ppsspp menus with the PAD direction but surprise!!!!! Even if in the menus, the PAD controlls don't work, it does in game!!!!!

That means that I have to manage the menus with the trackpad but once in the game, the dualshock 4 is working perfectly!!!!

Thanks a lot for your help!!

I was using a workaround until now which was to use "crossOver" and ppsspp for windows. But performance is much better with native mac!!

Curious thing, I tried to map again the arrows on the keyboard to manage the menus of ppsspp with the keyboard but then, I have again the confusion with the pad where "cross" is "Pad-down" and so on....

Conclusion: PS4 controller works great if keyboard is not mapped. I can live with that :-)

--> You can see on my snapshot that on the screen there is the wrong button displayed...

[Darknior]

WOAW really impressive to see a bug there from 2015 and nothing do to correct it :(
I ha ve the same bug with my x360 Pad on Raspberry 3 and Retropi !
I can't use DPad anywhere, not fine recognized, and i have some bugs on Analog Stick on some games ... strange thing ...

[cdelorme]

In my case games always worked correctly, it was the UI navigation that did not function correctly. As a result I had to use a keyboard or mouse to select a game, from there I could play from the controller.

The very first reply explains why remapping of the interface is explicitly disallowed.

I recently upgraded to Debian Stretch and this problem no longer exists for me, using PPSSPP 1.3 compiled from source.

I am confident at this point that the problem stems from a dependency, probably SDL, as debian very specifically freezes packages and does not update them until the next version (that's 2~ years of updates and patches you will never get in exchange for rock solid stability).

@Darknior I would suggest seeing if you can upgrade your retropi OS.

I am closing this issue since I do not believe it is something that can be resolved inside the scope of PPSSPP source code, and because for me the latest release of my distribution seems to have things working correctly.

[Darknior]

@cdelorme I understand what you write.
BUT it's false, i'm sure the problem come from the source code.

On my Retropie i play many emulators, that use Retroarch, and other indépendant like fba (Finalburn), coolcv (Collecovision), drastic (Nintendo DS) .... and ALL are working FINE on my system.
For some i have an interface to configure pads, for other i make the ini by hand.
On your emulator i try the two solutions but i can't found any solution.

If you search over the net you will found other guy's like me that have the same problem on xBox 360 en PS3 controler. And they post the problem this year in 2017 !

---

You speak about a PPSSPP 1.3, with Retropie on PI 3 we only have the version 033676c
Take from binay, i try from source but it crash when it try to compile ...
Do you know this version ? Is it an really old one ?
Because it's working very fine with many games, it is impressive for an PI machine :P

[unknownbrackets]

@joolswills do you know if Retropie/Raspbian ships with a really outdated SDL or something? Apparently there are controller mapping issues.

We did switch to using SDL_GameControllerDB in v1.4 and above to improve the default mappings. Is there some problem that's keeping people from using newer versions than v1.3?

-[Unknown]

[joolswills]

We include SDL 2.0.5

We update ppsspp binaries every so often - last binary update was only a month ago. Latest version can be installed from source. If a user is having trouble doing that they can post on the RetroPie forum.