Bug 54273

Summary: kms blackscreen ATI RV620 FirePro 2260, res: 2560*1600
Product: xorg Reporter: Alexandre Bique <bique.alexandre>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: bique.alexandre, christopher.dow, thesaxophonist
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
lspci -v
none
dmesg with drm.debug=1
none
Xorg.log
none
20120904-Xorg.0.log
none
20120904-dmesg.log
none
20120904-dmesg2.log
none
Xorg.0.log
none
skip watermark setup
none
radeon.regs
none
possible fix
none
possible fix linux-3.6.6
none
possible fix linux-3.6.6
none
Register output using fglrx-legacy driver
none
Register output using radeon kms driver
none
dmesg
none
Xorg.log none

Description Alexandre Bique 2012-08-30 16:19:31 UTC
Created attachment 66346 [details]
lspci -v

Hi,

When I start my computer with KMS enabled, I end up with a black screen.

See attached logs.
Comment 1 Alexandre Bique 2012-08-30 16:20:50 UTC
Created attachment 66347 [details]
dmesg with drm.debug=1
Comment 2 Alexandre Bique 2012-08-30 16:24:00 UTC
The original bug report from archlinux: https://bugs.archlinux.org/task/31264
Comment 3 Alexandre Bique 2012-08-30 16:26:12 UTC
One more thing is that the screens says that the resolution is unsupported, so it is not really a black screen ;-)
Comment 4 Alex Deucher 2012-08-30 16:29:23 UTC
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.
Comment 5 Alex Deucher 2012-08-30 16:29:49 UTC
Please also attach your xorg log.
Comment 6 Alexandre Bique 2012-08-30 16:36:53 UTC
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).
Comment 7 Alexandre Bique 2012-08-30 16:37:34 UTC
Created attachment 66351 [details]
Xorg.log
Comment 8 Alex Deucher 2012-08-30 17:14:43 UTC
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
Comment 9 Alexandre Bique 2012-08-30 17:19:30 UTC
Ok. I'll do it on monday as I am going on week-end.
Comment 10 Alexandre Bique 2012-09-04 18:00:29 UTC
Created attachment 66619 [details]
20120904-Xorg.0.log
Comment 11 Alexandre Bique 2012-09-04 18:01:03 UTC
Created attachment 66620 [details]
20120904-dmesg.log
Comment 12 Alexandre Bique 2012-09-04 18:02:22 UTC
Created attachment 66621 [details]
20120904-dmesg2.log
Comment 13 Alexandre Bique 2012-09-04 18:03:18 UTC
Hi,

I built your kernel and booted it.

See attached logs.
Comment 14 Alexandre Bique 2012-09-04 18:05:07 UTC
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.
Comment 15 Alexandre Bique 2012-09-05 10:14:59 UTC
Do you know why Xorg choosed resolution:

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

instead of 2560x1600?
Comment 16 Alex Deucher 2012-09-05 15:04:24 UTC
(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.
Comment 17 Alex Deucher 2012-09-05 15:08:55 UTC
(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
Comment 18 Alexandre Bique 2012-09-05 15:14:43 UTC
I'll try tonight.
Comment 19 Alexandre Bique 2012-09-05 18:10:45 UTC
I succeed to set 1600x1200, 1920x1200, 2048x1152 with xrandr, but It fails with high resolutions.

I update Xorg.log.
Comment 20 Alexandre Bique 2012-09-05 18:11:23 UTC
Created attachment 66693 [details]
Xorg.0.log
Comment 21 Alexandre Bique 2012-09-12 12:00:28 UTC
So do you have an idea about where the problem comes from?
Comment 22 Alexandre Bique 2012-09-14 13:12:13 UTC
=> try to boot with radeon.disp_priority=2
Comment 23 Alex Deucher 2012-09-14 13:19:07 UTC
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.
Comment 24 Chris Dow 2012-10-04 19:10:32 UTC
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
Comment 25 Alexandre Bique 2012-10-04 20:15:45 UTC
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 :-)
Comment 26 Chris Dow 2012-10-05 01:08:48 UTC
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).
Comment 27 Alexandre Bique 2012-11-08 12:54:52 UTC
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
Comment 28 Alexandre Bique 2012-11-08 13:10:35 UTC
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.
Comment 29 Alex Deucher 2012-11-08 13:36:29 UTC
(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.
Comment 30 Alexandre Bique 2012-11-08 18:49:42 UTC
Created attachment 69768 [details]
radeon.regs

Add radeon.regs
Comment 31 Alex Deucher 2012-11-15 15:37:33 UTC
Created attachment 70127 [details] [review]
possible fix

Does this patch help?
Comment 32 Alexandre Bique 2012-11-15 17:33:49 UTC
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).
Comment 33 Alexandre Bique 2012-11-15 17:39:25 UTC
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! :)
Comment 34 Alexandre Bique 2012-11-15 17:47:21 UTC
Created attachment 70138 [details] [review]
possible fix linux-3.6.6

Fixed the variable not found.
Comment 35 Alexandre Bique 2012-11-15 18:02:46 UTC
I'm sorry but it doesn't help :(
Comment 36 Chris Dow 2013-02-13 22:11:14 UTC
Created attachment 74786 [details]
Register output using fglrx-legacy driver
Comment 37 Chris Dow 2013-02-13 22:11:58 UTC
Created attachment 74787 [details]
Register output using radeon kms driver
Comment 38 Chris Dow 2013-02-13 22:17:22 UTC
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.
Comment 39 John-Michael Mulesa 2013-06-19 03:14:23 UTC
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.
Comment 40 John-Michael Mulesa 2013-06-19 03:19:56 UTC
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
Comment 41 John-Michael Mulesa 2013-06-19 03:20:46 UTC
Created attachment 81048 [details]
Xorg.log
Comment 42 John-Michael Mulesa 2013-06-19 04:32:59 UTC
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.
Comment 43 Alex Deucher 2013-06-20 18:21:57 UTC
(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.
Comment 44 John-Michael Mulesa 2013-06-20 23:31:13 UTC
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
Comment 45 Martin Peres 2019-11-19 07:35:47 UTC
-- 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.

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.