`overloadt2`, but resolves on press

[musjj]

overloadt2 resolves as a hold when another key is tapped. The problem is that this makes things feels really sluggish.

Can we have a different variant that behaves like overloadt2, but resolves into a hold as soon as another key is pressed down, instead of waiting for it to be released?

[nsbgn]

Isn't that just normal overload?

overloadi/lettermod can make things feel less sluggish.

On March 20, 2025 8:00:16 PM GMT+01:00, musjj @.***> wrote:

musjj created an issue (rvaiya/keyd#970)

overloadt2 resolves as a hold when another key is tapped. The problem is that this makes things feels really sluggish.

Can we have a different variant that behaves like overloadt2, but resolves into a hold as soon as another key is pressed down, instead of waiting for it to be released?

-- Reply to this email directly or view it on GitHub: https://github.com/rvaiya/keyd/issues/970 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[musjj]

Normal overload will immediately emit the hold key, I want it to be suppressed until another key is pressed. overload's behavior has caused some issues in certain applications for me.

overloadt2 does mostly what I want, but it waits for the intervening key to be released before executing the hold action, which makes things feel sluggish.

I tried reading through the description of overloadi, but I honestly have a hard time understanding how it works or how it would apply to my problem.

[rvaiya]

I assume you are trying to overload a non-letter key (otherwise you should use lettermod).

overload's behavior has caused some issues in certain applications for me.

Can you elaborate? Which applications/sequences are problematic? overload is intended for cases where sequence alone is sufficient to identify the intended action, overloadt2 only makes sense in cases where you care about how long the key is held (in most cases people who care about this probably want lettermod), which it sounds like you are trying to avoid.

[musjj]

Some games processes inputs in a certain way that causes certain inputs to be mis-processed when they are pressed quickly together: https://github.com/rvaiya/keyd/issues/151#issuecomment-2415406617

The solution was to use macro(10ms escape), but I personally find this unsatisfactory due to the artificial delay. Also, the trick didn't work 100% reliably for some games.

overloadt2 solves this problem for me, but with the aforementioned problem. I know that I'm not using it exactly as it was intended (I personally set <timeout> to a really high value, because it does not matter to me), but the "suppress the hold action until an intervening key" behavior is very useful for my purposes.

[nsbgn]

Normal overload will immediately emit the hold key, I want it to be suppressed until another key is pressed.

Ah, okay, then this is the same as https://github.com/rvaiya/keyd/issues/728, right? Can you explain more about your use case?

(I am not certain I understand how the immediate down-up mechanic that could by worked around by macro(10ms escape) would be solved by overloadt2. The down-up event for the tap action is also immediately emitted there, no?)

[musjj]

The difference is that overloadt2 does not emit the hold action at all when simply tapped (without an intervening key). The hold and tap action being emitted together confuses some applications.

[rvaiya]

but I personally find this unsatisfactory due to the artificial delay.

I am inclined to regard this as a bug in the game. If the problem is indeed the input processing loop of the game, then what you propose is unlikely to work anyway since it would emit the modifier and the key it modifies simultaneously.

Also, the trick didn't work 100% reliably for some games.

You might need to adjust the timeout.

[musjj]

Yes, it can be regarded as a bug in the game, but there's nothing I can do about that.

Here's a few diagrams clarifying the differences (verified using evtest):

• X = overload(Y, Z)

  This is what caused the original issue. Because of the simultaneous presses, Z is not registered by the game.

  keyboard:       X↓      X↑
  computer sees:  Y↓      Y↑
                         Z↓Z↑
  

• X = overload(Y, macro(100ms Z))

  To work around the issue, we can add a delay. It helps, but it's not 100% reliable. Also, I don't really like the idea of adding artificial delays to inputs that I frequently use.

  keyboard:       X↓      X↑
  computer sees:  Y↓      Y↑
                              (100ms later)  Z↓Z↑
  

• X = overloadt2(Y, Z, 10000)

  Another trick here is to use overloadt2 with a really high timeout value that will practically never trigger. This solves the original problem perfectly, because Y is never even emitted.

  keyboard:       X↓      X↑
  computer sees:         Z↓Z↑
  

• X = overloadt2(Y, Z, 10000) (N = intervening key)

  But now, another issue arises. When you want to trigger Y combo-ed with another intervening key N, things feel sluggish. This is because keyd waits for the intervening key N to be released.

  keyboard:       X↓    N↓    N↑    X↑
  computer sees:              Y↓    Y↑
                             N↓N↑
  

Now what I propose is an overload that behaves like overloadt2, but more immediate:

keyboard:       X↓    N↓    N↑    X↑
computer sees:        Y↓    N↑    Y↑
                      N↓

Hope this clarifies the issue.