gennari@HARLIE.UCI.EDU (07/05/87)
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: With a color window, one is supposed to specify two colors, fg and bg, or foreground (text) and background. Currently, any window except for the default blue and white window, comes with three colors: fg and bg and the text always comes in the default blue. "fg" now seems to specify the area immediately around the text, although its behavoir doesn't seem to be completely predictable. I have not found any way to modify the third color, and I don't think it's supposed to be there. At any rate, "fg and "bg" are clearly not working, and although the problem isn't crippling, it is annoying. Has anyone out there ever heard of this problem? (Does anyone else run X with the accelerator board?) Am I forgetting some type of switch? I would appreciate any suggestions or help that may be available. John Gennari <gennari@ROME.UCI.EDU>
haynes@DECWRL.DEC.COM (07/05/87)
Are you using the toolkit? It sounds to me like either text is broken, or you didn't set up the text GC correctly. If you are using the toolkit, then there may be a bug in the way text get's its resources, but I think this is a very low probability. Keep in touch. -- Charles
david@sun.uucp (David DiGiacomo) (07/06/87)
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
david@SUN.COM (David DiGiacomo) (07/11/87)
>Since we seemed to be having the same problem, I applied your patch to the >X libsun file "text.c". It seemed to take care of that specific problem just >fine, but it introduced lots more problems. For example, when you move the >cursor now you get little dots trailing after it. This may related to the >"mouse droppings" problem discussed earlier on this bboard. I'll have to >take a look through my bboard archives (which I just wrote to tape this >morning!). Also, the display has lots (and I mean LOTS!) of horizontal lines >all over it. Basically, this new version of the X server was totally unusable >because of all of these other problems so I backed off the changes. Didn't I say it was untested? Try this instead (also untested!): gp1_batchrop(dpr, dx, dy, op, src, count) struct pixrect *dpr; int dx, dy, op; struct pr_prpos *src; int count; { register struct gp1pr *dprd = gp1_d(dpr); struct pixrect newpr; struct cg2pr newprd; if (gp1_sync(dprd->gp_shmem, dprd->ioctl_fd)) return PIX_ERR; newpr = *dpr; newpr->pr_data = (caddr_t) &newprd; newprd.cgpr_va = dprd->cgpr_va; newprd.cgpr_fd = dprd->cgpr_fd; newprd.cgpr_planes = dprd->cgpr_planes; newprd.cgpr_offset = dprd->cgpr_offset; return cg2_batchrop(&newpr, dx, dy, op, src, count); } Needless to say, this is a rather disgusting hack which will break in a future release. Too bad.
raj@limbo.UCI.EDU (Richard Johnson) (07/11/87)
Since we seemed to be having the same problem, I applied your patch to the X libsun file "text.c". It seemed to take care of that specific problem just fine, but it introduced lots more problems. For example, when you move the cursor now you get little dots trailing after it. This may related to the "mouse droppings" problem discussed earlier on this bboard. I'll have to take a look through my bboard archives (which I just wrote to tape this morning!). Also, the display has lots (and I mean LOTS!) of horizontal lines all over it. Basically, this new version of the X server was totally unusable because of all of these other problems so I backed off the changes. Have you tried this locally? Has anyone else tried this change? Any I imagining things? ----------------------------------------------------------------------------- Richard A. Johnson raj@rome.uci.edu (Internet) UCI ICS Assistant Technical Manager ucbvax!ucivax!raj (UUCP) Postmaster / Network Services raj@limbo.uci.edu (via Nameservers)