Steps to reproduce:
1. Force the branch to be taken:
diff --git a/src/bindings.c b/src/bindings.c
index fe77bc8f..caa5848c 100644
--- a/src/bindings.c
+++ b/src/bindings.c
@@ -941,7 +941,7 @@ bool load_keymap(void) {
struct xkb_keymap *new_keymap = NULL;
int32_t device_id;
- if (xkb_supported && (device_id = xkb_x11_get_core_keyboard_device_id(conn)) > -1) {
+ if (0) {
if ((new_keymap = xkb_x11_keymap_new_from_device(xkb_context, conn, device_id, 0)) == NULL) {
ELOG("xkb_x11_keymap_new_from_device failed\n");
return false;
2. Run `python2 ./xproperty.py _XKB_RULES_NAMES ''` (from
https://github.com/siemer/xproperty) in the xinitrc
3. Memory sanitizers detect memory leaks.
Note: We don't (and didn't) pass NULL in xkb_keymap_new_from_names() but
an xkb_rule_names structures with NULL fields (fill_rmlvo_from_root only
fills its argument when there are no errors) should be equivalent:
767fa86d42/NEWS (L349-L351)
> The function xkb_keymap_new_from_names() now accepts a NULL value for
the 'names' parameter, instead of failing. This is equivalent to passing
a 'struct xkb_rule_names' with all fields set to NULL.
Fixes#2535.
xkb_state_new uses calloc and may fail in a rare case, which would cause a memory leak.
Note that xkb_state_unref checks if the parameter given is not null (!state) before freeing.
Calls to xkb_state_new have been grouped to remove code duplication.
Signed-off-by: Elouan Martinet <exa@elou.world>
With example config:
mode "a_mode" {
bindcode 27 --release mode "default"
}
bindsym $mod+r mode "a_mode"
The first time $mod+r is pressed "a_mode" is activated like normal. When
r (bindcode 27) is pressed to exit the mode:
- On the KeyPress event the corresponding bind->release is correctly
marked as B_UPON_KEYRELEASE_IGNORE_MODS.
- On the KeyRelease event the command 'mode "default"' is executed but
bind->release is still B_UPON_KEYRELEASE_IGNORE_MODS since they are only
reset on KeyPress events.
The second time $mod+r is pressed and "a_mode" is activated and when the
r key is released the 'mode "default"' is executed even though the mods
are not matching since bind->release == B_UPON_KEYRELEASE_IGNORE_MODS.
This still doesn't catch 2 cases:
1. When the order is: press $mod -> press r -> release $mod -> release
r. Since 'r' is released without any modifiers the binding matches.
2. With:
mode "resize" {
bindsym --release r mode "default"
}
bindsym r mode "resize"
This is arguably correct: on the KeyPress event we switch to the mode and
on the KeyRelease we switch back.
Before this commit, get_binding() exited on the first match without
marking the rest --release bindings with B_UPON_KEYRELEASE_IGNORE_MODS.
Similarly, once it found a --release binding during a KeyPress event it
would stop searching for a matching key press binding.
Example config, placing the --release line first will trigger the second
problem:
# i3 config file (v4)
bindsym Super_L exec notify-send "press"
# or
# bindcode 133 exec notify-send "press"
bindsym --release Super_L exec notify-send "release"
# or
# bindcode --release 133 exec notify-send "release"
Fixes#2733
From 548d74015c:
> 1. press $mod, press x, release x, release $mod
> 2. press $mod, press x, release $mod, release x
case (2.) didn't work, now it should be fixed.
Subset comparison was introduced with the rather large commit
bf3cd41b5d, but I now think we should use
equality.
In other words, the following key binding:
bindsym Mod4+x nop Mod4+x
previously would have been triggered when pressing Mod3+Mod4+x.
Strictly speaking, this is a change of behavior, but it breaks none of our
tests, and using equality instead of subset comparison enables more use-cases.
fixes#2002
This introduces the flag --exclude-titlebar for mouse bindings which
allows bindings like
bindsym --whole-window --border --exclude-titlebar button3 focus
fixes#2347
While defining the same mode usually wouldn't hurt and, in fact, the old behavior
allows to split the definition of a binding mode into several blocks, this
can lead to user errors where they accidentally define a mode twice and don't understand
why the mode behaves a certain way (this has been observed in real life :-)).
There's no good usecase for splitting a single binding mode into multiple blocks, thus
the new behavior is better.
fixes#2615
Before this commit, i3 only compared the user-specified modifiers and
incorrectly ignored the resolved modifiers (such as the numlock
fallback).
While at it, also fix the testcase which treated numlock as a momentary
modifier, whereas it really is a latched modifier.
fixes#2418
Previously, we always discarded the NumLock bit when looking up key
bindings for key press events, and we always grabbed every keycode with
and without the NumLock modifier.
With this commit, the NumLock bit is no longer discarded: since the
previous commit 3bd5e6e5c8 we can
correctly look up key bindings with/without the NumLock bit, as both
variants are stored in |keycodes_head|.
Further, before adding the NumLock fallback (resulting in grabbing the
keycode with the NumLock modifier), we now check whether the key has the
same meaning when NumLock is enabled. This correctly distinguishes the
KP_End vs. KP_1 case, i.e. one can now use the following key bindings:
# No longer accidentally triggered when pressing KP_1.
bindsym KP_End nop KP_End
# Properly distinguished now:
bindsym KP_End nop KP_End
bindsym Mod2+KP_1 nop KP_1
fixes#2346
This is a followup to #2049. While we had fixed that bug by only grabbing
buttons 4 and 5 if there is a whole-window binding for that button, this
did not consider buttons higher than 5 as found on many mice.
Therefore, we now ditch the special handling for scrollwheel buttons and
instead do the same for all buttons higher than 3.
fixes#2271
We don't actually need to grab the buttons to fix#2097, but doing so
will cause a freeze due to unreleased events.
We partially revert 6f12f02 which avoids the freeze, but doesn't break
functionality.
relates to #2097fixes#2168
Previously, mouse bindings could only be run when a window was present,
by using --whole-window. Such bindings would not work on empty
workspaces. However, this is a valid usecase for bindings like
bindsym $mod+button4 workspace prev
bindsym $mod+button5 workspace next
Hence, we need to grab the root window as well and run bindings on it.
fixes#2097
This reverts commit 9692c1498b.
That commit accidentally defaulted to group mask 1, but the default
should be to match any group mask, so that having multiple layouts
loaded at the same time works.
fixes#2062
With this patch, we only grab the scrollwheel buttons (4 and 5) when
managing a window if a whole window key binding exists for these buttons.
This allows both of these usecases:
- Bindings to scrollwheel buttons using --whole-window (see #1701).
- Scrolling in a window without focusing it if no such binding
exists (see #2049).
Furthermore, we drop all button grabs and regrab them after a config
reload in order to reevaluate the new bindings correctly.
fixes#2049
This introduces the flag "--pango" on the mode config directive to
explicitly enable pango markup for mode names. Not setting this will
cause the mode name to be rendered as is.
This fixes a regression in 4.11 where mode names containing characters
such as '<' would break user's configs as they didn't escape these
characters.
fixes#1992
1). See the issue #1926. For example, the second keybinding is not detected as a duplicate:
bindcode Mod4+24 sticky toggle
bindsym Mod4+q focus parent
2). To fix it, check duplicated bindings when translating the keysym to keycodes.
Reordering once (as we did it before this commit) would only sort the
bindings by the _first_ bit of their event_state_mask, but we need to
sort them by _all_ bits of their event_state_mask.
fixes#1870
