So the issue popped up again, these were the steps I did to debug it:

- jump to TTY3
- run: `DISAPLY=:1 setxkbmap | tee /tmp/setxkbmap.out` (not sure if I
should have been passing any arguments specifically)
- observe there was no output
- jump back to TTY2, keyboard/keybindings still unresponsive in i3
- jump back to TTY2
- run `DISAPLY=:1 xev | tee /tmp/xev.out` (output starts spewing out, and
also to the file)
- jump back to TTY2, keyboard is now responsive to i3wm bindings
- jump back to TTY3 and kill xev

Output in `/tmp/xev.out`:

Hope this helps with tracking down what could be causing this, as I still
don't have much of a clue how to fix it.

Ben Kaiser

On Mon, 2 Nov 2015 at 20:54 Benjamin Kaiser <>

> Thanks for the reply Michael,
> I had the issue happen again yesterday and ran `sudo
> libinput-debug-events`, then changed back to i3, run a bunch of shortcuts
> and pressed a bunch of keys (all of which did nothing) then changed back to
> the tty only to see that it was registering those keys being pressed.
> I'll try running `setxkbmap` and `xev` from a TTY next time the issue
> occurs to see if it fixes it / gives me any more information.
> Also another small thing I noticed. To get out of the situation I click
> the workspaces, but the keyboard only works if I click a different
> workspace the the one I am currently in, it doesn't do anything (keyboard
> still won't register shortcuts) if I click the current workspace.
> modified my i3config to that (i3lock then systemctl suspend), I think it
> was that at some point and the issue still occurred, but I'll try it out
> let you know if the issue happens again.
> Cheers,
> Ben Kaiser
> On Mon, 2 Nov 2015 at 19:00 Michael Stapelberg <> wrote:
>> When this situation happens:
>> 1. Does running xev(1) still show keyboard events?
>> 2. Does using setxkbmap to set your layout make the problem go away? That
>> should force i3 to re-grab all keys.
>> On Fri, Oct 30, 2015 at 12:38 PM, Benjamin Kaiser <
>>> wrote:
>>> Hello,
>>> I've got a really weird issue that's been bothering me for perhaps the
>>> last 6 months (before then it worked fine, perhaps could have been around
>>> when I switched to using my keyboard to suspend). Sometimes when I resume
>>> from suspend (I have i3lock launching at the same time as when I suspend) I
>>> can unlock my computer, but then no more keyboard events work. The keyboard
>>> remains active (lights on) and I can switch to a TTY, but none of the i3
>>> events fire. The only way I can fix it is to use the mouse (which is still
>>> working) to click on a workspace in the statusbar and then the keyboard
>>> responds again.
>>>  As mentioned above, it only happens sometimes, and as a fellow dev it
>>> really annoys me to no end when something is unreproducible. Things I have
>>> tried to reproduce are just suspending, then detaching my keyboard and
>>> attaching it again before resuming from suspend, but that doesn't trigger
>>> the issue. Just about the only common thing I can find is time (after being
>>> suspended for a long time, 12hours+, it seems to happen more frequently).
>>> One idea I've had is that because I use a keyboard shortcut to suspend
>>> (`bindsym --release $mod+Control+Shift+s exec "systemctl suspend; i3lock"`
>>> in my config, the --
>> nit: you should i3lock first, then suspend. That way, your screen is
>> guaranteed to be locked in a race-free way when you resume. “i3lock &&
>> systemctl” suspend should work.
>>> release was me weeks ago trying to rectify the issue, but it still
>>> persisted) i3wm is somehow holding onto the keyboard before flushing, but
>>> then post-suspend, i3lock takes the keyboards focus, i3wm holds onto an old
>>> un-flushed pointer to the keyboard (not sure if that is how that works) and
>>> doesn't refresh it upon i3lock giving up focus.
>>> From searching around in the i3 source code, seeing the line in
>>> main.c:main() with the comment annotation
>>>     /* Grab the keyboard to get all input */
>>>     xcb_flush(conn);
>>> And that function also occuring in click.c:route_click() (i.e. when I
>>> click the workspaces in the status bar)
>>>     xcb_flush(conn);
>>> Maybe this is what is allowing the keyboard to work again. Is there some
>>> way this could be run upon i3lock giving up focus / i3wm resuming focus?
>>> Any help in solving this would be much appreciated!
>>> Here is some information about my system:
>>> Mouse: Razer Naga, (one with 12 buttons on side)
>>> Keyboard: ducky shine 3 with mini usb cable for connection (issue has
>>> occurred on my laptops internal keyboard also though)
>>> Distro: Arch Linux
>>> i3 Version: 4.11
>>> Kernel version: 4.2.3-1-ARCH
>>> Cheers,
>>> Ben Kaiser
>> --
>> Best regards,
>> Michael

Reply via email to