[Xcb] xcb_change_window_attributes vs. XSelectInput

[Philip Rushik]

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/20140307/28ff820e/attachment.html>