FN-layer remapping is (somewhat) possible using "02 00 00 ??" mappings

[WinkelCode]

Description

I was investigating how the default macOS screenshot macro works, since the physical screenshot key doesn't actually have separate keymap entries, but still has different behavior depending on FN-key press.

I discovered that the "02 ?? ?? ??" bindings aren't actually redundant, but "redirect" the key press to other keymap offsets, depending on if FN is pressed.

The macOS screenshot macro uses 02 00 00 0C, which splits into offset 0240 and 0300. For example, I set 0240 to 00 00 00 68 for F13, and 0300 to 00 00 00 49 for Insert.

Further details like how many free slots are available is TBD, and still needs to be systematically analyzed.

[donn]

I... forgive my confusion but I don't understand how 0240 and 0300 were derived

[WinkelCode]

I... forgive my confusion but I don't understand how 0240 and 0300 were derived

I looked at the macOS keymap and found that Meta+Shift+3 and Meta+Shift+4 are at these offsets.

---

Edit: One other value I tried ended up just being the FN layers for the F1 key.

I previously believed the firmware was translating the function keys into separate keymap entries depending on if the FN key is pressed.

Now I believe that the these 02 ?? ?? ?? bindings are actually responsible for all that and that every key just has one "origin" keymap entry.

Edit 2:

This chunk of empty bindings

02a4  00 00 00 00  -> none
02a8  00 00 00 00  -> none
02ac  00 00 00 00  -> none
02b0  00 00 00 00  -> none
02b4  00 00 00 00  -> none
02b8  00 00 00 00  -> none
02bc  00 00 00 00  -> none
02c0  00 00 00 00  -> none
02c4  00 00 00 00  -> none
02c8  00 00 00 00  -> none
02cc  00 00 00 00  -> none

And it's counterpart:

0364  00 00 00 00  -> none
0368  00 00 00 00  -> none
036c  00 00 00 00  -> none
0370  00 00 00 00  -> none
0374  00 00 00 00  -> none
0378  00 00 00 00  -> none
037c  00 00 00 00  -> none
0380  00 00 00 00  -> none
0384  00 00 00 00  -> none
0388  00 00 00 00  -> none
038c  00 00 00 00  -> none

Might be up for grabs as custom FN layer bindings.

It's no match for QMK, but 12 (including the original screenshot binding) open FN-layer capable slots is quite nice, and will surely be useful to folks.

[WinkelCode]

serialized_keymap_win.txt
serialized_keymap_mac.txt

I had ChatGPT "Advanced Data Analysis" whip these up for me, they are the available slots for FN-layer remapping on the Air96. The // comment is the last byte of 02 00 00 ?? for that slot. I tested it on in the Windows keymap with slots // 2D

Edit: This can also be used to trace back the origin of some keys. We may actually have more slots available than expected, for example the "G" key utilizes an FN-layer for 0E 00 00 11, which may be unused on the Air96.

[gabrielsoldani]

@WinkelCode This seems promising. I'm comparing dumps from my Air75 and my Air60 and this is plausible. Can I ask you how you've made the association that the physical screenshot key for macOS is at offset 0138 (as that is the offset that contains 02 00 00 0c)?

[WinkelCode]

@WinkelCode This seems promising. I'm comparing dumps from my Air75 and my Air60 and this is plausible. Can I ask you how you've made the association that the physical screenshot key for macOS is at offset 0138 (as that is the offset that contains 02 00 00 0c)?

After I figured out how this "splitting" works, it's fairly straightforward to reference these bindings back and forth. However, at the "very beginning" I found it because in the Windows keymap, it only has a single (non-split) binding to SysRq/Print Screen.