FOLLLOWUP TO: X11R4 on DEC 5000 Ultrix 4.x

[Jim Gettys]

In article <2692 at sierra.ACA.MCC.COM> keyes at sierra.ACA.MCC.COM (Debbie Keyes) writes:
>In article <2604 at sierra.ACA.MCC.COM>, I wrote:
>> Apparently the DEC 5000 systems (running Ultrix 4.x) need a different
>> X server than the 3100 systems (the 3100s use Xcfbpmax & Xmfbpmax).
>> I have searched all the locations that I can think of for the
>> patches, sources or any references to this server, but have had no luck.
>> 
>
>So far I have determined that the DEC5000/200CX systems use the same
>server as the DEC3100 systems, but the DEC5000/200PX and DEC5000/200PXG
>systems use a different server (supplied with DECwindows as Xtm, but
>as an X11R3 version).  The X11R4 version of this server is not yet available.
>
>Until an X11R4 server is available, the only option (besides running
>DECwindows) is to use the R3 server (Xtm) and run X11R4 clients/window
>managers.  Clearly, this is a kludge and all clients/window managers
>will not work properly.
>

This seems to be a constant source of confusion...  There are NO protocol
changes between R3 and R4.  R4 clients should run fine with R3 servers.
As far as that goes, there weren't any in previous releases, though the
font naming convention caused lots of interoperability headaches early on.
I know people who run R4 clients against R1 servers!  If R4 clients
don't work against our servers, there is a bug, independent of what
the code base.

Having said this, I will also note there are some (quite obscure) bugs
in un-bug-fixed R3 servers; the ones I've been aware of should all be fixed
by now in current Ultrix releases.  R4 servers also have a "bug compatibility"
switch, to allow buggy R3 clients to run against R4 servers (some things
the server was supposed to detect and complain about were not complained
about in R3 and before).

The biggest reason for vendors to convert to R4 servers are two things:
1) better memory utilization
2) higher performance, particularly for windowing operations.
Many/most of 2) were implemented by Digital, and the results given to
MIT for R4, so it has been less pressing for us to convert than most
manufacturers.

On to the next subject: people have asked what the code base of servers
in UWS 4.2 (about to ship).  My understanding is that all servers are R4 based
except the Pixelstamp graphics on the DS5000 (PX, PXG, PXGTurbo).  The
conversion work didn't quite get finished in time for 4.2; you'll see it
soon.  R4 to R5 is much easier than R3 to R4 (much of the performance and
memory savings are achieved by interface changes in the server), so the
next time around, we shouldn't have this long a lag (and R4 came out 
a month or two too late to be used for the initial DS5000 release a year
ago.  It was exactly the wrong time for us.  Sigh...).

Part of what has been going on has been a complete rewrite of the
DECstation display drivers, to support multi-screen; UWS 4.2 supports
MX and CX multi-screen systems.  A single server runs on both monochrome
and color DS2100's and DS3100's, and DS5000 CX and MX's.  This saves
disk space and simplify system administration.  In fact, the server will
be happy to run on anyone's 1 or 8 bit frame buffer it finds, if you
are inclined to build a TURBOchannel display.  You can expect the
trend to continue as the rest of the displays are converted.

The new device driver has a different interface (no surprise), so if you
currently run an MIT server and want to continue on 4.2, you'll have to
do some work.  (Of course, if you are just to run R4, our server is
then R4; but researchers have good reasons to run what they have code to).
I gave MIT the new O/S interface routines a month or so ago; so they 
will appear in R5.  I plan to package them up and post them to comp.sources.x
in another week or two.

			Jim Gettys
			Digital Equipment Corporation
			Cambridge Research Lab
			Cambridge, MA
			jg at crl.dec.com




-- 
Digital Equipment Corporation
Cambridge Research Laboratory