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