Problems with a "Sticky" hyper key

Describe the bug

I have CAPSLOCK set as a hyper-key when pressed down, and on release it emits F18 (using a named trigger which will activate Alfred):

The problem is that every so often (~15% of the time), once Alfred is active and the CAPSLOCK fully unpressed (meaning the named trigger worked properly, if I then type a normal key (e.g. [e]) the hyperkey binding associated with that (in the screenshot that is [maximise window right half], gets triggered. The [e] is lost to Alfred and the Alfred window is moved. It is like the hyper key binding remains "stuck" even after release. This is a regression over the last couple of weeks.

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):

Macbook Pro11,5 keyboard input — macOS 12.2.1 BTT 3.743 (alpha stream)

This still occurs regularly in update 3.744…

If you want to avoid hyper key, or it does not work, but you want to use "Caps Lock" as a Modifier try this.

I suppose your keyboard does not have a „Control-Key“ on the right side. If so you can chance the Caps Lock to „Ctrl right“. Do this in the Mac OS, System preference —> Keyboard.

Now Caps Lock = Ctrl right

Then record the combination of Caps lock + x in BTT. Make sure you tell BTT to use „right Control“ (not left Control). So you can use the two keys as different modifiers, without Hyper Key but with Caps Lock.

Hi Frank, thanks for the workaround. I'm not quite sure how it works. In System Prefs > Keyboard > Modifier keys I don't see any options for left vs. right CTRL keys, just a generic ^ Control:

I used to use Karabiner elements for this sort of thing, but I wanted to simplify my setup which was why I moved to using BT exclusively. Exclusive use of BT was all working really well a while ago (after @Andreas_Hegenberg fixed another issue, see Reliability of Hyperkey on Release? - #6 by iandol).

Hi

Set Caps Lock to Control here (not Caps Lock = Caps Lock)


Then you have
Control = Control (of course)
and
Caps Lock = Control (this is right Control)

With BTT you can now use the Caps Lock control as a right control. To do so tell BTT "distinguish between left/right modifier" (or similar, I have a German System)

Now, shorcuts with right control do not work with left control and vice versa. You have a new modifier :slight_smile:

1 Like

One more thing: if you need the "Caps Lock" function, define a shorcut with the pre-defined BTT action to toggle on/off.

1 Like

The original "sticky" capslock hyperkey problem I mentioned is still a problem in the current release (3.812). In the screencast, I am using ⇪capslock alone to trigger Alfred. I depress and then release ⇪capslock and Alfred is correctly activated. At this point the ⇪capslock key has been fully released.

Then in Alfred I type single keys beq — the b enters into Alfred without issue (I do not have any hyperkey+b bound), but e triggers "Resize to right" ⇧⌃⌥⌘E which is the BTT binding you can see in the screenshot in the OP. To reiterate only e is depressed at the time the ⇧⌃⌥⌘E binding activates!

I tried to add a HUD overlay for caps lock to see if I visualise see rogue activations, but I only see the HUD on caps-lock-down, not when the hyper key wrongly triggers on single characters like e... @Andreas_Hegenberg -- is there any other way to try to debug this problem?

@iandol Just out of curiosity, have you tried right control? For some it works well, especially with the internal keyboard, for others unfortunately not :man_shrugging:

Thanks for your insights, I never managed to get it to work as I wanted:

  1. Use caps lock alone to trigger Alfred.
  2. Use caps lock down + another key as a hyper key-like modifier.

Your right-ctrl mapping method can handle (2), but not (1) as far as I could manage / understand.

I also would like the BTT hyper key feature work as it used to; this is a regression in behaviour as before BTT could handle this without this issue. I do appreciate how hard some of these features must be to make and therefore how hard it must be to debug for @Andreas_Hegenberg, especially like this issue where it isn't always reproducible...

@iandol I understand of course that you want hyper key to work properly if the feature is available. nevertheless, be patient with me please :pray:, I would like to understand this.

So number 2 works. Good, because that's the harder part :slight_smile:

Number 1 just opens Alfred's search window. Right? In the Alfred prefs I changed the default trigger to "double tab ctrl". Now if I double tab caps lock (= right-ctrl.) this search window opens. What am I misunderstanding? :man_shrugging:

I currently use 2⌃ (double tap) for Bookends, and it seems neither Alfred nor Bookends cares whether left or right ⌃ was tapped. I also find double-tap a bit annoying for something used so often in my day. Anyway I will remap Bookends to 2⌥ and try to see how I get along with 2⌃ for Alfred (my muscle memory is slow and glitchy, it took me ages to stop using ⌘space...) I do appreciate your workarounds, let see how my muscle memory feels in a few days :joy:

@iandol Ah, yes sorry, I forgot that other apps don't distinguish between right and left modifiers. But there is a solution for that too. So you don't have to overuse your muscle memory :joy: and can keep your bookends shortcut.

Open Alfred's search window with a shortcut you would never use. For example this

Then set up a key sequence in BTT with right control that triggers this complicated combination.

So this (right control, double tab)

triggers this

If you now do the same with left control and bookends (of course with another complicated shortcut), you should be able to use both ctrl keys separately, I think :smirk:

Double tapp r-control opens Alfred.
Double tapp l-control opens Bookends.

Let me know if this works for you. :innocent:

1 Like

Thanks Frank, yes the key sequence solution certainly works for Alfred, though Bookends only allows a very limited set of key presses (I can't use my own complex binding), so I will simply switch to to use another double-tap for Bookends. I still don't much like having to use double-tap for Alfred, and still hope this hyper-key bug will eventually get fixed…

After switching to a new Apple Silicon Laptop, this problem greatly reduced. However, over the last few builds I am again seeing this more and more frequently. @Andreas_Hegenberg - is there any way to stop the hyperkey binding activating in this case. I don't think this is related to the app (in this case Alfred), as I did see in a text editor when I tested this in 2022...