Strange X behaviour reporting root window ID on an Enter/LeaveNotify event

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081021/e25235ff/attachment.pgp>