LCD Range / HW Refresh Failing

[DJO_Maverick]

Good evening-

So I got a new screen and it is causing some oddities.  Same box was previously using a different panel, and LCD Range / HW Refresh were working exactly as intended.  I got a LG Dualup monitor and have it rotated to approximate a big 4:3, so Windows is running rotated. 

As far as I know, I'm using the same INI config and everything else is the same, but it absolutely refuses to create new modelines now upon game launch.  I tried putting the screen to its native orientation as well to see if that was somehow affecting switchres, but no luck.  The panel can verifiably sync at least as low as 54hz tested in OSD...  and if I create custom resolutions by brute force with Radeon software, Groovy will still elect from those...  but can't figure out why HW Refresh is no longer working and dynamically generating.  Representative Rtype log attached.

Since getting this screen, Groovy also hangs on the command line upon exit.  Not sure whether that is related.  May also have to do with the old card running it at the moment...  but it has a more modern successor coming sometime this week to drive this screen.

(And no, notwithstanding its other cool features, the display doesn't support any formal VRR)

Thanks-

[DJO_Maverick]

Still struggling with this.  Still looks like it ought to be working.

Also seems like the log is indicating that it is trying to set a resolution based on the resolution before the monitor is rotated in Windows (2560x2880, instead of 2880x2560).  It seems to be limiting itself to a width of 2560 even when it's something that can be cleanly integer scaled to the whole rotated panel width (320x9=2880).  Is the proper fix for that just setting super_width to 2880?

EDIT - Disregard the res rotating part, I figured out what was going on there.  So, back to just the HW Refresh and hang-on-exit issues from the prior log.

[Calamity]

The problem is that mode has a higher pixel clock than allowed by the old api. I patched CRT Emudriver to overcome this issue but you're using stock drivers (since your card isn't supported anyway, I'm seeing).

By looking at their docs, AMD has updated their api to allow higher values. This will require an update to Switchres code to handle the newer api.

[DJO_Maverick]

The problem is that mode has a higher pixel clock than allowed by the old api. I patched CRT Emudriver to overcome this issue but you're using stock drivers (since your card isn't supported anyway, I'm seeing).

By looking at their docs, AMD has updated their api to allow higher values. This will require an update to Switchres code to handle the newer api.

Thanks for the response.  So what's the least-bad option until such an update?  Just make a lot of manual custom resolutions and turn off modeline generation?

[DJO_Maverick]

Well, that idea certainly didn't work.  Trying to figure out what set of options would prevent it from trying to generate modes for the too-high pixel clock but still select the closest custom pre-generated resolution available, thus preventing mame from hanging on closing...  at least until a switchres update.

Oddly enough, now that I got the new card in that can handle that display (RX 6400 low profile), with its driver in, the behavior changed again a bit, even though the mame ini didn't.  Now it loads the lowest custom refresh available, no matter what the actual refresh of the game is (ie, if there's a 41hz mode for Star Wars...  groovy switches into that 41hz mode for everything).  Will tack on an additional log in a bit.