Nick Brassel

No code review as yet, but tested against #19997 and I2C OLEDs still work fine (with appropriate no-ops for comms start/stop).

Then it needs to be renamed to `via_ryanbaekr`, as per the PR checklist. Also, the unused combo feature should be removed, as well as empty layouts.

Compiles fine without combos enabled. Also, there's no mention on the **QMK** documentation of requiring combos. Perhaps the documentation you're referring to should be considered historical?

Your docs: > An essential piece to making this work is that we set the desired alternate keycode in the keyrecord_t’s .keycode field, and this field is only present when...

> To clarify, QK_REP works, get_last_keycode() does not Can't reproduce this I'm afraid. Implemented your repeat keycodes identically and it works fine without any combos. ```c case TZ_REP_2 ... TZ_REP_5:...

Converted to draft and marked with `needs-wireless-code` due to Tide65 being merged without wireless bindings. All Epomaker wireless boards are now on hold until Tide65 is rectified. Tide75 will need...

Moved back to draft until I get time to sort out test failures etc. Need to go digging as per Z's comment. Across the org: https://github.com/search?q=org%3Aqmk+__KEYMAP_GOES_HERE__&type=code

> > The keyboard advertises bluetooth and wireless support, but code seems doesn't . > > #18485 #18485 says that Wireless builds including QMK are bound by GPL. It does...

Can we find a solution that doesn't involve calling `layer_state_set_kb` from a secondary thread?

There's a bit of debate internally as to whether or not we should reshuffle the `eeconfig` definitions and allow for a`uint32_t` here. Will get back to you.