CRT switchres crash on raspberry pi 5

[thetooth]

Is there an existing issue for this?

• This is a bug in RetroArch frontend
• I have searched the existing issues

Description

Under any version enabling switchres under the gl driver causes segv in DRM driver. Have tried both native and super resolutions, even just regular old VGA modes crash.

Tried to deep dive this and found that in gfx_ctx_drm_swap_buffers, eglDestroySurface() is being called leaving the surface pointer not set to EGL_NO_SURFACE, later calls to egl_create_surface fail because it's expecting that deletion marker.

diff --git a/gfx/drivers_context/drm_ctx.c b/gfx/drivers_context/drm_ctx.c
index 78119d0..6383a1d 100644
--- a/gfx/drivers_context/drm_ctx.c
+++ b/gfx/drivers_context/drm_ctx.c
@@ -599,8 +599,7 @@ static void gfx_ctx_drm_swap_buffers(void *data)
             gbm_surface_release_buffer(drm->gbm_surface, drm->bo);
          if (drm->next_bo)
             gbm_surface_release_buffer(drm->gbm_surface, drm->bo);
-         egl_ctx_data_t *egl = &drm->egl;
-         eglDestroySurface(egl->dpy, egl->surf);
+         egl_destroy_surface(&drm->egl);
 
          gbm_surface_destroy(drm->gbm_surface);
       }

Unfortunately, this just creations another issue. For progressive resolutions switchres is working, but for anything with a frame buffer of 320x240 or similar results in drm->next_bo being null and crashing again.

Expected behavior

No response

Steps to reproduce the bug

./configure --enable-kms --enable-egl --enable-opengl --enable-opengl_core --enable-udev --enable-sdl2 --disable-x11 --disable-wayland
make DEBUG=1 SANITIZER=address,undefined -j"$(nproc)"
./retroarch

Version/Commit

master

Bisect Results

No response

Present in the nightly version

Yes, this is reproduced in the nightly build

Platform & operating system

Linux aarch64

Affected Cores

No response

Environment information

No response

Relevant log output

[INFO] [KMS] New FB: 720x480 (stride: 2880).
[INFO] [CRT] Requested resolution: 640x480@60.000000, orientation: normal.
[INFO] [CRT] Video context is: kms.
[INFO] [CRT] CRT mode: 2 - arcade_31.
[INFO] [CRT] SR rtn 0.
[INFO] [CRT] KMS context detected, keeping SR alive.
[DEBUG] [CRT] 640x480 rotation: 0 rotated: 0 core rotation:0
[INFO] Switchres: Calculating best video mode for 640x480@60.000000 orientation: normal
[INFO] Switchres: Modeline "640x480_60 31.500000KHz 60.000000Hz" 25.452000 640 664 760 808 480 491 493 525   -hsync -vsync
[DEBUG] [KMS] Mode details:  #0 RetroArch_CRT-640x480@60.00 60.00 640 664 760 808 480 491 493 525 25452
[DEBUG] [KMS] New mode detected: 640x480.
[INFO] [CRT] Aspect ratio forced by user: 1.333333.
[INFO] [Video] Video refresh rate changed to 60.000 Hz.
[DEBUG] [KMS] modeswitch detected, doing GBM and EGL stuff.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==88983==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000298 (pc 0x7ffec82ab3b8 bp 0x7fffca64ed60 sp 0x7fffca64ed60 T0)
==88983==The signal is caused by a READ memory access.
==88983==Hint: address points to the zero page.
    #0 0x7ffec82ab3b8  (/lib/aarch64-linux-gnu/libEGL_mesa.so.0+0x2b3b8) (BuildId: c3af8f042aee0a09ab064dd7f3d439a557cbf00c)
    #1 0x5555e98064b8 in gfx_ctx_drm_wait_flip gfx/drivers_context/drm_ctx.c:554
    #2 0x5555e98077d8 in gfx_ctx_drm_swap_buffers gfx/drivers_context/drm_ctx.c:631
    #3 0x5555e9856764 in gl2_frame gfx/drivers/gl2.c:4185
    #4 0x5555e8c45bec in video_driver_frame gfx/video_driver.c:5327
    #5 0x5555e8c27554 in video_driver_cached_frame gfx/video_driver.c:3347
    #6 0x5555e8a394d8 in runloop_check_state /home/user/RetroArch/runloop.c:6792
    #7 0x5555e8a464d0 in runloop_iterate /home/user/RetroArch/runloop.c:7825
    #8 0x5555e89ddabc in rarch_main /home/user/RetroArch/retroarch.c:6525
    #9 0x5555e89ddb7c in main /home/user/RetroArch/retroarch.c:6664
    #10 0x7ffecdf52258  (/lib/aarch64-linux-gnu/libc.so.6+0x22258) (BuildId: 13bc4af497c4104410d1e268e575ad7f1df46dd3)
    #11 0x7ffecdf52338 in __libc_start_main (/lib/aarch64-linux-gnu/libc.so.6+0x22338) (BuildId: 13bc4af497c4104410d1e268e575ad7f1df46dd3)
    #12 0x5555e8944cac in _start (/home/user/RetroArch/retroarch+0x5c34cac) (BuildId: a5f912c5fb21e069c29d94657e038dc603d9df83)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/aarch64-linux-gnu/libEGL_mesa.so.0+0x2b3b8) (BuildId: c3af8f042aee0a09ab064dd7f3d439a557cbf00c) 
==88983==ABORTING

[hizzlekizzle]

Thanks for helping pin it down!

Is there any way we could trouble you to bisect? Or at least to try the last couple of stable releases to see if it's a longstanding issue (i.e., design flaw) or just a bug that's crept in more recently?

[thetooth]

Looks like it's always been broken. I checked 1.20 and has the exact same behavior, but there are videos on yt of people using it 6 months ago on the pi5 without issues so possibly there has been some recent changes to the driver/kernel? My system is running latest raspbian lite stable.

In gfx_ctx_drm_queue_flip the flip is failing because gbm_surface_lock_front_buffer returns null after the above patch. I added some additional guards so that I can keep stepping through and after switching to any video mode below 480p (31kHz timing) egl surface breaks with "EGL_BAD_SURFACE".

I can't find any documentation on gbm surfaces whatsoever but they seem to be valid?

[gouchi]

ping @alphanu1 @substring

[substring]

Just out of curiosity, does this crash the same on the latest release ?

[thetooth]

Fellas I think I figured it out. Most people using this seem to be going with a DSI integrated DAC or using legacy GPUs that support custom modelines regardless of whether they are "valid" or not.

In my case I am using a HDMI DAC on the rpi 5. Recent-ish changes to the kernel now mean that modes MUST be valid as far as the DRM module is concerned. There are a lot of issues with the current implementation regarding error detection and handling leading to crashes whenever unsupported modes are used.

To detail what I mean about unsupported modes, in the case of HDMI, the dot clock has a minimum rate (~13.5Mhz) regardless of EDID overrides, this is a hw negotiation thing when setting up the transceiver not the TDMS clock or character clock range. There are also other kernel constraints that exist in the vc4 implementation that aren't at all apparent when you're trying to set this up. In fact the rpi 5 will only accept exact NTSC/PAL CEA timings, the default 15kHz option built into retroarch selects the arcade_15 monitor profile which is broader than SDTV and results in invalid timings for all standard SDTV modes.

Example:

• 1280x480_59i 15.734250KHz 59.940000Hz" 24.293682 1280 1316 1430 1544 480 487 493 525 interlace -hsync -vsync

Is a valid CEA mode and is accepted while

• 1280x480_60i 15.690000KHz 60.000000Hz" 26.108160 1280 1332 1455 1664 480 483 489 523 interlace -hsync -vsync

is out of range and DRM gives error code 22. I don't think there is any sense in trying to change the default behavior because it's working well for people using things like rg666 or similar, but there needs to be better documentation for switchres, and better error handling when the mode cannot be set for whatever reason.

I will add a PR that has the above patch and also adds some error messages to help users out. Below is a working switchres INI for HDMI on the rpi 5:

monitor                   ntsc
dotclock_min              13.5
super_width               1280

Perhaps a more specific profile can be made for HDMI DAC output? Since with the above you need to change between ntsc and pal every time you want to run different regions content, or the emulator core will run at the incorrect speed.

@substring yes, all released are affected.

[substring]

A kernel patch to remove that darn check on HDMI would be great. That's the very first time I hear about HDMI blocking bon conventional modes

[thetooth]

@substring I don't think that would work because we just move the problem into the driver so you will get kernel panics instead of user space errors.

I have done some more digging and found another possible failure mode that will cause a lot of timings to be rejected. The VC4 implementation on the rpi 5 and possibly all other devices using this IP, only accept horizontal resolutions that are multiples of 8.

Out of the box switchres will calculate per-pixel resolutions so your total horizontal clock can be an odd number, this is togglable in the INI file with pixel_precision where the borders will compensate for the active pixel area, this means it does not cause any shimmer because the content remains integer scaled. Additionally, this also means when you use the horizontal scale adjustment in retroarch the value must be even or VC4 rejects the timing due the byte alignment requirement.

See thetooth/rpi5-switchres for a working set up.

[substring]

You have no idea what we've patched in the kernel to get interlaced working on almost any modern AMD GPU whereas it is disabled ;)

DRM has some mechanics to validate modes and they can be driver dependant. Now the question would be : are non CEA modes rejected just because they are not supposed to exist, or because the hardware can't output them ? You've mentioned a few reasons that could be circumvented with switchres settings, so I still think kernel patching is possible somehow. But it means a non mainstream kernel, which can be an annoyance for people sticking to standard distros

[substring]

Spoke with the guy who rewrote Port Audio in groovymame as I know he thoroughly tested this on CRT with a Pi5 during the development of the kmsraw backend. He said all worked at the condition of disabling pixel precision and setting a min dotclock to 25.0 (or more, depending on HDMI adapters). Just some leads ...