Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!oliveb!sun!david
From: david@sun.uucp (David DiGiacomo)
Newsgroups: comp.windows.x
Subject: Re: Fix to allow Sun 3/110s to use the X windows system
Message-ID: <15099@sun.uucp>
Date: Mon, 16-Mar-87 14:53:44 EST
Article-I.D.: sun.15099
Posted: Mon Mar 16 14:53:44 1987
Date-Received: Tue, 17-Mar-87 04:00:51 EST
References: <8703140051.AA20492@ATHENA>
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 76

In article <8703140051.AA20492@ATHENA> cdh@bfly-vax.bbn.COM writes:
>The following two modifications permit the X server to work on the Sun
>3/110 color display...
>
>Sun 3/110 owners, rejoice and enjoy!

Don't rejoice yet -- the given changes are not sufficient to get X
running properly in color on the 3/110!

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

This is not too strange -- it has to default to bw2 emulation mode
because there is no way to go back in time and insert mode-changing code
in old binaries.  It is *not* necessary to change the the emulation mode
to run color applications, so it should be left alone unless you have a
very good reason.

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

Partially correct.  The reason for the modified mem_batchrop was better
performance, but the X version of cg2_batchrop has *different semantics*
than the pixrect library version.

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

This solution is too complicated.  There is no need to do any frame
buffer ioctls in InitDisplay since all the information needed is encoded
in the pixrect "PixRect".  Here is the code I have been using:

	Display = pw_open(vsdev);
	PixRect = Display->pw_pixrect;
	info->id = PixRect->pr_depth > 1 ? XDEV_SUN2COLOR : XDEV_SUN2BW;
	info->planes = PixRect->pr_depth;
	info->entries = 1 << PixRect->pr_depth;
	if (PixRect->pr_depth == 1)
		pw_reversevideo(Display,0,1);

(The info->id isn't used for anything so it doesn't have to be exactly
right.)

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

I think you will find the performance of the mem_batchrop in the release
3.2 and later pixrect library adequate.  However, if you still want to
patch in the hacked X version do it this way:

	if (PixRect->pr_depth == 1 && !MP_NOTMPR(PixRect))
		Pixrect->pr_ops->pro_batchrop = Xmem_batchrop;

>BUGS

The most important bug was omitted -- it doesn't work!  The cursor and
text code relies on the modified semantics of the supplied cg2_batchrop.
The batchrop functions in the pixrect library (including mem_batchrop)
follow (documented) pixrect semantics.

-- 
David DiGiacomo  {decvax, ihnp4, ucbvax}!sun!david  david@sun.arpa
Sun Microsystems, Mt. View, CA  (415) 691-7495