Block `W+Ctrl`

[jonpas]

Is it possible to block W+Ctrl in keyd?

I understand how to block Ctrl+W with the following config:

[ids]
*

[main]

[control:C]
w = noop

But I can't get W+Ctrl to be blocked without also blocking W on its own. I tried to layer w but that also blocks w itself, and I don't see a way to also emit a key if it's a layer.

What are the possible alternatives for blocking any combination of Ctrl and W keys (and also Shift in that mix, but that is less important)?

[nsbgn]

What is the exact behaviour that you're looking for? Normally, when you press w and then press ctrl, even if they're overlapping, nothing much will happen --- you'll just get a keypress of w and then a keypress of ctrl (which may activate the control modifier for a subsequent keypress).

If you want to block w when it overlaps with ctrl within a certain timeframe, you can use chords (tweaking the chord_timeout if desired):

[global]
chord_timeout = 50

[main]
w+leftcontrol = noop

[control]
w = noop

If you don't want to block w when it overlaps with ctrl, but want to block the activation of subsequent control modifiers:

[main]
w = layerm(wlayer, w)

[wlayer]
control = noop

[control]
w = noop

Does that help or did you mean something else?

[jonpas]

I want to prevent ctrl and w from ever being in "down" position at the same time. Maybe that's a better way to word it. Essentially I need to block a few of such combinations from appearing, but ctrl+w is a good example I can later extrapolate to others.

Chords aren't fitting here I believe, as you can technically hold one key down, and then pressing the other should still prevent the combination from being emitted.

Your second example with layers works for one part, which is blocking w while ctrl is pressed. However, to fully block both keys from emitting at the same time, I must also block ctrl while w is pressed - this part I am having trouble with.

In other words, one could say I need to block both ctrl+w as well as w+ctrl, both orders of pressing the combination.

[nsbgn]

However, to fully block both keys from emitting at the same time, I must also block ctrl while w is pressed

Hmm, isn't that what the second example would do? Entering the control layer blocks w from being pressed; pressing w would emit w and enter the wlayer, in which control is blocked.

(Out of curiosity: why? :P Would help to understand the ways in which keyd is used.)

[jonpas]

Actually yes, I have misread layerm for layer, my bad. However there is a different problem with w = layerm(wlayer, w), pressing w emites w down and immediately w up, before actually releasing the key - in other words holding it is not possible.

Use case here is an Unreal Engine PixelStreaming application. A "thin" client with a browser (Chrome in this case due to better WebRTC support) is used to connect to the application and remote access/control it. Chrome has some hardcoded keybinds like ctrl+w which closes tabs and that keybind specifically is something you might often see being pressed in a game-like application. Blocking ctrl+w is not really special, but we found another problem, in that holding down w and then pressing ctrl also activates the same keybind in Chrome. That is why we want to block in such a way. keyd seemed like it would be able to handle that due to the low-level it operates at.

[nsbgn]

Ah, got it. Yes, in a macro, the down and up events are generated immediately. In most situations, this makes sense (it is a macro, after all --- not necessarily limited to a single keypress).

It's not possible right now to have the final key in a macro be held until key release. That would be a (separate) feature request. It might be niche[^1], but it sounds like a good idea to me anyway, because it's less surprising even out of context.

That said, I'm not the developer, so there might be some subtleties that I'm overlooking --- maybe @rvaiya has time to respond later?

In the meantime, if it's urgent, I don't know of any other software remapping tools that do support this use case. You could check out kmonad, kanata, ktrl, or hawck.

[^1]: Maybe not that niche --- any game-ish context where layerm and friends are used on letter keys?

[jonpas]

None of the alternatives seem to support that. For this one we'll just have to live with it, but it would be nice to see this supported in the future, especially as no other similar project supports it either.

Thanks for the answers!

[rvaiya]

It is always interesting to discover such novel use cases :P.

It's not possible right now to have the final key in a macro be held until key release. That would be a (separate) feature request. It might be niche1, but it sounds like a good idea to me anyway, because it's less surprising even out of context.

The main problem I see with this is that, aside from the present case, it is almost never desirable to want a key depressed while a layer is active. layerm(layer, x), should read like type x, and then activate layer. Keeping x depressed for the duration of the layer activation is probably not what the user wants to do in the majority of cases:

E.G

capslock = layerm(nav, x)

[nav]

h = C-left
l = C-right
# etc...

would cause capslock+h to produce <x> <C-x-left>, instead of <x> <C-left>. The only case in which this might make sense is in the case of modifier keys like shift, in which case a modified layer (e.g nav:S) is the appropriate choice.

[nsbgn]

Ah, that's a good point. I was under the impression that a modifier (like a layer) never gets interpreted as retroactively applying to earlier keydown events (even if they're held), but quickly testing that assertion shows that's application-dependent.

More importantly, I forgot about key repeats. You don't want your nav layer to go all xxxxxxx... until the first keypress in that layer.