I'll preface by saying I'm by no means fully versed on the X protocol, so what I'm seeing might be valid but unintuitive.
I've been investigating an annoying bug in the xorg and metacity packages shipped with Fedora 9. Part of this bug was pseudo-fixed in Metacity shipping in Fedora 10. I have a triple-head Xinerama setup, running the Metacity window manager. The problem is that when Metacity starts up, it queries the X server for the root window ID by storing the return of RootWindow. Some unreliably reproducible series of events eventually causes X to send an EnterNotify event to Metacity, but with a root window ID that differs from the one queried at startup. This causes F9 Metacity to enter a segfault loop. The reason is because Metacity is trying to find its own internal "Screen" state data by this ID, and the function that finds it returns NULL, and is then immediately dereferenced. When Metacity is restarted by the session manager, it gets back the same original root window ID from RootWindow, and then receives the same EnterNotify event with the same differing root window ID. This behaviour was fixed in the latest Metacity by ignoring events associated with a root window ID that isn't the one that RootWindow returned. http://bugzilla.gnome.org/show_bug.cgi?id=422242#c7 So with the F10 package, when this same X behaviour springs up, it stops servicing pointer events. The Enter/LeaveNotify events have the bogus root window ID, but oddly enough, keyboard events get the correct root window ID. So I can alt-tab, but the mouse becomes useless. I wasn't sure if it was valid for one X screen to have multiple root windows, so I tried running xwininfo -id 0x3be (the bogus root window ID of the EnterNotify event that crashes Metacity), and that immediately crashed X. The root window ID reported by RootWindow was 0x3bc. _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
