Created attachment 76178 [details]
with EXANoComposite True

Created attachment 76179 [details]
Scrot1

Re-attaching scrot 1
Sorry for the first attempted screenshot. How to remove/strike?

Created attachment 76180 [details]
Scrot3

Created attachment 76181 [details]
Scrot4

Created attachment 76182 [details]
lspci-vvv

Created attachment 76183 [details]
Xorg.0.log withOUT workarounds

Created attachment 76184 [details]
Xorg.0.log WITH workarounds

Created attachment 76185 [details]
xorg.conf includes comments of other things tried

Created attachment 76186 [details]
dmesg output

Created attachment 76190 [details]
Replacing Scrot4

Did it again. Replacing scrot 4. My apologies for the bug spam.

Just to clarify, the patch was

    if (info->directRenderingEnabled)
-	OUTREGP(R128_DP_DATATYPE, 0, ~R128_HOST_BIG_ENDIAN_EN);
+	OUTREGP(R128_DP_DATATYPE, R128_HOST_BIG_ENDIAN_EN, ~R128_HOST_BIG_ENDIAN_EN);
    else

Str8bs, did you verify that EXANoComposite + MigrationHeuristic Greedy didn't solve colours without the patch?

That icon on your bottom panel that is green is your 'trash' icon.  Strangely, that is often messed up for me with my radeon card and EXA (it is just a random mess of colours).  MigrationHeuristic Greedy solves it for me too, although firefox is noticeably slower with that setting (and I don't use it).

The top panel should be a dark grey, almost black colour. It may help with the screenshots to keep a consistent alpha value.

You might not have to use ExaNoComposite anymore once cairo 1.12 gets packaged. I noticed defects with cairo 1.10 text as well but cairo 1.12 handles it more efficiently. Once I added "SolidPicture" support to the driver and upgraded cairo, text looked a lot better.

You also might not have to adjust the alpha used by xfwm4 if you put
Section "Extensions"
  Option "Composite" "false"
EndSection
in your xorg.conf. I remember seeing messed up colors in xfce apps that used libXcomposite but this was worse with XAA on my system.

Anyway, I have already thought about the issues that don't specifically have to do with the big endian byte order so I suggest that you keep ExaNoComposite "true" and window manager compositing on for the time being.

Like Adam, I suspect that MigrationHeuristic "greedy" is the only thing that solved your problem. The effect of this is to fall back to software 99% of the time so EXA hardly ever gets used. Therefore I suggest that you don't use this if you want to test EXA patches.

Can you test four cases four me? (OUTREGP patch not applied, DRI off), (OUTREGP patch applied, DRI off), (OUTREGP patch not applied, DRI on), (OUTREGP patch applied, DRI on). Each time I want to know if there are any color changes in 2D apps (like the xfce panel) and 3D apps (like glxgears).

Ack, just 3 cases are needed. (patch applied, DRI on), (patch not applied, DRI on) and (DRI off). All with ExaNoComposite "true", no MigrationHeuristic set and whatever xfce settings you think are the best.

Mr. Behan,
I have issues compiling (probably my lack of skills) so Adam was compiling for me.
So as not to waste your time:

Adam:
Please confirm the first R128 you gave via .deb was WITH OUTREGP patch and R128v2 was WITHOUT OUTREGP patch.
Testing now based on this assumption.

and yes, dark grey upper panel/bar as expected where I noted all issues apparently resolved. Alpha is at default except that one example.

Yep, that's right.  If you are not sure you can open up the deb with archive manager and find the changelog.  Currently there are 4 versions floating about:

The first unpatched on the iso - (6.9.1-0ubuntu2)
The 6.9.1-0ubuntu3 I released with the OUTREGP patch
The 6.9.1-0ubuntu4 with the solid picture patch
The 6.9.1-0ubuntu5 with the OUTREGP patch and the solid picture patch.

I compiled cairo 1.12.2 too (which I assume you've found), so you can see if that makes a difference.  From my own experiments with my radeon card, you'll definitely have funny colours with that unless you use one of the versions with the solid picture patch.

I could not observe any changes with or without OUTREGP patch. Will test SolidPicture patch.

The following is an attempt at more detailed notes of what I observe. I have a screenshot of each case if needed.

Constants:
EnablePageFlip True
EXANoComposite True
Window Manager Compositor Disabled


DRI Enabled and Extensions Composite False:
XFCE Panels and GLXgears colors look correct.
Terminal colors look correct.
Mouse pointer turns black when GLXgears is launched.
Goes back to white when GLXgears closed.

DRI Enabled and Extensions Composite True:
XFCE Panels are green. Mousing over icons in panel turns that square background black. It remains black once mouse moved elsewhere.
Terminal is green tinted white instead of grey. Launching GLXgears lines in terminal turns expected grey. Subsequent launches of terminal are expected grey. 
Mouse pointer turns black when GLXgears is launched.
Goes back to white when GLXgears closed.

DRI Disabled and Extensions Composite False:
XFCE Panels and GLXgears colors look correct.
Terminal colors look correct.
Mouse pointer remains white when GLXgears is launched.

DRI Disabled and Extensions Composite True:
XFCE Panels are green. Mousing over icons in panel turns that square background black. Does not remain black when mouse is moved elsewhere.
Terminal is green tinted white. Remains green when GlXgears is launched.
Mouse pointer remains white when glxgears is launched.

Thanks

So even the color change of the cursor and terminal are not affected by the patch? I guess this is not an endian problem then. I'll have to find out more about pitfalls with EXA + XComposite.

Correct. That list was the same patched and not patched.

Ubuntu 13.04 on iMac G3 R128 Ultra  3.8.0-7-powerpc-smp #13-Ubuntu SMP
withOUT oldmesa installed.
At 16 bit color, LXTerminal is green instead of black. At 24 bit color, LXTerminal looks as expected. No text issues apparent in either case.

I believe all the previous Ubuntu 12.04 tests I posted were at 16 bit. Any use to repeat at 24?

So using 24 bit depth helps? EXA and DRI are still active according to the log file right? If so, another case breakdown like comment 16 would help.

Comment #19 was daily test ISO of Lubuntu without old mesa so DRI was not enabled.
LXTerminal was green instead of black. Changing color depth from 16 to 24 resolved. Occasional black bar on one line instead of text in Firefox browsing.Scrolling or clicking clears the black bar. Should this be a new bug report?

Reverting back to original bug report which is Xubuntu 12.04 without OUTREGP patch.Old mesa is installed and DRI IS enabled. Changing depth from 16 to 24 resolves all issues. No options used in xorg.conf related to composite or EXA options.
Mouse pointer turns black when running GLXgears and goes back to white when stopped. (Note: it does the black mouse pointer in GLXgears with XAA also.)

I will get you a full redo of breakdown like comment #16 with/without patch at 24 bit color over the weekend.

Thanks

So to the "constants" in comment #16 should have also had ColorDepth 16

The following constants:
Constants:
EnablePageFlip True
EXANoComposite True
Window Manager Compositor Disabled
ColorDepth 24

I observe no problems with or without OUTREGP patch.

DRI Enabled and Extensions Composite False
XFCE Panels and GLXgears colors look correct.
Terminal is expected gray.
Mouse pointer turns black when glxgears is lauched.
Goes back to white when glxgears closed.

DRI Enabled and Extensions Composite True
XFCE Panels and GLXgears colors look correct.
Terminal is expected gray.
Mouse pointer turns black when glxgears is lauched.
Goes back to white when glxgears closed.

DRI Disabled and Extensions Composite False
XFCE Panels and GLXgears colors look correct.
Terminal Colors look correct.
Mouse pointer remains white when glxgears is launched.

DRI Disabled and Extensions Composite True
XFCE Panels are expected grey. Mousing over icons in panel turns that square background black.
Does not remain black when mouse is moved elsewhere.
Terminal is expected gray.
Mouse pointer remains white when glxgears is launched.

There's no longer an r128 DRI driver.