Changing resolution via runcommand prevents game from starting

dankcushions

@setiawan well, you have a bunch of custom overrides being applied. can you talk us through them? please upload them also.

/home/pi/.config/retroarch/config/Snes9x/Snes9x.cfg
/home/pi/.config/retroarch/config/Snes9x/snes.cfg
/home/pi/.config/retroarch/config/Snes9x/ChronoTrigger.cfg

Setiawan

@dankcushions Sure thing. The last one (game override) doesn't actually exist though, as described in the log.

It looks like the contents of both, snes.cfg and Snes9x.cfg are exactly the same:

custom_viewport_height = "224"
custom_viewport_width = "2520"
custom_viewport_x = "0"
custom_viewport_y = "8"
input_remapping_directory = "/opt/retropie/configs/snes/"
menu_linear_filter = "true"
rgui_aspect_ratio_lock = "0"
rgui_internal_upscale_level = "3"
rgui_menu_color_theme = "0"

I'll start by saying that, I just tried commenting out every line in both the config files, and the same issue is present, with the same verbose log.

Having said that, the first four lines were simply to adjust the picture to fit to the super resolution of the system (I was tinkering with it in the scenario I described in my OP where the super res does work, i.e. booting with the super res).

I'm not sure what input_remapping_directory is TBH.

The last four were set to make RGUI more usable with the super res.

jedcooper

I have the very same problem. Coming from CRTPi for RPi3 where this would work perfectly, on RPi4 it's a hassle.
It seems there's something odd in the runcommand.sh (/opt/retropie/supplementary/runcommand/runcommand.sh).
But for me it's too low level stuff to make head or tail of it.
What's interesting is if you kill one or another process runcommand or retroarch the resolution gets back to normal .
Also "weird": Have you tried vgencmd in a SSH terminal while having ES displayed on CRT? The res-change is working quite flawlessly - without tvservice nor fbset commands, only entering vcgencmd <options>!
So it's something with forth and back of the framebuffers I guess.
Yeah lots of guessing, but maybe others can make the more technical part here for this.

EDIT: some further read (but maybe some info valid for 240p RCA only) -> https://github.com/crtpi/rpi4-crt
There seems to be a watchdog what exactly happens with reschange and/or framebuffers and then interferes.
"I put together a simple script vmodes_watcher.py that runs in the background and monitors the value of a desired_mode file. If the file is modified, it waits for retroarch to start and then changes the screen to the desired mode with tvservice." - citation of the github

dankcushions

@setiawan you could try getting a backtrace via gdb to find where it's crashing in the code. exit emulationstation to command prompt, start and ssh session, then:

vcgencmd hdmi_timings 2560 0 64 256 320 240 1 3 4 6 0 0 0 59 0 48000000 0
tvservice -e "DMT 87"
fbset -depth 16

then

gdb --args /opt/retropie/emulators/retroarch/bin/retroarch --config /opt/retropie/configs/all/retroarch.cfg --appendconfig /opt/retropie/configs/snes/retroarch.cfg -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so /home/pi/RetroPie/roms/snes/ChronoTrigger.smc
tty /dev/tty1
run

then when it crashes, enter bt to get a backtrace that show where in the code it crashed. once you have made a note of that, you can use q to exit gdb (and then you might way to do the commands in your onend.sh to return to the original state).

(I've not tested the above - not sure if I've go the commands completely right!)

Setiawan

@dankcushions

Sure thing, I've gone ahead and done the backtrace. I'll copy and paste the entire command line input/output here:

pi@retropie:~ $ vcgencmd hdmi_timings 2560 0 64 256 320 240 1 3 4 6 0 0 0 59 0 48000000 0
hdmi_timings=2560 0 64 256 320 240 1 3 4 6 0 0 0 59 0 48000000 0
pi@retropie:~ $ tvservice -e "DMT 87"
Powering on HDMI with explicit settings (DMT mode 87)
pi@retropie:~ $ fbset -depth 16
pi@retropie:~ $ gdb --args /opt/retropie/emulators/retroarch/bin/retroarch --config /opt/retropie/configs/all/retroarch.cfg --appendconfig /opt/retropie/configs/snes/retroarch.cfg -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so /home/pi/RetroPie/roms/snes/ChronoTrigger.smc
GNU gdb (Raspbian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/retropie/emulators/retroarch/bin/retroarch...(no debugging symbols found)...done.
(gdb) tty /dev/tty1
(gdb) run
Starting program: /opt/retropie/emulators/retroarch/bin/retroarch --config /opt/retropie/configs/all/retroarch.cfg --appendconfig /opt/retropie/configs/snes/retroarch.cfg -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so /home/pi/RetroPie/roms/snes/ChronoTrigger.smc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb0489f30 (LWP 1459)]
[New Thread 0xae62ef30 (LWP 1460)]

Thread 3 "retroarch" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xae62ef30 (LWP 1460)]
0x001d435c in gl2_viewport_info ()
(gdb) bt
#0  0x001d435c in gl2_viewport_info ()
#1  0x001c5d60 in video_thread_loop ()
#2  0x001c5d60 in video_thread_loop ()
#3  0x001c5d60 in video_thread_loop ()
...

It continues with #X 0x001c5d60 in video_thread_loop () repeatedly (even as I type, it's still continuing with the same output). Does this tell us anything?

@jedcooper said in Changing resolution via runcommand prevents game from starting:

Also "weird": Have you tried vgencmd in a SSH terminal while having ES displayed on CRT? The res-change is working quite flawlessly - without tvservice nor fbset commands, only entering vcgencmd <options>!

I have been using vcgencmd over SSH (like in @dankcushions instructions), but I still do need to use tvservice and fbset for the CRT to do anything. Weird.

That link is pretty interesting. It's not clear to me whether it's a solution to the same problem we're experiencing (and even then, it's possible that the specific solution/instructions are for composite out). I'll try changing resolutions manually after RA starts and see if that seems to work. If that does, I guess using a watcher of sorts (like in the link) might be viable, though I would rather have it work without using a watcher process if possible.

Edit: I was able to change resolutions successfully after the game starts, but for some reason only the left quarter of the image is shown. Not sure what's up with that:
alt text

YFZdude

@setiawan said

Edit: I was able to change resolutions successfully after the game starts, but for some reason only the left quarter of the image is shown. Not sure what's up with that:

That's a common thing that happens with the current version RetroArch in use by RetroPie when widgets are turned on. Seems more likely to happen when you have overrides or other things that cause multiple widgets to show on screen. (Lower left corner)
You can (Hotkey + B) to restart the ROM and it should work the second time.

Setiawan

@yfzdude I tried Hotkey + B, and while it does restart the ROM, the same issue persists unfortunately. I've taken a screenshot and measured the width of the shown portion, and it's 640px wide - the width of the screen resolution before I change to the super resolution.

dankcushions

@setiawan for that issue (if it is the same), just disable widgets is the easiest solution for now - https://retropie.org.uk/forum/topic/26322/pi-4-display-issue-with-lr-genesis-plus-gx

regarding the crash, not really sure what it could mean at this point. i guess the issue is around here but it seems pretty generic https://github.com/libretro/RetroArch/blob/c377516db24f999251bec18da414381ff8aab640/gfx/drivers/gl.c#L4174

building retroarch in debug mode might make things easier to debug, but you'd have to mess with the install script for that.

jedcooper

@setiawan Any news on this topic?
Did you fix it? How?
Did you disable the widgets?
Or have another approach?
Any help regarding screenmode change on RPi4 appreciated :D

Setiawan

@jedcooper Sorry, never got around to fixing it. My menu widgets are already disabled, but the issue persists. I'm assuming that it's a similar issue to the one people are reporting with widgets, but not sure what more to do with that information unfortunately.

My other approach.. has been to emulate SNES on my Wii, haha. For an unrelated matter, I'm getting a VGA666 board in the mail some time. I don't expect that it will make a difference with this particular issue, but I'll give it a try anyway and report back if it makes a difference.