Created attachment 349061 [details] Proposed Patch Description of problem: The X server tries to infer the aspect ratio of the screen, and estimates the virtual size of the screen as the largest mode in the combined list of modes given then runs through the mode list checking it against the sync ranges from the monitor and the driver's ValidMode hook. In doing so it might filter away all modes that exactly match the earlier aspect ratio guess in which case the server picks the mode with the next most area by pixel count. This results in peculiar modes being selected, instead of the more logical next available mode listed by the monitor. Version-Release number of selected component (if applicable): xorg-x11-server-1.1.1-48 How reproducible: 100% reproducible Steps to Reproduce: 1. Install "xorg-x11-drv-mga-1.4.10-2" in a server with a Matrox G200e SE card 2. Make sure to use 24 bpp 3. Start the X server Actual results: (II) MGA(0): Estimated virtual size for aspect ratio 1.2593 is 1280x1024 ... (II) MGA(0): Not using default mode "1280x1024" (unknown) (II) MGA(0): Not using default mode "1280x1024" (unknown) (II) MGA(0): Not using default mode "1280x1024" (unknown) ... (WW) MGA(0): Shrinking virtual size estimate from 1280x1024 to 1280x800 (--) MGA(0): Virtual size is 1280x800 (pitch 1280) => The mode 1280x800 is used in replacement of 1280x1024 Expected results: (II) MGA(0): Estimated virtual size for aspect ratio 1.2593 is 1280x1024 ... (II) MGA(0): Not using default mode "1280x1024" (unknown) (II) MGA(0): Not using default mode "1280x1024" (unknown) (II) MGA(0): Not using default mode "1280x1024" (unknown) ... (WW) MGA(0): Shrinking virtual size estimate from 1280x1024 to 1024x768 (--) MGA(0): Virtual size is 1024x768 (pitch 1024) => The mode 1024x768 is used in replacement of 1280x1024 Additional info: What happens is that the original estimated virtual size is not supported by the hardware (the bandwidth is not supported by the chipset). But instead of selection the next mode advertised by the monitor which would give the best result, the X server selects the largest mode in pixels, so it picks up a mode that is very different from the modes listed by the monitor. The following patch changes the logic, and instead of picking the largest area, it looks first in the builtin modes, the driver modes and at last the rest of modes which includes the default modes. This way, if there is no mode matching the initial mode, we do not end up picking a random mode and prefer instead a user defined or a monitor mode. As the virtual size is changed, the line pitch also needs to be recalculated.
I prefer the patch from bug #508039, which fixes the Fujitsu/FTS problem (wrong resolutions with G200SE at depth 24) without deep and tricky logic changes.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.
@Fujitsu, We would like to confirm that there is commitment to test for the resolution of this request during the RHEL 5.5 test phase, if it is accepted into the release. Please post a confirmation before Oct 16th, 2009, including the contact information for testing engineers.
@Larry, @Fujitsu, Before we approve this request we need to get commitment to test. Unfortunately, we do not have the proper hardware to verify this fix in-house. Any additional information about alternative hardware variations we could use to reproduce this issue would be helpful.
Test hardware has been shipped to Red Hat on August 18. A ServerEngines Pilot2 boartd (idential VGA-wise to our HW) should also be available at Red Hat. We will be doing Red Hat regular beta test and we will of course test Kronos2 in the course of that beta test. Contact is myself and peter.pols.com.
Build xorg-x11-server 1.1.1-48.70.el5 MODIFIED
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~ RHEL 5.5 Beta has been released! There should be a fix present in this release that addresses your request. Please test and report back results here, by March 3rd 2010 (2010-03-03) or sooner. Upon successful verification of this request, post your results and update the Verified field in Bugzilla with the appropriate value. If you encounter any issues while testing, please describe them and set this bug into NEED_INFO. If you encounter new defects or have additional patch(es) to request for inclusion, please clone this bug per each request and escalate through your support representative.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0259.html