Bug 14383

Summary: EDID parser doesn't pick a preferred mode if one isn't marked
Product: xorg Reporter: Benjamin Otte <otte>
Component: Server/GeneralAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: 7.3 (2007.09)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Benjamin Otte 2008-02-05 02:36:10 UTC
So the Ubuntu people said "please file this upstream", so here it goes. See
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/147846
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/189198
for further details, including various X logs.

The short summary is:
I have a R100 and it comes up in 1600x1024, which doesn't work properly. In fact, 1600x1024 and 1440x900 are the only non-working resolutions. Everything else from 1920x1200 to 640x350 works properly.

I'm running without xorg.conf, the Xorg log is at http://launchpadlibrarian.net/11769885/Xorg.0.log
Comment 1 Timo Aaltonen 2008-02-05 02:40:37 UTC
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 :)
Comment 2 Alex Deucher 2008-02-05 09:07:46 UTC
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
Comment 3 Benjamin Otte 2008-02-06 00:27:10 UTC
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?
Comment 4 Daniel Stone 2008-02-06 00:38:26 UTC
(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?
Comment 5 Benjamin Otte 2008-02-06 00:55:53 UTC
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.
Comment 6 Alex Deucher 2008-02-06 14:18:04 UTC
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.
Comment 7 GitLab Migration User 2018-12-13 22:18:46 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.