[comp.windows.x] GraphOn OptiMax 200 X terminal questions and answers

casey@lll-crg.llnl.gov (Casey Leedom) (11/11/89)

  Someone sent me a note asking about the use of the GraphOn OptiMax 200
from home over a high speed modem connection.  I thought that my answers
might be of sufficient interest that I should post them.  (Yes, I know.
That feeling is the reason we have network congestion.  Feel free to
flame me, but be aware that my mailbox is sometimes linked to /dev/null.
:-))

-----
| I've been researching Xterminals for use at home and was given your name
| as someone who knows quite a bit about the Graphon OptimaX 200.
| 
| I just wondered what your general impressions of the xterminals, ie:
| 
| 1.  What the performance is like over V.32 or PEP.

  It works well over V.32.  It works great over V.32/MNP5.

  Very funky over PEP.  The typical echo delay of PEP makes window moves
and resizes very difficult to control.  Once you're in a window typing,
it's about the same as just typing on a normal terminal over a PEP
connection.  In my opinion PEP was [and maybe still is] a good idea for
some applications, but it's much more pleasant to use V.32 (with or
without MNP5) for interactive work.

  The PEP echo delay doesn't bother me when I'm just typing something in,
but it's very disconcerting and slows me down whenever I'm doing
something that requires hand-eye feedback control.  (Eg. cursor movement
in a screen editor, window movement or resizing, etc.)  If you're going
to buy a modem mostly for interactive use and occasional file transfer
I'd go for one of the cheaper V.32/MNP5 modems that seem to be hitting
the market.  On the other hand, with the way the Telebit T2500s are
dropping in price (down to $950 last I looked) it's probably worth a
couple hundred more ...  Your choice.

| 2.  General quality of the unit, especially screen and keyboard.

  The screen is excellent.  Very crisp and easy on the eyes.  Good
non-glare coating.  Only deficit is that it's small - only 13 inches -
and you only get 600x800 pixels.  I'm hoping they offer a larger screen
size with more resolution as an option in the future.

  It's also black and white, but I count that as a feature.  The only
good color monitors I've seen cost a hell of a lot and the non-good ones
are worthless for text editing.  I'm much more in favor of them offering
a terminal emulator package for the Macintosh and PC/VGA than I am of
them offering too many different hardware platforms.

  The screen sits on a small (~ 13in x 14in x 1in) pedestal that contains
the brains of the unit.  The screen swivels and tilts very easily through
a large range of motion.

  The keyboard is very good.  Slightly flimsy touch, but nothing that
can't be coped with.  There's an extremely long keyboard cord which can
extend out of either the left or right sides of the keyboard.  The mouse
uses a separate cord which should please people who like to put the
keyboard on their lap.  On the other hand, since the keyboard is
essentially an extended DEC keyboard layout, it's really too wide
(~ 20in) to sit on your lap comfortably.

  The layout of the keyboard is very nice.  As I mentioned above it's
essentially an extended DEC arrangement except that "<" and ">" are in
their right places over the "," and ".".  Control, escape, rubout,
backspace, "`~" all in the right places.  The only two real deficits are
the existence of a capslock (placed between control and "a") and a meta
key which is really too small and placed immediately to the left of the
shift key instead of below the shift and next to the spacebar as it is on
the Sun type 3 keyboard.  The "\|" key is to the right of the return key,
but that's close enough to where I expect them not to be too much of a
problem.

  The mouse is probably the weakest part of the whole system.  It's
mechanical (using two small perpendicularly arranged .25in wheels) and
feels flimsy.  The three buttons also feel klunky.  However, I have yet
to have any problems with it ...

| 3.  How well does it run x tools like xterm, xclock, etc.  Will it run
|     X applications like Framemaker that need to be run on a remote host?

  I don't have Framemaker to run, but I have tried running other large
applications.  The applications themselves run easily since they run on
the same hosts they run on normally.  (See answer to 5 below.)

  I've had two main problems: The first is the small pixel map
(600x800).  Many interesting applications like xmh (and I presume
Framemaker) presume larger maps and they get a little squished looking on
the OptiMax 200.  But this can usually be lived with.

  Much more of a problem is the flow control situation on the OptiMax.
The terminal only supports in band XON/XOFF and out of band hardware
DTR/DSR flow control.  Flow control is very important since the terminal
isn't able to keep up with a V.32/MNP5 modem.  I've been told that they
are working on speeding up the terminal, but until then all we've got is
flow control to keep our data intact.

  XON/XOFF works well when you're directly connected to the computer
running the X server, but are worse than useless if you have any kind of
bandwidth-delay product to deal with or must have a ``clean''
communications channel.

  I suppose the out of band hardware DTR/DSR flow control solves that
problem, but you're either going to have to find a modem that can do
DTR/DSR flow control or rewire your cable to hook the terminal's DTR and
DSR to your modem's RTS and CTS, respectively.  Rewiring your cable
unfortunately leads to other problems since DTR will no longer be
available for modem control.  I'ver talked to GraphOn a number of times
about this and they say they're looking at it ...  [As I understand it,
they use DTR/DSR because early DEC and Tek machines used this form of
flow control.]

| 4.  Is the Graphon software easy to install... any need to modify the
|     kernel?  Is it necessary to reboot after installation?

  Essentially trivial once you ignore their installation instructions.
They give you a tape full of X11 binaries and never explain that you only
really need their server (Xgo) and a slightly modified version of xinit
(xgoinit) if you already have X11.  There are no kernel modifications.

  My only objection is that Xgo and xgoinit have paths compiled into them
which makes it slightly difficult to just install them any where you
want.  I went ahead and installed them in my X11 binary directory
(/usr/local/bin/X11) and gave myself an alias for xgoinit:

alias xgoinit	'xgoinit -- /usr/local/bin/X11/Xgo \
-co /usr/local/lib/X11/rgb \
-fp /usr/local/lib/X11/fonts/misc,/usr/local/lib/X11/fonts/75dpi'

[Note that the alias is a single line in my .cshrc since csh
won't let you break aliases across lines.]

  I've suggested that they break their distribution tape into two files:
the first which would contain Xgo and xgoinit, and the second which would
contain the rest of the X11 distribution.  Additionally, the first file
should contain Xgo.o, xgoinit.o and xpaths.c which would allow you to
edit xpaths.c to reflect you X11 installation paths and generate new
custom versions of Xgo and xgoinit simply via:

% cc -O -c xpaths.c
% cc -O -o Xgo Xgo.o xpaths.o
% cc -O -o xgoinit xgoinit.o xpaths.o

  A small note on the history of their software as I've been exposed to
it: the first version (1.0.2?) that came with the terminal was essentially
unusable.  I received new versions of Xgo and xgoinit that were much
better and definitely usable, but a bug in the Sun kernel caused Xgo to
crash the machine from time to time requiring that I drive into work to
reboot the machine.  The latest version of the software is great.  It's
very usable and doesn't crash the machine.  I've been using it for over
two weeks now with no real problems other than some pixel droppings that
GraphOn is going to send me new PROMs to deal with.

  One other problem with the software is that they currently support very
few platforms (you'll have to call them to find out what the current set
is).  They're working on others, but they're personnel limited.  My own
recommendation to them was that they simply give the software away to the
X consortium, but I'm a communist at heart ... :-) This also points out a
last problem: their light weight graphics protocol used between their X
server and their terminal is proprietary.

| 5.  How are display #'s handled.  Ie, if my machine is called moria
|     and I have display moria:0, what names do the GraphOn displays
|     have?  Do I need to assign internet addresses?

  It's actually a beautifully simple setup that I've been trying my
hardest to promote as THE way to implement an X terminal.  The X server
runs on one of your machines.  The display number is therefore the name
of your machine:N.  The latest software starts trying N at 1 and works
it's way up.  The server uses a light weight protocol to talk to a simple
graphics engine running in the terminal.

  Because of this setup there's no need to assign the terminal an
internet address.  You don't have the hassles of dealing with dynamic
network connections, routing, etc.  You don't have your limited
communications channel bandwidth tied up with the TCP/IP and X protocols.
The server doesn't have to worry about living in the small finite memory
of the terminal - it's got your host's virtual memory at it's disposal.
And finally, if they ever do implement a terminal emulator for the
Macintosh and PC/VGA, those low power CPUs won't be bogged down with
the TCP/IP and X protocols or manipulation of the X databases.

  And now onto the part I've been told I have to put onto all notes like
this:

	Copyright 1989, Leith (Casey) Leedom.  No part of this note may
	appear in whole or part without the entire text of this copyright
	notice and disclaimer:

	My opinions are not necessarily those of the University of
	California, Lawrence Livermore National Laboratory, The United
	States Department of Energy, or any part of the California or
	United States governments.  I speak for myself only.  My opinions
	do not represent any bias of Lawrence Livermore National
	Laboratory, the University of California, the United States
	Department of Energy, or the California or United States
	Governments.

  Sorry for the long winded nature of that, but if I want to be able to
contribute to the community by posting opinions or product reviews, I
have to let everyone else off the hook.

Casey

ekrell@hector.UUCP (Eduardo Krell) (11/12/89)

In article <38146@lll-winken.LLNL.GOV> casey@lll-crg.llnl.gov (Casey Leedom) writes:

>Only deficit is that it's small - only 13 inches -
>and you only get 600x800 pixels.  I'm hoping they offer a larger screen
>size with more resolution as an option in the future.

The GraphOn GO-235 (from which I'm typing this message) has the same
13" screen but a resolution of 1024 x 792.

>The display number is therefore the name
>of your machine:N.  The latest software starts trying N at 1 and works
>it's way up.

The latest version of the software starts with N == your uid, which
makes more sense.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell@ulysses.att.com

envbvs@epb2.lbl.gov (Brian V. Smith) (11/12/89)

< In article <38146@lll-winken.LLNL.GOV> casey@lll-crg.llnl.gov (Casey Leedom) writes:
 
About the Graphon Optima 200:
< Only deficit is that it's small - only 13 inches -
< and you only get 600x800 pixels.  I'm hoping they offer a larger screen
< size with more resolution as an option in the future.
 
In article <12382@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes:
< The GraphOn GO-235 (from which I'm typing this message) has the same
< 13" screen but a resolution of 1024 x 792.

So, how does one use Framemaker, which requires a screen at least 880 pixels
tall?  I realize that Frame Technology should probably make the program
more portable by having a flexible window size, but the fonts are fixed in
their size, so that would mean only showing part of the text page at once.
--
_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.

casey@gauss.llnl.gov (Casey Leedom) (11/12/89)

| From: ekrell@ulysses.att.com (Eduardo Krell)
| 
| The GraphOn GO-235 (from which I'm typing this message) has the same 13"
| screen but a resolution of 1024 x 792.

  Sounds a little hard to read, but I'm certainly glad GraphOn is
offering a larger pixel map display.  I wonder how hard it would be to
get a larger screen with that?

| > The display number is therefore the name of your machine:N.  The latest
| > software starts trying N at 1 and works it's way up.
| 
| The latest version of the software starts with N == your uid, which makes
| more sense.

  Nope.  I've got a later version (BETA) than you do.

  And it makes more sense to start at one and work your way up.  If your
uid is a large integer, then 6000 + uid could very well extend out of the
reserved TCP port space for X displays.  I can't find a reference to how
many ports are reserved - does anyone know?

  Even if there is no maximum (an unbelievable concept) using uids would
needlessly scatter server ports across a large chunk of the TCP port
space.  For instance, we use employee numbers here for uids in order to
guarantee unique uids across all of our NFS servers.  My uid happens to
be 5218.  Using that for my display number would mean the server would
use TCP port 11218.

  Finally, if you have a standard login account for use by multiple
logins, you'd get an immediate display number collision.

Casey

dsill@ark1.nswc.navy.mil (Dave Sill) (11/14/89)

In article <38226@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey
Leedom) writes:
>   And it makes more sense to start at one and work your way up.

But then how do you know what display number Joe Blow is using?  With
the current UID scheme, I know Joe's UID, and which machine his
pseudo-server's running on, e.g., UID=200, machine=foo, so
display=foo:200.

>   Finally, if you have a standard login account for use by multiple
> logins, you'd get an immediate display number collision.

Then you just revert to finding the next unused display number.

Dave Sill (dsill@relay.nswc.navy.mil)

ekrell@ulysses.homer.nj.att.com (Eduardo Krell[dgb]) (11/14/89)

In article <4208@helios.ee.lbl.gov>, envbvs@epb2.lbl.gov (Brian V. Smith) writes:

> So, how does one use Framemaker, which requires a screen at least 880 pixels
> tall?

Well, I just tried it and it works fine. The window scales to the terminal
resolution. "xwininfo" on that window says:

	 ...
         ==> Width: 652
         ==> Height: 810
	 ...

-- 
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

    {att,decvax,ucbvax}!ulysses!ekrell	Internet: ekrell@ulysses.att.com

casey@gauss.llnl.gov (Casey Leedom) (11/14/89)

| From: Dave Sill <dsill@relay.nswc.navy.mil>
| 
| But then how do you know what display number Joe Blow is using?  With the
| current UID scheme, I know Joe's UID, and which machine his
| pseudo-server's running on, e.g., UID=200, machine=foo, so
| display=foo:200.

  I have the following in my .xinitrc:

	RDISPLAY=`hostname`:`echo $DISPLAY | sed 's/unix://'`
	export RDISPLAY

I then use ``-display $RDISPLAY'' in my .uwmrc whenever I'm rsh'ing an X
command on a remote host.  As for someone else randomly instigating a
connection to your server ...  I'm not at all sure that's something we
want to encourage.  We've already got enough security problems in X as it
is.  I'd say that you want to do something like handing a remote process
a capability which both informs the remote process of how to address you
correctly and provides authorization to use the server.

| > If you have a standard login account for use by multiple
| > logins, you'd get an immediate display number collision.
| 
| Then you just revert to finding the next unused display number.

  Then we have the same problem you worried about in the first paragraph,
so we may as well just deal with the problem.

Casey

envbvs@epb2.lbl.gov (Brian V. Smith) (11/14/89)

< 
< 
< > So, how does one use Framemaker, which requires a screen at least
880 pixels
< > tall?
< 
< Well, I just tried it and it works fine. The window scales to the terminal
< 
< 	 ...
<          ==> Width: 652
<          ==> Height: 810
< 	 ...


You must have a newer version than we; on our Vaxstation II (1024x864),
the window is just larger than the screen:

xwininfo: 

         ==> Width: 652
         ==> Height: 870  <====

We have v 1.3.

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.