No GUI on rpi4 when launching to GUI until input made

[joolswills]

Describe the bug
No GUI is shown until a joypad/keyboard input is sent when launching amiberry (without a game). Only tested on Rpi4 / raspbian buster via RetroPie so far

To Reproduce
Launch just amiberry without any game etc.

Rpi4 / fkms with sdl2

Amiberry 3.1.2 e94c4f0 - Built with PLATFORM=rpi4

I suspect this may be related to the GUI rendering changes / cleanups. I will bisect it though and follow up.

Possibly a separate issue but movement in the GUI seems glitchy - it looks like some events are being lost or not processed. Have to press more than once to navigate. Sometimes 3 presses (eg moving up / down in the left menu). I will see if I can narrow this down. This may be due to the input changes. Sometimes it will flicker between the new section you move to, then back to previous then to the new section again. The missed inputs only seems to happen on my gamepad though not keyboard although the flicker / switch glitch happens on both. I can open a new issue for this if it's unrelated.

[joolswills]

Sorry - I'm going to close this for now to do more testing as it seems specific to something related to retropie - I'll check our set up Vs building outside of retropie

[joolswills]

I believe this may only happen with building for rpi4-sdl2 but will debug later. Maybe we should be building without -sdl2 parameter for rpi4 anyway

[joolswills]

Sorry, ignore previous two comments. It's not a RetroPie-Setup issue.

Building with PLATFORM=rpi4-sdl2 and running ./amiberry with 3.1.2 has this issue.

Will provide more information after bisecting

[joolswills]

Bisected to bdde8cb

I've not debugged further.

[joolswills]

GUI also feels responsive building from the commit before the one above.

[midwan]

@joolswills
I can't recreate this so far, both the Dispmanx and SDL2 versions show the GUI immediately in my tests and the GUI seems responsive enough.

Do you have different behavior with the Dispmanx version VS the SDL2 version?
e.g. with target rpi4 vs rpi4-sdl2 ?

Could you elaborate a bit more on the "GUI feels unresponsive" so I can figure out what might be going on?

Do you have a controller connected in your tests? Have you tried without one?

[joolswills]

Will check with dispmanx.

Did you test on rpi4 running from console? (Outside of X etc and with fkms driver). The responsiveness feels as though there is a delay between navigating. Which would relate to the commit. Maybe the timing is different.

I tested with two controllers connected. I'll try without.

[joolswills]

Controllers plugged or unplugged made no difference.

The issue doesn't occur with dispmanx though. Only the -sdl2 build running from console (using retropie sdl2 library - not the raspbian one as that doesn't include the kms driver).

Btw the mouse pointer appears at the top left but I have to press something to see the GUI. It may be differences in SDL drivers and/or timing but this may occur on other systems using sdl2 Kms backend.

[joolswills]

If I call UpdateGuiScreen twice before the main loop in main_window.cpp the GUI shows after a short pause (pause could be related to the timing issue). that's why it needed an input before as it didn't update till the second call.

Could be a driver difference but I will debug more.

[joolswills]

Seems to be this issue.

https://www.raspberrypi.org/forums/viewtopic.php?t=235051

@psyke83 just tagging you as you have spent more time with the sdl code than me.

No pressure :-)

I may switch to dispmanx on rpi4 anyway. But it looks as though this may be a SDL kmsdrm driver issue. I'm still digging.

[joolswills]

@psyke83 The recent sdl2 changes from redream author may affect this as he found some issues with the driver (as you are aware). I will see if they make a difference. Primarily the triple buffer changes. Also I'll check if your patch we reverted affects it.

@midwan as this may not be an amiberry but SDL kmsdrm issue, if you prefer this closed that's ok. Or tag it with something to reflect it's a driver bug. Let me know, or if you're happy for me to report findings back etc and continue to spam it :-)

[joolswills]

The issue with GUI not showing right away is resolved with

inolen/SDL-mirror@6b5ad44

Which is part of SDL upstream. The GUI still feels slowish, but that could also be a related problem.

I may backport this change after more testing to retropie SDL2. And / or switch to PLATFORM=rpi4 for retropie

@midwan apologies for any inconvenience - I'm going to close this as it's not an amiberry issue.

[midwan]

@joolswills
Thanks for tracking this down - I am usually testing on Buster Desktop using the SDL2 from the repo, which doesn't have KMS support, so this explains why I didn't see the problem.

Regarding Dispmanx, it's still the best performing option for the RPI range, according to all the tests we've made. So I'd recommend you keep the PLATFORM=rpi4 target until this changes. ;)