This patch allows for the manual setting of cmd values 0xb3 and 0xb4. This is necessary on some TUF laptops in order to set the RGB mode. This should not break functionality that other machines might depend on. See bug report: https://lore.kernel.org/platform-driver-x86/443078148.491022.1677576298133@xxxxxxxxxxx/ With this you can pass 179 and 180 to the /sys/class/leds interface. I think a better solution would be to somehow detect which devices require these values on driver initialization and then just handle it like before 1 saving to bios and 0 simply setting it. Please CC. Best regard, Kristian Signed-off-by: Kristian Angelov <kristiana2000@xxxxxx> --- drivers/platform/x86/asus-wmi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index 1038dfdcdd32..8d3d283fb306 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -744,7 +744,12 @@ static ssize_t kbd_rgb_mode_store(struct device *dev, if (sscanf(buf, "%d %d %d %d %d %d", &cmd, &mode, &r, &g, &b, &speed) != 6) return -EINVAL; - cmd = !!cmd; + /* + * Some TUF models need B3 for setting the color and B4 for saving to BIOS. + * Keep old functionality for all other values + */ + if (cmd != 0xb3 || cmd != 0xb4) + cmd = !!cmd; /* These are the known usable modes across all TUF/ROG */ if (mode >= 12 || mode == 9) -- 2.40.0
