I have found that the cause of this problem is due to the resourceid in the
error event received by the window manager does not match the root window id
which results in mwm ignoring the error. I have found that if I change
PanoramiXChangeWindowAttributes to iterate over screens in the forward
direction rather than reverse, the correct resourceid is passed back and mwm
behaves correctly. My question now is what are the consequences of reversing
this iteration?

Darren.

On Fri, Feb 15, 2002 at 12:22:06PM -0800, Mark Vojkovich wrote:
> On Fri, 15 Feb 2002, Darren Marshall wrote:
> 
> > When a window manager starts up and tries to gain control using
> > XChangeWindowAttributes on the root window it normally receives a BadAccess
> > error if another window manager is already running. However this doesn't
> > appear to work with xinerama. I have been attempting to debug the problem but
> > my knowledge of the source code is severely lacking. I have seen that when the
> > X server is not operating in xinerama mode that EventSelectForWindow() in
> > programs/Xserver/dix/events.c returns BadAccess and thats the end of it. When
> > the X server is operating in xinerama mode the EventSelectForWindow() function
> > also returns BadAccess but there follows further calls to
> > EventSelectForWindow() which do not, due to the mask parameter not being set
> > appropriately. Can anybody give me any pointers on how to fix this problem.
> 
> 
>    Things start in dix/Xext/panoramiXprocs.c:PanoramiXChangeWindowAttributes.
> It iterates over screens, calling through the proc vector which is
> dix/dix/dispatch.c:ProcChangeWindowAttributes.  It's not obvious
> to me that ChangeWindowAttributes is modifying the valueMask so you
> should verify that stuff->valueMask isn't changing between iterations
> through loop in PanoramiXChangeWindowAttributes.  If somebody at the
> ChangeWindowAttributes level or below is modifying this, it needs to
> get pulled out of the stuff[1] array in PanoramiXChangeWindowAttributes
> and the unmodified copy should be getting passed down through the proc
> vector in the loop instead.  But I don't see anywhere that it's getting 
> modified at the moment.
> 
> 
>                               Mark.
> 
> _______________________________________________
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert


------------
This e-mail and any attachments are confidential.  If you are not the intended 
recipient, please notify us immediately by reply e-mail and then delete this message 
from your system. Do not copy this e-mail or any attachments, use the contents for any 
purpose, or disclose the contents to any other person: to do so could be a breach of 
confidence.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to