Also, one thing that has bothered me, is the macros in the dynamic keymap. Personally, I feel that it should be broken out and made separate from the keymaps, as it is a substantially different feature than keymaps.

Additionally, not everyone would want to use it, but more to the point, plenty of people want to use it without the rest of it (for instance, with the existing dynamic macros feature).

However, this is probably outside of the scope of this PR.

@drashna why is this labelled breaking_change?

Because it's a very big change, touching a LOT of files. And because it changes a number of user keymaps

Because it's a very big change, touching a LOT of files. And because it changes a number of user keymaps

imo a breaking change is something that breaks core behavior, changes an API, etc.

This is just a big change. It's not really breaking imo.

Does it really change user keymaps? As far as I can tell, this doesn't modify any user keymaps. Anyone using VIA for their keyboard knows that changes can happen - Wilba is being super nice fixing it for everyone instead of just breaking things and making people fix it themselves. VIA isn't officially publicly supported, so it's "implement at your own risk".

In terms of NEED DOC, I also don't think that's necessary. yet Until VIA is public again, I wouldn't want people adding things on a whim, etc. I agree that docs should be present when the feature is "ready".

These are the changed keymap files that aren't default or via (or some variation). You could argue a few of them are default-ish, but the others seem to be in personal keymaps:

keyboards/hs60/v2/keymaps/goatmaster/rules.mk
keyboards/hs60/v2/keymaps/iso_andys8/rules.mk
keyboards/hs60/v2/keymaps/stanrc85/rules.mk
keyboards/hs60/v2/keymaps/win_osx_dual/rules.mk
keyboards/keebio/iris/keymaps/osiris/rules.mk
keyboards/maartenwut/plain60/keymaps/RGB/rules.mk
keyboards/wilba_tech/rama_works_m10_b/keymaps/knops/config.h
keyboards/wilba_tech/zeal65/keymaps/split_bs/keymap.c

And yeah, we would prefer to see improvements like this broken up into smaller, more manageable logical chunks, as it makes it far easier and faster to review.

Because it's a very big change, touching a LOT of files. And because it changes a number of user keymaps

imo a breaking change is something that breaks core behavior, changes an API, etc.

This is just a big change. It's not really breaking imo.

Upas, if someone dumped a large change at you at work what would your reaction be? We want this as much as you do, but smaller more focused pulled requests are easier to digest and merge. You don't have to agree with the labels, they're mostly there for our workflow.

@drashna Changing EECONFIG_SIZE whenever QMK Core's usage of EEPROM is increased is not only trivial, it gives all QMK users (not just VIA) the ability for their code to auto adapt to any change. It is no different to how the SAFE_RANGE keycode works.

VIA uses the build date as the magic number/version number stored in EEPROM to detect new firmware and cause EEPROM reset to defaults. No system of magic number is perfect, but this is good enough for "official" releases of firmware, which won't happen on the same date, and does not require manual incrementing/decrementing. Also, bootmagic lite will be the recommended way of updating firmware, which makes EEPROM out-of-sync errors even less frequent.

Technically, VIA is at the end of the EEPROM by default, the dynamic keymaps/macros take up the available EEPROM (on ATmega32u4) and it has been designed this way because EEPROM is limited on Atmega32u4, and it is more logical to allocate in an incremental way after QMK Core's EEPROM usage. Allocating from the end of available EEPROM up to QMK Core's EEPROM usage would still require a limit such as EECONFIG_SIZE, so I don't see any advatage in doing this.

At some point, if QMK Core has an API/configuration for EEPROM usage (esp. disabling QMK Core's usage that is not needed for a keyboard), then we can switch to that.

Note also, ARM users could configure where VIA and dynamic keymaps uses EEPROM by overriding symbols.

@zvecr The only changes to "user" keymaps are replacing the redundant rules.mk with one that just enables VIA, which is how the original keymap was configured, even though technically that's a strange combination, wanting your "keymap" stored in the QMK repo but still building VIA enabled firmware. The other changes in keymaps are refactoring the default and via keymaps of PCBs that I maintain or which I put into VIA.

Merged master again.

I have updated @Boy-314 rules.mk (#7638) to the new way of enabling VIA.

Regarding "user" changes, I believe it's better to change them so that they continue to enable VIA as before (i.e. compile with exactly the same feature set), than leave them unchanged and effectively "disable" VIA.

Can someone please review that the changes to these rules.mk are confined to adapting to the new way of enabling VIA?

@andys8 @stanrc85 @mcmadhatter @sidcarter

Some large changes coming in and changes have been made to each of your keymaps. Are you guys ok with the changes to your keymaps?

@mechmerlin changes to hs60/v2/win_osx_dual are fine by me.

@mechmerlin I don't use VIA so I assume this won't affect anything I have in my QMK user space.

@noroadsleft Originally, wt_main.c contained the specifics of VIA protocol, i.e. actually handling messages and routing them to dynamic keymaps functions. My keyboard PCBs (and some others) would include that source file. When @awkannan made Satisfaction 75, he copied that code into satisfaction75.c and extended the protocol for his keyboard specifics (encoder handling, etc.)

This PR refactors the common code that was in wt_main.c and satisfaction75.c into via.c, leaving in those files the specific handling for those keyboards. This is much like how QMK works in other areas, how something like matrix handling can be overridden or extended at the keyboard level with things like strong linked matrix_scan_kb() functions. Thus, via.c handles everything for keyboards that just need the dynamic keymaps and macros handling, and keyboards like Satisfaction 75 can extend upon that by handling only the specific protocol (i.e. what's different) and leaving the common handling to via.c in QMK Core.

@sidcarter @andys8 Pinging you guys again as we need your signoff for this merge, since your user keymaps were impacted. Are you guys ok with the changes to your keymaps?

@Wilba6582 That's pretty much exactly what I thought it was doing. I did compare the parts I didn't understand from each file against each other and saw the minor differences. @awkannan's reminder about VIA working differently on his boards due to hardware changes (OLED, encoder, lighting implementations) made me realize it was all probably stuff that was specific to his PCBs.

Great explanation, and much appreciated. 👍

I'm okay with the changes being made and thankful for your contribution. I've to add I can't currently test the changes and I can't confirm there is no breakage.

@olivia @mechmerlin I'm good with the changes to my keymap 👍

Edit: @awkannan

Also, looking forward to this merge very muchly :D

I approve

Thanks!