On Jun 17, 10:53am, richard offer wrote:
> * $ from email@example.com at "17-Jun:12:10pm" | sed "1,$s/^/* /"
> * 4. Would it be possible for a free software company to redistribute
> * the SGI's X server? In that case, we could concentrate on getting
> * the IRIX emulation as good as possible and just use the SGI X
> * server and let Red Hat/Debian/GNU ship the cd with that binary.
> This would be my preferred solution, but I've had many an argument on this
> subject that I felt very dubious about bringing it up again.
> To me the quickest (and the best) way of getting an X server would be if we
> could simply port the existing Irix X server to Linux/SGI. My suggestion
> be, now that we have backing for hardware to get official backing for
> I don't think we should neccesarrily release the source code for the ddx part
> of the X server to the public, but we should at least be able to get backing
> release .o files so the user could re-link the X server if they needed to
> have done this before).
While this appears to be an ideal solution on the surface, it has some obvious
and immediate problems as well. Namely, the complete lack of the driver
infrastructure to support the device-dependant layer of the Xsgi server.
Given that it's unlikely we'd release the source code to our gfx drivers, there
is no easily viable way to produce the drivers in the linux kernel image.
Lacking the drivers, Xsgi would need some _major_ redesigns, which brings us
back to Xfree-porting-level efforts needing to be expended.
There are some very serious issues which come up even getting Xfree to a
moderate level of acceleration. By the time you've got all the pieces in
place, you are probably looking at the same device-independant ->
device-dependant -> gfx-device layering that Xsgi has in place. OpenGL adds an
order of magnitude of complexity to the issue.
I realize this comes off as fairly negative, but I'm just trying to explain the
issues involved once gfx gets added to the mix. There would need to be a
buy-in at a very high level of SGI mgmt. before we could start making the
hardware details of our graphics subsystems available (at least the more modern
ones, such as O2, Impact, etc.).
John Wiederhirn (DSD, Graphics Kernel MTS) firstname.lastname@example.org
"Smithers, unleash the human insight and creativity."