Bug 322861
Summary: | vesa mode validation doesn't handle multiple modes of the same size correctly | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Eric Smith <spacewar> | ||||||
Component: | xorg-x11-drv-vesa | Assignee: | Adam Jackson <ajax> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 7 | CC: | piskozub, triage, xgl-maint | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2008-06-17 02:36:08 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Eric Smith
2007-10-08 08:50:53 UTC
Created attachment 219111 [details]
log from X server 1.1.1 on Fedora Core 6
Created attachment 219121 [details]
log from X server 1.3.0 on Fedora 7
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. 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. 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. 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. (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. 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 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. |