[SOLVED] I3wm keybinds completely stopped working

Bepis · 2024-01-29 06:31:18

Hi all, hope your head doesn't hurt as much as mine!

So here's the thing, I tried switching to LightDM (currently on SDDM) but I ended up undoing the changes after realizing it wasn't really worth the effort IMO.
All I did was install it with a greeter, and enabling its service and disabling SDDM. It worked, but I switched back anyway.

That's pretty much when it started, at first the keybinds wouldn't work when logging in, but reloading i3 would fix it until the next reboot. But now the keybinds I have set in ~/.config/i3/config simply don't work and I feel like I've just been running in circles for about three hours now. I can confirm that the file is actually read by I3 since some processes that should start when I log in do it as expected (started from the same script the keybinds are in).
xmodmap shows the same normal mod keys that should be sent to i3:

$ xmodmap
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_L (0xcc),  Meta_L (0xcd)
mod2        XF86WWAN (0x4d)
mod3        ISO_Level5_Shift (0xcb)
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c)

I have already uninstalled LightDM and I'm pretty sure all the installed packages are now the same as they were before the incident, apart from an update for the linux kernel, but I'm on linux-hardened and have tried switching back to linux to see if it did anything (spoiler: it didn't).

So far I didn't see anything in dmesg, couldn't find anything in Xorg's log file or error.log that seemed to be linked to the issue (even when following it and reloading/restarting i3). Tried "reinstalling" i3:

pacman -S i3-wm --overwrite "*"

I really don't know what else to try, it's 1:30 AM and I'm dying out here... Any help is greatly appreciated!

$ uname -a
Linux Bepis-Laptop 6.7.2-hardened1-1-hardened #1 SMP PREEMPT_DYNAMIC Sun, 28 Jan 2024 03:21:03 +0000 x86_64 GNU/Linux

Last edited by Bepis (2024-02-19 01:30:45)

Bepis · 2024-01-29 07:02:20

Also, I just realized that the key modifiers aren't the only ones i3 can't detect, even the volume wheel on my headset which does send XF86AudioRaiseVolume and XF86AudioLowerVolume are completely ignored by i3, and I did set those keybinds there too.
I will also mention that i3 is the only one having trouble, kitty's keybinds work just fine.

seth · 2024-01-29 07:59:43

xev -event keyboard

for a desired key/shortcut.
Also post your i3 config (notably in case that just posts KeymapNotify events.

i3 is the only one having trouble, kitty's keybinds work just fine

Multilayout?

setxkbmap -print -query

Bepis · 2024-01-29 16:39:03

Hi seth,

The shortcuts seem to be working fine outside of i3, here is an example of me trying to open a terminal (Super_L+Return):

KeyPress event, serial 28, synthetic NO, window 0x1c00001,
    root 0x28e, subw 0x0, time 111436, (256,577), root:(981,865),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x1c00001,
    root 0x28e, subw 0x0, time 111573, (256,577), root:(981,865),
    state 0x50, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
"   XmbLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x1c00001,
    root 0x28e, subw 0x0, time 111675, (256,577), root:(981,865),
    state 0x50, keycode 36 (keysym 0xff0d, Return), same_screen YES,
"   XLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x1c00001,
    root 0x28e, subw 0x0, time 111896, (256,577), root:(981,865),
    state 0x50, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Here is my i3 config. I have separated it into 3 files, the other two are included at the top of the main config file.

i3/config: https://pastebin.com/wC0G9edp
i3/keybinds: https://pastebin.com/0Bwqz68F
i3/startup: https://pastebin.com/ZseSCNQe

I have confirmed through testing that the keybinds file is indeed included in the config, I tried adding a simple line executing Kitty and restarting i3 and it worked, but the keybinds seem to be completely ignored.

As for your last request:

$ setxkbmap -print -query
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+ca+inet(evdev)+terminate(ctrl_alt_bksp)"	};
	xkb_geometry  { include "pc(pc105)"	};
};
rules:      evdev
model:      pc105
layout:     ca
options:    terminate:ctrl_alt_bksp

seth · 2024-01-29 16:51:39

"exec_always --no-startup-id xmodmap ~/.Xmodmap" is a pot. issue dep. on what's in that modmap.
Notably

mod2        XF86WWAN (0x4d)

is sketchy becaus you've the numlock state in xev.

The shortcut isn't grabbed by anything (incl. i3) in the xevent output, despite

bindsym Mod4+Return exec kitty ; split toggle
bindsym Super_L+Return exec kitty ; split toggle

is only that shortcut affected? (it's the only one where you try to chain commands w/ a semicolon)

Bepis · 2024-01-29 16:58:32

[UPDATE]

I have no idea why that is, but I removed .Xmodmap from the configuration, and now everything seems to work fine?
I should have included it in the previous config, sorry about that:

$ cat .Xmodmap.bak 
keycode 90=0
keycode 87=1
keycode 88=2 
keycode 89=3
keycode 83=4
keycode 84=5
keycode 85=6
keycode 79=7
keycode 80=8
keycode 81=9
keycode 77=XF86WWAN
keycode 135=Super_L

Keycodes 79-90 are just my lazy way of forcing numlock, effectively disabling the numlock key (I use the numpad to navigate through workspaces and it kept going back to its other mode).
Keycode 77 is assigning the numlock key to a keycode I never use, so that it doesn't change every time I press it like numlock usually does.
I'm not sure why keycode 135 is there though, and this one seems to be causing all of my issues... I tested rebooting and executing all lines except for this one and the keybinds are all back!

I really have no idea why that is though, how can this xmodmap keycode kill all shortcuts for i3 specifically, even the keybinds that don't even contain Super_L?
Even a keybind that just toggle my monitor's backlight stopped working (Ctrl+#), but is back to normal now that I have removed this line... I'm so confused hahah

Bepis · 2024-01-29 17:12:20

Hi, sorry I missed your last message as I was writing an update.

bindsym Super_L+Return exec kitty ; split toggle

is a line I added to try and figure this out, and forgot to remove.
This (and the one above it) are the only ones with chained commands. It just makes it so that if I were to open multiple terminals, they don't all open side to side, but rather alternate between to the right and below.

Also, I just did some testing and you were right, it is actually XF86WWAN that causes everything to break... Super_L is fine in the end.
I still don't get why this happens, it always worked fine but suddenly it decided to break everything.

Thanks so much for your help!

seth · 2024-01-29 21:08:26

The problem is that numlock is a modifer like Alt but it's either on or off almost all the time and generally considered irrelevant to the actual shortcut.
So shortcut daemons typically grab every combination twice, once w/ and once w/o the numlock modifier.
You've the numlock active but apparently i3 wasn't able to grab that combination, either because it could not resolve the modifier or because it changed after the fact.
Either way this is most likely a race condition.

The general advice, regardless of any of this, would be to setup your keyboard *before* you start *any* process in your session, so they enter a set world.
Eg. run xmodmap in your xinitrc (and don't fork it!)

That being said, I'm not sure whether i3 will be happy w/ no numlock key/modifier available anymore.
If running xmodmap before i3 doesn't work, you'd then try to run only the numlock mapping after i3 has initialized (eg. w/ a scheduled subshell)

…
xmodmap ~/.Xmodmap
…
(sleep 10; xmodmap -e 'keycode 77=XF86WWAN') & # only run 10s after i3 started
exec i3

Bepis · 2024-01-30 20:10:01

Well I think I'll just drop the keycode replacement entirely, wouldn't want something like this to randomly happen again lol
Anyway thanks so much for your help seth, take care out there!

seth · 2024-01-30 20:53:23

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2024-01-29 06:31:18

[SOLVED] I3wm keybinds completely stopped working

#2 2024-01-29 07:02:20

Re: [SOLVED] I3wm keybinds completely stopped working

#3 2024-01-29 07:59:43

Re: [SOLVED] I3wm keybinds completely stopped working

#4 2024-01-29 16:39:03

Re: [SOLVED] I3wm keybinds completely stopped working

#5 2024-01-29 16:51:39

Re: [SOLVED] I3wm keybinds completely stopped working

#6 2024-01-29 16:58:32

Re: [SOLVED] I3wm keybinds completely stopped working

#7 2024-01-29 17:12:20

Re: [SOLVED] I3wm keybinds completely stopped working

#8 2024-01-29 21:08:26

Re: [SOLVED] I3wm keybinds completely stopped working

#9 2024-01-30 20:10:01

Re: [SOLVED] I3wm keybinds completely stopped working

#10 2024-01-30 20:53:23

Re: [SOLVED] I3wm keybinds completely stopped working

Board footer