From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 73530] Asus U38N: Black screen with Radeon driver in Linux Date: Sun, 16 Nov 2014 12:14:28 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0239294220==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id E7ED56E51D for ; Sun, 16 Nov 2014 04:14:27 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0239294220== Content-Type: multipart/alternative; boundary="1416140067.f1DB31.17433"; charset="UTF-8" --1416140067.f1DB31.17433 Date: Sun, 16 Nov 2014 12:14:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D73530 --- Comment #69 from Nicolas Werner --- (In reply to Alex Deucher from comment #65) > *snip* >=20 > In reply to Christian A=C3=9Ffalg from comment #63) > > I think / guess that I am having the same issues. I've got the same lap= top, > > running Arch Linux. Mostly, I've been using the proprietary catalyst dr= iver, > > since I never got the free driver working. The proprietary is working f= ine. > >=20 > > What is the issue here? You've been playing with timings for the physic= al > > link to the internal panel? Is it so frickly? What would you need to fi= x the > > issue? How can I help? >=20 > I suggested that it might be a timing issue, and as per comment 54.=20 > However, link training is successful so that monitor accepts the paramete= rs > that the driver proposed, it just sometimes chooses not to light up. I > would suggest trying to tweak the link training timing as per comment 54, > try disabling ss as per comment 6, and finally, try making some slight > changes to the modeset sequence as per the attached patch. The patch add= s a > delay before enabling the video stream and additionally calls the enable > video stream code again in case the monitor didn't quite get the signal t= he > first time. E.g., > *snip* I also have the same problem. (same notebook, so not surprising) I tried everything you recommended (in comment #65), in order, nothing help= s. Any more suggestions? Btw, I'm using OpenSUSE, so Kernel 3.16.6. Also xrandr output is much shorter than the ones posted here, is that normal when you use modeset=3D0? xrandr -q --verbose xrandr: Failed to get size of gamma for output default Screen 0: minimum 1920 x 1080, current 1920 x 1080, maximum 1920 x 1080 default connected primary 1920x1080+0+0 (0x180) normal (normal) 0mm x 0mm Identifier: 0x17f Timestamp: 7692 Subpixel: unknown Clones:=20=20=20=20 CRTC: 0 CRTCs: 0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter:=20 1920x1080 (0x180) 159.667MHz *current h: width 1920 start 0 end 0 total 1920 skew 0 clock 83.1= 6KHz v: height 1080 start 0 end 0 total 1080 clock 77.0= 0Hz --=20 You are receiving this mail because: You are the assignee for the bug. --1416140067.f1DB31.17433 Date: Sun, 16 Nov 2014 12:14:27 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Commen= t # 69 on bug 73530<= /a> from Nicolas Werner 
(In reply to Alex Deucher from comment #65)
> *snip*
>=20
> In reply to Christian A=C3=9Ffalg from comment #63)
> > I think / guess that I am having the same issues. I've got the sa=
me laptop,
> > running Arch Linux. Mostly, I've been using the proprietary catal=
yst driver,
> > since I never got the free driver working. The proprietary is wor=
king fine.
> >=20
> > What is the issue here? You've been playing with timings for the =
physical
> > link to the internal panel? Is it so frickly? What would you need=
 to fix the
> > issue? How can I help?
>=20
> I suggested that it might be a timing issue, and as per comment 54.=20
> However, link training is successful so that monitor accepts the param=
eters
> that the driver proposed, it just sometimes chooses not to light up.  I
> would suggest trying to tweak the link training timing as per comment 54,
> try disabling ss as per comment=
 6, and finally, try making some slight
> changes to the modeset sequence as per the attached patch.  The patch =
adds a
> delay before enabling the video stream and additionally calls the enab=
le
> video stream code again in case the monitor didn't quite get the signa=
l the
> first time.  E.g.,
> *snip*

I also have the same problem. (same notebook, so not surprising)

I tried everything you recommended (in comment #65), in order, nothing helps.
Any more suggestions?

Btw, I'm using OpenSUSE, so Kernel 3.16.6.

Also xrandr output is much shorter than the ones posted here, is that normal
when you use modeset=3D0?

xrandr -q --verbose
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1920 x 1080, current 1920 x 1080, maximum 1920 x 1080
default connected primary 1920x1080+0+0 (0x180) normal (normal) 0mm x 0mm
        Identifier: 0x17f
        Timestamp:  7692
        Subpixel:   unknown
        Clones:=20=20=20=20
        CRTC:       0
        CRTCs:      0
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:=20
  1920x1080 (0x180) 159.667MHz *current
        h: width  1920 start    0 end    0 total 1920 skew    0 clock  83.1=
6KHz
        v: height 1080 start    0 end    0 total 1080           clock  77.0=
0Hz

You are receiving this mail because: =20=20=20=20=20=20
  • You are the assignee for the bug.
--1416140067.f1DB31.17433-- --===============0239294220== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0239294220==--