I am trying to create an X app that consists of two processes. The
parent process creates the window and spawns a child process, to which
it passes the window XID. The child process opens an X connection of
its own, sets the WM_DELETE_WINDOW protocol in the window it was
passed, selects (XSelectInput) for events in said window, then sends
back info on these events to the parent process through a pipe.

I got this setup working fine for mouse/Expose/ConfigureNotify/...
events, which means the XID works across process boundaries.
Unfortunately, I can't seem to get the ClientMessage events in the
child process when I try and close the window. I can't close the
window either, which proves that the WM_DELETE_WINDOW property is
advertised correctly. I have tried doing it all in one process, just
to check that it works fine that way and I didn't miss anything too
obvious. In order to get it to work in my two-process setup, I have
tried the following, to no avail:

- Mapping the window in the child process.
- Using XChangeWindowAttributes rather than XSelectInput.
- Calling XSetWMProtocols before, after mapping/selecting.
- Calling XSync(dpy, False) after setting things up, in all the
combinations of the above.

My current workaround is to have the child process create the window
itself. That gets me the ClientMessage events, but this is not
satisfactory to me. I want to set up a GLX context in this window, and
I'd rather do that in the main process. It would be great if I could
get away with only passing the child process the XID of the window.
I'm thinking of it as a dumb event pump, I'd rather leave logic of
Visuals and GL context configurations out of there.

Is it a known feature/issue of X that only the client that creates a
window can get ClientMessages on it? Am I missing something else