Re: p9100 bug?

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

>> Is there any interest in other bugs?  p9100.c 1.34 breaks rather
>> unplesantly when asked to set a cursor <=32 pixels in the X
>> direction;
> Define 'breaks rather unpleasantly' -

The cursor comes out 64 pixels wide, with a junked bottom half.  To
illustrate by analogy with 4x4 and 8x8, a cursor that's supposed to be

* * * *
- - * -
- * - -
* * * *

comes out as

* * * * - - * -
- * - - * * * *
? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ?

where the ?s represent "random" bits - the image and mask bits come
from userspace memory past the bits passed to the ioctl.

> did you use fb or wsdisplay ioctls?  the former have been working
> fine with X for ages.

/dev/fb FBIOSCURSOR.  I can only speculate that the X server(s) it's
been working fine with compensate(s) somehow, such as by padding all
cursors' data to 64x64 before calling the ioctl.  I'd been assuming
that either pnozz support was new enough in 4.0.1 that it hadn't got
tested yet, or perhaps that people running X on the pnozz had been
using -softCursor, but I'm much more puzzled in view of what you say.

I can easily produce a test program for anyone interested.

Of course, it would help if FBIOSCURSOR's interface were documented
(or, if it is documented, documented more visibly - I haven't managed
to find any documentation on it).  For example, there is no stride
value in struct fbcursor; the image and mask values are typed as char,
which would tend to lead one to assume the rows are either packed
tightly into a bitstream or padded to 8-bit units - but p9100.c assumes
they're padded to 64-bit rows (which it accesses in 32-bit chunks),
whereas hw/sun/sunCursor.c in the X11R6.4 tree pads to 32-bit units, as
does the cg6 driver.  The sunCursor.c in 4.0.1's /usr/xsrc appears to
do likewise, though INTERNAL_VS_EXTERNAL_PADDING (which isn't in
X11R6.4) makes it less clear exactly what's going on.  (I can't tell
whether /usr/xsrc's server tickles the bug; I haven't managed to make
it get far enough yet.  It falls over with SIGPIPE or SIGBUS depending
on how I run it - the X11R6.4 one bus errored too before I taught it
about FBTYPE_P9100.)

I would normally hesitate to use the X11R6.4 code as a reference, but
FBIOSCURSOR (and thus its interface) is old enough that it does not
seem unreasonable to me to do so in this case.  Certainly stock p9100.c
did not interoperate correctly with it.

/~\ 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