Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!mit-eddie!bloom-beacon!dont-send-mail-to-path-lines
From: rws@expo.lcs.mit.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: white and black colors in the X server
Message-ID: <9105312159.AA05373@expire.lcs.mit.edu>
Date: 31 May 91 21:59:51 GMT
References: <"31-May-91.17:30:23.EDT".*.Nagesh_Pabbisetty.Henr801C@Xerox.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 28


  sunBW2.c sets whitepixel to 0 and black pixel to 1 for the Sun.
  We have hardware which has reverse values for white and black compared to Suns.

The QVSS which Keith mentions also has the reverse values.
Look at server/ddx/qvss/qvss_io.c.

  I reversed the pixel values in xrxBW2.c. But this change was not sufficient

Then you did something wrong.

  because other parts of the implementation KNOW the values of white and
  black pixel.

No, they do not.

	File mfbgc.c, function mfbValidateGC, has the following code

Don't just read the function names, read and understand the code.  "White"
in the mfb code simply means "1" not white, "Black" simply means "0" not black.
An unfortunate (and obviously confusing) choice of names.  What matters for
black and white colors is how the colormap gets initialized.

    What would be the easiest
    way for me to continue to use the code I have ported based on mfb, 
    AND take care of this reversal of white and black on my hardware? 

Try reading some other code examples, like the qvss code.