Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!tymix!tardis!oliveb!amiga!boing!dale From: dale@boing.UUCP (Dale Luck) Newsgroups: comp.windows.x Subject: Re: white and black colors in the X server Message-ID: <990@boing.UUCP> Date: 2 Jun 91 17:51:59 GMT References: <"31-May-91.12:33:33.EDT".*.Nagesh_Pabbisetty.Henr801C@Xerox.com> <9105311752.AA00413@xenon.lcs.mit.edu> Reply-To: dale@boing.UUCP (Dale Luck) Organization: Boing, Milpitas, Ca. Lines: 24 In article keith@expo.lcs.mit.EDU (Keith Packard) writes: > >> The fact that whitePixel is 0 and blackPixel is 1 has been built into the code >> at several places in the implementation on the X11R4 server. >This is simply untrue. The DEC QVSS - the first machine to ever run X11 is >a monochrome display with blackPixel 0 and whitePixel 1. Keith is right about there not being black and white hard coded pixel Values. It just appears that way when reading the names of some of the routines. The following in the source code would seem at first to imply that blackpixel and whitepixal are hardcoded when you see: (from mfbsolidarea.c) MFBSOLIDFILLAREA OPEQ EQWHOLEOWRD mfbSolidWhiteArea |= = ~0 mfbSolidBlackArea &=~ = 0 mfbSolidInvertArea ^= ^= ~0 A better set of names would have been: mfbSolidOnesArea, mfbSolidZeroesArea. Our server on the Amiga be sets Black=0 and WHite=1 on startup. This does cause problems with several applications that think they can XOR after setting the FGPen to blackPixel and have it do anything intelligent. xsol was one of the culprits here. When one of my main customers could not get their big ic simulator to run right when it ran fine on a b/w sparc I new I problems. (The program was being written by another company so they had no direct way of fixing it). We've added a new option to the server, "-swapbw" which swaps the values of pen 0 and pen1 (black and white) when the colormap is initialized for those the need to run such broken applications. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale