🚀 go-pugleaf

I have placed a new version of R5.Xsun.multi-screen.tar.Z on export,
in /contrib.

This new version incorporates the enhanced keyboard support, including 
type-5 keyboards, done by Marten Forssen.  The following is the README:

=======================================================================

The JPL R5 Xsun Multi-screen server is a general purpose replacement
for the MIT server/ddx/sun layer.  

This release *includes* the enhanced keyboard support written by Martin
Forssen (maf@dtek.chalmers.se).  It is *already* built in.  It is not 
necessary to apply the patch.  FYI, the original patch to the MIT sample 
server is available separately from export.lcs.mit.edu (18.24.0.12), as 
/contrib/sunkbd.tar.Z.

(Impatient?  Want to build now!  Build instructions are at the end of
this file.)

It was written to fulfill the following requirements:

First, (and foremost) to support up to three of the same type of
frame buffers on VME and S-Bus architectures.

JPL, and others, are discovering more and more, that a single screen
does not provide sufficient "real estate" for the activities of our
users.  In JPL's case, these users in question are our Mission Control
personnel who monitor the status of various robotic spacecraft.  One
might argue that various "virtual" desktops, such as those provided
by Solbourne's swm, or Tom LaStrange's tvtwm, or more generic solutions
such as "Rooms" might suffice.  Unfortunately, our users need many
"real-time" displays up, and it is virtually always not acceptable to
hide them "off screen".


Second, to simplify the interface to the frame buffers.

Perhaps it goes without saying, but the current implementation, as
distributed by MIT, is a real jumble.  Or, if I may use Keith Packard's
own term, crufty.  Adding support for new devices is less than easy.
The code was not, IMHO clear or easy to follow, and there was a lot
of redundant code spread across the various sunCG?C.c and sunBW2.c
files, particularly in regard to mmap()'ing the frame buffer memory.
There was also a lot of apparent disagreement about just how the
frame buffer memory should be mmap()'ed.  It is still not clear to me
that it is neccessarily correct, if it is wrong now, it is uniformly
wrong :-) I believe that it should also, at this point, be much easier 
to add new devices to the JPL code.


Third, to eliminate the SunView support.

The King is dead.  Long live the King.  The X Window system has been
with us long enough that most applications now have an X Window counterpart.
If you're using all available frame buffers for X, it's probably unlikely
that you're using SunView anyway.  If you need the SunView support,
use the MIT incarnation of Xsun.  Is it just me, or does it not make
sense to run Xsun on top of Sun's xnews?

=============================================================================

Things to know and miscellaneous notes:

In addition to adding multi-screen, you might also get to use your 
24-bit frame buffers, but NOT in 24-bit mode.  Generally, the device
drivers support emulation of lesser devices, e.g. I know that the cgsix
(GX) device driver will report that it emulates a cgfour, cgthree, and 
a bwtwo.  But, with the GX supported, it should never be necessary to
resort to emulation mode.  If the device you specify, either via XDEVICE, 
-dev, or by the fallback to /dev/fb reports that it'll do cgthree emulation, 
the server will try to treat the frame buffer as such.

XDEVICE environment variable.  Xsun will look here first to get the
    device(s) to try; examples:  

    'setenv XDEVICE /dev/cgtwo0:/dev/cgtwo1' 
    'setenv XDEVICE /dev/cgeight0'
    'setenv XDEVICE /dev/cgthree0:/dev/cgsix0'
    'setenv XDEVICE /dev/cgsix0:/dev/cgthree0'

-dev command line argument.  Xsun will look here second, and override
    XDEVICE specified devices, to get the device(s) to try; examples:

    'Xsun -dev /dev/cgtwo0:/dev/cgtwo1'
    'Xsun -dev /dev/cgeight0'
    'Xsun -dev /dev/cgthree0:/dev/cgsix0'
    'Xsun -dev /dev/cgsix0:/dev/cgthree0'

fallback list.  If neither of the two methods listed above are employed,
    Xsun will resort to a fallback list of devices to try.  The list is:

    /dev/cgtwo0, /dev/cgtwo1, /dev/cgtwo2, /dev/cgthree0, /dev/cgthree1,
    /dev/cgthree2, /dev/cgsix0, /dev/cgsix1, /dev/cgsix2, /dev/cgfour0,
    /dev/bwtwo0, /dev/bwtwo1.


cgfour note:
    Some Suns are equipped with a mono frame buffer on the mother board.
    All cgfours have an implicit mono frame buffer.  /dev/bwtwo0, I believe 
    will find the mother board frame buffer rather than the cgfour mono 
    plane.  In the absence of a real bwtwo, /dev/bwtwo0 will find the
    cgfour mono plane.

    If you experience strange behaviour, i.e. you have a cgfour and the 
    cursor appears to go off the side of the screen, override the
    fallback list with either XDEVICE or -dev, e.g. 'Xsun -dev /dev/cgfour'

    Likely ways of having a bwtwo are: real bwtwo frame buffer in a
    slot, real bwtwo frame buffer on the mother board (3/60 only),
    or the cgfour emulates a bwtwo.  Real problems arise when you
    have both a cgfour and another bwtwo.  What happens is that the
    real bwtwo is assigned to /dev/bwtwo0, but this server expects
    /dev/bwtwo0 to be the mono plane of the cgfour, when there is
    one.  The consequences are, that dragging the pointer off the
    edge of the screen causes the cgfour code to enable the mono
    plane; that's okay when the /dev/bwtwo0 is using the cgfour
    mono plane, but not okay when it's some other bwtwo, especially
    if that other bwtwo isn't hooked up to a monitor.

    As there is no way to tell from software whether a given bwtwo
    is real or emulated, it poses real problems with trying to
    automagically set up the server to handle all the available
    hardware correctly.  Possible work arounds are:
      1) specify the device list with either -dev or XDEVICE.
      2) specify -zaphod
      3) ensure that /dev/bwtwo0 uses the cgfour:
         'cd /dev;mv bwtwo0 bwtwo1;MAKEDEV bwtwo0' is alleged to work.

cgeight/cgnine/cgtwelve note:
    Sun apparently has a program that will allow these devices to emulate
    other "supported" devices.  MIT's Xsun check the emulation mode in
    a sort of backward way, thus, a cgeight, emulating a cgfour would
    be rejected, and would terminate claiming that no screens were found.
    Needless to say, if a cgeight is found and is emulating a "supported"
    device, it will be used, in the JPL code.  Please note, that since I 
    don't have any of these devices, I haven't tested this feature.

xdm note:
    Running Xsun with xdm has a funny peculiar problem.  The keyboard
    driver will erroneously report an unknown keyboard type within
    750 milliseconds.  Normally this isn't a problem if you're running 
    via xinit.  xdm, on the other hand, can (and does) terminate and 
    re fork-and-exec the server fast enough to encounter this.  The poor 
    server, thinks it's got an unknown keyboard type, aborts and leaves 
    a spurious core file.  This timing problem was previously addressed 
    in some other keyboard code.  The JPL code has generalized the solution, 
    and fixed the abort/core dump at initialization.

Sun 386i note:
    The source contains conditional compilation for building on Sun's
    386 boxes, which eliminates support for devices that will never be
    found on a Sun 386, and therefore, a smaller binary than might
    otherwise be created.  Sun's 386 compiler has a severe bug and
    will not generate correct code for mi/miscrinit.c, and cfb/cfbteblt8.c
    You may overcome this flaw by compiling all the server code, or just 
    these two files with gcc.  I have used both gcc-1.39 and gcc-1.40 with 
    success.

Bug fixes to server/ddx/mi:
    There is a bug in ddx/mi with regard to tracking the pointer across
    multiple screens.  This apparently seems to only be a problem on
    machines where there is no hardware cursor support.  This is true
    of all the "supported" Sun frame buffers.  Three files are supplied
    to fix the bug.  These files came from MIT, and, although the need
    to make them "public fixes" might seem apparent to those of us using
    multiple screens, MIT doesn't feel that the fixes, or the bug that
    they fix are critical enough to warrant their inclusion into a public 
    fix.  I've been told not to expect them to be official in any respect 
    until R6.  If you disagree with this assessment, I encourage you to 
    let MIT know.  Perhaps if enough people ask nicely, they'll make them 
    official by distributing them in a public fix.

    If you don't want to install the three ddx/mi files, the multi-screen
    feature will still work; you'll get apt to get some strange cursor
    behavior, particularly if you warp the pointer from screen to screen.


New constype.
    The old constype was pretty nearly useless (apologies to the original 
    author) and initial versions of the R5.Xsun.multi-screen didn't include 
    it for that, and some other reasons.  The new constype probes for all 
    the devices that Xsun supports, and reports any that it finds.


Old kbd_mode.
    Is included for completeness.


Credits:
    Thanks to George Ross (gdmr@dcs.edinburgh.ac.uk) for pointing
    out that I broke the support for high resolution monochrome
    monitors -- it's fixed now.

    Thanks to Jordan Hayes (jordan@moorenet.com) for pushing me to
    include (and indirectly to rewrite) constype and kbd_mode.

    Thanks to Andrew McRae (andrew@megadata.mega.oz.au) for finding
    a bug when used with Sun's SunOS GX patch -- it's fixed now.

    Thanks to Martin Forssen (maf@dtek.chalmers.se) and Ian Daniel
    (daniel@europarc.xerox.com) for the enhanced keyboard support and
    encouraging me to put it in, respectively.


Followup thoughts:
    If you're concerned, (and rightfully so) that I might have broken
    something else, rest assured that: 1) I didn't change the way any of 
    the critical mouse/keyboard handling stuff works.  2)  I've been
    adding multi-screen support to Xsun since R3.  This (R5) code has 
    been running at JPL since shortly after the public release of R5.  
    This code is in wide use by numerous others, world-wide.


Installation instructions:
    'cd ../mit/server'
    'mv ddx/sun ddx/sun.orig'
    'mv ddx/mi/mieq.c ddx/mi/mieq.c.orig
    'mv ddx/mi/mipointer.c ddx/mi/mipointer.c.orig
    'mv ddx/mi/mipointrst.h ddx/mi/mipointrst.h.orig
    'mv ../include/Sunkeysym.h ../include/Sunkeysym.h.orig'
    'zcat R5.Xsun.multi-screen.tar | tar xvf -'
    'make'

If you have any questions or comments, please send them to:

kaleb@thyme.jpl.nasa.gov

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.