On Tue, 2008-10-21 at 09:41 -0700, Bob Richmond wrote: > 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. > > <snip> > > 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.
Xinerama rewrites the protocol in a kind of non-obvious way. Hold tight... Inside the server there was traditionally a fairly tight binding between the ScreenRec and a protocol screen. Xinerama changed this, but attempted to do it in a way that required minimal changes to the ScreenRec itself. To do so, it creates a layer of proxy objects; for any object that would normally be instantiated relative to a screen, in Xinerama there is a corresponding proxy type, and a bunch of for loops to walk over the various screens. An example. Windows are per-screen; if you have two screens, a window created on screen 0 can't ever cross to screen 1. When you activate Xinerama, XCreateWindow actually creates an XRT_WINDOW type internally, which then has a list of N RT_WINDOW types associated with it, one per screen. Dispatching against all the backend screens is pretty straightforward, but the protocol munging is a little tricky. Any time you'd normally mention a potentially-multiplexed object in the protocol, you have to be careful to change the reference to be of the corresponding proxy type; likewise, any time a client asks about an XID, you have to look up only the proxy object class and not the backing classes. Easy enough on the way in, since object lookups are done relative to a type anyway, but when sending events you have to be a little more careful. There's a trick here, which is that the XID for a proxy type is exactly numerically equal to the XID for the corresponding backing type on the zero'th screen. EEEEEW GROSS. But, this is why in the Xinerama code you'll see us walking the list of screens _backwards_; by the time we reach screen zero, we've got the right XIDs in hand to send the reply or error. Anyway, probably what's happening here is we're generating a Notify event against one of the backing types and not against the proxy type. There's not that many places in the server that we generate those events, so it should be fairly straightforward to hunt down. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
