Home/ Questions/Q 1108879
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T02:08:58+00:00

Consider an application where it’s desirable to grab the keyboard when focused in order

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0