Created attachment 112761 [details] Xorg.0.log Using LXDE on Debian 8 PowerPC (iMac G3 w/ G4 upgrade), xf86-video-r128 package xorg-xserver-video-r128 6.9.2-1. I can upload several screenshots of corruption, artifacts, etc., most of which occur frequently but I can't yet reliably reproduce. I might be able to run xts5 and see if that gives anything more specific; is there another utility preferred for testing 2D rendering to help with identifying/investigating these kinds of issues?
Created attachment 112762 [details] Screenshot 1 This untouched screenshot shows artifacts in an LXTerminal window: -the left-hand edge of the the window, which incrementally disappears as text is output to the terminal (after running ls and scrot in this case). -the lower right-hand corner shows text from an Iceweasel window The artifacts persisted after moving the window to the position it now appears.
Created attachment 112763 [details] Screenshot 2 This untouched screenshot was taken after waking up the display from standby (the computer itself did not suspend): -the title bar and border of the LXTerminal window is partially missing/corrupted.
Created attachment 112764 [details] Screenshot 3 This untouched screenshot shows -corruption in the Iceweasel address bar (which was present in the other screenshots to a lesser degree) and -an artifact on the webpage displayed--"Configuring the" appearing in whitespace after scrolling down the page (smooth scrolling is disabled)
Created attachment 112765 [details] Screenshot 4 Similar to as in Screenshot 3, there is an artifact after scrolling--"Seeing Printers on Other Subnets" as well as missing text in LXTerminal (the prompt is missing on the current line and the previous line has a box at the prompt where it should say "scrot" for the sixth time.
Created attachment 112766 [details] Screenshot 5 This screenshot shows more substantial artifacts appearing in the LXTerminal window resembling information (scaled 50% vertically) from the PCManFM window.
Yes, a certain percentage of EXA render ops cause corruption, at least until you move the mouse to that area forcing a redraw. The bad news is that I never managed to fix this. The good news is that by selectively disabling features, you can probably get back to a normal screen. One thing is that these are mostly text composite operations. So you can add Option "ExaNoComposite" "true" to the "Driver" section. Another possibility is that the XComposite extension itself is causing a conflict. For this try an xorg.conf with Section "Extensions" Option "Composite" "false" EndSection and combinations of the two. Hope that helps.
(In reply to Connor Behan from comment #6) > Yes, a certain percentage of EXA render ops cause corruption, at least until > you move the mouse to that area forcing a redraw. In my case a redraw is not forced simply by moving the mouse; the cursor itself flickers as well (using the DMZ cursor theme; this might be a separate issue). Doing something in the window might cause it to redraw affected components only. I don't remember how else to trigger an entire redraw short of minimizing a window. I have yet to test the workarounds; for reference, the current xorg.conf should be the same as the "imac 400,450" entry here: http://oswaldkelso.blogspot.com/2009/11/imac-xorgconf-ppc-all-versions.html (when I installed Debian 7, it did not work out of the box--apparently a known issue).
(In reply to Christopher Chavez from comment #7) > (In reply to Connor Behan from comment #6) > > Yes, a certain percentage of EXA render ops cause corruption, at least until > > you move the mouse to that area forcing a redraw. > > In my case a redraw is not forced simply by moving the mouse; the cursor > itself flickers as well (using the DMZ cursor theme; this might be a > separate issue). It might be useful to try Option "SWcursor" "true" if you haven't already.
*** Bug 91420 has been marked as a duplicate of this bug. ***
Created attachment 121534 [details] screenshot of font corruption in KDE3 from openSUSE Tumbleweed with 18.0 server and r128 driver 6.10.1 This is with the following configuration: Section "Extensions" Option "ExaNoComposite" "true" Option "Composite" "Disable" EndSection Normally I only use disable composite, but tried other per comment 6 without any apparent effect. Same unpleasant effect using only ExaNoComposite. gfxcard pic: https://bugs.freedesktop.org/attachment.cgi?id=117165 cpuinfo: vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 2000+ stepping : 2 cpu MHz : 1666.415... flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow vmmcall
(In reply to Felix Miata from comment #10) > Created attachment 121534 [details] > screenshot of font corruption in KDE3 from openSUSE Tumbleweed with 18.0 > server and r128 driver 6.10.1 > > This is with the following configuration: > Section "Extensions" > Option "ExaNoComposite" "true" That one goes in "Driver".
(In reply to Connor Behan from comment #11) > (In reply to Felix Miata from comment #10) > > Section "Extensions" > > Option "ExaNoComposite" "true" > That one goes in "Driver". Please elaborate. String "river" is not present in any of sections Monitor, Screen, Device, DRI, Extensions, Module, Modes or anywhere else I can find in any of the many xorg.conf files I've accumulated, while the xorg.conf man page is heavily loaded with same string.
(In reply to Felix Miata from comment #12) > (In reply to Connor Behan from comment #11) > > (In reply to Felix Miata from comment #10) > > > Section "Extensions" > > > Option "ExaNoComposite" "true" > > That one goes in "Driver". > > Please elaborate. String "river" is not present in any of sections Monitor, > Screen, Device, DRI, Extensions, Module, Modes or anywhere else I can find > in any of the many xorg.conf files I've accumulated, while the xorg.conf man > page is heavily loaded with same string. In many (if not all) of the xorg.conf files I came across for the iMac G3, indeed there was not a Driver "r128" entry under the "Device" section (which according to man xorg.conf is mandatory, though I'm guessing the xf86-video-ati wrapper figures out what to do if it's not present). So the "ExaNoComposite" option entry is implied to go after the Driver "r128" entry in the "Device" section: Section "Device" Identifier "Configured Video Device" Driver "r128" Option "ExaNoComposite" "true" ... EndSection
(In reply to Connor Behan from comment #6) > One thing is that these are mostly text composite operations. So you can add > > Option "ExaNoComposite" "true" > > to the "Driver" section. Another possibility is that the XComposite > extension itself is causing a conflict. For this try an xorg.conf with > > Section "Extensions" > Option "Composite" "false" > EndSection > > and combinations of the two. Hope that helps. My preliminary, unscientific results are that the corruption in my case wasn't totally eliminated by any combination of toggling ExaNoComposite or the Xcomposite extension (confirmed each in the Xorg.0.log), though some combinations seemed to be worse off than others.
Option "ExaNoComposite" "true" is a sufficient solution here with or without my usual Option "Composite" "false" set.
I'm an idiot. I indeed meant "Device" :).
*** Bug 94913 has been marked as a duplicate of this bug. ***
I note that: 1) the X server was built in December 2014; 2) you're running a fairly old (3.2) kernel, also; 3) there seems to be an acceptable workaround (setting Option "ExaNoComposite" "true" in the "Device" section). Could you try this with a newer X server and kernel? I note that you're using really old graphics hardware; while I realize that this is not a Mesa problem, please note that Mesa dropped support for R128 in 2012 with version 8.0.
(In reply to Ben Crocker from comment #18) > I note that: > 1) the X server was built in December 2014; > 2) you're running a fairly old (3.2) kernel, also; Actually, I was running 3.16 at the time I reported this (3.2 was used by whichever machine debian used at the time to compile the 3.16 kernel for me). I did eventually use 4.x kernels but do not recall there ever being any noticeable improvement. > 3) there seems to be an acceptable workaround (setting > Option "ExaNoComposite" "true" > in the "Device" section). > > Could you try this with a newer X server and kernel? As I mentioned in bug 91739, I no longer possess any r128-equipped machines, and am unlikely to acquire any in the near future. If Felix Miata is still happy with the workaround (cf. comment #15), then I guess this can be closed as WORKSFORME/WONTFIX until someone wishes to reopen it.
The PC motherboard my r128 was installed in died shortly after I last commented here, and the last time I booted a G3 was long before then, so there is no need to keep this open on my account.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-r128/issues/4.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.