[Xcb] xcb_change_window_attributes vs. XSelectInput

[Philip Rushik]

Hello again,

I got all that working fine, but now I have a new problem. I have been
reading the xscreensaver sources (or trying) and I noticed that it also
gets substructure notify events so that it can handle newly created
windows. I figured I would have to do the same thing, so I added that to
the mask and I can now successfully get XCB_CREATE_NOTIFY events. I see
when new windows are created.
BUT when I call xcb_change_window_attributes *exactly* like I do for all
preexisting windows, I get nothing. I also added in error checking code,
but it is not reporting any errors, so I don't know why I don't get events
from newly created windows.

My event loop (create_notify part) looks like this:
                case XCB_CREATE_NOTIFY:
                {
                    printf("Window Created:
%X\n",((xcb_create_notify_event_t*)e)->window);


select_window(((xcb_create_notify_event_t*)e)->window,XCB_EVENT_MASK_POINTER_MOTION
| XCB_EVENT_MASK_KEY_PRESS);
                    xcb_flush(conn);

                    break;
                }


and select_window() looks like this:
static void select_window(xcb_window_t win, uint32_t mask)
{
    value[0]=mask;
    xcb_void_cookie_t cwa_cookie =
xcb_change_window_attributes(conn,win,XCB_CW_EVENT_MASK, value);

    xcb_generic_error_t *error = xcb_request_check(conn, cwa_cookie);

    if (error)
    {
        printf("error: %i on %d\n", error->error_code,win);
        exit(EXIT_FAILURE);
    }
}


Anybody know whats going on here?

Thanks!
--Philip Rushik


On Fri, Mar 7, 2014 at 12:01 PM, Philip Rushik <prushik at gmail.com> wrote:

>
>
>
> On Fri, Mar 7, 2014 at 5:03 AM, Jochen Keil <jochen.keil at gmail.com> wrote:
>
>>
>> `xcb_change_attributes` produces an XCB_ACCESS error. You can find out
>> about this by either calling the `xcb_change_attributes_checked` variant
>> and using the `xcb_request_check` function or checking for an error in
>> the event loop (both flavors are demonstrated in the attached program).
>>
>
> Oops.... thats what I get for not checking for errors...
>
>
>>
>> The XCB_ACCESS error happens because you don't own any of those windows.
>> You'd need to set XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT on your root
>> window to do that. But in that case you are competing with your window
>> manager.
>>
>> I remember that I read about this some time ago and why XSelectInput
>> behaves differently, but I don't remember the details.
>>
>
> Well in light of new information and testing, I am no longer convinced
> they do behave differently. More info below.
>
>
>
> On Fri, Mar 7, 2014 at 5:22 AM, Rémi Denis-Courmont <remi at remlab.net>wrote:
> Le vendredi 7 mars 2014, 04:02:16 Philip Rushik a écrit :
>  > AFAIK the X protocol does not allow more than one X client to capture
> either
> > button or key events for a given window at a time. The first client to
> request
> > them gets them, further clients will get an error. If no client requests
> them
> > at all, they will be passed to the parent window automatically (and so
> on).
>
> > Note this does not apply to motion events, which any number of client can
> > follow.
>
> Wow, that explains a lot. Turns out in the Xlib version I was only
> requesting motion events. I changed my XCB code to only select motion
> events and now it seems to work the same as the XLib code, thank you!
>
> > Are you sure nobody else catches the events? Most GUI frameworks
> > systematically catch input events no matter what, so you cannot easily
> steal
> > input events from the window of other applications (except by grabbing).
>
> Well, I don't know for sure what happens behind the scenes in JWM, but
> when the XCB code runs, it no longer _responds_ to mouse clicks.
>
> > At protocol level and thus at XCB level, you should not even need to
> modify
> > the children windows mask anyway; you will inherit the events provided
> that no
> > other X clients request them. I think.
>
> I would rather not modify other windows, but I want to be able to
> determine if there is any activity on the computer while the program is
> running.
>
> I had a look at the XScreensaver source, which does basically what I want
> to do and I found that it does use XSelectInput for all windows, but ONLY
> for motion events and keypress events. There is a comment in the
> xscreensaver source noting this exact problem, their workaround is
> /proc/interrupts, which doesn't work on all systems, so on some systems,
> clicking and scrolling isn't counted as activity.
> This is probably good enough for me, I can just ignore buttons since I
> think its very rare for a human to ONLY click without moving the mouse
> while using a computer, wouldn't be getting much of anything done.
>
> Thanks for the information, I have at least a starting point now.
>
> Regards,
> --Philip Rushik
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20140308/4e466775/attachment-0001.html>