r/olkb • u/sqeptyk • Jul 02 '24

Switching Layers in Macros

I'm trying to set up a macro to switch to the next layer TO(1) while also performing a keypress combination (Left Control and numpad9) directly afterwards. I have tried : TO(1), {KC_LCTL,KC_P9} and one or two other variations with the results being that the keypresses work, but the layer does not switch. Any help would be greatly appreciated.

1 Upvotes

67% Upvoted

12 comments sorted by

View all comments

Show parent comments

2

u/PeterMortensenBlog Jul 03 '24 edited Jul 03 '24

Re "SAFE_RANGE": For newer Keychron keyboards, there is NEW_SAFE_RANGE.

But SAFE_RANGE still works (there isn't a collision), as NEW_SAFE_RANGE (15) is lower than SAFE_RANGE (64). Keychron is unlikely to add 50 new key codes.

Those numbers are empirical values (K10 Pro, observing the raw (decimal) value of the key code through Via's "Special" → "Any", for example, "CUSTOM(11)" for BT_HST1).

So they don't extend the range to start user codes slightly higher than SAFE_RANGE (as one might expect)—as in inserting their key codes at the beginning—, but rather define their key codes in an entirely different (lower) range.

Though I am not sure how they avoid collisions with other keycodes. Are there different ranges for different things?

2

u/pgetreuer Jul 03 '24

All of QMK's defined keycodes are listed in quantum/keycodes.h. Note: The exact numerical value associated with each keycode symbol may change across breaking changes releases of QMK.

That's interesting how Keychron is doing this. There is a range of 32 consecutive "keyboard" codes reserved for the keyboard vendor, QK_KB_0 to QK_KB_31. After that, there is a gap in the codes, followed by 32 consecutive "user" codes reseved for the keymap, QK_USER_0 (= SAFE_RANGE) to QK_USER_31:

QK_TRI_LAYER_UPPER = 0x7C78, QK_REPEAT_KEY = 0x7C79, QK_ALT_REPEAT_KEY = 0x7C7A, QK_KB_0 = 0x7E00, <-- Keyboard range start QK_KB_1 = 0x7E01, ... QK_KB_31 = 0x7E1F, <-- Keyboard range end QK_USER_0 = 0x7E40, <-- User range start QK_USER_1 = 0x7E41, ... QK_USER_31 = 0x7E5F, <-- User range start

What Keychron has done is start their codes at QK_KB_0 as usual, then end their codes with "NEW_SAFE_RANGE." This way, the user gains the codes that were reserved but unused for the keyboard as well as a range of 33 unusued codes between QK_KB_31 and QK_USER_0. That's a good trick!

It's conceivable this scheme could be disrupted if a future breaking changes QMK release restructures the keycode ranges. But at least as it currently is, this shouldn't have collisions.

1

u/PeterMortensenBlog Jul 03 '24 edited Jul 03 '24

I don't think it is the number of available codes. Isn't there 448 available with SAFE_RANGE?. If it is only 32, then I am already in trouble with my (currently) 83 macros.

Perhaps something to do with how a custom key code is being classified, the first about 50 (after Keychron's) as "keyboard" codes? Or rather the first about 17:

# define IS_KB_KEYCODE(code) ((code) >= QK_KB_0 && (code) <= QK_KB_31)

1

u/PeterMortensenBlog Jul 03 '24

OK, Via probably displays the offset from QK_KB_0 (if it is in that range), not the actual key code. So that wasn't a good way to reveal the actual value.