You could convert the ToastyX numbers earlier in this thread, to proper ModeLines.
There's a formula to convert a ToastyX GUI into one text line (called a "ModeLine")
Did you try this, and did it work?
Also, this is too low:
HorizSync 30.0 - 200.0
Remember HorizSync is number of pixel rows per second, as screen refresh top to bottom --
www.blurbusters.com/scanout !!! -- Assuming a typical 1080p refresh cycle is 1125 pixels tall (HDTV standard size; 1080 visible plus 45 VBI (vertical blanking interval) being used as spacer between refresh cycles). Now if you're needing overclock headroom to 240....
1125 pixel rows x 240 refresh cycles per second
1125 x 240 = 270000
Scan rate = 270000 pixel rows per second = 270.0 KHz
In this case, one pixel row is transmitted out of the GPU output in 1/270000sec, during a VT1125 240Hz signal, spewing out all those pixel rows, as a defacto serialization of 2D image into a 1D cable.
So whomever told you to use 200.00 totally screwed up, and since I know one person overclocked to 265 Hz successfully, so let's round up to 300.00 KHz or 350.00 KHz to give you enough optional overclock room. Remember, these are not guaranteed to work, but you don't want to limit your own horizontal scan rate.
Corrected numbers:
HorizSync 30.0 - 300.0
As a rule of thumb, multiply your vertical resolution by approximately 1.05 (common VBI size is ~5% of vertical resolution, this varies a lot), then by refresh rate, then divide by 1000, add a safety margin, and that's the upper-bound number you should use for HorizSync So napkin math (1080p x 1.05 x 265 Hz) is about 300000. This is a mostly futureproof formula, for any future vertical resolution that's not a big VBI (e.g. Large Vertical Total,
Quick Frame Transport, etc). Large vertical totals
can reduce strobe crosstalk if you use motion blur reduction, but this is not as important if you're not using strobing.
On the GPU, refresh cycles are into a stream of pixels when pushed out of (VGA|DVI|DP|HDMI|tincans|whatever), raster-style (like reading a book or calender), beginning with the upper-left pixel, left-to-right, top-to-bottom, serializing 2D into 1D. The blanking intervals are the (porches + sync) combined. And you've got both a horizontal blanking interval and a vertical blanking interval.
Figuratively, by only using "200.0", somebody is trying to fly an airplane without learning to fly an airplane first.
If you can create bash scripts and compile a Linux kernel, then this stuff is dirt-easy to learn. This might not be enough, you may need to learn how to convert ToastyX numbers to Linux ModeLine numbers.
Please study
Custom Resolution Utility Glossary
A video signal is mapped out like this, this will help you understand how to convert ToastyX numbers to ModeLines:
P.S. Most Linux users have tended to be advanced users/programmers. I welcome such readers to read do some advanced reading of refresh cycle science & physics,
www.blurbusters.com/area51 -- not relevant to the above, but these are textbook reads by less experienced engineers at monitor manufacturers. Some people do buy 240 Hz and 360 Hz monitors just for better web browser scrolling and improved desktop experience (240Hz has 1/4th the scrolling motion blur of 60Hz, and 360Hz has 1/6th the scrolling motion blur of 60Hz), as high Hz is not just for esports anymore.