Conference bulova::decw_jan-89_to_nov-90

    I presume that they get some kind of error when they try to run against
    the local VAXstation display. Can you find out what it is? Can you find
    out the H/W configuration of the VAXstation?

    How do they do the EGA graphics? Do they construct a pixmap as their "fake"
    window and draw into it? If so the problem may be that they have run out
    of server resources (i.e. can't create a pixmap of that size).

	-- Charles

    Charles,
    
    Thank you for the quick response. I will speak to the developer
    and get his answers posted ASAP.
    
    Marshall
    

    I can't help but see some vagueness in the problem description too.
    What kind of DECstation are they talking about? A DECstation 3100/
    2100 type of machine (RISC) or a DECstation 200/300 type of
    machine (Intel)? Are they trying to use the hardware directly or
    use Xlib type calls to make it all work?
    
    Dan

    
    Dan,
    
    The problem manifests itself on VAX VMS DECwindows and VAX
    Ultrix DECwindow. The RISC implementation works as expected.
    Here is the scoop - including test code - from Insignia.
    
    Marshall
    
    
From:	DECWRL::"[email protected]" 28-NOV-1989 13:39:21.36
To:	wrksys::woods
CC:	wsint::goldberg
Subj:	VAX X server bug demo program

Richard,
 
This program illustrates the bug. Instructions for building on an Ultrix system
are at the head of the code.
 
Try it on a DECstation and a VAXstation.
 
Zdravko
 
-----------CUT-----------
/*
 * Build by "cc main.c -lX11 -o test"
 *
 * run by typing 'test' on the command line
 *
 * This file contains a test routine that should produce a black window
 * 640 pixels by 400, and then draw two cyan rectangles on top.
 * 
 * This program works as expected on Decstation 3100 and Tektronix workstations.
 *
 * However on Vaxstations the 2nd rectangle has a bar across the middle and the 
 * colour of both rectangles are red.
 *
 * It appears as though the plane mask is not working as we would expect. The
 * data describing the second rectangle is being corrupted by the data already
 * in the image buffer from the first rectangle, and our base colour plane is
 * also being overwritten.
 *
 * SoftPC installs its own 16 colour-colour map from pixel value 16 - 31(in
 * this case). The window is initialised to a black background by doing an
 * XFillRectangle of pixels[0]( pixel value 16,colour black ). We then just
 * write to the 2 planes that control bits 0 and 1 of the pixel value, thereby
 * specifying colours 16 - 19 in our colourmap.
 */
 
#include <X11/Xlib.h>
 
#define XWIDTH 640
#define YDEPTH 400
 
static unsigned char image_buffer[80 * 400 * 8];
static Display *dp;
static GC	gc;
static Window win_id, root;
static XImage *image;
static int plane_masks[4];
static int pixels[16];
static unsigned short
	red[] = {    0,     0,     0,     0, 55000, 55000, 55000, 55000, 
	       20000,     0,     0,     0, 65535, 65535, 65535, 65535},
	green[] = {    0,     0, 55000, 55000,     0,     0, 55000, 55000,
	       20000,     0, 65535, 65535,     0,     0, 65535, 65535},
	blue[] = {    0, 55000,     0, 55000,     0, 55000,     0, 55000,
	       20000, 65535,     0, 65535,     0, 65535,     0, 65535};
 
static void set_rect();
 
main()
{
	int x, y, w, h, b, depth;
	int colours,i, mask;
	XColor	colour, def;
	Colormap cmap;
 
	if( (dp = XOpenDisplay(0)) == (Display *)0 )
	{
		printf("can't open display\n");
		exit(1);
	}
 
	gc = DefaultGC(dp, 0);
 
	win_id = XCreateSimpleWindow(dp, RootWindow(dp,0), 0, 0, XWIDTH,
			YDEPTH, 3, WhitePixel(dp,0), BlackPixel(dp,0) );
 
	XMapWindow(dp, win_id);
 
	XGetGeometry(dp, win_id, &root, &x, &y, &w, &h, &b, &depth);
	
	cmap = DefaultColormap( dp, 0 );
	if( XAllocColorCells( dp, cmap, 0, plane_masks, 4, pixels, 1) )
		colours = 16;
	else
		printf("We have a XAllocColorCells problem\n");
 
	/*
	 * Set up colourmap used by SoftPC
	 */
	for (i = 1; i < colours; i++ )
		pixels[i] = pixels[0] + i;
 
	colour.flags = ( DoRed | DoGreen | DoBlue );
	for (i = 15; i>= 0; i--)
	{
		colour.pixel = pixels[i];
		colour.red   = red[i];
		colour.green = green[i];
		colour.blue  = blue[i];
 		XStoreColor( dp, cmap, &colour );
	}
	XSync(dp, 0);
	/*
	 * print out colour map entries 0x03 and 0x13
	 */
	def.pixel = 3;
	XQueryColor( dp, cmap, &def );
	printf("0x%.2x - red = %d, green = %d, blue = %d\n",
		def.pixel, def.red, def.green, def.blue );
	def.pixel = 0x13;
	XQueryColor( dp, cmap, &def );
	printf("0x%.2x - red = %d, green = %d, blue = %d\n",
		def.pixel, def.red, def.green, def.blue );
	/*******************************/
 
	image = XCreateImage( dp, DefaultVisual(dp, 0), depth, XYPixmap, 0,
		image_buffer, XWIDTH, YDEPTH, BitmapPad(dp), 0);
 
	XSetState( dp, gc, pixels[0], pixels[0], GXcopy, AllPlanes );
	XFillRectangle( dp, win_id, gc, 0, 0, XWIDTH, YDEPTH );
	XSetState( dp, gc, pixels[0], pixels[0], GXcopy, 0xf );
 
	/*
	 * only write to planes 0 and 1 - this should now set the pixel
	 * value to 0x13 after the XFillRectangle call above
	 */
	mask = plane_masks[0] | plane_masks[1];
 
	/*
	 * Produce long rectangle across the top of the screen
	 */
	set_rect(6, 0, 0, 640, 8 );	
	set_rect(7, 0, 0, 640, 8 );	
	XSetState( dp, gc, pixels[1], pixels[0], GXcopy, mask );
	XPutImage( dp, win_id, gc, image, 0, 0, 0, 0, 640, 8 );
 
	/*
	 * Produce rectangle in the middle of the screen
	 */
	set_rect(6, 100, 25, 320, 200 );	
	set_rect(7, 100, 25, 320, 200 );	
	XSetState( dp, gc, pixels[1], pixels[0], GXcopy, mask );
	XPutImage( dp, win_id, gc, image, 0, 0, 100, 25, 320, 200 );
 
	while(1);
}
 
/*
 * This routine sets all the bits in a specified rectangle on a specified plane
 */
static void set_rect( no, x, y, w, h)
int	no,	/* plane no - numbering from 0 - 7		*/
	x, y,	/* x and y co-ordinates of rect in pixels	*/
	w, h;	/* width and height of rectangle in pixels	*/
{
	int i, j, start;
 
	image->width = w;
	image->height = h;
	/*
	 * convert from pixels -(for test purposes, we asume multiples of 8)
	 */
	x = x>>3;
	w = w>>3;
	image->bytes_per_line = w;
	
	/*
	 * Write to the correct place in image buffer
	 */
	start = (no * w * h);
	for(j = 0; j< h; j++)
	{
		for(i = 0;i<w; i++)
			image_buffer[start+i] =0xff;
		start+=w;
	}
}
 
 
% ==== Internet headers and postmarks (see DECWRL::GATEWAY.DOC)
% Received: by decwrl.dec.com; id AA10117; Tue, 28 Nov 89 10:39:32 -0800
% Received: by mcsun.EU.net via EUnet; Tue, 28 Nov 89 16:55:09 +0100 (MET)
% Received: by mcvax.cwi.nl with SMTP; Tue, 28 Nov 89 16:40:55 +0100 (MET)
% Received: from ukc by hp4nl.nluug.nl with UUCP via EUnet
% 	id AA27290 (5.58.1.14/2.14); Tue, 28 Nov 89 16:41:44 +0100
% Received: from insignia.uucp by kestrel.Ukc.AC.UK   with UUCP  id aa05976;
% 	28 Nov 89 15:29 GMT
% Received: from piglet.insignia.co.uk by yogi.insignia.co.uk; Tue, 28 Nov 89 07:26:30 pst
% From: Zdravko Podolski <[email protected]>
% Date: Tue, 28 Nov 89 15:24:58 GMT
% Message-Id: <[email protected]>

    
    Jeff McLeman called and told us the problem was using XAllocColorCells.
    He said XAllocColorCells is hardware specific. He advised them to
    use XAllocColorPlanes. Could one of you Guru's convert the program
    in the previous note to use XAllocColorPlanes?  
    
    Marshall
    
    

That is not what I said. I said that if they are playing with plane masks,
they should be using XAllocColorPlanes, not XAllocColorCells. This is
good programming practice. I didn't say XAllocColorCells was hardware
specific. What I did say is that different hardware platforms have
different formats for color map entries. Two entirely different things.

    .4
    
    This simply looks like a programming bug, not a problem in
    AllocColorCells.
    
    When the program does:
    
        XAllocColorCells( dp, cmap, 0, plane_masks, 4, pixels, 1)
    
    It asks for 4 non-contiguous planes and one pixel.  This call will
    return 4 plane masks, and 1 pixel.  So for instance, the application
    could obtain:
    
    		Plane masks:	00000010
    				00001000
    				00100000   
    				01000000
    
    		Pixel:		00000001
    
    Which provides the following 16 VALID pixel values:
    
    
    		0		00000001
    		1		00000011
    		2		00001001
    		3		00001011
    		4		00100001
    		5		00100011
    		6		00101001
    		7		00101011
    		8		01000001
    		9		01000011
    		10		01001001
    		11		01001011
    		12		01100001
    		13		01100011
    		14		01101001
    		15		01101011
    
    But the application instead generates it's pixel values using:
    
	for (i = 1; i < colours; i++ )
		pixels[i] = pixels[0] + i;
    
    Which creates values (with the same input):
    
    	1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
    
    	Note that these are INVALID pixel values!
    
    Now, this will WORK if and ONLY if the application gets allocated
    a PIEXL VALUE of 0 (zero) and PLANE MASK BITS of 1, 2, 4 and 8.  Now
    from experience - this can happen frequently if you have no other
    applications running on the workstation, so it might APPEAR to work,
    but is *really* broken.
    
    Have them replace their build of the PIXEL array with the following
    (adapted from the Guide to Migrating VWS Applications to DECwindows):
    
    
    	int color, loop, cbits, plane_count = 4;
    
    	for (color = 0; color < plane_count; color += 1)
    	  {
    	    pixels[color] = pixels[0];
    
    	    cbits = color;
    
    	    for (i = 0; loop < 4; loop +=1)
    	      {
    	        if (cbits & 1)
    	          {
    	            pixels[color] |= plane_masks[loop];
    	          }
    	        cbits >>= 1;
    	      }
    	  }
    
    
    This loop will build a valid pixel array.  The ordering of the pixel
    values in the array will be such that if you OR all of the plane mask
    values into a single plane mask, when this combined plane mask is
    XORed with any of the valid pixel values, it will complement the value
    such that the result (and array index) is the pixel value in the
    ((array_size-1)-original_array_index) array element... i.e. you can do
    reasonable logical operations on the plane mask bits.
    
    

Oh well.. I was informed by someone to say use XAllocColorPlanes, but Fred's way
will work just fine. Sigh...

    Fred,
    
    I will zip your response off to Insignia and let you know
    how it goes. Thank you very much for the quick response!
    
    Marshall
    

Thanks Fred...I did not get time to figure this out before you did.

Using Plane Masks with XAllocColorCells is just fine.  In fact, AllocColorPlanes's
main purpose in life is to allow applications to be designed to deal with
DirectColor type devices regardless of the actual hardware type being used.
Similarly, AllocColorPlanes is for applications which are designed to be used
with PseudoColor-type devices, but works on both Pseudo- and Direct.

The main difference between the two is whether each possible pixel value is
completely independent from each other possible pixel value.  (I don't plan
to explain the whole thing here...see something like Gettys and Scheifler for
more).

Burns

From:	DECWRL::"[email protected]"  7-DEC-1989 07:01:06.55
To:	wrksys::woods
CC:	wsint::goldberg
Subj:	Re:  VAXstation X server bug - new improved test program still fails

Richard,
 
As mentioned in my fax, I enclose the test program, modified according to the
suggestions. It still exhibits the fault.
 
Zdravko
--------------CUT--------------
/*
 * Build by "cc main.c -lX11 -o test"
 *
 * This file contains a test routine that should produce a black window
 * 640 pixels by 400, and then draw two cyan rectangles on top.
 * 
 * This program works as expected on Decstation 3100 and Tektronix workstations.
 *
 * However on Vaxstations the 2nd rectangle has a bar across the middle and the 
 * colour of both rectangles are red.
 *
 * It appears as though the plane mask is not working as we would expect. The
 * data describing the second rectangle is being corrupted by the data already
 * in the image buffer from the first rectangle, and our base colour plane is
 * also being overwritten.
 *
 * SoftPC installs its own 16 colour-colour map from pixel value 16 - 31(in
 * this case). The window is initialised to a black background by doing an
 * XFillRectangle of pixels[0]( pixel value 16,colour black ). We then just
 * write to the 2 planes that control bits 0 and 1 of the pixel value, thereby
 * specifying colours 16 - 19 in our colourmap.
 */
 
#include <X11/Xlib.h>
 
#define XWIDTH 640
#define YDEPTH 400
 
static unsigned char image_buffer[80 * 400 * 8];
static Display *dp;
static GC	gc;
static Window win_id, root;
static XImage *image;
static int plane_masks[4];
static int pixels[16];
static int loop, cbits, plane_count = 4;
static unsigned short
	red[] = {    0,     0,     0,     0, 55000, 55000, 55000, 55000, 
	       20000,     0,     0,     0, 65535, 65535, 65535, 65535},
	green[] = {    0,     0, 55000, 55000,     0,     0, 55000, 55000,
	       20000,     0, 65535, 65535,     0,     0, 65535, 65535},
	blue[] = {    0, 55000,     0, 55000,     0, 55000,     0, 55000,
	       20000, 65535,     0, 65535,     0, 65535,     0, 65535};
 
static void set_rect();
 
main()
{
	int x, y, w, h, b, depth;
	int colours,i, mask;
	XColor	colour, def;
	Colormap cmap;
 
	if( (dp = XOpenDisplay(0)) == (Display *)0 )
	{
		printf("can't open display\n");
		exit(1);
	}
 
	gc = DefaultGC(dp, 0);
 
	win_id = XCreateSimpleWindow(dp, RootWindow(dp,0), 0, 0, XWIDTH,
			YDEPTH, 3, WhitePixel(dp,0), BlackPixel(dp,0) );
 
	XMapWindow(dp, win_id);
 
	XGetGeometry(dp, win_id, &root, &x, &y, &w, &h, &b, &depth);
	
	cmap = DefaultColormap( dp, 0 );
	if( XAllocColorCells( dp, cmap, 1, plane_masks, 4, pixels, 1) )
		colours = 16;
	else
		printf("We have a XAllocColorCells problem\n");
 
	/*
	 * Set up colourmap used by SoftPC
	 */
	for( i = 0; i < colours; i++ )
	{
		pixels[i] = pixels[0];
		cbits = i;
		for( loop = 0; loop < 4; loop++ )
		{
			if( cbits & 1 )
				pixels[i] |= plane_masks[loop];
			cbits >>= 1;
		}
printf("pixels[%d] = %d\n",i,pixels[i] );
	}
	
	colour.flags = ( DoRed | DoGreen | DoBlue );
	for (i = 15; i>= 0; i--)
	{
		colour.pixel = pixels[i];
		colour.red   = red[i];
		colour.green = green[i];
		colour.blue  = blue[i];
 		XStoreColor( dp, cmap, &colour );
	}
	XSync(dp, 0);
	/*
	 * print out colour map entries 0x03 and 0x13
	 */
	def.pixel = 3;
	XQueryColor( dp, cmap, &def );
	printf("0x%.2x - red = %d, green = %d, blue = %d\n",
		def.pixel, def.red, def.green, def.blue );
	def.pixel = 0x13;
	XQueryColor( dp, cmap, &def );
	printf("0x%.2x - red = %d, green = %d, blue = %d\n",
		def.pixel, def.red, def.green, def.blue );
	/*******************************/
 
	image = XCreateImage( dp, DefaultVisual(dp, 0), depth, XYPixmap, 0,
		image_buffer, XWIDTH, YDEPTH, BitmapPad(dp), 0);
 
	XSetState( dp, gc, pixels[0], pixels[0], GXcopy, AllPlanes );
	XFillRectangle( dp, win_id, gc, 0, 0, XWIDTH, YDEPTH );
	XSetState( dp, gc, pixels[0], pixels[0], GXcopy, 0xf );
 
	/*
	 * only write to planes 0 and 1 - this should now set the pixel
	 * value to 0x13 after the XFillRectangle call above
	 */
	mask = plane_masks[0] | plane_masks[1];
 
	/*
	 * Produce long rectangle across the top of the screen
	 */
	set_rect(6, 0, 0, 640, 8 );	
	set_rect(7, 0, 0, 640, 8 );	
	XSetState( dp, gc, pixels[1], pixels[0], GXcopy, mask );
	XPutImage( dp, win_id, gc, image, 0, 0, 0, 0, 640, 8 );
 
	/*
	 * Produce rectangle in the middle of the screen
	 */
	set_rect(6, 100, 25, 320, 200 );	
	set_rect(7, 100, 25, 320, 200 );	
	XSetState( dp, gc, pixels[1], pixels[0], GXcopy, mask );
	XPutImage( dp, win_id, gc, image, 0, 0, 100, 25, 320, 200 );
 
	while(1);
}
 
/*
 * This routine sets all the bits in a specified rectangle on a specified plane
 */
static void set_rect( no, x, y, w, h)
int	no,	/* plane no - numbering from 0 - 7		*/
	x, y,	/* x and y co-ordinates of rect in pixels	*/
	w, h;	/* width and height of rectangle in pixels	*/
{
	int i, j, start;
 
	image->width = w;
	image->height = h;
	/*
	 * convert from pixels -(for test purposes, we asume multiples of 8)
	 */
	x = x>>3;
	w = w>>3;
	image->bytes_per_line = w;
	
	/*
	 * Write to the correct place in image buffer
	 */
	start = (no * w * h);
	for(j = 0; j< h; j++)
	{
		for(i = 0;i<w; i++)
			image_buffer[start+i] =0xff;
		start+=w;
	}
}
 
 
% ==== Internet headers and postmarks (see DECWRL::GATEWAY.DOC)
% Received: by decwrl.dec.com; id AA07216; Thu, 7 Dec 89 03:56:01 -0800
% Received: by mcsun.EU.net via EUnet; Thu, 7 Dec 89 12:54:45 +0100 (MET)
% Received: by mcvax.cwi.nl with SMTP; Thu, 7 Dec 89 12:40:44 +0100 (MET)
% Received: from ukc by hp4nl.nluug.nl with UUCP via EUnet
% 	id AA10549 (5.58.1.14/2.14); Thu, 7 Dec 89 12:41:31 +0100
% Received: from insignia.uucp by kestrel.Ukc.AC.UK   with UUCP  id aa01313;
% 	7 Dec 89 11:08 GMT
% Received: from piglet.insignia.co.uk by yogi.insignia.co.uk; Thu, 7 Dec 89 03:03:48 pst
% From: Zdravko Podolski <[email protected]>
% Date: Thu, 7 Dec 89 11:04:16 GMT
% Message-Id: <[email protected]>

    
    I have looked at this and as near as I can determine, the plane mask
    seems to be non-functional for XYPixmaps!  I can get a modified version
    of this to do something more "reasonable" using ZPixmap format - but
    with XYPixmap I can only get a white rectangle.  Since I haven't ever
    tried this format (and a wierd one at that)... you'll have to refer
    this one to the VMS Server folks.
    
    Note that they *still* exhibit a non-understanding of what they will
    get back.  They *cannot* count on getting back the specific values
    they fetch (for display here).  They will NOT always get back 16-31
    (masks 1, 2, 4, 8 and pixel 16).
    
    _Fred
    

Right Fred, the XYPixmap format put image does not honor the plane mask. That
is a bug! It has been found and fixed and will be in the SSB version of 5.3-1.
						Bill

    Thanks to all for a resolution of this problem.
    
    We really appreciate the response.
    
    Marshall
    

    
    Insignia is on the phone with me and says they did have a
    misunderstanding of the color table entries and now have things
    completely under control and fixed. They wish to express their 
    thanks for the help you all have provided.
    
    Does anyone know the schedule for the release of VMS 5.3-1?
    
    Marshall
    

You might want to ask in VAXWRK::VMS_FIELD_TESTS