Modifier-only keybinds exist

[miku4k]

You can set a modifier-only shortcut by using the xkb name for the modifier as the second key (e.g. Super+Super_L). Hitting just the modifier, or any keybind that includes the modifier, triggers the mod-only bind.
I've only tested with Super+Super_L and the spawn action, but I believe other combinations behave similarly if not the same.

Checking that the non-mod key of a keybind isnt secretly a mod should be enough to fix this.

System Information

• niri version: niri 0.1.7 (unknown commit)
  (most recent version currently available in NixOS unstable)

• Distro: NixOS (unstable)

• GPU: AMD integrated

• CPU: AMD Ryzen 5 5500u

[YaLTeR]

Hm, I guess until we have release binds, this is more or less the best we can do. Though, maybe someone does use it, by carefully avoiding binds using that modifier...

[dev-nicolaos]

Is there an existing issue for release binds? I searched but couldn't find one. It would be nice to be able to bind an action to just Super without breaking all the other binds that use it as a modifier.

[YaLTeR]

I'm not sure there's an issue, but implementing release binds would involve some non trivial logic I imagine.

[jakesarjeant]

Is allowing mod-only binds necessarily a bug? I can think of at least a few use cases for it, but I'm not clear on what problem it causes... Anyone who doesn't want mod-only binds can just not make any, but it doesn't seem like there's any reason to disallow them for people who want them (of course, release binds are kind of necessary for them to be useful). I'm also bouncing around the idea of showing a workspace overview (see #624) while the mod key is held instead of putting it in my bar, so it seems useful to bind opening the view to Super+Super_L with a timer to close it after a few seconds.

[miku4k]

they can lead to unexpected behavior if they arent accounted for, which they arent
especially the fact that they get executed

the disallowing them was more a temporary suggestion since i too think release binds would be complex to implement

and yes mod-only keybinds definitively have their uses (super opens some kind of menu on almost all desktops)

[jakesarjeant]

Maybe a better solution would be to introduce an allow-mod-only; option in the binds section of the config and disallow them otherwise?

Should be fairly straightforward to implement

[dev-nicolaos]

I'm having trouble imagining a mod only keybind being useful without also being a release bind. Wouldn't the bound action run on every invocation of every other shortcut that uses that mod key? If that's the case, I worry introducing an allow-mod-only option would just be a waste of time.

[miku4k]

yes they run every time you use that key be it in another shortcut or not.

[CodedNil]

Sorry if this is an obvious question, but does this mean that it's currently impossible to set for example super key alone to launch fuzzel? Or is there a hacky workaround to make that work until release binds are in?
Thanks.

[YaLTeR]

I don't think there's a workaround

[bbb651]

I have lv3:caps_switch set in input.keyboard.xkb.options to remap caps lock to an additional modifier key, and weirdly ISO_Level3_Shift+ISO_Level3_Shift is a valid keybind (I never realized this wasn't allowed with other modifier keys, so I guess it's a bug?)
So if you can find a way to remap Super to ISO_Level3_Shift with xkb options I think it should work.
(also I'm still on 0.1.10, haven't tested it on 25.01)

Edit: Now that I think about it you can remap it to any other unused key, ISO_Level3_Shift is only special in that it allows you to use it as both a modifier and a key, which by itself is not very useful as both will trigger at once, turns out using an additional modifier works pretty well:

ISO_Level3_Shift { ... }
Shift+ISO_Level3_Shift+<key> { ... }

You can probably also hack release binds with this by spawning a sh -c "sleep 1 && <command>", and somehow find it and kill it in ISO_Level3_Shift+<key> binds.

[YaLTeR]

ISO_Level3_Shift+ISO_Level3_Shift is a valid keybind (I never realized this wasn't allowed with other modifier keys, so I guess it's a bug?

Uhh, I don't think this is intended. But I guess you can do it with other modifiers by using xkb names like Super+Super_L?

[boomskats]

@CodedNil I use key overloading in keyd for mod-tap like behaviour when remapping caps to ctrl/esc. I've found it to be reliable - should be pretty trivial to use it to do what you're wanting to do.

[CodedNil]

@CodedNil I use key overloading in keyd for mod-tap like behaviour when remapping caps to ctrl/esc. I've found it to be reliable - should be pretty trivial to use it to do what you're wanting to do.

That's amazing thanks dude!!!!! This works pretty flawlessly for me until release binds are in.

My nix config if it helps anyone sort similar

services.keyd = {
  enable = true;
  keyboards.default = {
    ids = [ "*" ];
    settings.global = {
      overload_tap_timeout = 200; # Milliseconds to register a tap before timeout
    };
    settings.main = {
      compose = "layer(meta)"; # Make the menu key press super
      leftmeta = "overload(meta, macro(leftmeta+z))"; # Make left meta tap open anyrun keybind
    };
  };
};

[tmarkov]

I'm having trouble imagining a mod only keybind being useful without also being a release bind. Wouldn't the bound action run on every invocation of every other shortcut that uses that mod key? If that's the case, I worry introducing an allow-mod-only option would just be a waste of time.

I have this use case:
Press Control -> Enable microphone
Release Control -> Disable microphone

Which essentially implements push to talk for me. Of course, this would short-term enable mic when copy/pasting, for example, but that's acceptable side-effect.

[miku4k]

im curious, how do you disable the microphone on release?

also relevant xkcd https://xkcd.com/1172/

[tmarkov]

Not with Niri. The inability to have some version of push-to-talk is why I'm not using Niri currently. I'm simply demonstrating a use-case for mod-only-keybind that's not a release bind.

As for the xkcd, I fail to see the relevance. This doesn't rely on a bug, and is usually the simplest way to achieve push-to-talk (AFAIK only hyprland has something better).

[YaLTeR]

I see. I guess for this specific microphone push-to-talk case, some system, for forwarding keys to specific windows would also work.