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 <
> benjaminjkai...@gmail.com> 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
>
