Alt/Super triggers other actions (wrongly) before combos are fired

[joshgoebel]

Example: You press the combo Super-A (which does who knows what) but as soon as you press Super your Desktop Environments menu or control center pops up (as it normally does on hitting Super).

What you desire: for Super to be ignored IF it's being used as part of a remapped combo.

---

Update 2022-06-14

The current BIG problem here: Suspending ("waiting and seeing") doesn't seem compatible with Cmd-click... (to say open a link in a new tab, etc) For example you hit Cmd - and we wait to see what you do next (without passing the key to ouput - which would create a unintended keypress) - but then you click the mouse - which we don't have access to at all. So now you get just a plain click instead of a Cmd-click.

Now it's easy to just let the keymapper proxy the mouse as well (listening to both)... in this case we see Cmd, we wait, we see click, and the keymapper understands your trying to Cmd-click and it does that. This also isn't 100% optimal because it breaks things like your existing mouse configuration (accel, speed, etc)... and requires setting those carefully on both the INPUT mouse and the OUTPUT mouse. I'm currently doing this with a script, but it's annoying.

The larger problem I don't see how this can work with trackpads #20. So unless I'm missing something it seems either someone has:

• no incorrect triggered keys, but cmd-click is broken
  • you have to hold down CMD a bit before you click
• you're stuck with incorrect keys, but at least cmd-click works as normal

I'm not sure we want to try to support "all the above" just depending on how someone configures things, there is a lot of complexity in doing that.

---

Reference:

• c-h and xcape control as esc conflict mooz/xkeysnail#157
• When remaping Super+key it opens application menu like when Super is pressed after remapped combination mooz/xkeysnail#143
• Globally unmap Alt key mooz/xkeysnail#82

This should already be fixed but requires more testing (and perhaps knobs to tune)... I've added the concept of "suspended" keys... keys that you've pressed but (for a period of time) we aren't sure what to do with - because we don't know if you mean the literal key or if you're using them as part of a combo (that you're just beginning to key in).

Right now such keys are "suspended" for 1 second. After that (if a combo hasn't been triggers) any keys you've pressed will be un-suspended and pressed on the output. If a combo is triggered the suspension is extended (to allow additional combos).

This seems to work well the only thing it would break is any type of "press and hold" modifier functionality like if you wanted to press and hold Super (and have it pop up some sort of menu/widget) immediately... that can't happen because we're suspending the Super key for 1 second. We may need tuning knobs to modify the delay here.

Press and release works immediately... as soon as it sees you start releasing keys the output is resumed and the presses (and releases) will be communicated to the output.

• further testing of interaction with multipurpose-modmaps

[joshgoebel]

CC @RedBearAK @rbreaves Thoughts?

I'm thinking we may need to suck it up and allow users the choice here... although perhaps Kinto will choose for users? I see two tuning knobs and two main configs:

Eliminate all false-combos, but doesn't support trackpads and Cmd-click (without waiting a second to click)

Mice can be run thru keyszer to support instant cmd-click, but with the caveat that they may need to be configured twice (accel, libinput settings, etc)...

multipurpose_timeout(1)
suspend_timeout(1)

• Multipurpose timeout being how long we wait to decide what to do with a multi-purpose key the user is not releasing.
• Suspend timeout being how long we "hold in reserve" modifiers the user is pressing, before sending them to output without any keymap translation. If the user completes combos within this window we can avoid sending any false-combos at all.

False combos are allowed, and Cmd-click should "just work'

multipurpose_timeout(1)
suspend_timeout(0.1) # close to zero

This is more like the behavior of 0.4.0... where keys go to output as soon as they are pressed but then when a combo is trigger we pull those keys off of the output and exert the correct keys... only to reexert the original keys afterwards (which never was great behavior). I do think perhaps a 3rd delay could be added here:

post_combo_timeout(1)

It seems rare/weird to me that someone might run a combo then (while still holding keys) start mouse clicking with modifiers (though perhaps I'm wrong)... so perhaps we could get away with a longer timeout after combos are fired. How this would work:

• User goes to type Cmd-Alt-E which is a shortut for Ctrl-Y
• They hit Cmd (and it's sent to output)
• They hit Alt (and it's sent to output)
• They hit E and we realize it's a combo
• We lift Cmd and Alt from the output.
• We send the Ctrl-Y combo to the output.

Now it's LIKELY the user is (soon) going to release all the keys... so if we added a post-combo timeout instead of reexerting them on the output immediately we'd hold them in reserve... and if they are released - they never get sent to the output a second time... if they keep being held then soon we can re-exert them on the output.

This could probably be even shorter with good results (0.25, 0.33 seconds?) This is the question #31 is asking.

[joshgoebel]

Closing this as about as fixed as we can get (for now) short of #31 which can carry on the torch of this issue.