<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 7, 2014 at 5:03 AM, Jochen Keil <span dir="ltr"><<a href="mailto:jochen.keil@gmail.com" target="_blank">jochen.keil@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
<br>
</div>`xcb_change_attributes` produces an XCB_ACCESS error. You can find out<br>
about this by either calling the `xcb_change_attributes_checked` variant<br>
and using the `xcb_request_check` function or checking for an error in<br>
the event loop (both flavors are demonstrated in the attached program).<br></blockquote><div><br></div><div>Oops.... thats what I get for not checking for errors...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The XCB_ACCESS error happens because you don't own any of those windows.<br>
You'd need to set XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT on your root<br>
window to do that. But in that case you are competing with your window<br>
manager.<br>
<br>
I remember that I read about this some time ago and why XSelectInput<br>
behaves differently, but I don't remember the details.<br></blockquote><div><br></div><div>Well in light of new information and testing, I am no longer convinced they do behave differently. More info below.<br><br><br>
On Fri, Mar 7, 2014 at 5:22 AM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:<br>Le vendredi 7 mars 2014, 04:02:16 Philip Rushik a écrit :<br>
> AFAIK the X protocol does not allow more than one X client to capture either<br>
> button or key events for a given window at a time. The first client to request<br>
> them gets them, further clients will get an error. If no client requests them<br>
> at all, they will be passed to the parent window automatically (and so on).<br>
<br>
> Note this does not apply to motion events, which any number of client can<br>
> follow.<br>
<div class=""><br></div><div class="">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!<br>
</div><div class=""><br>
</div>> Are you sure nobody else catches the events? Most GUI frameworks<br>
> systematically catch input events no matter what, so you cannot easily steal<br>
> input events from the window of other applications (except by grabbing).<br>
<div class=""><br></div><div class="">
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.<br><br>
</div>> At protocol level and thus at XCB level, you should not even need to modify<br>
> the children windows mask anyway; you will inherit the events provided that no<br>> other X clients request them. I think.<br>
<span class=""><font color="#888888"><br></font></span></div><div>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.<br><br>
</div><div>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.<br>
</div><div>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.<br>
</div><div><br></div><div>Thanks for the information, I have at least a starting point now.<br><br></div><div>Regards,<br></div><div>--Philip Rushik<br></div><div><br></div></div><br></div></div>