Refresh problems: X 4.2, KDE3, & FreeBSD 4.6 on ATA rage 128 / Dell Inspiron 8000
Brian T. Schellenberger
bts at babbleon.org
Mon Aug 12 05:25:54 BST 2002
[Please do NOT group-reply to this!
I'm broadcasting this far & wide. I will summarize any suggestions & results
to anybody who expresses an interest, but please let's never followup to such
a broad group.]
[For those of you coming in the middle, I've been having trouble with X not
refreshing properly since I upgraded to FreeBSD 4.6, XFree86 4.2, and KDE3.
This is most noticable with xv, where I will page through "xv *.*" output and
the previous pictures won't properly get redrawn; thus, there will frequently
be portions of multiple different pictures showing up at once. To see the
effect I'm complaining about, see http://www.babbleon.org/problem.png, where
you can see fractions of the first four images that I tried to display.]
Ok, I've been playing around some more, and I *do* now have a workaround for
this problem in xv. I don't really suspect that it's a bug in xv, but it's a
pretty cheap patch for anybody else having refresh problems with xv so it
might be worthwhile making it generally available, anyway, for anybody
running into similar symptoms.
But more importantly, this patch is interesting because for somebody with the
right backgroup is must surely hold a clue about what the underlying problem
is. The actual patch is pasted in below, but what it does is very simple: It
adds a 1-nonsecond delay to the the xv routine (openPic) that actually draws
a picture.
Now here is the really odd part (to me): This fixes the problem whether the
sleep is requested before *or* after the GenExpose() call in xv! That seems
quite odd to me, granted that my ignorance about both xv and X programming is
vast.
Anyway, if anybody is interested in unraveling this mystery, I would be happy
to try any experiments that you can suggest. In the meantime, my workaround
takes care of the main thing that was plaguing my life, so I will be
personally satisfied even if this matter is dropped here.
But I'd rather work with somebody with more expertise than myself to unravel
this mystery. If anybody getting this message can shed any insight, I'm all
ears.
i8k# diff -c xv.c.old xv.c
*** xv.c.old Mon Aug 12 00:01:50 2002
--- xv.c Mon Aug 12 00:02:09 2002
***************
*** 2784,2790 ****
--- 2784,2804 ----
to generate the correct exposes (particularly with 'BitGravity' turned
on */
+ #if 0
if (mainW && !useroot) GenExpose(mainW, 0, 0, (u_int) eWIDE, (u_int)
eHIGH);
+ #else
+ /*Brian T. Schellenberger: workaround for X 4.2 refresh problem*/
+ if (mainW && !useroot) {
+ #include <time.h>
+
+ struct timespec period;
+ period.tv_sec = 0;
+ period.tv_nsec = 1;
+
+ nanosleep(&period, NULL);
+ GenExpose(mainW, 0, 0, (u_int) eWIDE, (u_int) eHIGH);
+ }
+ #endif
return 1;
On Sunday 11 August 2002 08:40 am, Brian T. Schellenberger wrote:
| On Sunday 11 August 2002 07:33 am, Michel Dänzer wrote:
| | On Sun, 2002-08-11 at 05:01, Brian T. Schellenberger wrote:
| | > On Saturday 10 August 2002 04:47 pm, Michel Dänzer wrote:
| | > | On Sat, 2002-08-10 at 04:44, Brian T. Schellenberger wrote:
| | > | > First, thank you very much for responding!
| | > | >
| | > | > On Friday 09 August 2002 06:32 pm, Michel Dänzer wrote:
| | > | > | On Wed, 2002-08-07 at 05:10, Brian T. Schellenberger wrote:
| | > | > | > I've always had occaisonal problems with refreshes not properly
| | > | > | > taking place, but since I've installed XFree86 4.2, it has
| | > | > | > gotten much worse.
| | > | > | >
| | > | > | > If I invoke "xv", for example, on multiple pictures, then when
| | > | > | > I go to the next picture it will very frequntly fail to
| | > | > | > properly refresh the picture. For example, if the first picture
| | > | > | > is 200x200 and the second is 400x200, then it will typically be
| | > | > | > the case that once I hit the spacebar, I see the original
| | > | > | > picture on the left half of the xv window and the right half of
| | > | > | > the new picture on the right half.
| | > | > | >
| | > | > | > The other program where I notice this frequently is vncviewer.
| | > | > | > It has always had some noticable refresh problems, but they
| | > | > | > seem to be markedly worse now.
| | > | > |
| | > | > | I assume Option "NoAccel" fixes the refresh problems? If so, try
| | > | > | playing with the "XaaNo..." options described in the XF86Config-4
| | > | > | manpage to isolate an offending acceleration function. I'd guess
| | > | > | the ones related to Pixmaps would be a good start.
| | > | >
| | > | > This is a very logical assumption. Unfortunately, it's not true.
| | > | >
| | > | > If I try setting NoAccel, the problem still occurs; it's not even
| | > | > improved (that I can tell) by setting the option.
| | > |
| | > | Well, the CPU draws every single pixel without acceleration, so this
| | > | sounds like a problem with the apps (unlikely I think), the hardware
| | > | or maybe some kind of PCI configuration?
| | >
| | > The main application that's causing trouble being xv, which has been,
| | > to say the least, *very* stable, I'm making the starting assumption
| | > that it's not an application error, but of course it could be an error
| | > that is finally being exposed. The problem definately got worse when I
| | > installed the 4.2 version of XFree86, though, and I'm still using the
| | > same version of xv (of course, since it hasn't changed in nearly a
| | > decade, I think), so X would seem to be somehow involved.
| | >
| | > Also, I'm afraid that "PCI configuration" sounds dangerously close to
| | > hardware to me, and I don't really even know what you mean by it.
| | >
| | > Would you care to elaborate?
| |
| | I was thinking of something related to Write Combining or PCI latency...
|
| Ah. Well, perhaps it's coincidence that the problem got worse when I
| upgraded to XFree86 4.2, for I upgraded to FreeBSD 4.6 at the same time,
| and perhaps there's some optimization *there* that's making the difference.
|
| | > PS: FWIW, the trick of "pre-reading" all the images (page forward and
| | > back in xv) usually solves or at least greatly mitigates the problem.
| | >
| | > Also, an "xrefresh" always solves it, and is very fast if optimization
| | > is on; I supposed I could always hack the xv code to force one after
| | > every image change but this seems a little silly . . .
| |
| | ...indeed, and I wouldn't expect this to reliably help with a problem
| | close to hardware. Just to get this straight, you aren't using any
| | special options, are you?
|
| I don't think so, but then again I'm not sure which options would be
| special.
|
| I've attached my XF86Config. There are some possibly-unusual options for
| input, but presumably those could not be related to this problem. And I
| have options backingstore set, but the problem occured before I specified
| that as well; it was one of my first attempts to work around the problem,
| in fact.
|
| Other than that it looks pretty generic to me, but then again I'm not any
| sort of X expert even though I've abrogated the right to post on this
| list--it's more that I need the assistance *of* an expert than that I *am*
| one. Though, having used X for well over decade, and and XFree86 for six
| years, I'm not exactly a newbie, either.
Ok, I've been playing around some more, and I *do* now have a workaround fo
i8k# diff -c xv.c.old xv.c
*** xv.c.old Mon Aug 12 00:01:50 2002
--- xv.c Mon Aug 12 00:02:09 2002
***************
*** 2784,2790 ****
--- 2784,2804 ----
to generate the correct exposes (particularly with 'BitGravity' turned
on */
+ #if 0
if (mainW && !useroot) GenExpose(mainW, 0, 0, (u_int) eWIDE, (u_int)
eHIGH);
+ #else
+ /*Brian T. Schellenberger: workaround for X 4.2 refresh problem*/
+ if (mainW && !useroot) {
+ #include <time.h>
+
+ struct timespec period;
+ period.tv_sec = 0;
+ period.tv_nsec = 1;
+
+ nanosleep(&period, NULL);
+ GenExpose(mainW, 0, 0, (u_int) eWIDE, (u_int) eHIGH);
+ }
+ #endif
return 1;
--
Brian, the man from Babble-On . . . . bts at babbleon.org (personal)
http://www.babbleon.org
http://www.eff.org http://www.programming-freedom.org
___________________________________________________
This message is from the kde mailing list.
Account management: http://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde
mailing list