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 <benjaminjkai...@gmail.com> 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 <mich...@i3wm.org> 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 <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 >> > -- Best regards, Michael
