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

Reply via email to