Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: 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 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)