Have keyboard events "bypass" grabbed pointer

Peter Hutterer peter.hutterer at who-t.net
Wed Feb 15 23:27:32 UTC 2017

On Wed, Feb 15, 2017 at 02:58:02PM +0100, Lukas Barth wrote:
> Hi,
> On 14.02.2017 20:52, Thomas Lübking wrote:
> > grab synchronously and conditionally xcb_allow_events (for acceptable keys)
> That sounds like what I'm trying to do! However, after some playing around,
> I can't seem to make it work. The way I understand it, the workflow is this:
> 1) call xcb_grab_keyboard(…, …, …, …, XCB_GRAB_MODE_SYNC,
> XCB_GRAB_MODE_SYNC) [0] - the keyboard is now grabbed synchronously (instead
> of ansynchronously, as the locker did before)
> 2) when xcb_poll_for_event() gives me a new keyboard-event, call
> xcb_allow_events() after processing the event. If I want the event to
> propagate, call it with XCB_ALLOW_REPLAY_KEYBOARD, otherwise call it with
> However, XCB_ALLOW_REPLAY_KEYBOARD seems to also permanently release the
> keyboard grab (is that right? The documentation is a bit sparse…). I tried
> calling xcb_grab_keyboard() directly after xcb_allow_events(…,
> XCB_ALLOW_REPLAY_KEYBOARD, …), but that does not seem to work either. In any
> case, once I called xcb_allow_events(…, XCB_ALLOW_REPLAY_KEYBOARD, …), *all*
> keyboard events from that point on end up in my window manager…

find documentation for xlib, that's usually quite ok for these bits (or the
protocol directly). But yes, ReplayKeyboard ungrabs, so you have to
immediately grab the keyboard again.
> Thanks for the help so far!
> Lukas
> [0] Why do I have to specify the grab mode for the keyboard *and* the
> pointer in xcb_grab_keyboard? Shouldn't only the mode for the keyboard
> matter here?

History. For example, if you grab the pointer synchronously so you can
reshuffle windows on click, you don't want a keyboard event that occured
after that click to go to the previous window. You want it delayed so
you can handle it when the windows are in the new order, with the input
focus changed, etc. And if you're on a PDP-11 connected by carrier pigeons
to a dumb terminal, then this matters a lot more than now, but even now this
is still racy.


More information about the xorg mailing list