Re: [i3] Weird keybinding issue after suspend
If you want to be 100% sure, run `DISPLAY=:1 setxkbmap us; DISPLAY=:1 setxkbmap de; DISPLAY=:1 setxkbmap us`. If afterwards it still doesn’t work, chances are very high that it is NOT an i3 bug. See xinput(1) for your input devices. On Wed, Nov 11, 2015 at 2:55 AM, Benjamin Kaiser wrote: > Okay I tried with `DISPLAY=:1 setxkbmap us` (wasn't 100% if us was what I > wanted, it didn't print an error when I ran it) and then changed back to > TTY2 (where i3 was loaded) and the keyboard was still unresponsive. > > And yes I meant DISPLAY, that's what I typed, I just copied it out wrong > in the email. > > What commands can I run to list all input devices? Maybe that might help > investigate things. > Do you have any other ideas what could be causing it? > > Thanks again for your help! > > On Mon, 9 Nov 2015 at 03:48 Michael Stapelberg wrote: > >> 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 >>> 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 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
Re: [i3] Weird keybinding issue after suspend
Okay I tried with `DISPLAY=:1 setxkbmap us` (wasn't 100% if us was what I wanted, it didn't print an error when I ran it) and then changed back to TTY2 (where i3 was loaded) and the keyboard was still unresponsive. And yes I meant DISPLAY, that's what I typed, I just copied it out wrong in the email. What commands can I run to list all input devices? Maybe that might help investigate things. Do you have any other ideas what could be causing it? Thanks again for your help! On Mon, 9 Nov 2015 at 03:48 Michael Stapelberg wrote: > On Sun, Nov 8, 2015 at 6:01 AM, Benjamin Kaiser > 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 >> 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 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 commen
Re: [i3] Weird keybinding issue after suspend
On Sun, Nov 8, 2015 at 6:01 AM, Benjamin Kaiser 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 > 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 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 key
Re: [i3] Weird keybinding issue after suspend
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`: 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 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 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 >> >
Re: [i3] Weird keybinding issue after suspend
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 >
Re: [i3] Weird keybinding issue after suspend
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
