Seems like the fn key is intercepted by the firmware then, that sucks. I’m repeating the same question differently just to ensure we’re on the same page:

If I understood correctly, your fn key is constantly “active”, making any key with an fn-modifier act as a different key, and that is why forexample the enter-button won’t be… well, enter? but if it enter acts as a different key, i.e. pressing enter gives a totally different keycode, can’t you rebind whatever keycode that turns into, into enter?

I did a super surface-level quick search, it seems like the older macbooks have had some firmware reverse engineering done. Might be some options there. Also, your issue may be a common case of a specific board trace needing new solder, which might not be too hard. Maybe that guy who does apple repairs/right to repair has something on this, or a community who may know. Louis Rossman something? can’t recall.

Also, you may’ve mentioned in your original post, but are there other keys that could work? doesn’t mac have that extra “option” key? i think i read that ctrl+fn key could be switched on a firmware level, if that means the ctrl key is then intercepted by the firmware I guess it won’t add much, but if all else fails, could be worth checking if it acts differently.

good luck, I don’t have any more ideas but I’m rooting for you, would be interesting to hear if you find a solution.

The firmware might be hijacking the fn key. If you use one of the keycode-reporting tools, does it report the fn key? and what is fn+enter or fn+backspace being reported as? if you’re not seeing the fn key, or if say fn+enter is reported as a singular key instead of two keys, maybe you could bind that “key” to enter?

If the Mac settings panel has an option to lock the F-keys to either F1-F12 or the keybinds, that option may be stored in the firmware, so for those keys simply reversing it in firmware may be enough.

If you are on HDD then looking at what else is using the same disk, and reducing that usage, may yield some results. Forexample, if /var/log is on the same disk and can’t be avoided, then reducing log volume or batching writes may reduce the “context switches” your HDD has to do. There should be options for I/O limits/throttling/priority in systemd. If you have only postgres on the HDD, I’d consider giving it 90% of the max bandwidth – maybe that’d be more effective than going full throttle and hitting the wall. If you have postgres and some other service fighting for the HDD’s time, these limits could help. Make sure access time tracking is off (or set to relatime).

In general I agree with you, especially on the image part, but I found the opensuse page to be a decent variation of this.

Did you (or I?) miss something here? In the 3rd paragraph it’s “revealed”:

In a story of “what’s old is new again”, the solution dates back to ancient keyboards with physical keys for Copy and Paste.

Neo seems like a cool layout, reminds me of “unexpected keyboard” for android, but I fail to see the relevance since it doesn’t have the copy/paste buttons (like the keyboard in the picture in the article) as far as I can see