1
votes

In one terminal I'm starting a process that looks like this....

        // ...
        while(true) {
            XNextEvent(xw.dpy, &ev);
            if(XFilterEvent(&ev, None))
                continue;
            printf("type: %d\n", ev.type);
            if(handler[ev.type])
                (handler[ev.type])(&ev);
        }
       // ...

Then I use xev to monitor this process

xev -i <window>

I then open Chrome, copy some text, then focus the first process and do Shift+Insert. This results in text being pasted into the first process and we see it print '31' (/usr/include/X11/X.h) which indicates SelectionNotify. xev on the other hand doesn't show a SelectionNotify event, but it does show a PropertyNotify event that the first process doesn't show. The PropertyNotify event updates the PRIMARY property.

This is how the copy/paste algorithm is supposed to work: http://en.wikipedia.org/wiki/X_Window_selection#Selections

Thoughts?

1

1 Answers

3
votes

From the xev manpage, "Xev ... asks the X server to send it events whenever anything happens to the window (such as it being moved, resized, typed in, clicked in, etc.). You can also attach it to an existing window. It is useful for seeing what causes events to occur and to display the information that they contain; "

Apparently xev doesn't get the actual events that the window it is attached to is getting.

xev code looks like this

case 'i':           /* -id */
    if (++i >= argc) usage ();
        sscanf(argv[i], "0x%lx", &w);
    if (!w)
        sscanf(argv[i], "%lu", &w);
    if (!w)
        usage ();
    continue;

// ...

if (w) {
    XGetWindowAttributes(dpy, w, &wattr);
    if (wattr.all_event_masks & ButtonPressMask)
        attr.event_mask &= ~ButtonPressMask;
    attr.event_mask &= ~SubstructureRedirectMask;
    XSelectInput(dpy, w, attr.event_mask);
} else {
    // ...
}

//...

for (done = 0; !done; ) {
    XEvent event;
    XNextEvent (dpy, &event);

    switch (event.type) {
    // ...
    }
}

Presumably XSelectInput and XNextEvent are doing something weird when a process 'attaches' to some window and that window gets a SelectionNotify event.

"Unfortunately, xev is not fool proof if you ask it to track events on a window it does not own (the -id mode). It receives these events by requesting them with Xlib's XSelectInput() function. This technique has three major limitations:
1. grabs - If one client activates a server, pointer, or keyboard grab, then event reporting to all other clients will be affected. xev will not be able to report some (or all) events, even though the client activating the grab may be receiving them.
2. non-maskable events - The X protocol does not allow certain events to be reported to clients other than the one that created the event window. Most of these events deal with selections.
3. redirection events - The X protocol allows only one client to request certain events. xev cannot receive these if another client is receiving them. These events include window manager redirection events (e.g., substructure notify on the root window) and implicit passive grab events (e.g., mouse button presses)." (http://www.rahul.net/kenton/events.html#LimitationsOf)