Full-screen combo has changed on recent Mac OS

[joshgoebel]

Seems this is not consistent across time (how to make a window full-screen in Mac OS) and the larger matter (going full screen) requires a new issue, which I'm making now.

https://apple.stackexchange.com/questions/137361/shortcut-key-for-fullscreen-mode https://github.com/microsoft/vscode/issues/141323

Now evidently the latest OS uses Fn-F... I think that would mean we'd need to add TWO different mappings (and we could keep the old ones too, perhaps?)

• Fn-F
• whatever single KEY this maps to on keywords where FN in't a key (can someone tell us?)

The mapping is going to be different on keyboards where FN is a real key vs something the OS can't see... on my full size keyboard it registers as two key-presses.

I'm not 100% certain that Fn-F (Fn as a real key) can be mapped with the older xkeysnail currently in use - because it won't be considered a modifier, someone would need to test that.

Realted: https://github.com/rbreaves/kinto/issues/702#issuecomment-1154904695

[joshgoebel]

Event: time 1655197321.184114, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff0003
Event: time 1655197321.184114, type 1 (EV_KEY), code 464 (KEY_FN), value 1
Event: time 1655197321.184114, -------------- SYN_REPORT ------------
Event: time 1655197321.450710, type 1 (EV_KEY), code 464 (KEY_FN), value 2
Event: time 1655197321.450710, -------------- SYN_REPORT ------------
Event: time 1655197321.450710, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70009
Event: time 1655197321.450710, type 1 (EV_KEY), code 33 (KEY_F), value 1
Event: time 1655197321.450710, -------------- SYN_REPORT ------------
fEvent: time 1655197321.528138, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70009
Event: time 1655197321.528138, type 1 (EV_KEY), code 33 (KEY_F), value 0
Event: time 1655197321.528138, -------------- SYN_REPORT ------------
Event: time 1655197321.632137, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff0003
Event: time 1655197321.632137, type 1 (EV_KEY), code 464 (KEY_FN), value 0
Event: time 1655197321.632137, -------------- SYN_REPORT ------------

OK, on my Apple Magic keyboard (small, wireless) it's still a discrete key... so someone with different hardware will need to test this and reprot what it gets mapped to when the OS can't see Fn.

My fork now supports Fn as a valid modifier key.

[RedBearAK]

@joshgoebel

whatever single KEY this maps to on keywords where FN in't a key (can someone tell us?)

That was going to be my question.

someone with different hardware will need to test this and reprot what it gets mapped to when the OS can't see Fn

I don't see how this could actually work generically. Won't the detected key just be "F" on keyboards with an undetectable hardware-level Fn key, unless there is a built-in alternate function on the "F" key in hardware or the keyboard driver? So in a lot of cases on PC/laptop keyboards you should just see "F" when someone does Fn+F.

Just tried evtest and xbindkeys on my other laptop in Ubuntu and there is no evidence of a different key code event when using Fn+F versus just F alone.

On the other hand my arrow keys give out things like PlayPause and Stop when used with the Fn key.

[joshgoebel]

I don't see how this could actually work generically. Won't the detected key just be "F" on keyboards with an undetectable hardware-level Fn key,

No, the keyboard handles all this... the keyboard itself can detect Fn... when you hit Fn-F it [should] send an entirely different keycode to the OS. Try it with the F1-F12 keys on any Mac...

Just tried evtest and xbindkeys on my other laptop in Ubuntu and there is no evidence of a different key code event when using Fn+F versus just F alone.

Entirely possible that the hardware has to support specific keys - so that Apple keyboards have support for Fn-F, but other manufactuters do not... that is certainly going to make supporting Fn-F on keyboards without a discrete Fn key problematic or impossible - likely a good argument for keeping the old key mappings.

[joshgoebel]

Ok, now I'm quite confused because on my keyboard Fn has the "magic" behavior (of changing actual key codes on the keyboard) as-well-as counting as a normal keypress as well.

So Fn-F1 counts as two discrete events, Fn and F1... not Fn-brightnessdown... so using it in keyboard shortcuts may be more complex than I first thought.

The good news is mapping Fn-F on keyboard that can't send Fn wouldn't do any harm...

---

Fn-F is just Fn and then F...

[joshgoebel]

I think I'd be in favor of adding it still (as a combo) and saying it only works on Apple keyboards or hardware with a discrete Fn key...

[RedBearAK]

@joshgoebel

I think I'd be in favor of adding it still (as a combo) and saying it only works on Apple keyboards or hardware with a discrete Fn key...

The good news is mapping Fn-F on keyboard that can't send Fn wouldn't do any harm...

Won't the Fn reference crash the current xkeysnail branch unless support is added?

[joshgoebel]

Won't the Fn reference crash the current xkeysnail branch unless support is added?

Yes, but I didn't mean "right this second"... I was assuming after we transition to a modern and maintained keymapper that supports such things. :-)

[joshgoebel]

This whole section is interesting (in key.py):

   KEY_FN     = 0x1d0
    KEY_FN_ESC = 0x1d1
    KEY_FN_F1  = 0x1d2
    KEY_FN_F2  = 0x1d3
    KEY_FN_F3  = 0x1d4
    KEY_FN_F4  = 0x1d5
    KEY_FN_F5  = 0x1d6
    KEY_FN_F6  = 0x1d7
    KEY_FN_F7  = 0x1d8
    KEY_FN_F8  = 0x1d9
    KEY_FN_F9  = 0x1da
    KEY_FN_F10 = 0x1db
    KEY_FN_F11 = 0x1dc
    KEY_FN_F12 = 0x1dd
    KEY_FN_1   = 0x1de
    KEY_FN_2   = 0x1df
    KEY_FN_D   = 0x1e0
    KEY_FN_E   = 0x1e1
    KEY_FN_F   = 0x1e2
    KEY_FN_S   = 0x1e3
    KEY_FN_B   = 0x1e4

There is a KEY_FN_F for sure...

[RedBearAK]

@joshgoebel

There is a KEY_FN_F for sure...

That is very interesting indeed. Makes me wonder why fn+1/2/D/E/F/S/B in particular ended up in there, but no other keys outside the function keys. Can't find much reference to it besides these same key definitions in other contexts. Wish I was better at tracing these types of reference files back to their true historical origin point.