# fbset-fbmodes.fixture -- fb.modes(5) content for the fbset self-test.
#
# EVERY STANZA HERE PARSES UNDER fbset 2.1's OWN GRAMMAR, which is a narrower
# thing than "valid fb.modes" and is the reason this file exists rather than
# reusing data/fbset-modes-fbmodes.fixture. That one is written for the awk
# model in 99-fbset-modes.test, which accepts the two-name `mode "vga"
# "640x480"' form; modes.y is `vmode : MODE STRING geometry timings options
# ENDMODE', one STRING, and both geometry AND timings mandatory -- so the awk
# fixture is a syntax error at its first stanza, measured, not assumed.
#
# The five stanzas below are arranged to reach every conditional in BOTH of
# DisplayVModeInfo's output arms, which is what the byte-for-byte comparison
# against the x86-64 oracle is a statement about:
#
#   480x640      geometry + timings + one option. From the fbset-modes recipe's
#                own om-gta01/fb.modes, VERBATIM -- the one machine variant of
#                the five that fbset 2.1 can actually read.
#   800x480-65   omap3-pandora/fb.modes, with rgba's argument QUOTED. The
#                unquoted spelling upstream ships is a syntax error here:
#                `rgba : RGBA STRING' and the lexer's string rule is
#                \"[^\"\n]*\", so an unquoted 5/11,... lexes as NUMBER first.
#                That is not this fixture being fussy -- it is why
#                omap3-pandora/fb.modes does not parse, and the correction is
#                the whole of the difference.
#   1024x768-60  standard VESA timings, reaching the keywords the two real
#                variants never use, all in their OFF/low spelling.
#   flags-high   the same keywords in their ON/high spelling, so both sides of
#                every `if (vmode->x)' in both printers are covered. Composed.
#   noclock      pixclock 0, which is the ONLY way to reach `puts("\"")' in the
#                fb.modes arm and `DotClock Unknown' in the XFree86 one --
#                every other stanza takes the D:/H:/V: branch. Composed.
#
# gsync IS NOT A BOOLEAN HERE even though fbset's own usage text and its own
# output both call it one: modes.y says `gsync : GSYNC POLARITY', so `gsync
# low'/`gsync high' parse and `gsync true' does not. See the round-trip cases
# in 99-fbset.test -- that mismatch is a defect in fbset 2.1, and this fixture
# spells it the way the parser accepts so the rest of the file can be read.

# --- verbatim from the fbset-modes recipe's om-gta01/fb.modes ---------------
mode "480x640"
    # D: 26.000 MHz, H: 43.334 kHz, V: 65.657 Hz
    geometry 480 640 480 640 16
    timings 38461 104 8 2 16 8 2
    accel false
endmode

# --- omap3-pandora/fb.modes, with rgba's argument quoted so it parses -------
mode "800x480-65"
    # D: 36.001 MHz, H: 34.124 kHz, V: 64.998 Hz
    geometry 800 480 800 480 16
    timings 27777 40 214 10 34 1 1
    rgba "5/11,6/5,5/0,0/0"
endmode

# --- COMPOSED: every remaining keyword, in its off/low spelling -------------
mode "1024x768-60"
    geometry 1024 768 1024 768 16
    timings 15384 160 24 29 3 136 6
    hsync low
    vsync low
    csync low
    gsync low
    extsync false
    bcast false
    laced false
    double false
    nonstd 0
    grayscale false
endmode

# --- COMPOSED: the same keywords in their on/high spelling ------------------
# laced and double are mutually exclusive in FillScanRates (dblscan wins), so
# both being set here also pins which one the scan-rate arithmetic takes.
mode "flags-high"
    geometry 320 240 320 480 8
    timings 39721 16 16 8 8 24 4
    hsync high
    vsync high
    csync high
    gsync high
    extsync true
    bcast true
    laced true
    double true
    nonstd 7
    accel true
    grayscale true
    rgba "3/5,3/2,2/0,0/0"
endmode

# --- COMPOSED: pixclock 0, the no-DotClock branch of both printers ----------
mode "noclock"
    geometry 640 480 640 480 8
    timings 0 0 0 0 0 0 0
endmode