Re: p9100 bug?

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

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

Hello,

On Mar 8, 2010, at 5:42 PM, der Mouse wrote:

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

It's always 2MB, IIRC the chip doesn't support more than that anyway.

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

fb would be the place. Something like line size must be a multiple of  
32 or something - I don't think any graphics hardware you can stick  
into a Sun has a maximum sprite size of less than 32x32.

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

How would that make any sort of difference? The bits in question would  
be zeroed out either way.

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

Umm, no.

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

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.

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

I forgot when the switch happened, Xorg's sources live in xsrc/ 
external/mit

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

'bus enumeration' as in 'looking through /dev/fb*'.

have fun
Michael

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

iQEVAwUBS5WMYcpnzkX8Yg2nAQIx9wgAr9qlMov6t8hH+5mnfB9/23XARnajiY1C
896qKvwSNJn29jOb70AXRa/91OuLHU0I4dVM+ivkPTY65zjZ4BmhoxOFd1e+hwPj
p0lPpI/SDSoRC8rS/DoHlT+9cDvRrK0yqng4GryiA4qSXQ/AbaJKkqMWzvc+Abtj
adKF7bKDGF6Qj2KIJ9d/y927i2CUB3rEfZCw45a+kTTI9UPaB6U0kYzA0utlxut9
xlDxBT7fJ+oKc2HhQa1T1Q6e5zjhcbWMCvvjdBGr9eu5s/rriL1Yx2NgR4+zxRGD
vuaRBa+c4od+pTSFVVD2eASha9TRA4iM04D1+FIJXeq24uWahtVTxQ==
=F7PX
-----END PGP SIGNATURE-----