rgb_matrix: add optional split EEPROM sync#26027
rgb_matrix: add optional split EEPROM sync#26027optix2000 wants to merge 1 commit intoqmk:developfrom
Conversation
|
Not sure I agree with this; it becomes a very slippery slope. At some people someone is going to demand default layer sync, then backlight... then haptic config... then later VIA EEPROM sync, and everything in between. I don't think it's generally sustainable. Additionally, if you're running one-handed then swap sides and run the other one-handed -- who wins when you reconnect them? Should there be a periodic resync? |
Fair point, but I also believe that all those features are pretty useful.
I don't think it's possible to do any conflict resolution because the keyboards don't have persistent clocks to determine who has the most recent change. In this case, if you reconnect two halves, whoever is the master when they're connected together wins which I think is a reasonable compromise. Either that or you don't enable the feature because you're using a split keyboard as separate keyboards. |
|
This is something that could be just as easily implemented at the keyboard or user level. And with pretty simple code. And while it's not tzarc's intention, I do agree that the config should be all sync or all not synced. It should be handled consistently and uniformly. It shouldn't be piecemeal, or configurable per feature.
Exactly. there is no way to do any real conflict resolution. And that will create additional undesirable behavior. Also, your keyboards don't have a persistent clock. (I do have working RTC code that I use and have enabled). But is "last update" the correct option, even? What happens when somebody wants different settings for one handed vs two handed mode? It is a lot of questions and a lot of code. And I'm not sure that this is the correct direction for handling all of these. |
Yes and that's what I did for my case and I'm fine with keeping it there, though I felt like it would be a useful feature for everyone. As an aside, the feature is a good bit smaller firmware-wise being in the core compared to being at the keyboard/user level.
That's a pretty big jump in scope. I think it's a good goal for consistency sake if that's the direction you guys want to go, but I think we're putting the cart before the horse here. It seems more risky to big-bang a sync-everything solution over an incremental one, but it's your repo and you can let me know what you want to do here.
My take here is, the current state is already undesirable/unexpected behavior. I may be assuming here, but I think that most people treat a split keyboard as a single keyboard unit. Having it be master agnostic is the more common use-case over the unusual corner case that you provided. And in that example, we can keep the current behavior where each side is not synced for those that prefer split usage.
Unless I'm mistaken, qmk doesn't have native RTC support and it's implemented per-keyboard. I feel like the correct play is to support the lowest common denominator first and RTC for sure is not included there. |
|
I want to make it clear, this is an optional feature that's opt-in. In most of the counter-examples, the current behavior where settings don't sync still provides the same experience for those users. |
3 participants
Description
Add in optional RGB setting persistence across halves.
This ensures that the slave also saves RGB settings in the event you switch which half of a split keyboard is the master (eg. if you switch which side is plugged into the computer).
Adds an EEPROM flag that gets synced across so the slave knows which RGB changes are supposed to be saved to EEPROM.
Tested on a hotdox76v2, so I don't know how well this works on non-AVR keyboards.
Switching RGB colors and then immediately swapping which half is plugged into the computer now keeps the settings.
Issues Fixed or Closed by This PR
Checklist