GUI navigation with gamepad is partly broken on OUYA

[dlanor]

I've neglected PPSSPP testing for a while, so tonight when I decided to test recent versions more thoroughly on my OUYA I was shocked to discover a basic failure of the GUI navigation. Whenever I've scrolled the selection cursor by holding down a DPad button for a while there is a high risk of a malfunction where PPSSPP seemingly generates ghost button presses in reverse directions, so that the selection cursor keeps jumpin up and down between two rows or left and right between two columns (icons or whatever). Once this auto-repeat has been triggered it seems impossible to stop, so the only way out is to D-click the OUYA button and tell the system to exit PPSSPP.

Strangely enough this problem has never affected in-game behaviour, so it's almost certainly due to GUI-specific code.

Another oddity worth mentioning is that I do not see the same problem on another Android device with a USB gamepad (a Pipo Tablet).

NB: I'm unsure whether this problem was triggerable before the most recent OUYA update (Dec 18 2013), since I didn't test this issue then, and OUYA updates are not reversible. But whatever the case may be, this is now a serious issue on the OUYA, making it almost impossible to handle the GUI menus either pre-game or in a paused game, for cheats etc. (It can be done, by carefully scrolling only one row per keypress. Any more than that and the bug is likely to strike.)

After discovering the problem I started testing older versions to find where this problem started, and quickly noted that ALL v0.9.6-* versions are affected. Further testing showed that the last non-affected build available to me is v0.9.5-843, while v0.9.5-847 has the problem fully developed. The builds in between have no build-bot binaries available for download, so I can't test those. But judging by the brief build descriptions I consider build 845 to be the main culprit.

Its 'Commit Log' comment simply states:
"Update native (key repeat simulation, makes navigating the UI with gamepad nicer)."

And since the problem consists of unwanted auto-repeat of keys/buttons, this modification of build v0.9.5-845 is definitely related to it.

I'm posting this report both in the development forum and as an official issue at github.

Best regards: Ronald Andersson (aka: dlanor)

[Henrik]

Thanks for reporting, seems to be some collision between a built-in key repeat mechanism with the one I added. Will se what I can do soon.

[dlanor]

(12-19-2013 07:52 AM)Henrik Wrote:  Thanks for reporting, seems to be some collision between a built-in key repeat mechanism with the one I added.

Yes I agree, though I don't see the details of its working myself.
(Once triggered those auto-repeats just keep going even after I've laid the gamepad down.)

Quote:Will se what I can do soon.

That's great.
Please let me know if/when you want me to test this on some new build.

Best regards: dlanor

[Henrik]

I've done a little tweak to key repeat that should fix this.

[dlanor]

(01-03-2014 01:07 PM)Henrik Wrote:  I've done a little tweak to key repeat that should fix this.

Thanks!

I'll download the latest version and test this at once, and will report my results of this test shortly.

Best regards: dlanor

---

(01-03-2014 01:07 PM)Henrik Wrote:  I've done a little tweak to key repeat that should fix this.

I'm sorry to report that the fix does not work as intended.

I've now tested this in two different builds, starting with v0.9.6-295, which is the first build I found where a comment mentions this fix, and then I also tested it with the current latest build v0.9.6-338. Unfortunately both still have the auto-repeat bug which has only changed slightly in its symptoms, but not at all in its severity. It's very hard to navigate any of the GUI menus without risk of triggering the bug, as it can trigger whenever a DPad key is held down longer than one key-repeat interval.

The old symptom was almost invariably that the GUI cursor started jumping back and forth between two entries, as if two keys were being pressed alternately in endless repetition, though in fact all keys are released. At this point it is sometimes possible to move the cursor to another location perpendicular to its alternate jumping, but that jumping never stops even after such movement, and no other keys are accepted by the GUI (so 'X' is ignored, activating none of the entries the cursor jumps between). The only escape from this lockup is to press the 'OUYA' key and force-terminate the app through the system's popup menu.

That symptom still remains, though it's now accompanied by one other and less common alternative, which is that the cursor instead of jumping back and forth just proceeds to the extreme limit of current scroll direction (even after releasing all keys), and then gets stuck there. In some cases further attempts to use the DPad can then switch the behavior into the old symptom of jumping back and forth eternally. But the only way out of the lockup is still to use the system menu to force-terminate the app.

I'm afraid I still have to fall back on v0.9.5-843 as the last OUYA-compatible version, for now...

Best regards: dlanor

[Henrik]

Thanks for testing, I'll go hook up the Ouya again and see what I can do...

[Henrik]

I think I fixed it, works fine for me at least. Now there's that weird banding issue left on Ouya...

[dlanor]

(01-05-2014 11:03 AM)Henrik Wrote:  I think I fixed it, works fine for me at least.

Yes! I've just tested v0.9.6-342 and can no longer trigger that bug at all.
I've closed the github issue for it, with a note saying that it was fixed in v0.9.6-340.

Quote:Now there's that weird banding issue left on Ouya...

Oh yes, that one has been around for quite some time now, though I think it got fixed for a while (at least partially) and then reverted again.

Fortunately for me, my favorite games don't suffer much from it.

Best regards: dlanor