Bug 14383

Note that he tried using the driver snapshot by Tormod Volden (xserver-xorg-video-ati_6.7.197+git20080201.b.a38a903d-0ubuntu0tormod), which was pretty recent :)

This is an xserver bug.  Since your monitor's edid is not specifying a perferrred mode, the xserver is picking one that just happens to be one the monitor doesn't like.  you can work around this by adding a PerferredMode line to your monitor section and associating that monitor section with VGA-0.  See this page for more info:
http://www.intellinuxgraphics.com/dualhead.html

Yeah, my GNOME tends to xrandr into my preferred resolution on startup, so I didn't notice this bug until GNOME broke so there's enough workarounds. But I want it fixed right now, as the problem I'm seeing with this is that it's pretty critical for newly installed machines of average users who just get a broken screen.

It also looks like the code is either very dumb or deliberately stupid, because it seems to pick the most braindead resolution it can find.

So who do I need to poke to get that fixed?

(In reply to comment #3)
> It also looks like the code is either very dumb or deliberately stupid, because
> it seems to pick the most braindead resolution it can find.

Given that your monitor has indicated it can support all these resolutions -- including the ones that it doesn't -- and that it hasn't marked any particular mode as being its preferred/native mode, despite it being standard practice to do so, what would you recommend?

Two ideas come to mind from how I'd figure out a sane resolution:
1) ask the graphics card for its preferred resolution(s). This idea comes from looking at the supported frequencies per resolution in the xrandr output. More frequencies/higher frequency per resolution means better chance that it works.
2) Hardcode a list of resolutions that old/stupid monitors are likely to support and use them preferrably. That's what I do if something doesn't work: Try 1024x768 or 640x480 before trying 1600x1024.

I'd even prefer coming up in 640x480 to not coming up at all.

we should probably just pick the first detailed timing block as the preferred mode if the edid doesn't specify one.  I've seen quite a few similar bugs.  In the case of this bug that mode would be:

(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 229.5 MHz   Image Size:  354 x 265 mm
(II) RADEON(0): h_active: 1600  h_sync: 1664  h_sync_end 1856 h_blank_end 2160 h_border: 0
(II) RADEON(0): v_active: 1200  v_sync: 1201  v_sync_end 1204 v_blanking: 1250 v_border: 0

This edid is also not 1.2 compliant despite what it reports.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/360.