Article View: comp.windows.x
Article #25116Fix to allow Sun 3/110s to use the X windows system
From: cdh
Date: Fri, 13 Mar 1987 19:00
Date: Fri, 13 Mar 1987 19:00
148 lines
5893 bytes
5893 bytes
Hi all,
The following two modifications permit the X server to work on the Sun
3/110 color display as well as on the Sun 3/50 and 3/160 monochrome and
color displays. It should also work with the Sun 3/110 grey scale
monitor, but I have not verified that since we don't own one.
Sun 3/110 owners, rejoice and enjoy!
Carl
VERSIONS TO WHICH THIS APPLIES
* X release 10 version 3 (I'll try version 4 when I get a chance)
* Sun OS release 3.2 (you need 3.2 for the new ioctls for the 3/110)
THE PROBLEM
The reason the existing Sun library for X does not work on the Sun
3/110 is that the 3/110 frame buffer is not compatible with the frame
buffer used in 3/160 color displays. It differs in three specific
ways:
1) it has emulation modes of other frame buffers (monochrome
appears to be the only example,
2) it has two new ioctls, FBIOGATTR and FBSIOATTR, associated
with setting and reading the emulation modes and the real
attributes of the buffer,
2) it is a memory based frame buffer and does not have the
fancy rasterop hardware that the cg2 for the 3/160 does.
The strange thing about the 110 is that it *prefers* to run in
emulation mode; that's the mode it starts up in and that's the mode it
stays in unless you change it.
The other problem was that the cg4 board used in the 3/110 is the
first color board Sun has produced that uses mem_batchrop for doing
its batch raster operations. The bw2 monochrome also uses this
operation, and this caused the following problem:
The libsun library for X optimizes the mem_batchrop and cg2_batchrop
operations for higher speed than those provided by Sun (yay!). The
way that it does this is it defines new routines for mem_batchrop and
cg2_batchrop in text.c and lets the linker substitute these routines
into the dispatch tables contained in libpixrect.a for the specific
devices. The bad part is that the X-optimized mem_batchrop
only deals with monochrome frame buffers and the cg2_batchrop only
deals with color displays with rasterop hardware. The bug that
occurred in linking this in with the cg4 stuff is that the
mem_batchrop that only does monochrome got linked into the dispatch
table for the 3/110 color display.
THE SOLUTION
The solution is simple: upon display initialization, we get the
attributes of the display. If the display claims to be monochrome, we
try an FBIOGATTR ioctl to see if this might perchance be a 3/110
running in emulation mode (remember, it comes up in emulation mode!).
If it is, we turn off emulation, reget the frame buffer parameters and
go on our merry way.
I also renamed the X-optimized routine mem_batchrop to Xmem_batchop.
This prevents it from being put in the cg4 dispatch table and the bw2
dispatch table. Since it is no longer linked into the bw2 dispatch
table, we have to put it in there at run time. Therefore, if we
believe that we are a monochrome display AND the FBIOGATTR ioctl fails
(implying that we must be a garden-variety bw2 monochrome display),
then we patch the batchrop entry of the dispatch table for the bw2
display buffer to point to Xmem_batchrop and continue.
BUGS
This fix depends upon the cg4 being the only board that does
FBIOGATTRs. Clearly this will change next time that Sun brings out
yet another type of frame buffer. Maybe it will be retrofitted to the
old frame buffers in a later release. All I know is that it works
properly in Sun 3.2. I'm open to suggestions as to other ways to
determine what kind of display I'm running on independent of emulation modes.
The Sun-supplied mem_batchrop is kind of slow compared to the
monochrome and cg2-based color versions; however, this may just be a
result of using a straight memory-based frame buffer with no hardware
assist.
CODE
Here are the diffs:
-------------------
X/libsun/initial.c
-------------------
241a242,280
> }
>
>
> /*
> * Now we do some fixing up for distinguishing the Sun 3/110 color
> * display from a monochrome Sun 3/50 display.
> */
>
> if (fbt.fb_type == FBTYPE_SUN2BW) /* is it a BW display? */
> { /* yes, might be a 3/110 in */
> /* emulation mode */
> struct fbgattr AttBuf; /* for reading 3/110 attributes */
> if (ioctl(fd, FBIOGATTR, &AttBuf) >= 0)
> /* supports get attributes */
> { /* must be Sun 3/110 type machine */
> AttBuf.sattr.emu_type = FBTYPE_SUN4COLOR;
> /* tell display not to emulate */
> if (ioctl(fd, FBIOSATTR, &AttBuf.sattr) < 0)
> {
> fprintf (stderr,"Can't FBIOSATTR on %s\n",
> sc.scr_fbname);
> return (-1);
> }
> if (ioctl(fd, FBIOGTYPE, &fbt) < 0)
> { /* now redo FIOGTYPE */
> fprintf(stderr, "Can't FBIOGTYPE on %s\n",
> sc.scr_fbname);
> return (-1);
> }
> }
> else /* This is not 3/110, must be */
> { /* SUN2BW; patch his mem_batchrop */
> /* to be Xmem_batchrop */
> extern Xmem_batchrop();
> extern struct pixrectops bw2_ops;
> struct pixrectops *ptr = &bw2_ops;
>
> ptr->pro_batchrop = Xmem_batchrop;
> }
-----------------
X/libsun/text.c
----------------
344,345c344,345
<
< mem_batchrop(dst, op, src, count)
---
>
> Xmem_batchrop(dst, op, src, count)
Technical Details
Message-ID:
<8703140051.AA20492@ATHENA>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!bfly-vax.bbn.COM!cdhShow Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!bfly-vax.bbn.COM!cdh From: cdh@bfly-vax.bbn.COM.UUCP Newsgroups: comp.windows.x Subject: Fix to allow Sun 3/110s to use the X windows system Message-ID: <8703140051.AA20492@ATHENA> Date: Fri, 13-Mar-87 14:00:00 EST Article-I.D.: ATHENA.8703140051.AA20492 Posted: Fri Mar 13 14:00:00 1987 Date-Received: Sat, 14-Mar-87 15:32:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 148