Re: p9100 bug?

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

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

>>> 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.  [...]
>> What am I missing?
> [...XFree86 pnozz-specific code...]

Ah.  Gotcha.

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

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.

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

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

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

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

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

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

And it actually doesn't compel 8bpp; it would be fairly easy to have
some one of the pieces involved do depth switching, since you say the
hardware supports it.

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

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.

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

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

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