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

Reply via email to