Re: Got an R5k Indy

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

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


Hello,

On Feb 9, 2009, at 3:26 PM, Stephen M. Rumble wrote:
> On Feb 9, 2009, at 11:55 AM, Michael wrote:
>
> > ( shipping was more expensive than the Indy itself )
>
> And the Indy is one of, if not the lightest!

It's certainly the lightest one I have ( the others are an O2 and an  
R10k Indigo2 )

> > Questions so far:
> > - - I noticed that either the last character isn't drawn or the  
> > cursor isn't updated in time. Is it just me or do others see this  
> > too? Might be just a missing wbflush() somewhere in the newport  
> > driver. Or, if characters are drawn directly into the framebuffer  
> > we probably need to map it uncached.
>
> I think you're seeing a known issue with the cursor positioning.  
> Some revisions apparently need a workaround to get the correct  
> location, but nobody really knows which. C.f.:
>    http://mail-index.netbsd.org/port-sgimips/2004/12/26/0002.html

XFree86's newport driver uses a slightly different logic to determine  
the cursor offset.
For the record - mine is:
- - board revision 1
- - cmap revision 5
- - xmap revision 5
- - vc2 revision 0
and the appropriate offset is 29

> > - - do we have any real documentation on newport? The next thing  
> > I'd do is to port the X driver over to Xorg.
>
> Check out the following:
>    http://www.linux-mips.org/wiki/IP22#Hardware_Documentation
> I'm not sure if it's 'real', but the Indy is probably the best  
> documented SGI machine.

That's better than I expected and it should allow us to accelerate at  
least the more common Xrender operations, at least on 24bit newports.  
On the other hand, the X driver doesn't support any acceleration  
whatsoever right now, I'll get there when I'm done with the kernel  
driver.
More things I noticed:
- - scrolling downwards doesn't work - the blitter's direction is set  
the wrong way so it just duplicates the same line over and over again
- - we should use fastfills for rasops erase* ops - we need no ROPs,  
clipping or anything, just plain fills
- - no virtual consoles
- - on 24bit newports we copy 32 planes even if we only use 8 - not sure  
if that has any impact on anything yet
- - there's no support for fonts that are not 8 pixels wide although  
newport could easily do at least 32 pixels which should be enough for  
what we need
I think I have enough documentation to fix all that.

have fun
Michael

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

iQEVAwUBSZDTlMpnzkX8Yg2nAQLRkwf/V05c6PCsdd69LcefKrQaEPMtiX/xdIYM
sI0khf/Fvnxdnsa1w9jbkANA9YEUX4gnf9pRcWTJlrPINDvUjTaBgp0nU0OYhZed
u+SqSTlZH6EOa5wb7ZPWzhD0rn5YFeqE541nQiatN+Xlnge66wkhqmIVBS7xuhpb
mg1bD51gbQsiweB1uykt1QntFdWe2T3xLRCFLEIRp+9Jp1cNfySipbuln92eC17A
ABQdwdzOl2xBhC3ISDfnFPcvoDbmZR+sqelLf0Lx6dpvYXs2OMlQRKagPx1BjbcV
PuH0aRIAgf1Nij6c6XqIgVEfMdy+b2Jmv8ISPOeMI7YsccuaTX+UTg==
=+APq
-----END PGP SIGNATURE-----