Subject: Re: Getting X on Linux/SGI

From: "John Chen" <[email-masked]>
Date: Wed, 18 Jun 1997 12:41:23 -0700

On Jun 18,  9:41am, Ken Klingman wrote:
> Subject: Getting X on Linux/SGI
> John,
>
> There's an effort going to port Linux to SGI systems.  They've
> got the basic kernel up on an Indy, but are now trying to figure
> out what to do with X.  Could you reply to the mail alias (linux@engr)
> with a few words on the effort involved and what kind of specs they
> need?  I know that our X server architecture is complicated by the
> support of OpenGL, but wouldn't it be a lot simpler to just do X
> without any OpenGL support?
>
> ...
>
> Ken
>
> ...
>
> Forwarded message:
> > Larry McVoy wrote:
> > >
> > > : There are some very serious issues which come up even getting
> > > : Xfree to a moderate level of acceleration.
> > >
> > > How about to a simple level of working?  Without any acceleration?
> > > For most people, just having xterms and netscape working is enough.
> > >
> > > I'm not a graphics or X person.  Could someone who knows SGI's gfx
> > > devices tell us how hard it would be to make the basics work?

The fastest path to make basic X works is probably by implementing
a device dependent layer (DDX) that controls all pixels going in/out
framebuffer, opens and closes devices like keyboard and mouse,
interpret input events and control graphic display backend.
Since frame buffer on Indy system is not directly accessible.
all pixels in/out frame buffer has to be via this DDX layer.
A lot of sample code under cfb directory should be
reuseable with minor changes. To begin with non-accelerated
rendering, only setpixel and getpixel are required.

A generic DDX layer which described in "The X Window System Server" book
(authors: Elias Israel and Erik Fortune) can be FTP from export.lcs.mit.edu

I think you also need following stuff for Indy system with Newport graphic:

1) Newport graphics spec.
2) A basic graphic driver that map RE chip to Xsgi's address
   space, so X can program RE registers
3) This graphic driver also needs to set up graphic backend display
   id table and display mode registers (if X support only one visual,
   this step is simple), to program Cmap for cursor color
   and to program cursor registers for glyph and location.
   All of these work can also be done in X if driver map backend to X.

> > >
> >
> > ...
> >
> >  Questions:
> >
> > - How much HW dependent stuff is in Xsgi itself?

Xsgi contains something specific to IRIX, e.g. share memory input
queue stuff which may not be wanted by Linux.

> > - Which of the DSOs in /usr/lib/X11/dyDDX are minimally
> >   needed to bring up an non-GLX Xserver?

All DSOs in dyDDX support GLX. If the system is Indy,
rex3.so is used for Newport graphic and exp.so is used for
EXPRESS graphic. By trimming down Xsgi and DSO's, you should be able
to run Xsgi on Linux without GLX.

-John

> > - How much efforts would it cost to compile the dyDDX
> >   stuff for Linux and distribute the binaries only
> >   (assuming that there is not to much HW stuff in Xsgi itself)?
> >
> >
> >  And of course, we probably have to provide the microcode and
> > loader for the different GFX cards.
> >
> >  I definitely agree with Ariel, that this is the most important
> > topic once we have Linux running stable.
> >
> > Martin
> >
>-- End of excerpt from Ken Klingman

---

From: "David S. Miller" <[email-masked]>
Date: Wed, 18 Jun 1997 15:56:11 -0400

From: "John Chen" <[email-masked]>
   Date: Wed, 18 Jun 1997 12:41:23 -0700

I have this.

15 minutes of coding...

I can do this since I have #1, in fact I might be setting up the
backend display for one visual already in the text console driver I
wrote.  The way to manipulate the cursor and cmap is pretty much
documented in my text console driver as well, but I think some of the
actual cursor code is just pound define'd out but it is/was there.
(worse case you have to sift through the CVS history for the driver
and check out a version right before I snipped the code out if I in
fact did remove it at some point)

As for the input queue stuff, this has already been implemented on the
Sparc port because we were using SunOS Xsun binaries long ago, the
stock X11R6 sources use this mechanism anyways in the Sun frame buffer
support code, and their interface is very similar to IRIX's I think
(they call it VUID events).

---

From: Alex deVries <[email-masked]>
Date: Wed, 18 Jun 1997 16:15:50 -0400 (EDT)

>    1) Newport graphics spec.

Q: is the newport graphics spec available outside of SGI?  If so, is there
any way for me to get my hands on a copy of it, either electronically or
physically?

- Alex

---

From: Alex deVries <[email-masked]>
Date: Wed, 18 Jun 1997 17:34:14 -0400 (EDT)

I've had a few bits of email from people asking me about SGI-Linux.  I'm
thinking as we start to get things off the ground that it would be a good
idea to publish something at www.linux.sgi.com. As this will reflect on
SGI, does anyone want to write anything there?

Also, have the folks at SGI considered a press release announcing that
SGI-Linux is being officially sponsored by SGI? This would be _very_
impressive news to the Linux community, I think.  Certainly mklinux gave
me a much better view of Apple.

I'm thinking it would be a good idea to start writing some documentation
on where we're at, how to get started, what equipment it runs on, etc. I'd
be happy to start writing an SGI-Linux FAQ and/or HOWTO, if there are no
objections. I'm well aware that I don't speak on behalf of SGI, so if
there's someone over there who'd prefer to write it, I understand. 

- Alex

      Alex deVries           "Alex can cut a mean rug."
  System Administrator       - M. Dittberner <[email-masked]>
   The EngSoc Project

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 19 Jun 1997 13:01:24 -0700

> any way for me to get my hands on a copy of it, either electronically or

     With the approval of Tom Furlong (then the SGI VP/GM in charge of Indy),
I provided the specification to the Linux-on-SGI project (in the person
of David Miller :-) ).  It is only available in paper, and David may be
the quickest source for it.  (I am now in a different division, far from
the home of the paper documents.)