Re: p9100 bug?

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

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

Hello,

On Mar 8, 2010, at 1:28 AM, der Mouse wrote:

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

It's never been intended to handle anything else than 64x64.

> > > /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?

A lot.
Look at the xf86-video-pnozz driver.
The Xsun code doesn't know anything about P9100, it was only ever  
intended to deal with cg6, cg3, maybe cg14 and similar chips, I'm not  
even sure p9100's mmap() offsets match whatever the Solaris driver  
used, they probably don't.
That said, the xf86-video-pnozz driver uses the XFree86 DDX which has  
a generic API to deal with cursor images intended to support most  
bitmap formats in common use. This API will always hand the driver in  
question an image which matches the description given by the driver -  
always the same size, endianness, bit order etc.
Since for some reason some accesses to the DAC from userland code  
turned out to be unreliable ( probably some timing issue, talking to  
the blitter Just Works(tm) ) the driver uses /dev/fb* ioctl()s to  
program the DAC ( that is, palette and cursor sprite ).
That is the only reason I implemented support for the cursor sprite  
ioctl()s at all.

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

Good question, I know the cg6 only supports a 32x32 sprite, same with  
S24 and cg14 - AG-10e and p9100 support 64x64 but these use generic  
IBM DACs, and as far as I remember all PCI and UPA cards ever sold  
by / for Sun support 64x64 as well.
Either way, it's not technically a Sun part - IIRC only Tadpole and  
Fujitsu ever used the P9100 in SBus hardware and Fujitsu used a  
completely different DAC.
That said, I have never found any authoritative documentation on the  
cursor sprite ioctl()s, so I have no idea if drivers are supposed to  
accept arbitrary image sizes. Also, specifying a stride other than  
width makes little sense, just leave whatever part of the image you  
don't want to use transparent. I don't think every driver should come  
with code to convert arbitrary bitmaps to whatever size its hardware  
likes. Supporting 32xn is easy enough though. I don't see what good  
that would do just to support Xsun though - there's no acceleration  
available and it would only give you 8 bit colour anyway.

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

That would be quite useless on the sparcbook unless you like a dumb 8  
bit framebuffer.

> > 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 I said - you probably already use a wscons kernel, with that you  
can just use Xorg -configure to get a mostly useful xorg.conf, adjust  
DefaultDepth to your liking ( 8, 16 or 24 bit work ) and you'll have  
accelerated X.

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

Have fun porting the acceleration code - the blitter is easy enough to  
program, the drawing engine supports rectangles, lines, triangles and  
quadrilaterals with the usual set of rasops, the only pitfall is that  
the blitter works on bytes and the drawing engine works on pixels.  
Switching colour depth is tricky but code to do it is in the kernel  
driver, just needs to be made available via some private ioctl() ( I  
never got around to get rid of the colour depth switching code in the  
X driver - I hate it when userland messes with important hardware  
settings behind the kernel's back. The kernel driver will switch to 8  
bit when it gets control back though. )

have fun
Michael

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

iQEVAwUBS5VdpcpnzkX8Yg2nAQKOFQf/Q94DN3MRBg2SCSC7as8MCNhJRjPTL4bT
7jORsPFRLmrMKUSiqLDmja2pAV+ffjn1yuVDcuK/lSfu/9Z3MIjX5B9uZbvRcGom
RCbQ6z2VSNSF1H8cJCU2QR+lxdFBVM0s0C4c1YnaqSnNXXS9DM8OIVXytpkNqlTu
bBf3WajmtE5pFo2uXw0KY4Pr9o4Akj4j633P1ICFjZrnEn05v4yODbtDeX8Jb3xR
TVP2ZB2hck8R39VaACtRQSWw+dM3mLGO/cmHH+cA1tbfen50kJSNoHpEAY6Kf9PP
YCavCtSdAr06morKoJPd3PDrMdIO8Sb4jfW/puRAEY9YiSnrVckOFA==
=vNV/
-----END PGP SIGNATURE-----