Re: p9100 bug?

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

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

Possibly, but it doesn't mmap anything but the video RAM, which is what
was behind my implication that the only thing that mattered was that
video RAM was at offset zero.  Cursors and colourmaps are done via
ioctl()s.

Yes, you put the registers right after the video RAM, but finding them
was nontrivial - as far as I can tell, the only way to find that offset
is to read the boot-time message which reports the size of the video
RAM area (or "just know" it).

>>> That said, I have never found any authoritative documentation on
>>> the cursor sprite ioctl()s, [...]
>> [...].  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.

Aye.  Though I'd say more important than exactly where we draw the line
between userland's responsibility and the driver's responsibility is
documenting it.  fb(4)?

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

Well, ideally. :-)  My 3GX has some dead bits in the cursor RAM.
Fortunately they're in the image plane rather than the mask plane, but
if they *were* in the mask plane it's entirely possible I would
consider it important to handle a 32x32 cursor as such rather than by
padding to 64x64.

Of course, that's a workaround for broken hardware.  But still.

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

If FBIOSCURSOR accepted arbitrary sizes, userland code wouldn't have to
"deal with" different hardware sizes, except when it wants a cursor
larger than the hardware supports.  Add a stride value and userland
wouldn't even to futz about with getting padding right, FWVO "right";
it could just describe the data it has.

I see four basic alternatives:

(a) Every driver does this itself.
(b) Every driver does this with a kernel utility routine.
(c) Every userland app does this itself.
(d) Every userland app does this with a userland library routine.

Personally, I prefer (b), though it's admittedly a close call.

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

"We" aren't?  That's what /usr/xsrc holds.  (I'm fairly sure I said,
near the beginning of this thread, that I'm doing this on 4.0.1, but it
wouldn't surprise me if, even if I did, readers had lost track.)

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

If it still has the braindamage from XFree86, such as doing bus
enumeration in userland, such as setuid-root X servers, then I'm just
as (un)willing to tolerate it, even if the XFree86 warning label on the
front has been covered up with an Xorg sticker.

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

Me neither.  4.0.1, as mentioned above.

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