Pabbisetty.HENR801c@xerox.COM (05/31/91)
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 makes it difficult to port the server to architectures where the values of white and black are reversed. Has there been any effort in X11R5 server implementation which isolates this dependencies so as to make the port easier? (One way would be to have #define for white and black) Thanks, Nagesh Pabbisetty
keith@expo.lcs.mit.EDU (Keith Packard) (06/01/91)
> 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. The cfb code does (by default) allocate white pixel before black pixel, which generally causes white = 0 and black = 1; a trivial modification which assigns the appropriate values before calling cfbCreateDefColormap makes it possible to use any pixel values you'd like.
Nagesh_Pabbisetty.Henr801C@xerox.COM (06/01/91)
Keith,
Thanks for the response.
Here is some background information:
We would like to use the mfb code of the MIT server as the base.
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.
I reversed the pixel values in xrxBW2.c. But this change was not sufficient
because other parts of the implementation KNOW the values of white and
black pixel. Looks as if I will have to go thru the entire code and figure
out where the changes have to be made.
Now, back to your reply:
> This is simply untrue.
I may not have understood the implementation well.
Here is the scenario I am talking about.
File mfbgc.c, function mfbValidateGC, has the following code
(there are quite a few such instances in the server. This is one
instance I can think of):
if (pGC->fgPixel)
pGC->ops->ImageGlyphBlt = mfbTEGlyphBltWhite;
else
pGC->ops->ImageGlyphBlt = mfbTEGlyphBltBlack;
It would have been more appropriate (in terms of portability)
to code it as:
/* in some global place */
#define WhitePixel 0
#define BlackPixel 1
/* in mfbgc.c, function mfbValidateGC */
if (pGC->fgPixel == WhitePixel)
pGC->ops->ImageGlyphBlt = mfbTEGlyphBltWhite;
else
pGC->ops->ImageGlyphBlt = mfbTEGlyphBltBlack;
This way, people who have to port to a different architecture
have to change ONLY the file containing the global definitions
of WhitePixel and BlackPixel.
Please clarify if my understanding is incorrect. 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?
Any input you can provide will be appreciated ...
Nagesh Pabbisettyrws@expo.lcs.mit.EDU (Bob Scheifler) (06/01/91)
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.dale@boing.UUCP (Dale Luck) (06/03/91)
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
Nagesh_Pabbisetty.Henr801C@xerox.COM (06/06/91)
Bob & keith, Thanks for responding to my query. Sorry for taking so much of your time, but I am a little confused about what you said in your message: On the Sun, 0 is white and 1 is black (set in sunBW2.c). But you mentioned the following in your message: "White" in the mfb code simply means "1" not white, "Black" simply means "0" not black. Does the "ddx/sun" portion of the server have a different notion of white and black than the "ddx/mfb" portion of the server? Doesn't seem probable! In your message, you said: "Don't just read the function names, read and understand the code". I am unable to find the segment of code which makes mfbTEGlyphBltWhite paint 1's if white is defined as 1 in sunBW2.c, and makes it paint 0's if white is so defined there... Any help you can provide will be appreciated. Also, on the Sun, mfb.h defines the following #define RROP_BLACK GXclear #define RROP_WHITE GXset #define fnCLEAR(src, dst) (0) #define fnSET(src, dst) (~0) Doesn't GXclear/fnCLEAR means setting to 0? If it does, then how can RROP_BLACK be synonymous with GXclear on a Sun? mfbPaintWindow procedure in mfbpntwin.c has the following segment of code: case BackgroundPixel: if (pWin->background.pixel) mfbSolidWhiteArea(pWin, REGION_NUM_RECTS(pRegion), REGION_RECTS(pRegion), GXset, NullPixmap); else mfbSolidBlackArea(pWin, REGION_NUM_RECTS(pRegion), REGION_RECTS(pRegion), GXclear, NullPixmap); return; On the Sun, if 1 is Black, and 0 is white, then how come WhiteArea is called when the background pixel is not equal to 0... Overall Question: Where, if any, is the magic segment of code which communicates the values of black and white from sunBW2.c to the mfb routines so that the correct drawing effect with 0's and 1's is achieved (irrespective of the name of the functions) Thanks... Nagesh Pabbisetty
rws@expo.lcs.mit.EDU (Bob Scheifler) (06/06/91)
You seem so confused that I doubt I have enough free time to set you straight.
Perhaps you should have gone to Keith's server tutorial at Xhibition this week.
Does the "ddx/sun" portion of the server have a different notion of white and
black than the "ddx/mfb" portion of the server?
ddx/mfb doesn't have a notion of what pixel is RGB black and what pixel is
RGB white, ddx/sun does.
I am unable to find the segment of code which makes
mfbTEGlyphBltWhite paint 1's if white is defined as 1 in sunBW2.c, and makes
it paint 0's if white is so defined there...
mfb doesn't have such code. The client specifies pixel values for drawing
operations, usually on the basis of colormap entries. The RGB values for
0 and 1 are held in the colormap for the screen. The default mfb cmap code
decides which pixel to make RGB black and RGB white based on the blackPixel
and whitePixel entries of the screen, initialized by the ddx.
Doesn't GXclear/fnCLEAR means setting to 0?
Yes.
If it does, then how can RROP_BLACK be synonymous with GXclear on a Sun?
You obviously didn't understand the previous message segments you quoted back
at me. I said that ""Black" simply means "0" not black.". Substitute "0"
for BLACK in your question and the answer is "clear".
On the Sun, if 1 is Black, and 0 is white, then how come WhiteArea is called
when the background pixel is not equal to 0...
You still haven't understood what black and white mean in mfb code.
Where, if any, is the magic segment of code which communicates
the values of black and white from sunBW2.c to the mfb routines
In SunBW2Init:
pScreen->whitePixel = 0;
pScreen->blackPixel = 1;Nagesh_Pabbisetty.Henr801C@xerox.COM (06/06/91)
> You seem so confused that I doubt I have enough free time to set you straight.
Not really (:-)
I was missing certain pieces which you clarified in your recent message...
I sure WAS missing the point on what black and white meant in the mfb code.
Thanks for setting me straight on that!
Nagesh PabbisettyNagesh_Pabbisetty.Henr801C@xerox.COM (06/06/91)
Bob,
At the outset, let me thank Mouse, Keith and you for having helped me
understand the implementation. However, I would like to point out some
of the issues that came to light as a result of this exchange.
> You seem so confused ...
Thanks for the compliments.
The point of counfusion is that it is difficult for anyone other
than the implementors to understand the implementation when the
functions and operations have misnomers. If these misnomers are
documented, the confusion may be reduced somewhat.
The names do not seem to conform to the most basic of Software
Engineering practices - enhance the READABILITY of the code.
Proper naming of routines sure goes a long way in enahancing
the readability and improving the maintainability of the
implementation. Considering that the X server is a software
package which quite a few programmers are going to use as a
base implementation, READABILITY is more of an issue here.
I think I have read all the documentation on the X server that I
could lay my hands on, but don't recall reading anywhere that
ddx/mfb and ddx/sun have different understanding of white and
black. I would like to suggest that these facts be documented in
the Poting Layer Definition document.
With the kind of naming scheme (without documentation) that has
been pointed out, I am not surprised that I am confused. I would be
surprised if someone isn't!
Cheers!
Nagesh.rws@expo.lcs.mit.EDU (Bob Scheifler) (06/06/91)
However, I would like to point out some
of the issues that came to light as a result of this exchange.
What you say is quite true. Would that we had time to write decent
documentation about internals. We barely have time to write code.
I know a pair of people writing a book about the X server, perhaps
it will be able to help.sherman@unx.sas.com (Chris Sherman) (06/22/91)
In <"31-May-91.12:33:33.EDT".*.Nagesh_Pabbisetty.Henr801C@Xerox.com> Pabbisetty.HENR801c@xerox.COM 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 makes it >difficult to port the server to architectures where the values of white and >black are reversed. How about HP servers which sometimes forget that the black pixel shouldn't be touched. Sometimes xloadimage and others will cause the X server to allocate some other color to black, and everything that was black on my screen turns to some other color permanently. Also, Does anyone have any code that sets black back to black, and permanently allocates it so that some other program won't take it back again? Thanx, -- Chris Sherman .................... sherman@unx.sas.com | ,-----------------------------------------' / Q: How many IBM CPU's does it take to execute a job? | A: Four; three to hold it down, and one to rip its head off.