Bug 45968

Summary:

[RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing

Product:

DRI

Reporter:

Tobias Diedrich <ranma+freedesktop>

Component:

DRM/Radeon

Assignee:

Default DRI bug account <dri-devel>

Status:

RESOLVED NOTOURBUG

QA Contact:

Severity:

normal

Priority:

medium

Version:

unspecified

Hardware:

Other

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Xorg log	none
xrandr --verbose output	none
dmesg output	none
video bios rom	none

Description Tobias Diedrich 2012-02-12 15:39:22 UTC

My new monitors native resolution is 2560x1440 which requires dual-link.
I'm using the DVI-Cable that came with the monitor.
KMS/Xorg claims to have set the resolution to 2560x1440.

Debian/unstable
Linux 3.3.0-rc3 (built from source)
libdrm 2.4.31-0 (built from source)
xserver-xorg              1:7.6+11 
xserver-xorg-video-radeon 1:6.14.3-2 (tried building from source, had the same problem)
Gigabyte GA-MA78GPM-DS2H

As a workaround, custom 2560x1440@30 and 2560x1440@24 modelines work, but seems very suboptimal...

Comment 1 Alex Deucher 2012-02-13 05:27:57 UTC

Please attach your xorg log, dmesg output, and xrandr --verbose output.

Comment 2 Tobias Diedrich 2012-02-13 08:12:35 UTC

Created attachment 56974 [details]
Xorg log

Comment 3 Tobias Diedrich 2012-02-13 08:13:07 UTC

Created attachment 56975 [details]
xrandr --verbose output

Comment 4 Tobias Diedrich 2012-02-13 08:16:57 UTC

Created attachment 56977 [details]
dmesg output

Comment 5 Tobias Diedrich 2012-02-13 08:18:44 UTC

Created attachment 56979 [details]
video bios rom

Comment 6 Alex Deucher 2012-02-13 08:22:51 UTC

Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)?  If so, does reverting this commit fix the issue?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295

Comment 7 Tobias Diedrich 2012-02-13 08:27:05 UTC

(In reply to comment #6)
> Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)?  If so, does reverting this commit fix the issue?
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295

It didn't work with 3.2.4, which is why tried 3.3-rc.

Comment 8 Tobias Diedrich 2012-02-13 08:28:23 UTC

(In reply to comment #7)
> (In reply to comment #6)
> > Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)?  If so, does reverting this commit fix the issue?
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295
> 
> It didn't work with 3.2.4, which is why tried 3.3-rc.

Looking at the mentioned patch I should actually retry HDMI, which with 3.2.4 only supported up to 1920xsomething

Comment 9 Tobias Diedrich 2012-02-14 03:00:35 UTC

FWIW using HDMI on 3.3-rc I can go up to 2560x1440@48, but 2560x1440@60 is above the 340MHz pixelclock limit for one link.

I installed XP yesterday and found that it shows the same problem with dual-link not working properly, so this seems to be just a case of bad HW.

Comment 10 Alex Deucher 2012-02-14 06:01:56 UTC

Seems like the oem may not have wired up the DVI port correctly for duallink.

Comment 11 Roland Scheidegger 2012-02-14 10:04:35 UTC

(In reply to comment #9)
> FWIW using HDMI on 3.3-rc I can go up to 2560x1440@48, but 2560x1440@60 is above the 340MHz pixelclock limit for one link.

I'm surprised this old hw supports 340Mhz pixelclock on hdmi, I thought only Tahiti could do that, and monitors wouldn't support it neither typically (though I know some hw tolerates overclocking tmds quite well).
In any case 2560x1440@60Hz should be clearly below 340Mhz with reduced blanking (around 250Mhz).

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.