I'm running Ventura 13.6. In multiple apps (e.g. Finder, Preview, Music, Google Chrome, Omni Outliner), 
-F is the shortcut for "View/Enter Full-Screen", and -E is the shortcut for "Edit/Emojis & Symbols".
And, System Settings/Keyboard has a "Press key to:" control, which can be set to "Change Input Source", "Emojis & Symbols", "Start Dictation (Press Twice)" or "Do Nothing".
So, it still would be nice if the key could be used in Keyboard Maestro triggers.
I'm afraid that's not going to happen.
If you want to use fn as a modifier because of the special position (bottom left), then do it with BTT. Many KM users use both apps. This has many advantages.
If you just need additional modifiers, then there is a KM macro that lets you distinguish between left and right modifiers. That means, left cmd + letter can trigger a different action than right cmd + letter.
It (the Fn Key, also called Globe) works for me, as a KM hotkey, using Sonoma. But in order to make it work I had to go into the System Settings / Keyboard page and switch "Press Globe key" to "do nothing." In fact, I've been using it for months without knowing that it wasn't supposed to work.
Well, I can use the fn key as trigger for a macro, but only the fn key (not any combo like fn-F).
I set the fn key to "nothing" like this:
but this doesn't change it (still can set the fn key as trigger, but no combos).
Okay, I understand and agree. I didn't realize that was what was desired. Maybe I didn't read far enough back in the thread.
@Tom I have not tested this, but it should work. If you want to use fn + letter as a hot key, don't set fn to "do nothing" but to control. It won't show up, but fn should now be your right control key, which you don't have on most keyboards. There is a macro in the KM library that distinguishes between left and right modifiers. This allows you to trigger something with left control + letter (normal) and additionally with right control + letter (i.e. fn + letter).
I hope what I am telling you is correct. 
Edit: By the way, this should also work with the Caps Lock --> right control. In my opinion, this is the simplest and most reliable method for Hyperkey, because a "real" modifier is pressed instead of four virtual ones.
Interesting tip on making use of the Karabiner recommendations above:
TIL How to Use the Mac's
fnKey with Keyboard Maestro
Into the keyboard your keypress goes, then Karabiner sees it, "emit[s] a USB device key signal", and into Keyboard Maestro goes that signal.
Shows as something like: "Karabiner DriverKit VirtualHIDKeyboard 1.x.x #3"
Tip credit Carlo Zottmann via this super-short blog post
Triggered by Function.kmmacros (2.3 KB)
Triggered by Command + Function + 8.kmmacros (2.3 KB)
Major caveat - both of those macros run when pressing the hotkey for the second one. Seem to recall someone had a way to overcome that kind of problem but don't remember whether it was straightforward, with a delay and cancellation...
I'd love to see the macro you created.
It's interesting that some apps like Wavelab have found ways around this.
That would be cool, like an option in the cogwheel or something that switched from the Hot Key API you are referring to.
Interesting, so by doing this the Public API stays up to date and that keeps Keyboard Maestro up to date? Wouldn't you have to bake the public API in everytime you release Keyboard Maestro or are you saying that it just gets downloaded in the background to keep things working?
That's kind of you to mention that.
Interesting that it sees the left and right modifier keys but this may be something different.
https://hidutil-generator.netlify.app
I really love your details of explaining things like this. It makes using Keyboard Maestro so much better.
I really hope you can train someone and get another younger person up to speed on the code so that Keyboard Maestro stays in development always and forever!
Ah, no you wouldn't. Since then, I found this simple trick:
All hail @peternlewis !
(Someone please DM me how to resize these images)
Apple has public APIs (one they document for use) and private APIs (ones they use internally and do not document). Those internal APIs sometimes allow things to be done that would be nice to do, and so some applications will use them even though they are not documented and are thus subject to change at any time by Apple. Keyboard Maestro does not use such APIs.
Nonetheless, even publicly documented APIs will eventually be removed, so Keyboard Maestro (unchanged) would not run forever, eventually an API that apple documented would be retired (after lots of warning from Apple over a number of years generally).
But using private APIs, they can change at any time, even for minor updates, and with no notice.
How likely is that? And how many times has it happened. The question is meant seriously. I have no idea.
The fact that you do not use private APis is your decision, which must be respected.
You would probably argue like this: If Apple changes something, I have to explain to users why something no longer works in KM.
Now you have to explain to users that something doesn't work in KM because you don't use private APIs.
Either way, you always have to explain something 
I expect that you would agree with me that combining KM’s API-compliant sturdiness and the adventuring of some “alternative” applications can quite often be very productive. I am pleased that we have access to the “best of both worlds”[1] from those different approaches.
Shouldn‘t that be “the better of both worlds”? Where should I file an issue for that? 
[Edit 2025-05-04: no, it means the best from both worlds, doesn’t it. 
] ↩︎
Just compare how many times applications that do use private APIs "break" during OS updates. For example, BTT has been slightly or severely broken every major macOS update since 2018.
Really? I've been using BTT intensively for much longer than 2018 and I can't confirm this.
Unless you mean it needs an update, which is usually available in a few hours. Yes, then I wouldn't have noticed that and I wouldn't care, because it doesn't matter to me as a user.
I’m still using BetterTouchTool 2.428 on macOS sequoia and it’s doing just fine
https://updates.folivora.ai/downgrades/btt_2.428_recovery_mojave.zip)
I have been using that version since 2018 because it was the last included in my two year license
Some of the breakages were minor. And were easily fixed. You didn't notice. 2019 had the biggest breakage, relating to input capturing.
From the Keyboard Maestro FAQ section on sandboxing:
Everything Keyboard Maestro does is strictly part of the standard system APIs, but Apple simply has not provided the entitlements required to do the things Keyboard Maestro does from within a sandbox.
No, it's worse than that: You have to explain why the app they paid $$$ for no longer does what it used to do, and you better be willing to handle a lot of refund requests if this were to happen. Using a private API in a paid app is a very risky thing to do. For our company, we have only one app where we do that, and it's incredibly cheap, such that people get their money's worth after only a couple days' usage.
For everything else, though, we won't touch private APIs. It's just too risky.
You can do this without having to offer a refund, because they're asking for something that doesn't yet exist—that's a very easy story: "Apple doesn't allow developers to do this, sorry!" The other way around, your app no longer does something that it used to do, and which might be the sole reason they purchased the app. That's much worse, to me.
-rob.
-rob.
that’s why apps like BTT say they only guarantee to work on the macOS version that was current at the time of purchase.
Personally I have had multiple apps that I don’t think used private API stop working on newer macOS versions (especially in the audio tooling area), all of these companies tell their users their software is only verified on specific macOS XY, I don’t think any of these companies issued any refunds. There are even quite some examples of old Apple software that doesn’t run on modern macOS anymore
Do you really guarantee your users your apps will continue working with all macOS upgrades ? Even with public API I think things can always break because nobody knows what Apple will do. I think this would be way more risky than using private API.
I agree 
But since I don't really understand anything about it, I can only pass on what people who really do understand it say.
If you use a private API, you have usually taken precautions so that you can quickly switch to a public API. So there is another way.
The reason for using a private API is often performance.
Many once private API have been converted to public API with a few additional security features. They don't disappear, they become official.
If many Apple employees use an app, it is correspondingly unlikely that a private API will disappear. The reason is obvious.
And, last but not least, as @thomasd explains: The rules are so arbitrary that it is hardly worth wasting too much thought on them.
