bindings: Do not grab pointer when executing bindings #5755
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Grabing the pointer produces a `GrabFrozen` error in applications that are run from key bindings. Since we don't need the pointer in such cases, we can change the call to use ASYNC. This seems to be a historical leftover. I've tested locally that these still work: - bindsym $mod+x ... - bindsym --release $mod+x ... - bindsym $mod+button1 ... - bindsym --release $mod+button1 ... - bindsym --release $mod+x exec program that grabs the keyboard now works (see original issue) Even in the main branch, I actually couldn't get `import` and `xdotool` to fail with the pointer being frozen, potentially because these programs wait a bit for the pointer to be unfrozen like i3lock does. This patch came up in i3#5735 (comment) I wonder why the pointer is actually grabbed. The argument I change in `xcb_grab_key` there, is `pointer_mode`, from https://www.x.org/releases/X11R7.7/doc/man/man3/xcb_grab_key.3.xhtml: ``` pointer_mode One of the following values: XCB_GRAB_MODE_SYNC The state of the keyboard appears to freeze: No further keyboard events are generated by the server until the grabbing client issues a releasing AllowEvents request or until the keyboard grab is released. XCB_GRAB_MODE_ASYNC Keyboard event processing continues normally. ``` I traced via `git blame` the usage of `xcb_grab_key` throughout 14 years of i3 development and it seems that `pointer_mode` was always set to `XCB_GRAB_MODE_SYNC`, going all the way back to b664456. Fixes i3#5735
|
CC @MikuChan03 |
|
Thank! |
stapelberg
approved these changes
Nov 5, 2023
desmana
pushed a commit
to desmana/i3
that referenced
this pull request
Apr 3, 2024
Grabing the pointer produces a `GrabFrozen` error in applications that are run from key bindings. Since we don't need the pointer in such cases, we can change the call to use ASYNC. This seems to be a historical leftover. I've tested locally that these still work: - bindsym $mod+x ... - bindsym --release $mod+x ... - bindsym $mod+button1 ... - bindsym --release $mod+button1 ... - bindsym --release $mod+x exec program that grabs the keyboard now works (see original issue) Even in the main branch, I actually couldn't get `import` and `xdotool` to fail with the pointer being frozen, potentially because these programs wait a bit for the pointer to be unfrozen like i3lock does. This patch came up in i3#5735 (comment) I wonder why the pointer is actually grabbed. The argument I change in `xcb_grab_key` there, is `pointer_mode`, from https://www.x.org/releases/X11R7.7/doc/man/man3/xcb_grab_key.3.xhtml: ``` pointer_mode One of the following values: XCB_GRAB_MODE_SYNC The state of the keyboard appears to freeze: No further keyboard events are generated by the server until the grabbing client issues a releasing AllowEvents request or until the keyboard grab is released. XCB_GRAB_MODE_ASYNC Keyboard event processing continues normally. ``` I traced via `git blame` the usage of `xcb_grab_key` throughout 14 years of i3 development and it seems that `pointer_mode` was always set to `XCB_GRAB_MODE_SYNC`, going all the way back to b664456. Fixes i3#5735
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Grabing the pointer produces a
GrabFrozenerror in applications that are run from key bindings. Since we don't need the pointer in such cases, we can change the call to use ASYNC. This seems to be a historical leftover.I've tested locally that these still work:
Even in the main branch, I actually couldn't get
importandxdotoolto fail with the pointer being frozen, potentially because these programs wait a bit for the pointer to be unfrozen like i3lock does.This patch came up in
#5735 (comment)
I wonder why the pointer is actually grabbed.
The argument I change in
xcb_grab_keythere, ispointer_mode, from https://www.x.org/releases/X11R7.7/doc/man/man3/xcb_grab_key.3.xhtml:I traced via
git blamethe usage ofxcb_grab_keythroughout 14 years of i3 development and it seems thatpointer_modewas always set toXCB_GRAB_MODE_SYNC, going all the way back tob664456.
Fixes #5735