From: Luke Jones <luke@ljones.dev>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
Mark Gross <markgross@kernel.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/6] asus-wmi: Implement TUF laptop keyboard LED modes
Date: Tue, 09 Aug 2022 09:43:32 +1200 [thread overview]
Message-ID: <KCGBGR.P2V4UO7HLOX11@ljones.dev> (raw)
In-Reply-To: <CAHp75VcR-strGDhaGE78NjToamK98e8UO-rQhU-Ow81AavU5YA@mail.gmail.com>
Hi Andy,
>
>> + if (sscanf(buf, "%hhd %hhd %hhd", &save, &mode, &speed) !=
>> 3)
>> + return -EINVAL;
>
> Same comment as per v1.
>
You wrote:
> Usually we have three separate nodes for that, but they are kinda
> hidden in one driver, so I don't care much.
I think that is the wrong direction to take. Doing so would mean that
every write to one of these values has to write-out to device. I don't
know how long writes on an i2c device take, but on the USB connected
versions they are 1ms, which means that to individually set colour,
save, mode, speed (also direction and sometimes a 2nd colour on USB)
adds up to 4-6ms - and I don't know what sort of impact that has in the
kernel itself, but I do know that users expect there to be fancy
effects available on par with Windows (like audio equalizer visuals on
the RGB, something that is in progress in asusctl).
Using multicolor LED class already breaks away from having a single
packet write, but the gain in API scope was worth the compromise.
Hopefully we can keep the single set of parameters here?
Pavel suggested using triggers, I've yet to look at that, but will do
so after finalising this.
I suppose one alternative would be to store speed and mode as
attributes, but not write out until the "save" node is written to? So
this raises the question of: we can't read from device, and speed+mode
must be saved in module for use with "save" now, should I then allow
showing these values in a _show? On fresh boot they will be incorrect..
I'm going to go ahead and split those parameters in to individual nodes
now anyway - it may help with later work using triggers.
> ...
>
>> + asus->keyboard_rgb_mode.mode = mode < 12 && mode != 9 ?
>> mode : 0x0a;
>
> Same comment as per v1.
>
I missed it sorry. Done now.
> ...
>
>> + switch (speed) {
>> + case 0:
>> + asus->keyboard_rgb_mode.speed = 0xe1;
>> + break;
>> + case 1:
>> + asus->keyboard_rgb_mode.speed = 0xeb;
>> + break;
>> + case 2:
>> + asus->keyboard_rgb_mode.speed = 0xf5;
>> + break;
>> + default:
>> + asus->keyboard_rgb_mode.speed = 0xeb;
>
> break;
Done
>
>> + }
>
> ...
>
>> +
>
> A blank line is not needed here.
Okay thanks, I'll go through previous patches and check this.
Kind regards,
Luke.
>
next prev parent reply other threads:[~2022-08-08 21:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 3:04 [PATCH v2 0/6] asus-wmi: Add support for RGB keyboards Luke D. Jones
2022-08-08 3:04 ` [PATCH v2 1/6] asus-wmi: Implement TUF laptop keyboard RGB control Luke D. Jones
2022-08-08 3:04 ` [PATCH v2 2/6] asus-wmi: Implement TUF laptop keyboard LED modes Luke D. Jones
2022-08-08 16:01 ` Andy Shevchenko
2022-08-08 21:43 ` Luke Jones [this message]
2022-08-09 7:20 ` Andy Shevchenko
2022-08-08 3:04 ` [PATCH v2 3/6] asus-wmi: Implement TUF laptop keyboard power states Luke D. Jones
2022-08-08 16:08 ` Andy Shevchenko
2022-08-08 23:27 ` Luke Jones
2022-08-09 8:29 ` Andy Shevchenko
2022-08-09 22:25 ` Luke Jones
2022-08-08 3:04 ` [PATCH v2 4/6] asus-wmi: Document previously added attributes Luke D. Jones
2022-08-08 16:11 ` Andy Shevchenko
2022-08-08 3:04 ` [PATCH v2 5/6] asus-wmi: Convert all attr-show to use sysfs_emit Luke D. Jones
2022-08-08 16:13 ` Andy Shevchenko
2022-08-08 3:04 ` [PATCH v2 6/6] asus-wmi: Add support for dGPU-only mode Luke D. Jones
2022-08-08 8:38 ` Luke Jones
2022-08-08 15:44 ` Andy Shevchenko
2022-08-08 3:26 ` [PATCH v2 0/6] asus-wmi: Add support for RGB keyboards Luke Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=KCGBGR.P2V4UO7HLOX11@ljones.dev \
--to=luke@ljones.dev \
--cc=andy.shevchenko@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox