Does anyone know what past version of retroarch does not have this bug?
Indeed I did try it but game input didn’t work at all once I tried the hid driver; fortunately keyboard input was still working fine so I was still able to navigate RA’s menu to switch the input driver back to android without having to hand-edit my retroarch.cfg or anything along those lines. 
Indeed I did try it but game input didn’t work at all once I tried the hid driver; fortunately keyboard input was still working fine so I was still able to navigate RA’s menu to switch the input driver back to android without having to hand-edit my retroarch.cfg or anything along those lines.
[QUOTE=talos91;37377]A workaround for this bug would be using an onscreen overlay in retroarch and use an android app like tincore keymapper or game controller to touch to map the the physical buttons of a controller to touch inputs (tablets like the nvidia shield or the archos gamepad have a builtin app to do that), then set the opacity of the overlay to 0, the simultaneous button presses work perfectly using a gamepad overlay. Just tested this method and it works, at least is better than nothing until someone finds a solution to this android bug.[/QUOTE]That’s a ridiculous workaround but whatever works I guess. Do you know if / how it’s possible to configure Tincore on an nVidia Shield TV (i.e., no touchscreen interface at all, just a virtual mouse) to do this? I already sideloaded it but in my quick playing around with it, it seemed like attempting to set it up without actual touch controls was going to be tricky at best. 
Yeah Tincore is a pain to use but luckily there is a wiki that explains how to use every function in detail. Does the retroarch gamepad overlay responds to your virtual mouse presses? If yes then it should be possible to use tincore to map your controller buttons to mouse input but you need root I think. Also Tincore has an option to simulate different external controllers but idk if this bug happens with all external controllers.
I had the same experience with the hid driver. Simultaneous inputs don’t work for me on most cores, but seem to work for me on the mGBA, Nestopia, FCEUmm, and Gambatte cores (tested with games like Double Dragon GB, RCR NES/GBA, and KoF EX2 GBA). Simultaneous inputs don’t work for me on the overlays. I’m on a Galaxy Core Prime with an 8bitdo Zero and a Moga Hero Power.
I’m not sure. I tried 1.2.0, but it still had the bug. I also tried one of the early builds with pre-installed cores like 1.0.0.2, but couldn’t get the controllers working at all with it.
[QUOTE=Brianvgplayer;37537]I had the same experience with the hid driver. Simultaneous inputs don’t work for me on most cores, but seem to work for me on the mGBA, Nestopia, FCEUmm, and Gambatte cores (tested with games like Double Dragon GB, RCR NES/GBA, and KoF EX2 GBA). Simultaneous inputs don’t work for me on the overlays. I’m on a Galaxy Core Prime with an 8bitdo Zero and a Moga Hero Power. [/QUOTE] It is weird that the simultaneous button presses do not work in gamepad overlays for you, do you have any other android device to test the gamepad overlays simultaneous input?
No, that’s the only one. Simultaneous button presses on overlays with two buttons work in MAME and the .emu emulators. The Android phone I have has multi-touch, but it’s limited to two presses at once.
That is interesting, does anyone else have the same problem with the gamepad overlays?
fixed, thanks to diablodiab
Report any weirdness asap
Literally a one-bit fix (changing a single character from 0x30 (‘0’) to 0x31 (‘1’) for what seems like is a bug in the Android NDK. Whatever works I guess. It definitely solves this from my testing though.
It works perfectly now! Tested fighting games and the simultaneous button presses work all the time! Big thanks to diablo, good job man! Guys report if you find any bugs.
Working for me too. I tested with PCSX Rearmed and Genesis Plus GX and inputs work great. I still have an odd input isue with the PSX core where the up input is unresponsive on the right analog (and the default setting is inverted for Moga Hero Power).
That’s great! I hope we don’t discover any issues with the fix these next few days.
I know that the fix does change one thing if you are using an Nvidia Shield TV and the Shield controller:
Clicking the NVIDIA button on the controller will not go back into the RetroArch menu at the moment.
The autoconfig for NVIDIA_SHIELD_Gamepad.cfg needs to be updated and the keycode for the menu button needs to be changed from 84 to 203.
If we don’t see any issues with the fix the next couple of days I’ll submit a pull request for this change - unless someone beats me to it
Fantastic news, great work diablodiab. I will install the nightly and test all of my devices later today.
Just to clarify, the Moga right analog mapping issue was there before the fix. I deleted aFBA and started using Retroarch for FBA again since it runs so much better in Retroarch. Thanks for the fix!
Edit: I noticed in a couple games with analog controls in FBA like Galaxy Force II and Space Harrier, the dpad inputs are acting weird, with both the touch inputs and external controllers.
Edit: After trying the games in the Windows FBA, it seems the input issue is a FBA input mapping issue rather than an issue with Retroarch.
Back attacks in Golden Axe working perfectly now. I’m assuming this fix will have made it into the v1.3.4 release? I’ll try it later today if I can.
Yes it should be part of the latest release.
Working perfectly so far, no bugs found. I am curious as to how changing just one single value fixed the bug. Anyone knows?
The fix is more of a workaround for a bug that must be in the Android NDK.
By changing the value, the call to ALooper_pollAll was changed from a non-blocking call to a short 1 ms blocking call (0 = nonblocking call, 1 = 1ms blocking call).
It really should be enough to use a non-blocking call to check for queued events which would then be available for handling in the inputQueue. But for some reason this would only lead to one input event being added to the inputQueue despite there being more available. Changing it to a short blocking call solved this problem. I’m not sure why it was necessary - that’s why I’m thinking it might be a bug in the NDK. The bug was found by narrowing it down to that function call after debugging the code surrounding that call.
Fantastic find, thank you again. I believe this fix may be more significant than making a handful of fighting games playable.
I have a Belkin Bluetooth keyboard that never worked very well as a controller with the Android version of RetroArch. Certain button combinations wouldn’t register, keys got “stuck on” frequently and I gave up trying to play Super Mario Brothers and such. It worked much better with other emus and with RetroArch when paired with a PC.
Since this fix was implemented, it’s working perfectly.