If no config file is present, party mode (demo mode) is the default
If “leds disabled” is saved in the config, the LEDs no longer blink/flash at startup before the config file is loaded.
There is now a function to update the LED effect mode once, instead of continuously updating from the system_config.led_effect variable. This give us more control over the LED mode during startup.
When messing with the config file, I noticed that the VT100 toolbar is leaking before config is loaded. I had a fix for that at one point, but it seems like the boot order changed a bit. I’ll investigate that next.
The rgb stuff underwent a huge professionalization, it’s so much nicer now. There was just a tiny bug in the logic of party mode.
I know some people hate the LEDs and I’m happy those folks don’t have to see them anymore (outside the logic analyzer and other modes that use them for status indication).
If there’s a bug, Ian’s just being nice by not saying it was probably my changes which introduced the bug. Thanks for discovering and fixing that, Ian!
I prefer to think it was my bug. It was a nasty consequence of storing everything in the system_config, as well as relying on that to load/save the config settings. It made tracking the effect rotation really ugly, and the impact of that was exposed by your rework in rgb.c.
Unraveling everything was really tough, I poked at it for three days before giving up on an elegant solution. Probably the “correct” way to finish the fix: make the effect variable in rgb.c extern, and then load/save config directly from that and remove the duplicate in system_config. For now, we should have stemmed the tide of “Bus Pirate turned red after update” reports