[PATCH] platform/x86: asus-wmi: Allow setting RGB mode on some TUF laptops

[PATCH] platform/x86: asus-wmi: Allow setting RGB mode on some TUF laptops

[Kristian Angelov]

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@nm83.abv.bg/


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@abv.bg>
---
 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

Re: [PATCH] platform/x86: asus-wmi: Allow setting RGB mode on some TUF laptops

[Luke Jones]

On Thu, Jul 13 2023 at 21:04:02 +03:00:00, Kristian Angelov 
<kristiana2000@abv.bg> wrote:
> 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.

My own notes at 
https://gitlab.com/asus-linux/reverse-engineering/-/blob/master/TUF-i2c_laptops/led-rgb.md 
mention these commands, so I'm left wondering how I ended up with `cmd 
= !!cmd;` in the first place.

> 
> See bug report: 
> https://lore.kernel.org/platform-driver-x86/443078148.491022.1677576298133@nm83.abv.bg/
> 
> 
> 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.

I think we would be safe to use 0 and 1 for simplicity and map those to 
0xb3 and 0xb4. That might even have been what I intended in the first 
place. There is nothing in my dumps to indicate the 0 and 1 were inputs 
to the ACPI methods and it looks very much like a mistake made by me - 
the one TUF I managed to get hold of does indeed have `If ((Local0 == 
0xB3))` and `If ((Local0 == 0xB4))` in the ACPI methods.

Cheers,
Luke.

> 
> Signed-off-by: Kristian Angelov <kristiana2000@abv.bg>
> ---
>  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
>