ag@amix.commodore.com (Keith "Cheese Whiz" Gabryelski) (03/13/91)
I am having a problem with an implementation of the X11R4 server. On our 68030 box I have compiled with gcc a MFB server using Sun's BW code. My X11R4 source is up to patch level 18. While using the server parts of windows may become `stuck' in the foreground and obstruct any other objects (that is, it is stuck in the `super' foreground and no client will be able to write over it). This obstruction will stay even if client that created the window is moved or killed. The only way I have found to remove the obstruction is to reset the server. This `ghosting' as I will call it stays even when the screen saver turns on. If a window is move to region of the obstruction events will go to the window moved window NOT the window that caused the obstruction. I can usually make this problem appear by using olwm (from AT&T) and click and hold with the right mouse button on the menu bar and (when the menu comes up) click on ``Full size'' option with the left mouse button (while the right mouse button is still held down). At this point the xterm with grow to full screen size but the bottem part of the old window will be stuck. This also happens when using twm but I haven't been able to re-create it at will in this case. I have investigated this problem a bit and nothing seems out of the ordinary to my admittedly naive eye. Has anyone seen this or a similar problem? Any pointers would be aprecieated. Pax, Keith -- Too many people take too many risks. Too many people I see get dis'd. Keith Gabryelski Advanced Products Group ag@amix.commodore.com ...!cbmvax!amix!ag
schoch@trident.arc.nasa.gov (Steve Schoch) (03/14/91)
I have seen this problem with a server I was working on once. What happens
is that rectangles can get removed from the clip lists of all windows,
including the root. Once this happens, there is no way to get it back
because no window "owns" that rectangle by having it as part of its
cliplist.
The problem turned out to be in server/ddx/mi/miregion.c. I don't know if
this was fixed in later versions but I doubt it because the problem was
also a problem with bcopy() from libc on this machine. The section of code
is:
if (prepend)
{
new = REGION_BOX(dstrgn, numRects);
if (dnumRects == 1)
*new = *REGION_BOXPTR(dstrgn);
else
bcopy((char *)REGION_BOXPTR(dstrgn), (char *)new,
dnumRects * sizeof(BoxRec));
new = REGION_BOXPTR(dstrgn);
}
If you look carefully at this piece of code (which only gets called if prepend
is TRUE, which isn't very often), you will see that when bcopy() is called,
both REGION_PTR(dstrgn) and new point to the same buffer, but new is a higher
address (new = REGION_PTR(dstrgn) + numRects).
This is the only piece of code I could find in the MIT X source in which
it is assumed that bcopy can handle overlapping buffers. On some machines,
perhaps yours, bcopy always copies in the forward direction which will
overwrite one or more rectangles in the region.
If this is your problem, call ovbcopy() instead of bcopy() if you have it,
or write your own ovbcopy().
Steve
schoch@trident.arc.nasa.govmouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/18/91)
> The problem turned out to be in server/ddx/mi/miregion.c. I don't > know if this was fixed in later versions but I doubt it because the > problem was also a problem with bcopy() from libc on this machine. > bcopy((char *)REGION_BOXPTR(dstrgn), (char *)new, > dnumRects * sizeof(BoxRec)); > [...] when bcopy() is called, both REGION_PTR(dstrgn) and new point > to the same buffer, but new is a higher address (new = > REGION_PTR(dstrgn) + numRects). > This is the only piece of code I could find in the MIT X source in > which it is assumed that bcopy can handle overlapping buffers. On > some machines, perhaps yours, bcopy always copies in the forward > direction which will overwrite one or more rectangles in the region. In the absence of a "standard" spec for bcopy(), one has to treat some implementation as a reference implementation. Since bcopy() is a Berkelyism, the implementation to choose would be Berkeley's. And the ability to correctly handle overlapping arguments is one of the big features of Berkeley's bcopy(). Thus, I would maintain that a bcopy() that doesn't correctly handle overlapping arguments is simply broken. (Not a very helpful point of view if you're stuck with such a bcopy(). But let's lay the blame where it belongs. X should perhaps use memcpy() or memmove(), as appropriate, instead of bcopy(), if such bcopy() implementations are excessively common.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu