Bug 585371 - xf86DefaultModes and DMTModes should be merged
Summary: xf86DefaultModes and DMTModes should be merged
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-server
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Adam Jackson
QA Contact: desktop-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-23 20:00 UTC by Mark Ostroski
Modified: 2010-11-15 14:52 UTC (History)
3 users (show)

Fixed In Version: xorg-x11-server-1.7.7-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-15 14:52:16 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Mark Ostroski 2010-04-23 20:00:07 UTC
Description of problem:
RHEL5 included a patch, xorg-x11-server-Red-Hat-extramodes.patch, which adds ModeLines that are not included in the default Xorg server distribution.  Some of these modelines enable resolutions for widescreen LCD displays which are now quite commonplace.  RHEL6 Beta currently does not include these extramodes.  The effect of this is such that in some cases the optimal resolution cannot be selected for a display without manually adding the ModeLine to the xorg.conf file.  ModeLines are non-trivial to lookup, so it would be best to restore the ModeLines that were included in the RHEL5 distribution.  One such case where the extramodes or ModeLine is required occurs when a display is attached to the system through an analog KVM which prevents the transfer of EDID data.

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

How reproducible:

Steps to Reproduce:
1. Using 22" LCD panel, connect analog VGA connection through analog KVM switch. The KVM prevents the system from reading the EDID for the monitor, which I think normally would be used to set the correct mode.  In the absence of EDID, a correctly configured ModeLine would be required (correct?)
2. Configure xorg.conf manually, attempting to select Mode "1680x1050" without specifying the associated ModeLine.  The Monitor section must have a suitable HorizSync and VertRefresh for the monitor being used.  Example:
    Section "Monitor"
       Identifier "Monitor0"
       VendorName "Unknown"
       ModelName  "Unknown"
       HorizSync  30.0 - 81.0
       VertRefresh 56.0 - 75.0
       Option "DPMS"
    Section "Screen"
        Identifier "Screen0"
        Device "Card0"
        Monitor "Monitor0"
        SubSection "Display"
          Viewport 0 0
          Depth 24
          Modes "1680x1050"

3. Start X windows, then review /var/log/Xorg.0.log
Actual results:
Failure to start X windows with the requested resolution.  Tested using both the provided nouveau driver and the proprietary nvidia driver.  Without the required modeline, each driver auto-selects a display resolution lower than the required value.  Nouveau selects 1600x1200, nvidia selects 1024x768.

Expected results:
Expect same results as in RHEL5.  If the Monitor section is configured with an appropriate HorizSync and VertRefresh, then specifying Mode "1680x1050" should result in the use of that display resolution.

Additional info:
Workaround is to add the modelines to the Monitor section of /etc/X11/xorg.conf. I copied the ModeLines from the /usr/share/xorg/extramodes file on an RHEL5.4 build.  Another option in my case would be to remove the KVM and attach the monitor directly, then steal the ModeLine reported by the nouveau driver in /var/log/Xorg.0.log when it loads.  This may not apply in other situations (different drivers/hardware, or some other reason for missing EDID).

This problem also prevents the selection of the correct display resolution using any of the GUI display tools.

Also note that if EDID is working, then the display resolution can be set without specifying the modeline.  Clearly, my requirement is a special case where almost every user in my organization has multiple PC's and an analog KVM.

Comment 2 RHEL Program Management 2010-04-23 21:04:23 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Adam Jackson 2010-04-26 18:51:40 UTC
Actually, we should just alias the DMT mode list and xf86DefaultModes together.  The latter is almost entirely anachronism now.

Comment 6 releng-rhel@redhat.com 2010-11-15 14:52:16 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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