On Sun, Nov 8, 2015 at 6:01 AM, Benjamin Kaiser <benjaminjkai...@gmail.com> wrote:
> 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) > I meant using e.g. “setxkbmap de” to set the keyboard layout. Also, I think you meant DISPLAY. > - 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`: http://p.nnev.de/7524 > > 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. > > Cheers, > Ben Kaiser > > On Mon, 2 Nov 2015 at 20:54 Benjamin Kaiser <benjaminjkai...@gmail.com> > wrote: > >> 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 <mich...@i3wm.org> 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 >>> >> -- Best regards, Michael
