two very long-standing X bugs

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

I've just found two very long-standing bugs in the X server (they date
back to - at least - X11R4).  I've fixed one of them; while what I've
done for the other is not a real fix, it's a good enough kludge for my
purposes.

I mention them here in case anyone wants to push them upstream (x.org's
bug-reporting appears to require tolerating some Web thing, so I won't
be doing it) and/or adopt them, either for NetBSD or privately.

I have a test program available at
ftp.rodents-montreal.org:/mouse/X/cursorbug.c for people who want to
test for these bugs.  It has a lengthy comment header explaining the
misbehaviours it tests for.

The first is that a CreateCursor request (Xlib call
XCreatePixmapCursor) with a non-bitmap source pixmap and a None mask
pixmap is supposed to draw a BadMatch error, but it doesn't, because
the test for depth 1 is an else-if on the if checking for a None mask
pixmap.  Here's my patch for that (this is against 5.2's xsrc, but the
code is basically identical at least as far back as X11R4):

--- a/external/mit/xorg-server/dist/dix/dispatch.c
+++ b/external/mit/xorg-server/dist/dix/dispatch.c
@@ -2863,9 +2863,10 @@ ProcCreateCursor (ClientPtr client)
     }
     else if (  src->drawable.width != msk->drawable.width
            || src->drawable.height != msk->drawable.height
-           || src->drawable.depth != 1
            || msk->drawable.depth != 1)
        return (BadMatch);
+    if (src->drawable.depth != 1)
+       return (BadMatch);
 
     width = src->drawable.width;
     height = src->drawable.height;

The other is that using a None mask bitmap ends up, on at least some
hardware, extending the mask to the right with background bits to a
multiple of 32 bits.  In my experience i386 and amd64 suffer from this;
I don't know whether the exact video hardware matters.  Suns are mixed;
either exact video hardware or exact X version does matter there, since
I don't see it on sparc32 with X11R4 on hardware like cg6 aand cg14,
but I do see it on sparc64 with X11R6 on an ATI Rage I/II.

Here's what I've done for this.  It's ugly and inefficient and probably
will not work right for other bitmap bit orders and/or byte orders; I'm
sure someone familiar with server internals could fix this right.  But
it does at least indicate one place this bug could be fixed, and it
works for the cases I personally care about so far.  Cursor creation is
a rare enough event for my use cases that speed is not critical here,
so I didn't bother complicating the code to speed it up.

--- a/external/mit/xorg-server/dist/dix/dispatch.c
+++ b/external/mit/xorg-server/dist/dix/dispatch.c
@@ -2890,9 +2890,17 @@ ProcCreateCursor (ClientPtr client)
                                         XYPixmap, 1, (pointer)srcbits);
     if ( msk == (PixmapPtr)NULL)
     {
-       unsigned char *bits = mskbits;
-       while (--n >= 0)
-           *bits++ = ~0;
+      register int y;
+      register int x;
+      register int w;
+      w = BitmapBytePad(width);
+      for (y=height-1;y>=0;y--)
+       { for (x=(w*8)-1;x>=0;x--)
+         { if (x < width)
+            { mskbits[(y*w)+(x>>3)] |= 1 << (x & 7);
+            }
+         }
+       }
     }
     else
     {

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B