Bug 10754

Created attachment 9733 [details]
config file

Created attachment 9734 [details]
log with DDC enabled

Created attachment 9735 [details]
log with DDC disabled

Probably just broken EDID data from the monitor.  What manufacturer/model is it?

that question is answered in the log with ddc - isn't it obvious that "Manufacturer: IVM  Model: 1901  Serial#: 0" is an iiyama vision master pro 450? :-D
there are sufficiently many broken crts out there - the weirder it seems that xorg seems to let ddc override the sync limits explicitly requested in xorg.conf.

fwiw, Modes is not *completely* ignored - if it contains no supported mode, the server aborts. but afterwards it is simply ignored - why else would 1600x1024 be chosen when 1280x1024 is the max?

i don't think retitling this report was very wise; it doesn't reflect the issues properly any more. instead, the problems need to be isolated and more reports filed once it is halfways clear what is going on. *then* one can think about reducing this report to one issue.

update. now using the 2.1 driver.
with ddc it doesn't try to nuke the crt any more ;), so the title definitely doesn't match any more. so i'm changing it.
the remaining problems still exist: the explicitly set Modes are ignored after validation, and the automatically chosen mode is adequate for 16:9 or something, but definitely not for 4:3.

    HorizSync   31.5-105
    VertRefresh 40-150

You're specifying ranges beyond the capability of your monitor.  Please remove them (and probably the rest of the custom configuration) and try again.

that doesn't matter - my last test was *without* dcc (*), so the crt would shut off/explode, but not the driver refuse to work because of *that*.
and the modelines in question are well within the crt's capabilities - they actually *work* (with another card+driver), you know.

(*) in case it wasn't obvious, the comment about dcc referred exclusively to the fact that this particular sub-issue is gone.

minor correction: actually, i have no idea, whether the modelines are still picked up by the nv-based setup - i didn't try it for something like four years. but i know that the parameters are correct as such.

removing the modelines didn't change a thing.
removing the Modes (be it built-in modes or my modes) didn't make a difference, either; i always get a 16:9 mode.
not sure this is entirely consistent with previous observations ... the interaction of ddc, modelines and modes makes isolating the real pattern pretty hard. and it's damn late at night here. :)

By dcc you mean ddc, right?  You need DDC in order for your monitor to tell the driver what capabilities it has.  Otherwise, the user has to specify them, and the user usually gets them wrong (as you did).  If you have the wrong ranges specified, we will validate in modes that your monitor can't handle.

So, remove your manual configuration, and things should just work.

slowly you are making me angry. so let me repeat it one last time: the config is *valid*. it *works* with the nv driver with an old server (it was still xfree at that time).

anholt@vonnegut:/home/anholt% gtf 2048 1536 60

  # 2048x1536 @ 60.00 Hz (GTF) hsync: 95.34 kHz; pclk: 266.95 MHz
  Modeline "2048x1536_60.00"  266.95  2048 2200 2424 2800  1536 1537 1540 1589  -HSync +Vsync

This modeline is within the ranges you have told your driver that your monitor supports.  Is it actually supported by your monitor?

of course it isn't. and guess what? i told the server to use only the modes i specified. too bad that it outright ignores my command.

Created attachment 11653 [details]
another log

xserver 1.3 now. the situation got slightly better:
- with ddc, i get a reasonable initial mode
- without ddc i also get one, even though it is clearly underpowering the crt (1024x768) despite better modes being available.
that means that i'm almost back to a pre-modesetting state. but:
- Modes is now ignored. and i mean ignored - not even a non-existing mode is complained about. ModeLines are picked up, as the log indicates.
- the calculated dpi is completely off. for another report, i guess.
- it seems that after some video mode switches the graphics mode (but not the text mode) produces no color signals any more (but still correct timings). InitPrimary does not help, i have to reboot. clearly for yet another report.

Created attachment 11654 [details]
config file

err, xserver 1.4, of course. driver 2.1.1. as packaged by debian.

for reference, the current config.

OK, with that last log, things look a lot better and there are now some clear issues with the server mode handling code for supporting your monitor.  The most severe is that 1280x1024 is being chosen contrary to the EEDID 1.3 spec (presumably accurate for 1.1 as well) that preference should be given to standard timings in order listed after detailed timings.

Also, we're adding modes from our standard modes table just because they fit the range of hsync/vsync used by timings from DDC, despite having a wide selection of modes to choose from already from DDC (afaik that code was originally motivated by 1: not having ddc and wedging old code into place in the post-DDC world, 2: flat panel scalers that have just 1 or 2 modes in EDID but which can scale whatever you throw at it.  We're exposing that with new randr abilities soon, so it may become irrelevant).

Created attachment 12453 [details] [review]
respect Modes option

user: why is my "Modes" line ignored?
xorg: uhm ... probably because we don't call the function to make use of it anywhere.
user: ah, sounds plausible ... ermm ... !?!?!

Created attachment 12460 [details] [review]
add UseDdcModes and UseDefaultModes options

mainly to simplify debugging, add options to suppress using modes from edid and generating default modes.
maybe the options should be pre-parsed elsewhere - no idea.

Created attachment 12473 [details] [review]
consider horizontal resolution, too, when picking initial mode

this doesn't seem to be necessary for my configuration any more, but it seems more correct that way. dunno.
note that i weight a horizontal mismatch less than a vertical one - you might want to tune that factor in either direction.

correct the component field...

not really. all the patches i submitted apply to the server, not the driver. afaics at this point, there are no driver-specific issues.

ok. thanks for correction. change the component field again. sorry for the spam.

Created attachment 15140 [details] [review]
consider horizontal resolution, too, when picking initial mode (rebased)

somebody feels like finally reviewing these patches?

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.