Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ll-xn!mit-eddie!bloom-beacon!gatech!mcnc!decvax!elrond!jam
From: jam@elrond.CalComp.COM (Julie A. Melbin)
Newsgroups: comp.windows.x
Subject: bug in dispatch.c ?
Message-ID: <2039@elrond.CalComp.COM>
Date: 24 Feb 88 16:07:31 GMT
Reply-To: jam@elrond.UUCP (Julie A. Melbin)
Organization: Calcomp Display Products Division, Hudson, NH, USA
Lines: 51

I believe I located a bug in X.V11R1 dix/dispatch.c, but instead of assuming
so...

In dispath.c, the original function ProcLookupColor() had the following 
function call:

	    (*pcmp->pScreen->ResolveColor)(&lcr.screenRed,
	                                   &lcr.screenGreen,
					   &lcr.screenBlue);

Notice 3 parms for ResolveColor. However, in the file dix/colormap.c in
function AllocColor, the ResolveColor function is called:

    (*pmap->pScreen->ResolveColor) (pred, pgreen, pblue, pVisual);

	[same for function StoreColors() in the same file.]


For ddx code which uses other than 8 plane, the call from ProcLookupColor() 
could crash or produce weird results.

So, i changed dispatch.c to look like:

	    (*pcmp->pScreen->ResolveColor)(&lcr.screenRed,
	                                   &lcr.screenGreen,
					   &lcr.screenBlue.
					   pcmp->pVisual);

Was this correct?  It fixed MY problem where my ddx layer uses different numbers
of planes depending on software vs hardware cursors, etc.

I would guess those folks who use a straight 8 planes in 
their color implementation will never see this problem; the sun code in 
sunCG2C.c does not use the pVisual parm, from sunCG2C.c:

sunCG2CResolvePseudoColor(pRed, pGreen, pBlue, pVisual)
    CARD16	*pRed, *pGreen, *pBlue;
    VisualPtr	pVisual;
{
    *pRed &= 0xff00;
    *pGreen &= 0xff00;
    *pBlue &= 0xff00;
}


If I really broke something, someone please tell me. Thanks.


that's all..


...{harvard, decvax}!elrond!jam or jam@elrond.CalComp.COM