Re: p9100 bug?

[Michael <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Mar 7, 2010, at 11:52 PM, der Mouse wrote:

> > > 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.

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

> > 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.

X always hands the driver an image that matches the cursor's reported  
maximum size so it never triggered this.

> 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.)

Most code I've seen so far seems to assume that you have to use images  
the size ioctl(FBIOGCURMAX) reports. On the other hand, *MAX implies  
that smaller images should be supported.

> 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.

Eh? Which X11R6.4 code are you talking about? Are you trying to use  
Xsun with cg3 emulation or something like that? Why on earth would you  
want to do that?

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBS5SWQMpnzkX8Yg2nAQJsfQf/ZT1nAXbPP6P+WnI685sHgb3/NgpjHlse
58G0oSFamuRXm8r+4Y+thE5yqhyPOPIFBJox8ng7yGbZt3Gft3/bZF+N0cg1tX8y
fRDaMEyTcX/23n1STUGhKyuNiqILHqd2rED2ENBkC0vDqDeMAQSDtXpiD6au5ExE
TjWdZgnTE98muhAD+L/wgDtmfLCP7kIdzgM4aQJeZDgmeFhuBAJR+7s42oHQsPuU
M9Sf1kZ9WNyC1PIQlDtLYIZiYSZ1gZb2lx9YrSqZIyKZ1bIlvso/hStN3saskZ3v
3/J5cf6op6Ya1gyOjKwdfdMZ6rAgwMKSbMWkVLq1yCbVKaRWV5CWkw==
=oqtw
-----END PGP SIGNATURE-----