--Signature_Sat__4_Jun_2005_07_44_15_-0400_oOeCSmRHocozS.SB
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

> > Interesting. This needs further analysis- others reported garbled
> > text in xterms, misplaced window borders and all kinds of other
> > blitter weirdness.

> Maybe a different minor hardware revision?=20

I guess so, I'll definitely check that as soon as I can figure out
what's wrong with sunffb.

> From the Old Days when a ATI MACH64 PCI was very hot stuff I know that
> ATI likes to subtly change the hardware without showing it to the
> outside.

Yeah, and they like to throw out gazillions of different revisions and
variants that may need extra voodoo...

> Maybe a firmware difference?

Possible. Hmm, I noticed that in your XFree86.log the Xserver claims it
successfully mapped the graphics controller's ROM ( not that it would
help much since there's certainly no PC BIOS inside ) but I seem to
remember this failed for others. I'm pretty sure ATI put some
information about the graphics chip and how to set it up into a table
in ROM - maybe this thing is still present.
On 2nd thought I'm not even sure the Ultra uses the chip's ROM at all,
if the driver is in the main firmware image then the ROM may contain
literally anything, even a PC BIOS, or it may not be present.

> > But be careful with ffb yet - for simple stuff like a bunch of
> > xterms, sylpheed and so on it's certainly usable, but both Konqueror
> > and mozilla seem to issue commands that mess up something in the
> > sunffb driver which sooner or later crashes the Xserver.

> OK. So I can't put the U1e-Creator into service that soon. ;-)

Well, xfce4, a bunch of xterms, sylpheed and gaim worked pretty well for
me, only mozilla and and konqueror crashed it so far.

> > ( well, there's an Indogo2 R10K sitting here too, but I'm afraid
> > docs for the IMPACT series of graphics boards are next to impossible
> > to get, even then we won't have 3d any time soon.
> Someone at the LinuxTag fair toled me there was success in getting
> grafics out of an IMPACT. The IMPACT is one (or two on MaxI) R10k CPU
> as geometry engine.

I guess I'll have a look at mine ( a simple Solid IMPACT ) ;)

>  You have to give firmware (stolen from IRIX) to it and then it is
> feed with OpenGL. It does "OpenGL in hardware". "All" you  need is a
> Xserver that translates everything into OpenGL and sends it to the
> GFX.

We already have to steal the firmware for afb/Elite3D graphics boards.
So we talk to the IMPACT through a firmware interface. Interesting.

> > The little Indys with their
> > non-3d graphics hardware would be a more sensible target since you
> > wouldn't lose important functionality when abandoning IRIX ) ;)
> I asume the same for the O2. AFAIK it has no 3D hardware capabilities
> at all and the grafics is similar to the intel based Visual Workstatin
> 320

All I 'know' about the O2's graphics is that it uses main memory ( as
much as it wants ) so it can handle very large images in real time. I'd
be pretty sure it still has some z-buffer, blitter and all that, just no
dedicated geometry processor.

 .
> This stuff is supported by Linux, so there may be enough information
> to get the O2 GFX supported with basic 2D functionality.

True.

> That is all I need. (And a 1600SW LCD. ;-) )

Or an Apple Cinema ;)

have fun
Michael

--Signature_Sat__4_Jun_2005_07_44_15_-0400_oOeCSmRHocozS.SB
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQqGUD8pnzkX8Yg2nAQIqQwf/RLZuetaaAIMTEU4DQG5/MgLsB+SeqmHj
Crs/3izp+BZ437ibdUqKjgEctGQP7GpZsEeOBWy5BskpHgJ5lNgrb7RF6sme/0wQ
ziNyDKw83eVkTITW1GB+sGWJ1U7Vi8xk1+G73WbheJAgVKWGJq8J7RUktbxt0jry
+vMkRm+HbItdBaf6cgn+fSg1z4FQeTKh6mpIhezNJdi+FKbjmNabnpyYiFBoi5tM
yEKIJWkNS3fb/XvLWtFVAF2dOJgE4Y8V8Fgogbx/blJaAKRp2y7py/XQT8Rd3Nil
sZXuffflDUkVLkCGfRshWzfcgG/1+QYJ9Hp/zySfhNxc8MqgzBMOuQ==
=zL22
-----END PGP SIGNATURE-----

--Signature_Sat__4_Jun_2005_07_44_15_-0400_oOeCSmRHocozS.SB--