Bug 54273

Created attachment 66347 [details]
dmesg with drm.debug=1

The original bug report from archlinux: https://bugs.archlinux.org/task/31264

One more thing is that the screens says that the resolution is unsupported, so it is not really a black screen ;-)

How is your monitor connected and what resolution is it?  Your board seems to have two DP (displayport) connectors.  2560x1600 requires a dual link connector if you are using DVI.  As your board does not have any dual link DVI connectors, you can't run the monitor at 2560x1600 over a passive DP to DVI adapter.  Passive DO to DVI adapters only support single link DVI.  You either need to connect the monitor via native DP or an active DP to dual link DVI adapter.

Please also attach your xorg log.

My display is connected using DisplayPort.

At the moment I am using Xorg + vesa driver (1600*1200).

I have a previous xorg.log, with the radeon driver (I had black screen). I booted with nomodeset and removed my /etc/X11/xorg.conf so I let Xorg detect and use radeon.

Then I installed xf86-video-fbdev-0.4.3-1, dri2proto-2.8-1, xf86driproto-2.1.1-2,
xorg-xdriinfo-1.0.4-3 and now if I start Xorg with no config file, my computer crash (ie numlock do not work anymore).

Created attachment 66351 [details]
Xorg.log

Can you attach your xorg log from when you are using KMS?  Also, please attach logs uncompressed in the future.  You might want to try my drm-fixes-3.6 kernel tree as there are some displayport related fixed in there.
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6

Ok. I'll do it on monday as I am going on week-end.

Created attachment 66619 [details]
20120904-Xorg.0.log

Created attachment 66620 [details]
20120904-dmesg.log

Created attachment 66621 [details]
20120904-dmesg2.log

Hi,

I built your kernel and booted it.

See attached logs.

By the way I got horizontal or vertical black and white lines. Then the screen blinked and shown that the resolution was unsupported and that I should switch to 2560*1600.

Do you know why Xorg choosed resolution:

[   199.363] (II) RADEON(0): Setting screen physical size to 677 x 423

instead of 2560x1600?

(In reply to comment #15)
> Do you know why Xorg choosed resolution:
> 
> [   199.363] (II) RADEON(0): Setting screen physical size to 677 x 423
> 
> instead of 2560x1600?

That's not the resolution, that the size of the screen in millimeters.

(In reply to comment #16)
> (In reply to comment #15)
> > Do you know why Xorg choosed resolution:
> > 
> > [   199.363] (II) RADEON(0): Setting screen physical size to 677 x 423
> > 
> > instead of 2560x1600?
> 
> That's not the resolution, that the size of the screen in millimeters.

The driver is using 2560x1600

[   199.146] (II) RADEON(0): Output DisplayPort-1 using initial mode 2560x1600

Does switching to another mode with xrandr help?

E.g.,

xrandr --output DisplayPort-1 --mode 1920x1200
or
xrandr --output DisplayPort-1 --mode 1024x768

I'll try tonight.

I succeed to set 1600x1200, 1920x1200, 2048x1152 with xrandr, but It fails with high resolutions.

I update Xorg.log.

Created attachment 66693 [details]
Xorg.0.log

So do you have an idea about where the problem comes from?

=> try to boot with radeon.disp_priority=2

Created attachment 67155 [details] [review]
skip watermark setup

Try booting with radeon.disp_priority=2 on the kernel command line in grub.  Next try the attached patch.  Make sure you shutdown and do a cold boot after applying the patch so all the registers values get reset.  If that doesn't work we can try comparing registers between fglrx and the open source driver.  Load up both drivers and then use radeonreg (http://cgit.freedesktop.org/~airlied/radeontool/) to dump the registers (as root):

with radeon loaded:
./radeonreg regs dce3 > radeon.regs

with fglrx loaded:
./radeonreg regs dce3 > fglrx.regs

and attach the files.

This sounds like the same issue I am having.  Do you only get a black screen on modes that have a lowere refresh rate?  I reported it for Debian here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661943

The refresh rate is 60hz or 59.9hz (I guess it is the same?) for the native resolution.

I promise I'll find time to dump the registers next week :-)

Sorry, I should have been clearer.  I was trying to verify that we do in fact have the same issue.  

You had mentioned previously that you were able to get the display to work for certain resolutions but not others.  I get a blank screen for display modes that have a lower refresh rate (usually around 60Hz).  However, if I use a display mode that has a higher refresh rate (say around 75Hz) I don't get a blank screen.  Is this the case for you?  Are all of the modes that you can get to work using a higher refresh rate than your native resolution?

If this is the case then I believe the cause of the issue is monitor refresh rate is actually being set to a lower value than it should be.  For instance if I use a display mode that has a 75Hz refresh rate then my monitor reports that it is actually getting a refresh rate of 56Hz.

Currently I am working around this by create a new mode that is my monitor's native resolution but has the refresh rate higher than it should be (75Hz rather than 60Hz).

This is the radeon regs with linux 3.6.6 (from archlinux) and kms:

RADEON_DAC_CNTL	00000000
RADEON_DAC_EXT_CNTL	00000000
RADEON_DAC_MACRO_CNTL	00000000
RADEON_DAC_CNTL2	00000000
RADEON_TV_DAC_CNTL	00000000
RADEON_DISP_OUTPUT_CNTL	00000000
RADEON_CONFIG_MEMSIZE	00000000
RADEON_AUX_SC_CNTL	ff9b7bc9
RADEON_CRTC_EXT_CNTL	00000000
RADEON_CRTC_GEN_CNTL	00000000
RADEON_CRTC2_GEN_CNTL	00000000
RADEON_DEVICE_ID	00000000
RADEON_DISP_MISC_CNTL	00000000
RADEON_GPIO_MONID	00000000
RADEON_GPIO_MONIDB	00000000
RADEON_GPIO_CRT2_DDC	00000000
RADEON_GPIO_DVI_DDC	00000000
RADEON_GPIO_VGA_DDC	00000000
RADEON_LVDS_GEN_CNTL	00000000
RADEON_LVDS_PLL_CNTL	00000000
RADEON_FP_GEN_CNTL	00000000
RADEON_FP2_GEN_CNTL	00000000
RADEON_PPLL_CNTL	00000000
RADEON_PPLL_REF_DIV	00000000
RADEON_PPLL_DIV_3	00000000
RADEON_PIXCLKS_CNTL	00000000
RADEON_P2PLL_CNTL	00000000
RADEON_P2PLL_REF_DIV	00000000
RADEON_P2PLL_DIV_0	00000000
RADEON_VCLK_ECP_CNTL	00000000
RADEON_MEM_TIMING_CNTL	00000000
RADEON_TMDS_PLL_CNTL	00000000
RADEON_TMDS_TRANSMITTER_CNTL	00000000
RADEON_CRTC_MORE_CNTL	00000000
RADEON_FP_H_SYNC_STRT_WID	00000000
RADEON_FP_V_SYNC_STRT_WID	00000000
RADEON_FP_CRTC_H_TOTAL_DISP	00000000
RADEON_FP_CRTC_V_TOTAL_DISP	00000000
RADEON_FP_HORZ_STRETCH	00000000
RADEON_FP_VERT_STRETCH	00000000
RADEON_FP_HORZ_VERT_ACTIVE	00000000
RADEON_CRTC_H_TOTAL_DISP	00000000
RADEON_CRTC_H_SYNC_STRT_WID	00000000
RADEON_CRTC_V_TOTAL_DISP	00000000
RADEON_CRTC_V_SYNC_STRT_WID	00000000
RADEON_CRTC2_H_TOTAL_DISP	0200000f
RADEON_CRTC2_H_SYNC_STRT_WID	00000000
RADEON_CRTC2_V_TOTAL_DISP	00000100
RADEON_CRTC2_V_SYNC_STRT_WID	00000002

I just tried to boot with the catalyst-firepro driver, but as it doesn't support xorg 1.13, I can't dump the registers with the official driver.

Can we check that the previous registers dump is correct to set 2560x1600@60Hz?

Thanks.

(In reply to comment #28)
> Can we check that the previous registers dump is correct to set
> 2560x1600@60Hz?

Those aren't the right registers, it looks like you are using radeontool rather than radeonreg.  See comment 23 for how to dump the registers.

Created attachment 69768 [details]
radeon.regs

Add radeon.regs

Created attachment 70127 [details] [review]
possible fix

Does this patch help?

Created attachment 70134 [details] [review]
possible fix linux-3.6.6

I modified the patch to apply against linux 3.6.6 (used by archlinux).

radeon_crtc is not defined with my kernel version.

It is easier for me to apply a patch against linux-3.6.6, is it possible?

Otherwise can you tell me which kernel version I should use?

Thanks! :)

Created attachment 70138 [details] [review]
possible fix linux-3.6.6

Fixed the variable not found.

I'm sorry but it doesn't help :(

Created attachment 74786 [details]
Register output using fglrx-legacy driver

Created attachment 74787 [details]
Register output using radeon kms driver

I was finally able to get a version of the fglrx driver running so I could generate the register output.  I used the fglrx-legacy driver, which displayed that I had 'unsupported hardware' but seemed to function properly.  At the very least I was able to set the correct refersh rate.  I hope this helps.

I attached the output register outputs for fglrx and radeon kms.  Both were generated using the same configured resolution and refresh rate.

I believe I'm having this issue as well. I have an RV620 Radeon 3470 with two displayport outputs (which are the only two outputs on the card.) Both of my native Displayport displays (HP L2201x and a Dell U2311H, 1920x1080x60 native) go to "Input not supported" mode as soon as KMS kicks in. However, connecting a DVI display to an active DP->DVI adapter works perfectly. Using fglrx-legacy allows native displayport to work on the card. I've tried on kernel 3.9.0 and 3.10rc6 with the same results.

Created attachment 81047 [details]
dmesg

DisplayPort-0 has the active DP->DVI adapter with working screen attached
DisplayPort-1 has the native displayport with blank screen attached

Created attachment 81048 [details]
Xorg.log

Adding/setting a modeline in xrandr for the native resolution at 80hz (instead of 60hz) works around this problem in X. I noticed my dell monitor was outputting at 56hz when it should have been at 75hz on a lower resolution. There seems to be a 3/4 ratio between what the display sees and what xrandr sees.

(In reply to comment #42)
> Adding/setting a modeline in xrandr for the native resolution at 80hz
> (instead of 60hz) works around this problem in X. I noticed my dell monitor
> was outputting at 56hz when it should have been at 75hz on a lower
> resolution. There seems to be a 3/4 ratio between what the display sees and
> what xrandr sees.

It sounds like your monitor may prefer a different DP lane count and clock rate than the driver wants to use.  The link training appears to complete successfully, but the monitor doesn't seem to like the selected lane/rate.  Bumping the clock up to 80Hz, you're probably getting a different lane/rate combination that the monitor prefers. See radeon_dp_set_link_config() in atombios_dp.c.

Thanks for the advice. Sadly this doesn't appear to be the issue. I added some variable debug printing around that code and did some xrandr switches between the working and non-working modes. The link clock and number of lanes stayed consistent regardless of the mode.

[   90.440260] radeon: dp_link_clock: 270000
[   90.440265] radeon: dp_lane_number: 2
[  151.480696] radeon: dp_link_clock: 270000
[  151.480699] radeon: dp_lane_number: 2
[  161.053043] radeon: dp_link_clock: 270000
[  161.053047] radeon: dp_lane_number: 2
[  374.582457] radeon: dp_link_clock: 270000
[  374.582459] radeon: dp_lane_number: 2

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/38.