Excluding some keys from XGrabKeyboard

Question

Consider an application where it's desirable to grab the keyboard when focused in order to capture all window manager commands (Alt+F4 and whatnot) for processing. Now, this has the downside that the user has no way of switching to another application or virtual desktop via the keyboard when the keyboard is grabbed. I'd like to have a user-defined whitelist of key combination (say, the key combinations for switching virtual desktops) that are excluded from the grab.

I can think of two possible approaches. When a whitelisted key event arrives, either

1. Somehow tell X to continue processing it as usual. This sounds like a more natural way of doing it but I can't find a way to do this, or
2. Ungrab the keyboard and re-send the event by hand to the window manager for processing, however I don't know where to send it (the root window?) or whether that would even work.

Can anyone fill in the blanks on those? Any other suggestions?

If there's no way to exclude keys from a grab, I guess I'll have to settle for having an "escape key" that ungrabs the keyboard when pressed. The user'll have to press both that and then the window manager command, though, which isn't as nice.

Garlicky

Answer 1

I don't think there's a way to do it. None of the mechanisms work quite how you would need them to.

Approach 1 is sort of what the window manager does if it decides not to intercept a click or key for example. However, the WM is using "passive" grabs on particular keys (XGrabKey=passive XGrabKeyboard=active) and then XAllowEvents(). XAllowEvents() does not work with XGrabKeyboard(). also, when you XAllowEvents with one of the Replay modes, the replayed event bypasses all passive grabs on the window that had the original grab and on all its parent windows. The WM's grabs will be on the root window which will always be a parent so there is no way to replay to the root window, best I can tell. Doing XGrabKey on every possible key would be sort of psycho anyhow.

Approach 2 would have bad race condition problems, because other key and mouse events could be processed before you could resend, so you'd reorder keys and send events to destroyed windows and other confusion. Also, there is no good way to send a key event. XSendEvent() is ignored by many clients (it sets a send_event flag in the event allowing this). XTest extension can be used but may be disabled on production X servers and still has race condition issues.

What you probably would need is a protocol extension that let you do an AllowEvents(mode=ReplayKeyboard) after a GrabKeyboard and without bypassing passive grabs on parent windows.

One caveat is that I don't know all the wild stuff that can be done with XKB and XInput2, so maybe there's something in those extensions.

Anyway, as far as I know you have to settle for the "escape key," though it might be nice eventually for the X server and/or the window manager specs to have "VMWare/VNC-type-thing awareness," that won't help you in the short term. An EWMH spec extension could be as simple as a new _NET_WM_WINDOW_TYPE for vnc/vmware/stuff-like-that and the window manager could reduce its keybindings or add an extra modifier to them or something when that window was focused, for example.

Hunsinger

I was afraid I was going to get an answer like this. I'm sure I would've seen a software that does this if it's possible. However, thanks for pointing me towards XInput 2, I'm looking at it right now and it does seem to have new ways of grabbing input devices. Going to run some tests to see if it makes this possible – Garlicky

It turned out something like this is "possibly scheduled for XI2.1", which doesn't even seem to exist yet according to Google. New WM hints don't sound like a bad idea, however, so I started some discussion on the freedesktop.org wm-spec list. mail.gnome.org/archives/wm-spec-list/2010-September/thread.html – Garlicky

Answer 2

I ran into the same problem when I wanted to grab the keyboard for a screenshot program but leave the PageUp PageDown keys to scroll the screen. I ended up with an extreme and ugly solution:

1. When the desired key is detected, XUngrab all devices and XCloseDisplay.
2. Emit the key as usual (in my case using libxdo, the xdotool library).
3. Initialize from XOpenDisplay all over again. This has to include all function calls that involved the display: root window, cursors, colors, etc.

There seems to be no other ways to solve the problem...

Violone