Re: p9100 bug?

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

> I don't think any graphics hardware you can stick into a Sun has a
> maximum sprite size of less than 32x32.

<nitpick>Well, of hardware that supports hardware cursors at
all.</nitpick>

>> 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.
> How would that make any sort of difference?  The bits in question
> would be zeroed out either way.

But the dead bits are late in the RAM, where they aren't used if you
turn off DAC_CURSOR_64.  As I say, in my case they are in the image
plane and hence extending the mask would work to conceal them, but if
they were in the mask plane (and failed in the "opaque" direction) that
wouldn't work.

>> 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.
> Well, the userland that needs to deal with it is the Xserver and
> pretty much nothing else.  Having it in one program seems more
> reasonable than having it in every single driver.

You don't have to have it in every single driver any more than you have
to have it in every single hardware module in the X server.  The code
is (or at least ought to be!) in one common place in the X server; it
could equally well be in one common place in the kernel.

I can see advantages each way.  Putting it in userland means it's not
sitting there resident even when nobody ever runs anything that wants a
cursor.  Putting it in the kernel means it's available even to those
few exceptional non-X-server programs that use cursors - and to X
servers written by people with a different understanding of FBIOSCURSOR
than the one we eventually settle on - and mostly avoids scattering
multiple versions of the code throughout compat/.

> [...], Xorg's sources live in xsrc/ external/mit

(I assume the last whitespace there is spurious - it was a line break
in the original.)  Definitely newer than 4.0.1, then - its /usr/xsrc
has no external/ subdir at all.

>> 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.
> 'bus enumeration' as in 'looking through /dev/fb*'.

Bus enumeration as in walking the SBus looking for framebuffers, which
I saw code for in at least one version of XFree86-for-Suns.  If it's
not doing that, good - but in that case why is it mode 4711 root?  A
non-setuid X11R6.4 Xsun works just fine; what does /usr/X11R6/Xsun need
to be setuid for?

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