mirror of
https://github.com/i3/i3.git
synced 2026-08-18 19:13:50 +00:00
next
This PR is a follow-up to the discussion in #6372 .
I'm not too familiar with the internals of X11, but it seems that sequence numbers are sometimes of type `uint16_t` and sometimes of type `unsigned int` or `uint32_t`. In some places XCB provides the field `full_sequence` (for example as part of `xcb_generic_event_t`), but other structs only have the 16-bit sequence. Then there is also `xcb_void_cookie_t` which has `unsigned int` for `sequence`.
The current code for tracking ignored events mixes these different data types. This works fine, as long as the sequence number doesn't overflow a `uint16_t`. Afterwards, the tracking of ignored events will fail. This appears to be the reason for #6372 and probably also #6364 . There is also the open PR https://github.com/i3/i3/pull/6559 which notes: "[...] add the sequence to the ignore list, but under some (unknown) circumstances, that does not seem to work reliably."
This problem already existed in 4.23 (and before), but only became visible in 4.24, because it seems that is was masked by using `XCB_GRAB_MODE_SYNC` when executing key bindings. This seems to mask the bug, but sending a command via `i3-msg` also triggers it in 4.23 . Commit b42dc21068 changed `XCB_GRAB_MODE_SYNC` to `XCB_GRAB_MODE_ASYNC` and surfaced the bug. Additionally, the commit https://github.com/i3/i3/commit/cfa4cf16 increased the number of messages being sent and sequence numbers being used, which triggers this bug more quickly than before.
The first commit in this PR introduces a test for #6372 . I found a more performant way of overflowing the uint16_t sequence number (using sync_with_i3 to create fairly cheap messages). The test runs in 1.3 seconds on my system.
The second commit fixes the problem. It defines a new data type `ignore_event_sequence_t` and a macro `ENSURE_FULL_SEQUENCE` which is then used at every call site for `add_ignore_event` and `event_is_ignored`. This way the compiler checks that a full sequence number is used everywhere. Perhaps this is over-engineered? Please let me know - I don't work much in C.
This change makes the test pass and also fixes #6372 for me in my manual testing.
Looking forward to feedback!
Disclosure of AI assistance: I used Claude Fable 5 and GPT-5.6 Sol as sparring partners, but everything here is hand-written.
i3: A tiling window manager
i3 is a tiling window manager for X11.
For more information about i3, please see the project's website and online documentation.
For information about contributing to i3, please see CONTRIBUTING.md.
Description
Languages
C
58.1%
Perl
36.4%
Raku
2.6%
Ruby
1.2%
Meson
0.7%
Other
1%