Bug 59703

Created attachment 73436 [details]
Xorg.0.log

Created attachment 73437 [details]
Build script

P.S. HD7850 2GB on Debian wheezy amd64 with KDE. I changed /etc/kde4/kdm/kdmrc to have
ServerCmd=/opt/xorg/bin/X -verbose 9 -logverbose 9 -configdir /opt/xorg/share/X11/xorg.conf.d

(In reply to comment #1)
> Created attachment 73436 [details]
> Xorg.0.log

Oops, I just noticed that the driver didn't load at all in this case. Will try again tomorrow.

The Xorg.0.log you posted in the Phoronix forum didn't have any trace of Option "AccelMethod", meaning your Section "Device" didn't get picked up. Have you tried renaming the xorg.conf.d/ file containing it to *.conf, or just putting the Section "Device" into a good old-fashioned xorg.conf file?

I noticed the following in your xorg log :

55.506] (II) [KMS] drm report modesetting isn't supported.

Can you post dmesg output as well ?

Never mind, looks like you already noticed the KMS startup problem (#5).

OK one crash and one hang with fglrx 13.1 today gave me a lot of incentive to work some more on this.
I got it to work! It seems that the root cause was that the old X server didn't pick up the config files from /opt/xorg/share/X11/xorg.conf.d correctly. Once I cat'd them all to /etc/X11/xorg.conf and got rid of the -configdir argument for X things became much better. Thanks all! You got me on the right track.

Observations:
The whole thing hung hard immediately with Dave Airlie's 3.8rc4 drm-next kernel but with 3.7 it works mostly.

DRM/KMS with 2560x1440 monitors on DP->DVI adapters doesn't work correctly. The monitors were detected with the wrong resolution (1024x768) even after I hardwired them on the kernel command line with video=DP-1:2560x1440-24@60e video=DP-2:2560x1440-24@60e.

The only thing that worked was to hardwire the modeline in xorg.conf but xrandr -q still thinks they can do other modes than 2560x1440 (they don't):

DisplayPort-0 connected 1440x2560+3360+0 right (normal left inverted right x axis y axis) 0mm x 0mm
   2560x1440      60.0*+
   1024x768       60.0  
   800x600        60.3     56.2  
   848x480        60.0  
   640x480        59.9  

However the monitor detection/mode switching code in the Atom BIOS is broken in general for DP outputs. Not even the BIOS switches modes correctly when these monitors are connected. I had a long and fruitless exchange with AMD tech support about this. Now the monitors are still not detected reliably but switching to a text console and back gets them all up after a couple of tries.

KDE decorations don't look quite right (default theme, XRender or OpenGL.) I'll attach a screenshot.

Every now and then the display freezes for a moment. During that time the migration process is very busy, often with over 200% CPU and several threads. This can be triggered by switching KDE desktop effects on/off (Shift-Alt-F12.) Doing that also leaves some garbage on the screen.

Other than that, I have messed around for a while and haven't seen a crash yet. So far so good :)

Created attachment 73508 [details]
Screen shot

Created attachment 73509 [details]
Latest build script, this worked

Created attachment 73510 [details]
Current xorg.conf

(In reply to comment #8)
> 
> DRM/KMS with 2560x1440 monitors on DP->DVI adapters doesn't work correctly.
> The monitors were detected with the wrong resolution (1024x768) even after I
> hardwired them on the kernel command line with video=DP-1:2560x1440-24@60e
> video=DP-2:2560x1440-24@60e.

This is material for another bug report.

> 
> However the monitor detection/mode switching code in the Atom BIOS is broken
> in general for DP outputs. Not even the BIOS switches modes correctly when
> these monitors are connected. I had a long and fruitless exchange with AMD
> tech support about this. Now the monitors are still not detected reliably
> but switching to a text console and back gets them all up after a couple of
> tries.

What kind of DP->DVI adapters are you using?  Make sure they are active adapters that support dual link since your monitors require dual-link DVI and passive DP->DVI adapters only support single link.  Also, most active adapters also only support single link DVI; you need to make sure you specifically got dual-link capable active adapters.  If they are active adapters, make sure they are properly powered.  You might also want to try alternate adapters as a lot of cheap ones don't work very well.

(In reply to comment #8)
> The whole thing hung hard immediately with Dave Airlie's 3.8rc4 drm-next
> kernel but with 3.7 it works mostly.

How about the latest drm-fixes tree? If it still happens with that, can you bisect?


> KDE decorations don't look quite right (default theme, XRender or OpenGL.)

I can't seem to reproduce this.

Did you change any decoration options from the default?

Which Git commits of libdrm, Mesa, glamor and xf86-video-ati are you currently using?


> Every now and then the display freezes for a moment. During that time the
> migration process is very busy, often with over 200% CPU and several
> threads.

Can't seem to reproduce this either. AFAICT the migration/%d kernel threads are related to stopping CPU cores, so this doesn't sound directly related to the graphics drivers.


> This can be triggered by switching KDE desktop effects on/off
> (Shift-Alt-F12.) Doing that also leaves some garbage on the screen.

Leaves garbage where? The only garbage I've noticed so far is when a window is dimmed due to a modal dialogue, and only when using OpenGL for effects. That's probably a radeonsi driver issue.

(In reply to comment #12)
> This is material for another bug report.
Where should I report this? Going through AMD support was fruitless and this is clearly a BIOS bug. Does it belong here, or http://ati.cchtml.com? Is the latter actually used by anyone at AMD?

> What kind of DP->DVI adapters are you using?
Accell B087B-007B, an improved version of the approved one for Eyefinity.

(In reply to comment #14)
> (In reply to comment #12)
> > This is material for another bug report.
> Where should I report this? Going through AMD support was fruitless and this
> is clearly a BIOS bug. Does it belong here, or http://ati.cchtml.com? Is the
> latter actually used by anyone at AMD?

For the open source driver, use this bugzilla.

> 
> > What kind of DP->DVI adapters are you using?
> Accell B087B-007B, an improved version of the approved one for Eyefinity.

Ok.

(In reply to comment #13)
> > KDE decorations don't look quite right (default theme, XRender or OpenGL.)
> 
> I can't seem to reproduce this.
> 
> Did you change any decoration options from the default?
I haven't looked into this any deeper yet, but an observation:
I just used NX (nomachine debian packages) to log into a box running bog standard Debian wheezy (amd64/KDE) and I saw the white vertical lines in konsole window titles too so it seems that it's just the gradient that doesn't come out right.
I confirmed that by running konsole locally and resizing it: The pattern of stripes changes with the width of the title bar. The effect is best seen with a black background.

(In reply to comment #13)
> Leaves garbage where? The only garbage I've noticed so far is when a window
> is dimmed due to a modal dialogue, and only when using OpenGL for effects.
> That's probably a radeonsi driver issue.

This and the window decoration weirdness both seem so happen with semi-transparent UI elements. The konsole window title is also semi-transparent.

The occasional hiccups with a migration thread running are gone after my latest update (rebuilt everything from git) with the Debian 3.8-1~experimental.1 kernel.

Right now I'm quite happy - the only issue is the slight corruption with semitransparent KDE GUI elements (easily seen when opening a file in e.g. kate) but since that's only temporary it doesn't bother me too much.

(In reply to comment #9)
> Created attachment 73508 [details]
> Screen shot

I have this graphical glitch if I choose Qt graphics system: Native. With Qt graphics system: Raster it goes away.

(In reply to comment #18)
> The occasional hiccups with a migration thread running are gone after my
> latest update (rebuilt everything from git) with the Debian
> 3.8-1~experimental.1 kernel.

This is kernel dependent:  Happens with Debian 3.7.3-1~experimental.1 but not with 3.8-1~experimental.1.

(In reply to comment #18)
> Right now I'm quite happy - the only issue is the slight corruption with
> semitransparent KDE GUI elements (easily seen when opening a file in e.g.
> kate) but since that's only temporary it doesn't bother me too much.

The corruption is gone with Dave Airlie's 3.9.0-rc2+ kernel. There's some slightly incorrect rendering left with semitransparent window decorations in KDE (OpenGL or Xrender desktop effects.) See the screenshot.

Created attachment 76739 [details]
Slightly incorrect semitransparent window decorations

Ralf-Peter, remember you resolved this report two months ago. :)

Any remaining issues should be tracked in separate reports.

(In reply to comment #23)
I'm not complaining - just informing you of progress :)

My last build didn't work so I'm not up to date. When I get a new build working and it's still there I'll open another bug.

(In reply to comment #24)
P.S. Another reason is that I'm running a Franken-Debian with libdrm-radeon1 2.4.42-0ubuntu1 right now because experimental still has 2.4.40. Waiting for an update...

(In reply to comment #19)
> I have this graphical glitch if I choose Qt graphics system: Native. With Qt
> graphics system: Raster it goes away.

Where can I choose that?

(In reply to comment #26)
> (In reply to comment #19)
> > I have this graphical glitch if I choose Qt graphics system: Native. With Qt
> > graphics system: Raster it goes away.
> 
> Where can I choose that?

In Kubuntu it is System Settings / Desktop Effects / Advanced