Re: p9100 bug?

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

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

Hello,

On Mar 8, 2010, at 4:11 PM, der Mouse wrote:

> > > 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.
>
> That would explain a lot. :)

It doesn't even support all the cursor ioctl()s, only what I needed  
for X.

> > 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.
>
> Well, it was the work of maybe an hour to make X11R6.4 run on my
> Tadpole, and it would have been more like half that except that I had
> to deal with some bugs that manifest when that code is faced with a
> framebuffer type it doesn't grok.

Yeah, getting things to work as dumb framebuffers is usually easy.

> I don't recall whether I had to supply an mmap offset when adding that
> support.  The video RAM offset is zero, though, which I think is how
> most of the other framebuffers work.

IIRC I put the 2MB video memory at offset 0 and the registers right  
behind it. Your Xsun code probably uses the cg3 offsets though.

> > > I think the p9100 is the first Sun framebuffer I've run into [...]
> > Either way, it's not technically a Sun part -
>
> Heh.  I should not have needed to be reminded of that.  The thing  
> feels
> so much like a Sun I tend to forget it actually isn't.

There's plenty of non-standard hardware in the sparcbook - the pcmcia  
part for example is not in any way compatible with Sun's SBus-PCMCIA  
frob, the keyboard and pointing stick are PC parts ( compare to  
contemporary thinkpads... ) and only the built-in microcontroller  
makes them look like a Sun keyboard and mouse to the rest of the  
machine. The serial port for the built-in modem is a 16550, not the  
usual Zilog part. The ISDN/audio chip can be powered down separately,  
unlike the variants Sun used, the auxio register layout is different  
and there's an additional auxiotwo...
I have no clue wether the P9100 they used is a special SBus part or if  
it's the PCI variant sitting behind some sort of SBus-PCI glue  
( that's the case with the AG-10e - if contains a bridge of some sort  
and three PCI graphics chips )

> > 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.
>
> Well, X and Y sizes are passed in, and all the drivers whose code I've
> checked look at them at least for rudimentary sanity.  Sometimes they
> even use some of them, such as the "count = p->size.y * 8" line in
> p9100.c.  So I'd say the design calls for using the size values,  
> though
> of course I didn't actually design it so I don't truly know.

Well, at least supporting width 32 seems reasonable.

> > Also, specifying a stride other than width makes little sense,
>
> Hm?  I disagree.  For example, specifying a stride of 32 for a cursor
> of width 16 makes perfect sense; it just means each row's first bit is
> displaced by 32 bits, rather than 16, from the first bit of the
> previous row.

It's superfluous - the right half of the image would be empty anyway.

> > just leave whatever part of the image you don't want to use
> > transparent.
>
> Oh, it's not *necessary*.  It's not even particularly difficult to
> avoid.  But it makes sense.

Not really. All it does would be telling the driver to ignore parts of  
the image - why not leave them empty in the first place? A 16x16  
cursor looks exactly the same in a 32x32 and in a 64x64 bitmap.

> > I don't think every driver should come with code to convert arbitrary
> > bitmaps to whatever size its hardware likes.
>
> I don't see why not; the alternative is to push that code into  
> userland
> instead.  That's a defensible position, certainly, but I think arguing
> it belongs in the kernel is also defensible, especially given how the
> (apparent!) design of FBIOSCURSOR has userland providing a size.

Well, userland code would have to deal with different hardware  
supposrting different cursor sizes anyway, so pushing the same  
functionality into every single driver seems counter productive.

> > > 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.
>
> I prefer it to tolerating the idiocies XFree86 imposes.

We're not using xfree86 anymore ;)
( yes, I know, Xorg isn't any less PCish but as far as I can tell it  
runs reasonably well on sparc hardware these days )

> > 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.
>
> Xorg?  There is nothing by that name in my latest build's DESTDIR, its
> OBJDIR, or /usr/X11R6.

It lives in /usr/X11R7, not sure if that's built for 5.0 though. It's  
been in -current for sparc ever since it was imported.

> The notion of needing a config file for the X server borders on
> insanity to me (well, for a case like this; for XFree86, given their
> attempt to shoehorn what should have been multiple servers into one,
> it's fairly necessary - I still call it insanity, but it's consequent
> insanity, not primary insanity).  I'll stick with X11R6.4.

It's supposed to work without a config file but I usually don't like  
the defaults.

> > > As for why I'm using X11R6.4 rather than /usr/xsrc X, [...]
> > Have fun porting the acceleration code -
>
> Why do you expect me to bother?  I might someday teach it to use the
> blitter for scrolling, but it's unlikely I'd bother with even that.

Because I find most dumb framebuffers intolerably slow.

> > 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()
>
> It is?  I don't see any; is it newer than p9100.c,v 1.34?

Apparently.

have fun
Michael

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

iQEVAwUBS5V1pcpnzkX8Yg2nAQI9MQgAn9WhbRmI2RiUNhPBo0fGx2xpoGhG9z3u
Ag08RiWbIhVxadgliMyBSSSbsw/IcDD9h/9reqmVKIQvFbLpDz8/Eskuelo2ud/2
O5h2iCydVPi7qelSihchhjQTyi3kHLHY7TZw4fljNqo6b9tRnU85WtVnrAByhAL6
oYw0GSqze6tI7mJttccm3/yvXAM3gPOue/M9A4R+ZbziQqn+lYec2iCzuXrZT34R
0hN4haAioajBlcC1/UOFOStbPvRijDP9IG1egK4HZdubqkaQu07nE3KjSLwClPeE
jkZLAe9kV0MZglPLl8bkp+6iZ2kmhrwn1iU7dK/yk/lrSDbWucrq9w==
=ScpC
-----END PGP SIGNATURE-----