Bug 322861 - vesa mode validation doesn't handle multiple modes of the same size correctly
vesa mode validation doesn't handle multiple modes of the same size correctly
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-08 04:50 EDT by Eric Smith
Modified: 2009-10-22 08:44 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 22:36:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log from X server 1.1.1 on Fedora Core 6 (78.17 KB, text/plain)
2007-10-08 04:50 EDT, Eric Smith
no flags Details
log from X server 1.3.0 on Fedora 7 (77.72 KB, text/plain)
2007-10-08 04:51 EDT, Eric Smith
no flags Details

  None (edit)
Description Eric Smith 2007-10-08 04:50:53 EDT
Description of problem:

The X server supplied with Fedora Core 6 works fine with an ATI Radeon HD2600
Pro card (using VESA driver) and Samsung SyncMaster213T LCD monitor (1600x1200)
connected by DVI; a suitable Xorg.conf is created by the installation process. 
On Fedora 7, however, the X server claims that the 1600x1200 mode has too high
an hsync, and only allows a maximum resolution of 1280x1024.

Both X servers show two different modelines for 1600x1200:  one using a 161 MHz
pixel clock, and one using 130.37 MHz.  The latter is suitable for the monitor,
with all parameters within range.  On Fedora Core 6, the server correctly picks
the latter.  On Fedora 7, the server apparently either rules out both, or
doesn't consider the second one.


Version-Release number of selected component (if applicable):

Fedora 7:   1.3.0.0-9.fc7 
Fedora Core 6:   1.1.1-47.fc6 

How reproducible:

100%

Steps to Reproduce:
1.  Install Fedora 7 with an ATI Radeon HD2600 Pro card and a 1600x1200 LCD
monitor using a single-link DVI display.
  
Actual results:

Default (and maximum) display resolution is 1280x1024

Expected results:

Default and maximum display resolution should be 1600x1200, as it is with Fedora
Core 6.

Additional info:

I doubt that this problem is specific to the video card I'm using, though I have
not tested other cards.

I suspect the algorithm for evaluating suitability of modelines must have
changed between 1.1.1 and 1.3.0, causing this problem.

I will attach the server logs from both servers.
Comment 1 Eric Smith 2007-10-08 04:50:53 EDT
Created attachment 219111 [details]
log from X server 1.1.1 on Fedora Core 6
Comment 2 Eric Smith 2007-10-08 04:51:55 EDT
Created attachment 219121 [details]
log from X server 1.3.0 on Fedora 7
Comment 3 Eric Smith 2007-10-11 15:25:31 EDT
Tracked down the bug.  The patch vesa-1.3.0-mode-heuristics.patch in the SRPM
breaks the processing of the modelines; if I comment out the %patch1 line in the
SRPM and rebuild, the VESA driver finds the working 1600x1200 mode just as it
did with in FC6.  I don't fully understand the patch, but it appears to cause
the second 1600x1200 mode found by EDID to be ignored, even though it is a valid
mode and the first was not.
Comment 4 Eric Smith 2007-10-11 19:00:22 EDT
I probably should have been more precise in my last comment on this bug.  I
narrowed down the location of the bug, but I don't have any proposed fix. 
Presumably the mode heuristics patch is necessary to solve problems other users
have encountered, but I don't know exactly what those problems are, so I'm not
sure how to improve it to solve my modeline problem without breaking any
desirable behavior it provides.
Comment 5 Adam Jackson 2007-10-16 10:09:24 EDT
I think I see what's happening here.  The monitor is actually reporting a
1600x1200 mode that it can not possibly do:

(II) VESA(0): Ranges: V min: 56  V max: 75 Hz, H min: 30  H max: 81 kHz,
PixClock max 140 MHz

But yet:

(II) VESA(0): Modeline "1600x1200"  161.00  1600 1712 1880 2160  1200 1203 1207
1245 -hsync +vsync

161 > 140 by quite a bit; the only 16x12 mode the monitor could actually do is
one with reduced blanking.  But we're only checking timings based on standard
blanking.

So either the monitor is lying, or the card is somehow smart enough to do
reduced blanking setup for you?  Hmm.
Comment 6 Eric Smith 2007-10-16 13:38:01 EDT
With all due respect, I think you're mistaken.  Here's an excerpt from the
attached log from FC6:

(II) VESA(0): Modeline "1600x1200"  161.00  1600 1712 1880 2160  1200 1203 1207
1245 -hsync +vsync
(II) VESA(0): Modeline "1280x1024"  109.00  1280 1368 1496 1712  1024 1027 1034
1063 -hsync +vsync
(II) VESA(0): Modeline "1600x1200"  130.37  1600 1648 1680 1760  1200 1202 1206
1235 -hsync +vsync

The monitor is reporting TWO 1600x1200 modes, the second of which is within its
capabilities.  I'm not sure why it reports the first.  Before the
mode-heuristics patch was introduced, the server correctly determined that it
could use the second 1600x1200 modeline.

With the mode-heuristics patch, it won't do 1600x1200 at all, even if I try to
add the appropriate modeline explicitly to the xorg.conf.  I suspect that when
it sees the first 1600x1200 and determines it to be unsuitable, it is ignoring
the second 1600x1200 mode.  But I don't really understand the code well enough
to verify that.

Comment 7 Adam Jackson 2007-10-22 11:29:44 EDT
(In reply to comment #6)
> The monitor is reporting TWO 1600x1200 modes, the second of which is within its
> capabilities.  I'm not sure why it reports the first.  Before the
> mode-heuristics patch was introduced, the server correctly determined that it
> could use the second 1600x1200 modeline.

Yes, I kind of said that.  The heuristics patch scans the other way around
though; it only sees one entry for 1600x1200 in the video BIOS, then scans the
list provided by the monitor for the first match.  This is clearly broken.

I had missed that VBE can actually set arbitrary blanking intervals on modes as
long as the size in question is in the BIOS table.  I don't know that our driver
is actually taking advantage of that, but I suppose it could be!  I'm looking
into it.
Comment 8 Bug Zapper 2008-05-14 10:39:33 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2008-06-16 22:36:05 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.