Changing resolution via runcommand prevents game from starting

Setiawan

So currently when my pi boots, it boots in 480i (using custom hdmi_timings in config.txt, producing 640x480 interlaced). ES automatically starts, and everything looks fine in 480i.

In my runcommand-onstart.sh script, I try to set a super resolution:

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

If I try to start a game, I get some command line text flashing by quickly (the usual boilerplate stuff that you see). Then the monitor's resolution successfully changes to the super resolution, and I get two more lines of command line text (the hdmi_timings from the vcgencmd command in the script, and "Powering on HDMI with explicit settings (DMT mode 87)").

After a moment's pause, the resolution changes back to 480i (this is expected, as I have set the resolution to change back in runcommand-onend.sh), and I get returned to ES.

Everything happens pretty quickly, so I've had to record the screen with my phone and play it back slowly to watch what's happening, but as far as I can discern there are no error messages that appear pertaining to the issue.

I've used the super resolution in my description of the issue here, but the same issue occurs if I use CEA 6 (480i from the pi's built-in modes) or CEA 8 (240p) in the runcommand-onstart.sh file.

Strangely though, if I boot with the super resolution (i.e. set it in config.txt), and don't try to change resolutions in the runcommand-onstart.sh script, RetroArch is able to successfully start the game in that super resolution. Similarly, if I boot in 480i (as per the scenario described above) and don't try to change resolutions in the runcommand-onstart.sh script, RetroArch is also able to successfully start the game in 480i.

Off the bat, has anyone experienced this, and know of a solution? Otherwise, does anyone know how I might get more information (e.g. where I might expect to find helpful error logs) about this issue?

Video chain: Pi HDMI output -> HDMI to VGA converter -> RGB input on CRT monitor (JVC TM-H150CG)

Pi Model: Pi 4 B 8GB
Power Supply: Official Raspberry Pi Power Supply
RetroPie Version: Er, my RetroPie-Setup is on commit 9143023
Built From: retropie-buster-4.7.1-rpi4_400.img
USB Devices connected: USB KB & MayFlash Wii U Pro Controller Adapter
Controller used: Wii U Pro Controller

mitu

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

Pi Model: Pi 4 B 8GB

The Pi4 has a different set of GPU drivers (integrated with the Linux KMS/DRM system), which don't fully support the tvservice command to reliably change resolution.
The tvservice method only works for older models (Pi 3 and before) and should not be used on the Pi4.

Setiawan

@mitu Ah okay. I thought that was dependent on the dtoverlay used, and only affected full KMS. I'm currently using fake KMS (vc4-fkms-v3d) and it mostly appears to work fine other than this issue.

In any case, is there a recommended way to change resolutions for the Pi 4?

mitu

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

In any case, is there a recommended way to change resolutions for the Pi 4?

For something similar to what tvservice offered for previous Pi models (custom resolutions + on-the-fly switching), there isn't.

Setiawan

@mitu Ah okay. Well in any case, are there any errors that might be logged by either ES or RA, that I can look at for further information? I'm generally able to use tvservice to change resolutions fine, and even in this case, the resolution changes from the runcommand scripts actually happen successfully, it's just that the game refuses to start. So if I could find some more information on what the system is complaining about, it might be helpful.

dankcushions

@setiawan

do you see any errors in /dev/shm/runcommand.log after you try this?

there's some general info here: https://github.com/raspberrypi/firmware/issues/1470

Setiawan

Thanks @dankcushions

It looks like the runcommand.log file does get updated after I try to run a game. The contents:

Parameters: 
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so --config /opt/retropie/configs/snes/retroarch.cfg "/home/pi/RetroPie/roms/snes/ChronoTrigger.smc" --appendconfig /dev/shm/retroarch.cfg
/opt/retropie/supplementary/runcommand/runcommand.sh: line 1283:   960 Segmentation fault      /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so --config /opt/retropie/configs/snes/retroarch.cfg "/home/pi/RetroPie/roms/snes/ChronoTrigger.smc" --appendconfig /dev/shm/retroarch.cfg

The error is referencing the first line within the else block in this function:

function launch_command() {
    local ret
    # escape $ to avoid variable expansion (eg roms containing $!)
    COMMAND="${COMMAND//\$/\\\$}"
    # launch the command
    echo -e "Parameters: $@\nExecuting: $COMMAND" >>"$LOG"
    if [[ "$CONSOLE_OUT" -eq 1 ]]; then
        # turn cursor on
        tput cnorm
        eval $COMMAND </dev/tty 2>>"$LOG"
        ret=$?
        tput civis
    else
        eval $COMMAND </dev/tty &>>"$LOG"
        ret=$?
    fi
    return $ret
}

I'm not too familiar with shell scripting, or the general context around what's happening here. Any ideas?

dankcushions

@setiawan it sounds to me like it's segfaulting within the emulator itself. Can you please supply a verbose log? https://retropie.org.uk/docs/Runcommand/#launch-with-verbose-logging

this may give us a bit more information

Setiawan

@dankcushions

Here's the verbose log below. Does it shed any more light on what's happening?

Parameters: 
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so --config /opt/retropie/configs/snes/retroarch.cfg "/home/pi/RetroPie/roms/snes/ChronoTrigger.smc" --verbose --appendconfig /dev/shm/retroarch.cfg
[INFO] RetroArch 1.8.8 (Git 9552f87)
[INFO] Redirecting save file to "/home/pi/RetroPie/roms/snes/ChronoTrigger.srm".
[INFO] Redirecting save state to "/home/pi/RetroPie/roms/snes/ChronoTrigger.state".
[INFO] === Build =======================================
[INFO] Capabilities:  NEON VFPv3 VFPv4
[INFO] Built: Jan 20 2021
[INFO] Version: 1.8.8
[INFO] Git: 9552f87
[INFO] =================================================
[INFO] Loading dynamic libretro core from: "/opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so"
[INFO] [Overrides] core-specific overrides found at /home/pi/.config/retroarch/config/Snes9x/Snes9x.cfg.
[INFO] [Overrides] content-dir-specific overrides found at /home/pi/.config/retroarch/config/Snes9x/ChronoTrigger.cfg.
[INFO] [Overrides] content-dir-specific overrides stacking on top of previous overrides.
[INFO] [Overrides] no game-specific overrides found at /home/pi/.config/retroarch/config/Snes9x/ChronoTrigger.cfg.
[INFO] Config: appending config "/home/pi/.config/retroarch/config/Snes9x/Snes9x.cfg"
[INFO] Config: appending config "/home/pi/.config/retroarch/config/Snes9x/snes.cfg"
/opt/retropie/supplementary/runcommand/runcommand.sh: line 1283:  8978 Segmentation fault      /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so --config /opt/retropie/configs/snes/retroarch.cfg "/home/pi/RetroPie/roms/snes/ChronoTrigger.smc" --verbose --appendconfig /dev/shm/retroarch.cfg

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.