NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/windows/x/19304

Internet Message Format | 1992-11-18 | 11.3 KB

Path: sparky!uunet!destroyer!ncar!noao!arizona!azhao
From: [e-mail] (Qiang Alex Zhao)
Newsgroups: comp.windows.x
Subject: Re: X11R5  Hi-Res mono patch?
Message-ID: <[e-mail]>
Date: 18 Nov 92 22:16:10 GMT
References: <[e-mail]>
Sender: [e-mail]
Followup-To: comp.windows.x
Organization: Computer Science Dept, Univ of Arizona, Tucson
Lines: 242

In article <[e-mail]>, [e-mail] (James Moody) writes:
|> I understand that a similar problem exits with the 24-bit sun displays, too.
|> ...

Maybe you can take a look at the "multi-screen" X server?

........................................................................
Advantages:

  o Correct multi-screen support.

  o Might also get to use 24-bit frame buffers, but NOT in 24-bit mode.
    I.e. we may be able to use our new color monitor in 24-bit mode,
    which means more colors...

  o Built in support for *all* Sun keyboards including NumLock, CapsLock,
    and Compose keys.  Credit to Martin Forssen for actually doing the
    work.

  o Fixed a bug that caused a spurious abort when running via xdm.

  o Recognition of frame buffer emulation modes.  (from the author:
    "You still have to set the driver/frame buffer into emulation
    mode. I may 'fix' this someday, but real work keeps getting into
    the way, and I don't have a cgeight, cgnine, or a cgtwelve to test
    with anyway.")

The README follows:
........................................................................
The 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 ([e-mail]).  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.

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.


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.  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.

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 ([e-mail]) for pointing
    out that I broke the support for high resolution monochrome
    monitors -- it's fixed now.

    Thanks to Jordan Hayes ([e-mail]) for pushing me to
    include (and indirectly to rewrite) constype and kbd_mode.

    Thanks to Andrew McRae ([e-mail]) for finding
    a bug when used with Sun's SunOS GX patch -- it's fixed now.

    Thanks to Martin Forssen ([e-mail]) and Ian Daniel
    ([e-mail]) 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.  I have been running
    this code since shortly after the public release of R5.  This code is
    also 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:

[e-mail]

--
= Qiang Alex Zhao                 ___       .             ______
  Computer Science Dept          /   )     /|   )          __//  )
  University of Arizona         /   /     /_|  / _        //    /_  _. ._
  [e-mail]         (__)(_o   /  (_(_(-'_)(   ((____/ (_(_(_(_)