Re: p9100 bug?

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

> Ah, now I know what you meant.  Yeah, the code doesn't know how to
> handle cursor images other than 64x64.

Look again.  It works just fine for 64xN images for any N from 1 to 64
(maybe for zero N too; I'd need to think about it).  I believe it
probably breaks badly for negative x or y, but I haven't investigated
that in detail; I just EINVALed out for negative sizes as part of my
Xsize<33 fixes and let it go at that.

>> /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.
> X always hands the driver an image that matches the cursor's reported
> maximum size so it never triggered this.

It does?  I don't see it doing so.  I see code in sunLoadCursor() which
crops the cursor if it is larger than pCurPriv->width by ->height, and
in the xsrc sunLoadCursor I see some conditionally compiled code whose
semantics are opaque to me but which is commented "for 64-bit server,
convert image to pad to 32 bits".  But I don't see anything that
ensures the cursor is at least as wide as the max size.  (It may happen
to always do so at present because it pads pixmaps to 64 bits and
that's the cursor max size, but that's not the same thing.)

What am I missing?

> Most code I've seen so far seems to assume that you have to use
> images the size ioctl(FBIOGCURMAX) reports.

And, with at least some other framebuffers, padding to 32 bits amounts
to doing exactly that, at least in the X direction (and, as I
mentioned, p9100.c handles the Y size correctly when userland's data's
X stride is 64 bits).  I think the p9100 is the first Sun framebuffer
I've run into whose hardware supports something larger than 32x32.  (I
daresay your experience is wider than mine; is my impression that 32x32
is commoner than anything larger wrong?)

>> 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.
> Eh?  Which X11R6.4 code are you talking about?

The sunLoadCursor() in xc/programs/Xserver/hw/sun/sunCursor.c from the
X11R6.4 distribution.

> Are you trying to use Xsun with cg3 emulation or something like that?
> Why on earth would you want to do that?

No; as I said, I had to teach it about FBTYPE_PNOZZ, and if you're
doing cg3 emulation it says it's FBTYPE_SUN3COLOR.

As for why I'm using X11R6.4 rather than /usr/xsrc X, there are
multiple reasons.  First is consistency; this is the same X source tree
I use everywhere else.  Second is bugfixes; I've fixed a few bugs in it
which I haven't verified to be fixed elsewhere.  Third is sane design;
4.0.1's /usr/xsrc appears to be XFree86, with all the design botches
that implies (such as userland doing bus enumeration, even on machines
that don't suffer from the peecee braindamage that led to it on
peecees) and setuid-root X servers.  I dislike these botches enough
that I was willing to put some little amount of effort into making my X
tree work.  (It turned out to be easy.)

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