Bug 507536 - Xserver selects the largest mode available and not the most suitable
Xserver selects the largest mode available and not the most suitable
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-server (Show other bugs)
5.3
All Linux
high Severity high
: rc
: 5.5
Assigned To: Adam Jackson
desktop-bugs@redhat.com
: Patch, Regression, Reopened
Depends On:
Blocks: 499522
  Show dependency treegraph
 
Reported: 2009-06-23 04:40 EDT by Olivier Fourdan
Modified: 2013-03-03 21:48 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:33:55 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)
Proposed Patch (3.67 KB, patch)
2009-06-23 04:40 EDT, Olivier Fourdan
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0259 normal SHIPPED_LIVE xorg-x11-server bug fix update 2010-03-29 08:50:08 EDT

  None (edit)
Description Olivier Fourdan 2009-06-23 04:40:10 EDT
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.
Comment 3 Martin Wilck 2009-07-27 05:01:15 EDT
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.
Comment 6 RHEL Product and Program Management 2009-07-27 16:05:28 EDT
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.
Comment 12 RHEL Product and Program Management 2009-07-28 13:32:05 EDT
Quality Engineering Management has reviewed and declined this request.  You may
appeal this decision by reopening this request.
Comment 15 RHEL Product and Program Management 2009-10-08 12:04:06 EDT
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.
Comment 17 Chris Ward 2009-10-13 11:07:15 EDT
@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.
Comment 23 Chris Ward 2009-11-10 07:07:27 EST
@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.
Comment 24 Martin Wilck 2009-11-10 08:53:33 EST
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@ts.fujitsu.com.
Comment 27 Adam Jackson 2009-12-02 13:52:10 EST
Build xorg-x11-server 1.1.1-48.70.el5

MODIFIED
Comment 30 Chris Ward 2010-02-11 05:03:40 EST
~~ 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.
Comment 35 errata-xmlrpc 2010-03-30 04:33:55 EDT
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

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