keyes@sierra.ACA.MCC.COM (Debbie Keyes) (05/09/91)
In article <2604@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 is all the information that I have. If there is enough interest, I will post any other information that I receive (it seems that there are several other people who need to use X11R4 on their DEC5000 systems). Debbie DISCLAIMER: These opinions may not be the same as those of my employers. ========================================================================= Debbie Keyes keyes@mcc.com MCC (512)338-3440 3500 W. Balcones Center Drive Austin, TX 78759 USA =========================================================================
jg@crl.dec.com (Jim Gettys) (05/09/91)
In article <2692@sierra.ACA.MCC.COM> keyes@sierra.ACA.MCC.COM (Debbie Keyes) writes: >In article <2604@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@crl.dec.com -- Digital Equipment Corporation Cambridge Research Laboratory
schoch@sheba.arc.nasa.gov (Steve Schoch) (05/10/91)
In article <1991May8.235652.2246@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes: |> 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. There are a couple of other, more obscure reasons: 1) The R4 server handles new connections differently. Try this on your workstation: telnet <your workstation> 6000 If you are running R4, you telnet will connect and your server will go about its business of dealing with other clients. If your are running R3 (e.g. DECwindows) your server will freeze for about 60 seconds. The reason for this can be seen by looking in the routine EstablishNewConnections in server/os/4.2bsd and comparing R3 against R4. The scary thing is that anyone on the network can freeze your server this way whether they are authorized to connect to your display or not. 2) The R4 server has a way of giving access to your server on a per- client basis in addition to the per-machine method of R3. If you do all of your work on your workstation you probably don't care about this, but if you run clients from a "public" machine it is nice that other users on that machine can't do nasty things to your display (e.g. "bounce"). I am anxiously waiting for DEC to release a DECwindows that does these things. Steve
jg@crl.dec.com (Jim Gettys) (05/10/91)
In article <1991May9.192546.18589@news.arc.nasa.gov> schoch@trident.arc.nasa.gov (Steve Schoch) writes: >In article <1991May8.235652.2246@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes: >|> 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. > >There are a couple of other, more obscure reasons: > >1) The R4 server handles new connections differently. Try this on your >workstation: telnet <your workstation> 6000 >If you are running R4, you telnet will connect and your server will go >about its business of dealing with other clients. If your are running >R3 (e.g. DECwindows) your server will freeze for about 60 seconds. The >reason for this can be seen by looking in the routine EstablishNewConnections >in server/os/4.2bsd and comparing R3 against R4. The scary thing is that >anyone on the network can freeze your server this way whether they are >authorized to connect to your display or not. > >2) The R4 server has a way of giving access to your server on a per- >client basis in addition to the per-machine method of R3. If you do >all of your work on your workstation you probably don't care about this, >but if you run clients from a "public" machine it is nice that other >users on that machine can't do nasty things to your display (e.g. "bounce"). > Yup. You are correct; if we want to get more obscure, I can do so. How obscure do you want me to be? I bet I can out trivialize all but 3-4 people in the world on X trivia :-). I just mentioned the two biggest reasons, one of which is less of a reason on our systems than on most other vendors. I didn't mean to imply there aren't lots of other minor reasons... As my mail said, UWS 4.2 is about to appear in customer's hands, and it uses R4 servers for most hardware. Folks are working hard to make it ALL the hardware. - Jim -- Digital Equipment Corporation Cambridge Research Laboratory
rsk@gynko.circ.upenn.edu (Rich Kulawiec) (05/13/91)
>In article <1991May8.235652.2246@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes: > The biggest reason for vendors to convert to R4 servers are two things: > 1) better memory utilization > 2) higher performance, particularly for windowing operations. I was under the (possibly mistaken) impression that correct handling of ICCCM for R4 clients necessitates using an R4 server -- at least, the problems I seem to be having with things like drag-and-drop seem to be related to mishandling of ICCCM. (I'm running DEC's R3 server on a DS5000/PXG with MIT X11R4 clients and XView 2.0-built applications.) ---Rsk -- ---Rsk rsk@gynko.circ.upenn.edu, rsk@ecn.purdue.edu, pur-ee!rsk
lutmann@geocub.UUCP (Patrice LUTMANN) (05/21/91)
In article <1991May8.235652.2246@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes: > The biggest reason for vendors to convert to R4 servers are two things: > 1) better memory utilization * JOKE * > 2) higher performance, particularly for windowing operations. * RE-JOKE * 3) more bugs