Re: p9100 bug?

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

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

Hello,

On Mar 8, 2010, at 8:40 PM, der Mouse wrote:

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

<nitpick>something that doesn't have a cursor sprite can't have a  
maximum cursor sprite size</nitpick>
:p

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

Oh, that's what you mean. I forgot you can do that on the P9100 -  
other DACs always use a 64x64 bitmap and if you want a smaller cursor  
you just leave the rest of the sprite blank.

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

And I'd have to change every single driver to use it.

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

... which is, and always has been, doing that by going through the / 
dev/fb*s
We don't even have a userland interface to walk SBus(es).

> If it's not doing that, good - but in that case why is it mode 4711  
> root?

For PCI crap that needed it until some time ago.

> A non-setuid X11R6.4 Xsun works just fine; what does /usr/X11R6/Xsun  
> need
> to be setuid for?

It doesn't, and neither does XFree86 or Xorg if you use only SBus  
graphics hardware.

have fun
Michael

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

iQEVAwUBS5WpBspnzkX8Yg2nAQLqQQgApB+jf4a9ZzP8Rzi2gOJEAVwY2QG8ETsh
1lxOxJmlecrqcQ2R+F2g3oQbVN5WW2BSsbHVxApetdd5/eDp0ZAdvxc1OQwlva2c
4S+nh5Ugn99uAPXLlhaTkelQRQqj9H/rSJf08//n3/ZijStjiJtHLPTIke6FiPWh
/6qlRmF98sz8IgsniX2O4RJOlIJYST9pq6cMbcqu0UOw+VRCm5OGPBuNjWTcwgSY
uQ6/SwxtAKpyiceHoXN2YvM5PBPDodNkR8W6yLmBpi25zhWEqC6po1XbwjEghydt
hC3GE8dkCzDP+2q9t3AR0eE48W/TJFga3Oj8gZXAvl26M5C0+wO67w==
=sAky
-----END PGP SIGNATURE-----