The default driver/mode used for PowerMac G5 Radeon 9800PRO's messes up all normal text display by default...

[Justin Hibbits]

Just catching this.  The radeon.ko driver is barely functional for
PowerPC.  I recommend removing it before trying again (we should just
disable it, since it's useless right now, and instead put effort into
getting the radeonkms working).

- Justin

On Sun, Jul 20, 2014 at 7:26 PM, Mark Millard <markmi at dsl-only.net> wrote:
> Hmm. I see that I managed to not mention that this context is/has xfce4's desktop and standard/included programs involved, along with just xscreensaver having been added. (It is from a preliminary stage of installing things before more might be added.)
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> On Jul 20, 2014, at 7:07 PM, Mark Millard <markmi at dsl-only.net> wrote:
>
> [Context: Xorg -configure generated xorg.conf file for a G5 (7,2), except for explicit alternatives noted for noAccel and SubPixelOrder. Also this is the same SSD used for booting NVidia based PowerMac G5's (7,11's) that have no such problems for the distinct Xorg -configure file generated for them. uname -a reports for this SSD:
>
> FreeBSD FBSDG5S0 10.0-STABLE FreeBSD 10.0-STABLE #0 r268571: Sun Jul 13 06:28:19 UTC 2014     root at grind.freebsd.org:/usr/obj/powerpc.powerpc64/usr/src/sys/GENERIC64  powerpc
>
> (just freshly installed a day or so ago) and the "portsnap fetch extract" was executed earlier today.
> ]
>
> The "user experience" report for what I've observed:
>
> The PowerPC64 "ATI Radeon 9800PRO NH (AGP)" driver used in a PowerMac G5 (7,2) messes up *all* normal text display unless Option "NoAccel" is enabled: menu text, window titles, input fields, label text, all such text. (Basic desktop display, simple dialogs and windows from programs, nothing fancy involved.) When the problem exists in my context the xorg.conf is strictly as generated by Xorg -configure when in this type of PowerMac.
>
> The other normal graphics seem fine: only text is messed up for these basic displays. But the compositing results are messed up if they are turned one to try to provide a visual difference around/near windows.
>
> With "NoAccel" disabled (acceleration on) so the text problem happens NONE and BGR for SubPixelOrder are messed up the same way and RGB SubPixelOrder changes how it looks but the result is still just messed up text. This is on an Apple ADC FlatPanel. (An Apple ADC CRT also gets the issue.) Some internal interface to accelerated text handling does not map things in memory as required as far as I can tell. (But I've only explored SubpixelOrder and NoAccel changes so far. I've not tried to make compositing work: I just turned it back off.)
>
> I did find one part of one example display that is simple to describe, possibly due to font size details for my context and my text size settings: The "Logout Charlie Root" text in the logout dialog had vertical strips missing (i.e., just the background color showing) from the middle or sides of letters but enough of each letter was present to be able to tell what each letter was. The strips might also have had some small amount of extra space compared to pure what "white-out" would be (?unsure!). Also with the logout dialog up the whole display got a significant red tint.
>
> All of this may suggest byte/bit order handling issues for the text when acceleration is enabled. Or possibly the 24 bits of color information in a 32 bit representation being mishandled relative to acceleration interfaces for handling such.
>
> Unfortunately I'm only around the PowerMac's for a couple of days again before being far from them for a considerable time. So for now there are limits to what I can do to help isolate things --nor will I be able to provide the test case of that G5 until I'm back round them again. But I figured an explicit note was better then saying nothing.
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
> _______________________________________________
> freebsd-ppc at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"