Alright after 10 days I can tell you that I haven't seen that problem again, and it is completely fixed.

from xkeysnail.

@rbreaves I've been getting a similar issue! I finally was able to reproduce the problem.
I use xkeysnail with the kinto project.
I think these are the relevant lines in my config:

define_conditional_modmap(lambda wm_class: wm_class.casefold() not in terminals,{
    Key.LEFT_ALT: Key.RIGHT_CTRL,   # WinMac
    Key.LEFT_CTRL: Key.LEFT_META,   # WinMac
    Key.RIGHT_ALT: Key.RIGHT_CTRL,  # WinMac
    Key.RIGHT_CTRL: Key.RIGHT_META, # WinMac
})

define_conditional_modmap(re.compile(termStr, re.IGNORECASE), {
    Key.LEFT_ALT: Key.RIGHT_CTRL,   # WinMac
    Key.LEFT_CTRL: Key.LEFT_CTRL,   # WinMac
    Key.RIGHT_CTRL: Key.LEFT_CTRL,  # WinMac
})

Steps to reproduce bug, on standard windows keyboard (When I say x key is clicked, I'm referring to the physical keyboard):

1. Open a terminal
2. Exit terminal by pressing the left ctrl + d. KEEP HOLDING left ctrl
3. While holding left ctrl hold down left meta key (windows key for my keyboard)
4. Let go of all keys. The ctrl key is now stuck. If you go to firefox, and press t, a new tab will open

To "release" the ctrl key when it is stuck:

1. Open a terminal
2. Press the left ctrl key once
3. key is no longer stuck!

I'm glad I stumbled upon this 😅. I've been trying to find what caused it, and finally discovered one way to reproduce the bug. I'm not sure if there are other ways to hit this case.

Although I have no idea what causes this, or how the heck to fix it. My guess is that it has to do something with the left ctrl key no longer being the left ctrl key when the terminal is exited.

from xkeysnail.

So I've been trying it for several hours and up to know it's worked. I'm pretty sure that it had to do with my config file looking like this:

[Global modemap] Change modifier keys as in xmodmap

define_modmap({
Key.CAPSLOCK: Key.LEFT_CTRL
})

[Conditional modmap] Change modifier keys in certain applications

define_conditional_modmap(re.compile(r'Emacs'), {
Key.RIGHT_CTRL: Key.ESC,
})

What that lead to is me moving to my right desktop, using emacs and that being taken as a CAPS LOCK that also doubles as a ctrl key at the KDE level (I think, need to double check that), and perhaps that made it believe it was a caps lock key after I left emacs and it would get stuck.

Not sure if this made sense but at least after 4 hours it hasn't gotten stuck.

If emacs hadn't been in that desktop the ctrl key would not have gotten stuck.

Does that make sense?

from xkeysnail.

@binamkayastha Thank you for that, the detailed steps on how to reproduce it. I still need to revisit this.. I just have a higher priority atm -.-. As soon as I can refocus on this I will though and before I tackle other items/features on the Kinto project, as most of them are not as important as fixing this & possibly similar issues.

I am sadly dog fooding Kinto's Autohotkey in Windows 10 a bit more atm, but I may see how DEs run under WSL so I can continue testing both. (Virtual machines are kinda heavy unless I have a real reason to be inside of one) Also if I change my primary laptop away from a macbook then I will be using Linux by default and Windows 10 in VM or a dual boot partition.

from xkeysnail.

@joshgoebel Wow this is an old issue!
I just tried reproducing this issue and couldn't 🤷. Kinto has been super stable and smooth for a while!
I'm not exactly sure when it stopped being a problem since it was sort of transient. It's been so long I'm not sure if it was because of a config change or if I did an update at some point.
I'm currently on xkeysnail 0.3.0 (retrieved from xkeysnail -v). Unfortunately I do not know what version I was on back when I could reproduce the issue.

Unlike @masutaka, I do have define_conditional_modmap in my current config, and yet I have no issues.

Sorry I couldn't be much help 😬, transient issues that only effect a small userbase are the worst.

from xkeysnail.

This comment has me a little nervous, I just redid how the modifier keys get released in my own fork, but I assume there is more likelihood of a stuck modifier key occurring than less, but I needed the modifiers to hold more akin to the original modifier being held down and not release immediately.

You're welcomed to try out my fork though and see if it is any more reliable/stable. https://github.com/rbreaves/xkeysnail

If it is a specific key remap causing the issue then I do not mind taking a look at that too.

from xkeysnail.

Thanks for this. I will give it a try (although I haven't actually come across the problem that you mention in #70, e.g., Alt in Alt+Tab keeps being pressed until I release Alt).

Regarding the stuck Control key. I don't think it's from my keymap. But I have not been able to reliably reproduce the bug. In fact, I haven't experienced it in the last week or so. The problem is that when the bug happens, I have no recourse but to kill the process from tty so I can't really troubleshoot it.

from xkeysnail.

@haji-ali The issue comes from trying to remap something like Ctrl-Tab → Alt-Tab, Alt-Tab → Ctrl-Tab or Super-Tab → Alt-Tab.

Of course if you do not have a current remap set for that combo it will continue to work as expected, but the default behavior of xkeysnail is definitely set to only emit a combo briefly and then let up on the modifier keys. It isn't surprising to be honest, autohotkey on Windows has the same behavior, but there is a a specific AltTab function you can reference that will allow it to keep the proper behavior.

from xkeysnail.

I have this exact same problem. I'm 100% sure it's xkeysnail as I run it manually from the command line, and it happens a lot. Whenever i close xkeysnail with just a c on the command line everything goes back to normal. My alt tab is the same, I haven't changed it. But I'm running a patched version of xorg server that lets me use alt shift tab on release instead of on keydown (since I also use alt shift to change language and those shortcuts interfere).

https://aur.archlinux.org/packages/xorg-server-bug865/

Do you think that might be related to the problem?

from xkeysnail.

@ddshore Which version are you on? When this ticket was first created my changes to the modifiers had not yet been merged and like I mentioned earlier in the thread you are welcome to try the latest in my fork to see if it resolves the issue.

https://github.com/rbreaves/xkeysnail

from xkeysnail.

Hey,

I've been running tests on your fork and on the original one, both have the same problem. I can reproduce it at will now, and my have a temporary fix:

I have multiple desktops, and I switch with Ctrl + Alt + → and Ctrl + Alt + ←.

If emacs is on the other desktop:
With the mooz version, if I switch to the right it will rarely get stuck, but if I switch to the left it will always get stuck. For some reason with yours it seems to work the other way around.

If I do Ctrl + Alt + ↑ or ↓ to switch to the other desktops it never gets stuck.

It seems to happen more when emacs is on the other virtual desktop but it also happens after a while is emacs isn't in that desktop.

My caps lock key doubles as a 2nd control key, and if I use my normal ctrl key it doesn't happen as often. Emacs detects my caps lock key as a caps lock key:

WM_CLASS 'Emacs' | active keymaps = []
LM-CAPSLOCK

All I had to do was add:
Key.CAPSLOCK: Key.LEFT_CTRL to my config file under emacs. I'll keep testing to see if that fixes it, but initially it at least reduced it.

from xkeysnail.

I actually need to move the last 2 commits in my fork's master branch into a separate branch - they did fix some issues for some users here, but it also broke some other functionality - trying to recall what exactly - I think it had to do with me remapping Super-Tab to Ctrl-Tab as a held modifier, but it would no longer appear to be held maybe?

Regardless I am not sure I have time to fix it right away. I have a few other priorities at the moment before I can really sit down and tackle this one again. I don't want to be breaking any existing functionality that any of you guys rely on, but I'd also like the hotkeys to behave in the same manner in which they are held - when it makes sense to do so, but it probably does need to be an optional argument or separate function (held vs emitting).

from xkeysnail.

@binamkayastha Could you please confirm this issue is only with kinto's xkeysnail and not with xkeysnail 0.4 mainline?

If we are seeing this with 0.4 mainline I wonder if it might be related to #150 with the buffer sometimes getting overwhelmed and dropping keys... if (RELEASE, Control) were dropped this is the behavior you would see (a stuck output key)... although in that case it would be easy to fix - just punch and release control again.

Your "how to fix steps" almost sounds like that but I'm not sure why it would require opening a terminal (or any new window)... unless kinto is holding keystrokes back... just pushing and releasing the ACTUAL control (as part of no sequence) should press and release that key on the output.

from xkeysnail.

Welp. Good news and bad news, I figured out what is going on but I don't have any idea how to fix it haha. Hopefully this debugging information will be useful 🤞

I had some trouble with kinto, so I switched to using xkeysnail directly and am having this issue again (I think I was using kinto's fork for xkeysnail before. I'm on exclusively xkeysnail 0.4.0 right now as I figure out what's wrong with my kinto setup - none of my keys were working though that's not related to this issue so I digress)

Now things make more sense - I have similar behavior to @masutaka with regards to define_conditional_modmap causing the problem

@joshgoebel After being able to reproduce this again and investigate, I think you're exactly right. My guess for the reason pressing the ctrl key again doesn't work is because on the default kinto config, the left ctrl key gets mapped to left meta, so I think there's no way for xkeysnail to "register" the left_ctrl key anymore?

# [Global modemap] Change modifier keys as in xmodmap
define_conditional_modmap(lambda wm_class: wm_class.casefold() not in terminals, {
    Key.CAPSLOCK: Key.ESC,
    # - Default Mac/Win
    # - Default Win
    Key.LEFT_ALT: Key.RIGHT_CTRL,   # WinMac  # Sortof workaround: CHANGE THIS TO LEFT_CTRL, so you can tap it if LEFT_CTRL gets stuck
    Key.LEFT_META: Key.LEFT_ALT,    # WinMac
    Key.LEFT_CTRL: Key.LEFT_META,   # WinMac
    Key.RIGHT_ALT: Key.RIGHT_CTRL,  # WinMac - Multi-language (Remove)
    Key.RIGHT_META: Key.RIGHT_ALT,  # WinMac - Multi-language (Remove)
    Key.RIGHT_CTRL: Key.RIGHT_META,  # WinMac - Multi-language (Remove)
})

# [Conditional modmap] Change modifier keys in certain applications
define_conditional_modmap(re.compile(termStr, re.IGNORECASE), {
    Key.CAPSLOCK: Key.ESC,
    # - Default Mac/Win
    # - Default Win
    Key.LEFT_ALT: Key.RIGHT_CTRL,   # WinMac
    Key.LEFT_META: Key.LEFT_ALT,    # WinMac
    Key.LEFT_CTRL: Key.LEFT_CTRL,   # WinMac
    Key.RIGHT_ALT: Key.RIGHT_CTRL,  # WinMac - Multi-language (Remove)
    Key.RIGHT_META: Key.RIGHT_ALT,  # WinMac - Multi-language (Remove)
    Key.RIGHT_CTRL: Key.LEFT_CTRL,  # WinMac - Multi-language (Remove)
})

This is what I think is happening:

• Terminal is open (left_ctrl -> left_ctrl mapping set)
• left_ctrl + d is DOWN PRESSED to exit the terminal
• Terminal exits and the user is not focused on a terminal window (left_ctrl -> left_meta mapping set)
• left_ctrl + d is LIFTED UP but is registered as left_meta (and so xkeysnails left_ctrl was never lifted up

Also it turns out that kinto's default config has it set so that the left_alt gets mapped to RIGHT_ctrl, and so the left_ctrl cannot be lifted even if you press left_alt again. So I've swapped it so I can tap the alt key when it gets stuck. Though it's still frustrating as it consistently happens when I close terminals with left_ctrl+d 😢

I don't know if this makes any sense but it feels like define_conditional_modmap should not change the mapping of any modifier key if it's on a down press until it's lifted up? or something along those lines

cc: @rbreaves you might find this interesting :)

from xkeysnail.

This is what I think is happening:

Looks reasonable at a glance. xkeysnail has nothing to prevent this chain of events, as keys are always re-mapped when pressed AND released so it's entirely possible to release a key using a different mapping than when you pressed it - which makes 0 sense.

My fork has long since fixed this issue: https://github.com/joshgoebel/keyszer

from xkeysnail.

I don't know if this makes any sense but it feels like define_conditional_modmap should not change the mapping of any modifier key if it's on a down press until it's lifted up? or something along those lines

I avoid emitting hotkeys and want held key behavior as that allows for the most natural interaction with the system in general. Regardless I plan to switch keyszer soon - so even if this is still an issue of some sort we'll see how things work on keyszer soon and as Josh states he's fixed the issue.

Also the way these remappers work is that they grab the raw uinput of the physical keyboard and then transforms it into another input device which the OS actually takes as the input instead. So cross talk type issues between input devices or loops of some kind really should not happen.

from xkeysnail.

I still get a stuck modifier once in a blue moon (but I haven't found the pattern) and I have a known bug with multipurpose mods that shouldn't be too hard to fix, just hasn't been a huge priority. I'm using the pipe key as the "right side" version of my Caps Lock HYPER key (but only when it's held)...

from xkeysnail.