My understanding is that each LED can only be assigned to one engine (there's a check in MCE led.c for this that ignores a pattern that tries to assign a led to two engines), so wouldn't a three digit format work? First digit is Red LED, second is Green, third is Blue. For example: 112 = Red + Green on engine1, Blue on Engine 32 111 = All on Engine 1 123 = Red on 1, Green on 2, Blue on 3. then tack on another pattern to the end of the ini string like has already been suggested for the engine3 pattern.
[LED] # List of patterns for the LED functionality # # A list of all pattern names that should be configured LEDPatterns=PatternVboost;PatternError;PatternDeviceOn;PatternPowerOn;PatternPowerOff;PatternCommunicationCall;PatternCommunicationIM;PatternCommunicationSMS;PatternCommunicationEmail;PatternCommonNotification;PatternWebcamActive;PatternBatteryCharging;PatternBatteryFull;PatternDeviceSoftOff;PatternInhibit [LEDPatternLystiRX51] PatternError=0;5;0;r;9d8040005000500040ff0b8c5c000000;9d800000 PatternDeviceOn=254;0;0;gb;9d80400006c509ad23650000;9d800000 PatternDeviceSoftOff=253;0;0;rg;9d804000423f433f7f100000;9d800000 PatternPowerOn=9;3;0;rgb;9d80400042ff02ffc000;9d800000 PatternPowerOff=10;3;0;rgb;9d80400001ff43ff7f007f00c000;9d800000 PatternCommunicationCall=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000 PatternCommunicationIM=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000 PatternCommunicationSMS=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000 PatternCommunicationEmail=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000 PatternCommonNotification=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000 PatternWebcamActive=20;1;0;r;9d80400004ffc0000000;9d800000 PatternBatteryCharging=50;4;0;rg;9d80400020de0dc57f007f0042000000;9d800000 PatternBatteryFull=40;4;0;g;9d80407f0000;9d800000 ###[[new]] [LEDPatternLystiRX51-new-mce] # Section for new MCE. Stock MCE will ignore this section. # New pattern syntax goes here to keep it out of the classical [LEDPatternLystiRX51] section for backward compatibility, though that's not mandatory. # Any pattern in this section overrides a pattern with same name in [LEDPatternLystiRX51] section. # Pattern names in here need to get declared in "[LED] LEDPatterns=..." just like the classical patterns in [LEDPatternLystiRX51] ###[[end-new]] # # Priority (0 - highest, 255 - lowest) # ScreenOn - 0 only show pattern when the display is off # 1 show pattern even when the display is on # 2 only show pattern when the display is off, including acting dead # 3 show pattern even when the display is on, including acting dead # 4 only show pattern if the display is off, or if in acting dead # 5 always show pattern, even if LED disabled # ###[[new]] # Timeout in seconds before pattern is disabled, 0 for infinite - [[++]] decimals allowed: "0.5" = 500ms # LED mux to map each LED to either none (0) or to Engine 1/Engine 2/Engine3 # 1 to 9 digits, short strings get filled to length 9 by appending zeroes # Meaning of each of the 9 positions is: # R G B kbd1 kbd2 kbd3 kbd4 kbd5 kbd6 # # Example: # "031010020" maps the red LED to none, # green LED to engine 3, # blue LED to engine 1, # kbd backlight LED1, 3, 4, 6 to none, # kbd LED2 to engine 1, and kbd LED5 to engine 2 # Do not mix the new mux syntax consisting of digits "0".."3" with the old "rGB" syntax in one pattern! # Engine 1 pattern in Lysti format (31 commands at most) - one step used internally to store muxmap used by 9d80 cmd # Engine 2 pattern in Lysti format (32 commands at most) # Engine 3 pattern in Lysti format (32 commands at most) # empty patters allowed (;;), such empty patterns shall not change the state of the according machine. # A pattern of "-" changes the meaning of "0" in LED mux: an LED previously assigned to this engine will not get reassigned to none when "0" in LED mux #PatternVboost=60;5;0;rB;9d80401a480040d948000000;9d80400b2c900000 PatternVboost=60;5;0;102;9d80401a480040d948000000;9d80400b2c900000 # Kbd fade in 250ms; engine3; patterns for engine1/2 empty+no-remux, thus any pattern running in engine1/2 and using RGB will continue PatternKbdOn=11;5;0.251;000333333;-;-;9d80400003ffc000
# OK, let's get fancy # 9d80 allegedly init for mux. 1001 1101 1000 0000 is mux_map_next # In fact lp5523 driver creates a mux table of one entry length, so # mux_map_next will spin index in one point and will reload same # mapping which is pointed to by mux_ld_start and mux_ld_end # mux_ld_start: 1001 1110 0sss ssss; sssssss = SRAM start addr (0-95) # mux_ld_end: 1001 1100 1sss ssss; sssssss = SRAM end addr (0-95) # lp5523 driver executes a short program to load the mapping # from engineX_leds to the location of mux_ld_start # Later we might want to use mux_sel to associate _ONE_ LED directly: # mux_sel: 1001 1101 0bbb bbbb; bbbbbbb = int (0-16), 0=nothing, # (1-9)=LED1-9; 16=GPO