Red Hat Bugzilla – Bug 494979
nv ignoring requested resolution in xorg.conf
Last modified: 2010-10-05 14:08:48 EDT
Description of problem: The nv driver is choosing an odd resolution instead of the one requested by system-config-display. The system has an nVidia NV44 [Quadro NVS 285] connected to an ACR ad87 CRT monitor. The monitor has a native resolution of 1440x900, and that is what is listed in the xorg.conf: SubSection "Display" Viewport 0 0 Depth 24 Modes "1440x900" "1400x1050" "1280x1024" "1280x960" "1280x800" "1152x864" "1024x768" "800x600" "640x480" EndSubSection However, X starts with a virtual resolution of 1440x1050, a strange combo of the larger dimensions of 1440x900 and 1400x01050: (--) NV(0): Virtual size is 1440x1050 (pitch 1440) Version-Release number of selected component (if applicable): hwdata-0.213.11-1.el5-noarch system-config-display-1.0.48-2.el5-noarch xorg-x11-drv-nv-2.1.12-3.el5-x86_64 xorg-x11-server-Xorg-1.1.1-48.52.el5-x86_64 How reproducible: every time Steps to Reproduce: 1. configure xorg.conf with a preferred resolution of 1440x900 Actual results: X starts at 1440x1050 Expected results: X starts at 1440x900 Additional info: I took the hex EDID data from the Xorg.0.log and converted it to a binary with 'xxd -r -p' and then ran that through an EDID decoder from Adam Jackson and got: $ ./edid-decode acr-ad87.bin Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 04 72 87 ad 00 00 00 00 29 10 version: 01 03 basic params: 08 29 1a 78 e8 chroma info: 9a e5 a6 58 49 99 23 11 50 54 established: bf ef 80 standard: 90 4f 95 0f 81 80 81 40 81 0f 81 00 71 90 71 4f descriptor 1: c4 22 a0 a0 50 84 1a 30 30 20 36 00 9a 01 11 00 00 1e descriptor 2: 00 00 00 fd 00 38 4c 1f 54 0e 00 0a 20 20 20 20 20 20 descriptor 3: 00 00 00 ff 00 36 34 31 30 31 34 31 39 34 30 31 30 0a descriptor 4: 00 00 00 fc 00 41 4c 31 39 31 37 57 0a 20 20 20 20 20 extensions: 00 checksum: d4 Manufacturer: ACR Model ad87 Serial Number 0 Made week 41 of 2006 EDID version: 1.3 Analog display, Input voltage level: 0.7/0.3 V Sync: Separate Maximum image size: 41 cm x 26 cm Gamma: 2.20 DPMS levels: Standby Suspend Off RGB color display Established timings supported: 720x400@70Hz 640x480@60Hz 640x480@67Hz 640x480@72Hz 640x480@75Hz 800x600@56Hz 800x600@60Hz 800x600@72Hz 800x600@75Hz 832x624@75Hz 1024x768@60Hz 1024x768@70Hz 1024x768@75Hz 1280x1024@75Hz 1152x870@75Hz Standard timings supported: 1400x1050@75Hz 1440x900@75Hz 1280x1024@60Hz 1280x960@60Hz 1280x800@75Hz 1280x800@60Hz 1152x921@76Hz 1152x864@75Hz Detailed mode: Clock 89.000 MHz, 410 mm x 257 mm 1440 1488 1520 1600 hborder 0 900 903 909 926 vborder 0 +hsync +vsync Monitor ranges: 56-76HZ vertical, 31-84kHz horizontal, max dotclock 140MHz Serial number: 641014194010 Monitor name: AL1917W Checksum: 0xd4 EDID block does NOT conform to EDID 1.3! Missing preferred timing
Created attachment 338809 [details] example xorg.conf and Xorg.0.log files This is a tar of some xorg.conf and Xorg.0.log files showing the strange behavior. new-config/* contains the default, generic, bare-bones xorg.conf, and the Xorg.0.log shows the display running at 1440x900, the native resolution of the monitor. (--) NV(0): Virtual size is 1440x900 (pitch 1440) initial-reconfig/* has an xorg.conf with a requested mode of 1440x900 (as shown in comment #0), but it starts at 1440x1050 (--) NV(0): Virtual size is 1440x1050 (pitch 1440)
But that's not wrong. Your monitor really does claim to support both 1400x1050 and 1440x900. The latter is _preferred_, but both are listed. We pick a virtual size large enough for any supported resolution; since both are supported we pick a box that's big enough for either. Virtual size is not resolution. It's just how much video memory is reserved for display. At any rate, according to the log we then pick the preferred resolution by default. So unless that's really not working, I don't think this is a bug. Are you seeing the wrong resolution displayed?
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.