Clarification about skhd-grabber and Karabiner coexisting

[Kumagawa97]

I've read the documentation and there's one thing that I'm not sure I fully understand.
I apologise if the answer is actually as obvious as it seems.

Currently I have installed skhd, skhd-grabber [both 0.1.10-977ce1d (fast)] and karabiner-elements (which I use mainly for game controllers).

I wanted to override cmd+q in order to require cmd+q+q to close apps, but I don't see a way of achieving this with skhd; I thought that maybe layers could provide a workaround but that's a relatively new implementation that I want to get to know better before messing too much with it.
Karabiner, on the other hand, has some complex modifications for this use-case but having skhd-grabber installed creates a conflict.

The Karabiner modification did actually work for a while but I noticed that the DriverKit was updated to the latest version, which isn't fully supported by skhd-grabber. As soon as I downgraded it the tap-hold rules resumed working as expected whereas Karabiner's setup became ineffective.

Am I right in understanding that since skhd-grabber is running, all keypresses, whether they are part of the basic syntax or tap-hold rules, are intercepted and cannot be routed to Karabiner in any way?

If that's the case, the only workarounds I can think of right now would be:

• remapping cmd - w and cmd - q to the fn_layer and keys that are distant enough to prevent accidentally triggering the wrong one due to proximity.
• assigning a harmless action like echo "" to cmd - q and osascript -e 'tell app "{{1}}" to quit' to a different hotkey.

[jackielii]

hi, we use Karabiner HID driver only, we don't use its grabber. So:

HID -> grabber -> event tap

However, if you don't use the .remap directive, skhd.zig won't install grabber or depend on HID driver.

In your use case, I suggest you use Karabiner for the remap, and only use skhd for the event tap.

https://github.com/jackielii/skhd.zig#coexistence

[Kumagawa97]

Hi, thank you for the quick reply!

I actually use the .remap directive for a few things.
This is part of my skhdrc:

# Remaps
.device builtin { vendor: 0x05ac, product: 0x027b }

# 2. caps_lock acts like ctrl when held, escape when tapped.
.remap caps_lock [device builtin] {
    tap             : caps_lock
    hold            : lctrl
    timeout         : 120ms
    permissive_hold : off
}

# 3. Hold space to enter a "function layer", release to exit.
:: fn_layer @
.remap space [device builtin] {
    tap             : space
    hold            : fn_layer
    timeout         : 200ms
    retro_tap       : on
}

# 4. While the layer is held, number row → F-row.
fn_layer < 1 | f1
fn_layer < 2 | f2
fn_layer < 3 | f3
fn_layer < 4 | f4
fn_layer < 5 | f5
fn_layer < 6 | f6
fn_layer < 7 | f7
fn_layer < 8 | f8
fn_layer < 9 | f9
fn_layer < 0 : @toggle_app("bitwarden")
fn_layer < 0x1b | ctrl + shift - c
fn_layer < 0x18 | ctrl + shift - v

I honestly like how skhd is straightforward and relatively easy to set up, so if moving this whole part to Karabiner can be complicated, I'd rather keep everything as is and limit my use of Karabiner to game controllers.

[jackielii]

thanks, same reason why I didn't just use Karabiner. So the conflict is the grabber. both run as root as try to seize the keyboard from the kernel level. Let me know you usage from Karabiner and see if we can support it from skhd.

[Kumagawa97]

The main reason was mapping controller buttons to specific keys while play games.
For example, on a Playstation controller the up arrow would be w, the down arrow s, the circle spacebar and so on.
I think this is already possible by using .device <alias>, I haven't tried it yet only because I haven't been playing anything recently.

Now, the above is a situation in which even if I had to disable skhd-grabber to use Karabiner, I wouldn't really mind it.
If I'm playing games I don't need to use Yabai or quickly toggle apps.

What I think could make a difference is adding a hold delay to non-modifier keys or the ability to concatenate them while holding a modifier.
The implementations I had in mind:

cmd - q (hold q for at least n seconds) or cmd - qq (press q two times while holding cmd).
I think this might require overriding or disabling the default action of the system's modifier - key to avoid unwanted results.

Since skhd can define process-specific bindings, you could limit its scope to selected apps while keeping the default action in others:
cmd - q closes any other app but cmd - qq is required to close app XYZ.
You could think of this as an almost seamless implementation on the user's side as it does not require remembering another hotkey but it also prevents misclicks.

Also, depending on how the grabber works, a similar result could be achieved without having to assign an action and/or disabling the default one.
By ignoring the first keypress while holding that modifier, when using cmd - qq the first q is "absorbed" by the grabber and only pressing it a second time actually sends cmd - q to the system.

Hopefully I've explained this clearly enough but let me know if that's not the case!

[jackielii]

I have this working on PR #52 . do you want to give it a try before I merge:

simple config:

.sequence_timeout 1500ms

cmd - q, cmd - q [
    "TextEdit" | cmd - q
]

so normal application cmd - q is recevied as is, where as textedit will need twice. the first one is swallowed.

or try

cmd - q, cmd - q [
    "TextEdit" : skhd -t "hello world "
]

which inserts the text hello world

[Kumagawa97]

It seems to be working great with my setup, thanks!

[jackielii]

Great! Glad it worked, I also discovered some optimisation opportunities in my skhdrc. I'll make a release soon.

Bear in mind that when using this with Karabiner Elements, skhd.zig requires a specific version of the HID daemon. I think the new version v7 & v8 have different wire protocols. We'll wait for it to stabilise before we upgrade