Bug 144401

Created attachment 64302 [details]
/tmp/Screenshot.png

Created attachment 64303 [details]
bug144401.tar.bz2

Great that you didn't report this earlier! radeon driver is currently in a bad shape anyway. Therefore I don't think that anyone will take care about ppc bugs at this moment. Anyway, we need to see xorg.conf and Xorg.0.log.

Check first if the use of the "fbdev" X driver does work.

Created attachment 64309 [details]
Screenshot-1.png

fbdev doesnt work, some ioctl fails.

with '  Option "usefbdev" "true"', the screen looks worse.

but the panel looks better at least. There is still a drawing bug above the desktop menu.

will check KDE now.

Maybe ' Option "noaccel" ' helps ...

Created attachment 64312 [details]
Screenshot-2.png

yast looks ok. the screen is not updated properly if windows are moved.

kde looks ok. what is used to draw the background? Maybe this app has a problem.

option "noaccel" "true" does work with GNOME.

Is the GNOME WM using some composition manager? 
With all the new stuff added I'm not sure if all these pieces have been thoroughly tested on BE. Althought this doesn't look like an endian problem right off hand.

I installed on a Mac with r128 and gnome looks ok there. I dont have another Mac with radeon card currently.

Olaf, please remove the ' Option "Composite" "on" ' line in your xorg.conf and try again.

I tried it on a G5 (f46 @ schwab) and it happens there as well. 
disabling "Composite" does not help.

*** Bug 144660 has been marked as a duplicate of this bug. ***

Here is an interesting experience I found just trial and error: if I enable DRI (not enabled by default), the problem still occurs. But as soon, as I start a program using it (like glxgears, I used to test if 3D acceleration is really enabled), the problem is gone...

Removing "Composite" "on", or changig it to "off" did not change, that in /var/log/Xorg.0.log I still find:

[...]
(II) Initializing built-in extension COMPOSITE
[...]

It's probably enabled independent of settings.

Sure that you're able to start xcompmgr (package xcompmgr) with having Composite disabled in xorg.conf?

No, I'm not able to start xcompmgr.
But any OpenGL application helps to get things to normal if DRI is enabled (load "dri"), independent if composite is enabled...

Maybe the same as https://bugs.freedesktop.org/show_bug.cgi?id=4456

Maybe, try ' Option "AccelMethod" "EXA" ' to verify.

From olh: Yes, works.  Please update x11db.

Hmm ... "exa" is considered highly experimental. IMHO we shouldn't enable it by default, but I could well do it for this chipset on ppc only.

yeah, or we just put the hint on the opensuse webpage.

Good idea. I propose to put it on the "Specific PowerPC problems" page.

http://www.opensuse.org/Bugs:Most_Annoying_Bugs

--> PPC only

In which section do I have to set

   Option "AccelMethod" "EXA"

?

Where you have BusID as well. It's in the "Device" section.

Thanks - now it works.

Please go back to XAA and check which one of the following options fixes the problem.
Option          "XaaNoScreenToScreenCopy"
Option          "XaaNoSolidFillRect"
Option          "XaaNoSolidFillTrap"
Option          "XaaNoSolidTwoPointLine"
Option          "XaaNoSolidBresenhamLine"
Option          "XaaNoSolidHorVertLine"
Option          "XaaNoDashedTwoPointLine"
Option          "XaaNoDashedBresenhamLine"
Option          "XaaNoMono8x8PatternFillRect"
Option          "XaaNoMono8x8PatternFillTrap"
Option          "XaaNoColor8x8PatternFillRect"
Option          "XaaNoColor8x8PatternFillTrap"
Option          "XaaNoCPUToScreenColorExpandFill"
Option          "XaaNoScanlineCPUToScreenColorExpandFill"
Option          "XaaNoScreenToScreenColorExpandFill"
Option          "XaaNoImageWriteRect"
Option          "XaaNoScanlineImageWriteRect"
Option          "XaaNoPixmapCache"
Option          "XaaNoOffscreenPixmaps"

You mean addig one after the other to the Device section and start gnome?

The first one solved the blurry screen problem on GNOME (Option "XaaNoScreenToScreenCopy"), but made moving windows extremly slow. I check the others as well.

I tried all of the mentioned options, one after the other. It's Murphi's law: the other option helping was the last one (Option "XaaNoOffscreenPixmaps"). This one is much better, as it does not have any side effects on window movement speed. With the other option, when I move a firefox window, it takes more than 1s to redraw.

Yes. You want to have offscreen pixmaps.
I assume it is the XAA code that added Render support thru textures. We had problems with it before. I'll investigate.

Egbert, if possible could you try to reproduce it on

  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x5964 "RV280 5964"
  SubVendor: pci 0x147b "ABIT Computer Corp."
  SubDevice: pci 0x6191 

or similar? This is the chip, which is affected according to the information Olaf gave us (comment #2). BTW, cantaloupe has exactly this board builtin and I could see this problem on Gnome yesterday on this machine.

Assigning to Egbert for investigation. Egbert, let me know if/when I can help. Thanks.

Stefan, I'm doing my very best. Please note that I will need physical access to the machine for visual inspection. Therefore cantaloupe won't help me. - 
I only have one G4 with a R128. I also have a MGA card with OF. Without a OF Radeon card I cannot reproduce this here. 

Ok, I understand. Olaf, do we have a Radeon baord with OF, we could send to Egbert for regular testing?

I dont have any radeon card. We could ship the g5 from schwab, if he doesnt care.

I'm not responsible.

I don't know why this is NEEDINFO aj, I see nothing where I can help.

Just a wild guess. Maybe Andreas Schwab thinks *you* need to decide whether he is allowed to send his G5 machine to Egbert.

To both Andreas. Should be sufficient to read comments beginning with #39 and to comment.

> I'll add ' Option "XaaNoOffscreenPixmaps" ' for this chipset for now as
> workaround.

done.

AJ, who owns that G5? schwab isnt answering...

Olaf, could you talk with Matthias and Andreas Schwab about this offline, please? Thanks.

FYI: Exact same problem on ia64/radeon (sles10p4 onwards) when using Gnome. 

#143274

Looks identical to the screenshots olh posted.

*** Bug 143274 has been marked as a duplicate of this bug. ***

Tony, does ' Option "XaaNoOffscreenPixmaps" ' in Section Device of /etc/X11/xorg.conf (see comment #34) fix it for you as well?

Yes. This fixes it, at least for sles10p4.  I havn't been able to install beta 1 or 2 so far.

Interestingly, drop down menu's display correctly, it's just windows and icons that have issues.

If you can reproduce this in ia64 this is not a problem of BE platforms. I therefore may not need the G5.

(In reply to comment #47)
> > I'll add ' Option "XaaNoOffscreenPixmaps" ' for this chipset for now as
> > workaround.
> 
> done.
> 

I installed SLES 10 beta3, and it's not yet there.

If it isn't yet, it will be for Beta4.

On an HP RX2600 system that previously had this problem, I no longer see the problem in the updated packages that Gerald provided to me.

I have not had a chance to check other system types (like SGI Prism) yet but
I thought I'd pass along what I know so far.

I'll note that this system was upgraded from Beta3 to the stuff Gerald gave
me and that xorg.conf doesn't include "XaaNoOffscreenPixmaps" - so, if I read
the bug right, it's working on the box now even though the work around isn't
in place.

It might have been fixed for you accidently by other changes in the driver. Unlikely, but possible. Anyway, the workaround is still active and I don't plan to disable it for now.

I wonder if it would make sense for me to try to reproduce this problem - considering that it would require quite some efford and that the likelyhood is rather uncertain.

FYI.
With SLES10 Beta4, our HP box is still working with gnome.
In addition, a SGI Prism with dual Fire GL X2 cards worked fine with
SLES10 Beta4.

In the HP case, it was a fresh install.  In the SGI Prism case, it was
a by-hand upgrade.  In all cases, there was no
XaaNoOffscreenPixmaps option what so ever in xorg.conf.  In the
upgrade case, that's because that was how the system was configured
prior.  In the fresh-install case, this option didn't show up either.

So it seems fixed on ia64 in general even though the workaround isn't
showing up.  -Erik

Hmm. Sure that these boxes ship both with

  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x5964 "RV280 5964"

I added this option only for this chipset.

I don't know if any machines we have here have that chipset in it.
That explains it, but then it makes me wonder why our bug was duped
to this one.

In any event, it works for us now too.  Hopefully the bug doesn't come back
to haunt us :)

Workaround is applied. IMHO this should be tested/investigated again after switching to X.Org > 7.0 with SUSE > 10.1 Beta. ==> LATER

I've added the current ati-1-0-branch radeon driver to RC1. Some things 
might have been fixed. Give it a try with "sax2 -r -m 0=radeon10b". 
(The driver is called "radeon10b") 

Stefan, since our access to RC1 is a few weeks away, can we rebuild the 
xorg-x11-driver srpm from factory?  Is that the same code base as what ends up
in SLES10?  If not, could you stick an srpm out on ftp somewhere for us?

Sorry, with RC1 I've meant 10.1 RC1. So you'll get it with SLES10-Beta9 in a few days. Of course you can also rebuild from factory. X.Org is the same code base for 10.1/SLES10/SLED10 (called "CODE10").

Well, does "radeon10b" driver work for you?

NEEDINFO.

what option do I need to get a 10.1 default install into the failed state?

"radeon10b" shows no corruption. How can I get "radeon" back into the failing state?

Replace "radeon10b" driver entry in xorg.conf with "radeon".

that would mean that 10.1 default is broken. But thats not the case.

For 10.1 I've applied the workaround to set 

  Option "XaaNoOffscreenPixmaps"

But since you say, the radeon10b fixes this issue comletely I'll close this one.

I dont see any corruption with this, I wonder if it was fixed elsewhere:
Section "Device"
  BoardName    "RV280 5964"
  BusID        "1:8:0"
  Driver       "radeon"
  Identifier   "Device[0]"
  VendorName   "ATI"
  Option "XaaOffscreenPixmaps"
EndSection

XaaOffscreenPixmaps is the default. XaaNoOffscreenPixmaps disables them. Please double check (was the section in comment #76 copy-and-paste or from memory?).

If you don't see any corruption, it appearantly has been fixed in the meantime. This is weird.

Stefan, seems that you can remove that option for
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x5964 "RV280 5964"
again...

yes, both "XaaOffscreenPixmaps" and "XaaNoOffscreenPixmaps" show no corruption, even with suse10-1280x1024.jpg as background.

I suggest you remove the relavant changes for this bug to see what happens in 10.2.