Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!cmcl2!beta!hc!ames!oliveb!sun!david
From: david@sun.uucp (David DiGiacomo)
Newsgroups: comp.windows.x
Subject: Re: Color X and Sun 3/260
Message-ID: <22696@sun.uucp>
Date: Mon, 6-Jul-87 13:10:29 EDT
Article-I.D.: sun.22696
Posted: Mon Jul  6 13:10:29 1987
Date-Received: Tue, 7-Jul-87 06:05:58 EDT
References: <8707030926.aa21045@ROME.UCI.EDU>
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 33

In article <8707030926.aa21045@ROME.UCI.EDU> gennari@HARLIE.UCI.EDU writes:
>     Hi. A recent acquisition here, we have a Sun 3/260 with a color
>monitor. We also have the Sun graphics accelerator and buffer board. 
>When the system was first set up, X worked very well, and I quickly
>came to enjoy setting up different windows in different colors. However,
>we noticed that our accelerator was not doing anything - it turns out we
>had forgotten to set up the device driver for this board. However, once
>we installed the driver, X displayed a peculiar bug:
>
>[ description of problems with color text ]

If you peer into the murky depths of the X.V10R4 libsun/text.c, you'll
see a function called cg2_batchrop which does the actual rendering of
text when running on a color board.  When running on a GP, the
gp1_batchrop in the pixrect library is called instead and color text is
wrong (not that the X cg2_batchrop gets things completely right, but
it's closer).

It's questionable whether you get any benefit from the GP when running
X.10, but if you insist the easiest way to patch things up is to hack a
gp1_batchrop function into text.c:

	gp1_batchrop(dpr, dx, dy, op, src, count)
	struct pixrect *dpr;
	struct pr_prpos *src;
	int dx, dy, op, count;
	{ return cg2_batchrop(dpr, dx, dy, op, src, count); }

Remember, THE SUN X DRIVERS ARE PROVIDED AS IS WITH NO WARRANTIES OF ANY
KIND blah blah (and so is this posting).

-- 
David DiGiacomo, Sun Microsystems, Mt. View, CA  sun!david david@sun.com