Bug 18512

Summary:

Invalid resolution being selected on ATI Radeon 9200 SE RV280

Product:

xorg

Reporter:

Bryce Harrington <bryce>

Component:

Server/General

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

major

Priority:

high

CC:

freedesktopbugzilla

Version:

7.4 (2008.09)

Hardware:

All

OS:

Linux (All)

URL:

https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/274290

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Xorg.0.log	none
Xorg.0.log.old	none
untested fix	none
randr-target-exact-harder.patch	none
untested fix	none

Description Bryce Harrington 2008-11-12 19:44:45 UTC

Created attachment 20274 [details] [review]
Xorg.0.log

Forwarding this issue from a ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/274290

[Problem]
X is trying to boot with 1400x1050 when it should be booting 1280x1024, resulting in a black screen.  If a lower resolution such as 1024x768 is set via xrandr in ~/.xprofile, X comes up okay at that resolution.

[Discussion]
User had been running with -vesa on Hardy, but on installing Intrepid, found that it was failing why trying to use -ati.  Manually specifying to use vesa worked, but the question is why did -ati not work?

After some debugging work, it was found that -ati would come up fine on 800x600 and 1024x768 if specified in ~/.xprofile.  Specifying 1280x1024 with xrandr did *not* work, even though both the monitor and video card support that resolution.

[lspci]
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
00:0a.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)
00:0d.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02)
00:0e.0 USB Controller: NEC Corporation USB (rev 43)
00:0e.1 USB Controller: NEC Corporation USB (rev 43)
00:0e.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
00:13.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02)
00:13.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(TM) XP 2600+

Comment 1 Bryce Harrington 2008-11-12 19:45:11 UTC

Created attachment 20275 [details]
Xorg.0.log.old

Comment 2 Alex Deucher 2008-11-13 06:49:57 UTC

This is a "bug" in the randr code in the xserver.  Your monitor's edid does not specify a preferred mode and the xserver picks 1400x1050 based on the sync ranges.  We should probably patch the xserver to only pick modes from the edid by default at least on digital monitors.

Comment 3 Alex Deucher 2008-11-13 07:04:50 UTC

Created attachment 20280 [details] [review]
untested fix

This patch should do the right thing.

Comment 4 Adam Jackson 2008-11-13 10:19:00 UTC

Created attachment 20284 [details] [review]
randr-target-exact-harder.patch

I think xf86TargetExact should just try harder when there's only one monitor attached.  I'd still be in favor of not adding the default modes if the monitor doesn't claim to be continuous-frequency, but I think this patch is correct on its own.

Comment 5 Alex Deucher 2008-11-13 10:56:17 UTC

Created attachment 20285 [details] [review]
untested fix

This patch only added the default modes if the GTF bit is set in the edid.

Comment 6 Alex Deucher 2008-11-13 12:06:10 UTC

Pushed!
c232f3d673fb00d7fceb8e82741349d64e5ac0ad
81fd17f5f49cdd2c10d0bf3b7ddeb8b5953886a5

Comment 7 Danny 2008-12-24 04:57:15 UTC

although it certainly looks correct to me, it caused the loss of all VESA modes that can be quite useful:

https://bugs.freedesktop.org/show_bug.cgi?id=19203

danny

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.