[Odroid XU4] lr-flycast - Input causing graphical bug
-
Hello !
When I try to run a game on flycast, there is a very strange bug that appears when I press a key of the keyboard: Input seems to be sent both in retroarch and the linux terminal, causing graphical bugs and random crashes:
Mores informations:
- It seems to be a problem specific to flycast because I don't have this issue when using lr-fbalpha2012.
- I also tried several games but the problem is same.
- I tried to change retroarch and core input/video configs but no luck
- I tried to run retroarch directly from the command line but the problem is still here. So maybe it's not a retropie problem but a flycast one instead ?
- I think you can easily reproduce the problem by having an Odroid XU4 with minimal Ubuntu and simply install lr-flycast and try to run a game
Specs informations:
-
System: odroid-xu (armv71)
-
OS: Ubuntu 18.04.5 LTS (The one in the doc: https://retropie.org.uk/docs/Odroid-XU3-XU4/)
-
RetroPie-Setup Script Version: 4.6.9 (I also updated all the core package and lr-flycast one)
Output files:
- /dev/shm files:
retroarch.cfg: https://pastebin.com/J1eCt757
runcommand. info: https://pastebin.com/qYZWjp3b
runcommand.log: https://pastebin.com/7rgi6vfU
Any help is greatly appreciated ! :)
-
hmm, xu4 has gles3, but it looks like all xu models default as gles (2) only in retropie: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/system.sh#L493
this is a bug i guess - but i think some xu models are gles2 so we will have to be careful.
are you comfortable editing the scripts? if so:
nano ~/RetroPie-Setup/scriptmodules/system.sh
then edit
function platform_odroid-xu() { __default_cpu_flags="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" # required for mali-fbdev headers to define GL functions __default_cflags=" -DGL_GLEXT_PROTOTYPES" __platform_flags+=(arm armv7 neon mali gles) }
to
function platform_odroid-xu() { __default_cpu_flags="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" # required for mali-fbdev headers to define GL functions __default_cflags=" -DGL_GLEXT_PROTOTYPES" __platform_flags+=(arm armv7 neon mali gles gles3) }
and then update lr-flycast from source and retry. it may not be the cause of the issue, however...
-
(if you're not comfortable doing this i am going to submit a fix shortly)
-
Thank you for your fast reply !
I tried to edit the script like you said and update lr-flycast but sadly it did not change anything. :(
Another thing I did is to update retroarch because I saw in the scripts that gles3 flag add --enable-opengles3 to retroarch: https://github.com/RetroPie/RetroPie-Setup/blob/39d72a20e1f7a4f2c0dfa54d72ca018c6077b4cc/scriptmodules/emulators/retroarch.sh#L58
But it didn't work either..And last thing I tried is to set retroarch video driver to glcore but still no improvement.. Here is the runcommand.log if it can help: https://pastebin.com/qNZm06vZ
-
I will look into it when I get a chance.
@dankcushions why do you think it was related to gles3 ? I can't think of any reason why it would be.
In regards to gles3 - I have been recently going over stuff on the odroid and will look into adding that once I have tested it (PRs for this are not useful).
I will look into this issue when I get a chance. I've seen it before and I have a couple of things I want to check.
-
@BuZz i think i was misled by the lr-flycast makefile:
https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-flycast.sh#L49-L50if isPlatform "gles3"; then params+=("HAVE_GL3=1")
this is wrong.
HAVE_GL3
is for core open GL (v3):there is no build param difference between gles2 and gles3, so you're right, it's not the issue.
clearly
HAVE_GL3
doesn't appear to be causing problems on pi4 or other gles3 platforms (maybe it's overridden byFORCE_GLES
) but it confused me, heh. -
This is untested - I will try it out on my system, but please can you try editing
/opt/retropie/configs/dreamcast/emulators.cfg
and remove the
</dev/null
stringThis may well make no difference (or it may cause it to not work). But it came to mind. It's a workaround that was needed for the RPI.
-
@dankcushions I'll take a look. I probably based this on the existing makefile so there may have been things set incorrectly there. However it works. I seem to remember it was needed, but maybe I remember incorrectly.
-
I tried to remove it but it causes retroarch to crash. Here's the log: https://pastebin.com/dFx4K74J
Let me know if you need me to do more testing !
Thanks for your time.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.