Having followed this thread a bit, and gotten a bit lost in the details - again, what are you trying to attempt here?...and what is your overall progress?
We are trying to utilize the full potential of an arcade monitor for refresh rate exactness (to drive the game by that if possible, so avoid tearing at least expense of the system by following the video cards vsync interrupts), and general resolution/modeline duplication (similar to what Advanced Mame did/does but in a way that uses the systems native methods like the registry and xrandr in Linux, so we are able to keep it up to date and have it be more transparent and separate from Mame). We want to do this equally well in both Linux and Windows, basically no limited modeline counts.
So far the progress is, in Linux things are pretty much perfect if you have most Radeon cards, although there's some issues in the OpenGL side stopping certain ones from working. I have a d9800 and can run everything just about perfect vsync and hxw, no throttle and no tearing or sound slowness or fastness.
So far in Windows we have gotten the ability on the Radeon/ATI driver/cards to do about the same within limits of 60 predefined hxw combinations but we can dynamically rewrite those modelines to change the refresh rates to what we need (so mostly all games will be able to do the same as in Linux, but there's really 100 or so hxw modelines needed to match Linux with a few exceptions, possibly 160 or so to do just about the exact same in Windows).
Also out of this there's a Linux cabmame version able to utilize arcade monitors, same patches, plus it works in 140u2 for Windows too, extra benefit to help our goal of running full potential of arcade monitors there.
So basically the ATI radeon drivers in Windows can eventually be patched to hold the needed 160 custom modelines, Calamity is working on that. Would be nice to dynamically load modelines in all drivers for Windows, I'm not sure if that'll happen unless people figure out how to patch them (The ATI one seems to just do it with certain API calls done with it).
In Linux we need to expand into other cards besides ATI Radeon ones, although the other drivers in Linux not as matured as the ATI DRM one currently (Nvidia and Intel ones *might* work though, untested). Also figure out these OpenGL issues, in Linux it's best to build a distribution to do all this because it requires patches to the system and very new code they are just releasing combined with just the right build options and setup. So we've done that, and it's working quite well besides rough edges and the compatibility. We seem to be now figuring out some things about J-Pac support, there's a few issues there with driving it correctly since the system can't really sense the monitor so the issues are probably due to that.
Also of course the modeline generation of SwitchRes is quite nice and probably the best out there of any modeline generator for Arcade monitors, which was at first the main goal but it turns out to get those modelines to work on systems you have to do all the other work too. Fortunately we have Soft15khz to do the registry setup of modelines in Windows for us to dynamically modify, and in Linux the DRM KMS kernel work and xrandr to push the modelines into work there.
It's quite a list of stuff we want to do because of the goal of the full potential (arcade monitors and radeon cards, and others, in theory should be able to really get perfect display on a d9800, and near perfect for a lot of games on other monitors, which that hasn't ever been exploited before this), but we've done a lot too at the same time so that if you have a radeon card and arcade monitor both Windows and Linux have increased capability at display on arcade monitors with exact vsync within the monitors physical limitations.