Switchres picks the wrong mode

[enzo0932]

I recently replaced the Nvidia GPU in my Linux machine with an AMD one (both modern, not an old Radeon card). Switchres has not worked on my system since then -- strange, because the AMD drivers are better in every other respect. The card is an RX 7900 XT, OS is Fedora 38, running MAME v0.258 - SR 2.002v built from source on my local machine.

The issue is that Switchres will calculate and create a new display mode, and add it to the monitor successfully, but then ultimately a different display mode gets activated instead. There are two patterns this can follow:
1. The monitor's "preferred" mode gets used. The game (or MAME UI) shows up very small in the bottom-left corner on a black background.
2. The monitor switches to a pre-existing mode which is "closest" to the requested mode. For instance, circa-240p games will switch to the 640x350@85Hz mode (pulled from the EDID, some VESA list, etc. on X server startup), rather than the SR-generated mode (e.g. SR-1_384x256@110.04). Or, for a game that runs at 640x480@60Hz, SR will still make its own mode, but then ultimately switch to the pre-existing 640x480@60Hz mode from the monitor's EDID.

One or the other issue will occur at random. It's always one or the other -- the SR-generated mode never gets used.

Interestingly, it is possible to alt-tab to a terminal window after launching a game. xrandr confirms that the SR-generated mode is indeed added to the monitor, it's just not active. It is possible to run

Code: [Select]

xrandr --output DisplayPort-0 --mode SR-1_XXXxYYY@ZZZ.ZZ to switch to the desired mode, then go back to the game -- I'm not sure if this works in terms of synchronization/tearing/etc, but X doesn't complain and the monitor syncs to it. So, there is nothing wrong with the generated modes.

I've unplugged my other monitors for testing, though it doesn't have any effect. I also redid my ini file, but couldn't make any progress there either. (My ini file is attached). I've also attached a logfile where I open R-type twice: first I get one failure mode, then the other one (can't remember the order). There doesn't seem to be anything out of place however, no errors or complaints from SR. It calculates a mode, adds it, then confirms it's been added -- all true! -- and that's it.

To me, it smells like a race condition. Maybe the X server says the mode has been added before it's done "thinking about it", so when SR asks to activate that mode, it craps out. It could be that my new card just takes a little longer to finish up. (Personal experience: I once wrote a shell script to test out different display modes quickly; it didn't work until I added a 1-second delay between adding the mode and activating it. This feels similar.)

Any ideas?

[Substring]

Is it a genuine X or X over Wayland ?

[enzo0932]

Is it a genuine X or X over Wayland ?

Genuine X. At the Fedora login screen, I pick "GNOME on Xorg".

Custom modelines don't seem to be supported at all in Wayland and xrandr becomes pretty useless too, so I'm stuck with X as long as I have a CRT on my desk.

[enzo0932]

I am happy to share that I fixed both issues tonight!

The first issue was that I had modesetting turned off in my mame.ini. Oops...

Code: [Select]

modesetting               1
Setting the above fixed issue #1 from my original post, and Switchres now worked about 50% of the time. Issue #2 wasn't affected, though, so I decided to put my "race condition" theory to the test. In custom_video_xrandr.cpp, I added a 100ms software delay at the beginning of the set_timing() function:

Code: [Select]

bool xrandr_timing::set_timing(modeline *mode, int flags)
{
        log_verbose("<%d> (set_timing) delay before applying mode...\n", m_id);
        usleep(100000); // 0.1 seconds

        // Handle no screen detected case
        if (m_desktop_output == -1)
        {
                log_error("XRANDR: <%d> (set_timing) [ERROR] no screen detected\n", m_id);
                return false;
        }

// --- cut ---

And now issue #2 seems resolved as well. Of course this is a pretty ugly kludge, but I think it proves the point. I tried using an XSync() call in this same spot but it didn't have any effect. Hopefully someone else with better knowledge of the xrandr library can fix this for real.

I'm happy to test out experimental patches etc since it might be impossible for others to reproduce without the same hardware as me.