Message-ID: 
 <CAGwozwFBcmawucqfyTOD-S0Ah6dnKBao75Z3J0K0J3FbVhth-Q@mail.gmail.com>
Date: Mon, 31 Mar 2025 10:35:51 +0200
From: Antheas Kapenekakis <lkml@...heas.dev>
To: "Luke D. Jones" <luke@...nes.dev>
Cc: Jiri Kosina <jikos@...nel.org>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	platform-driver-x86@...r.kernel.org, linux-input@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>, Benjamin Tissoires <bentiss@...nel.org>,
	Corentin Chary <corentin.chary@...il.com>,
 Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v5 09/11] HID: asus: add basic RGB support

On Mon, 31 Mar 2025 at 10:19, Luke D. Jones <luke@...nes.dev> wrote:
>
> On 30/03/25 21:39, Antheas Kapenekakis wrote:
> > On Wed, 26 Mar 2025 at 12:00, Jiri Kosina <jikos@...nel.org> wrote:
> >>
> >> On Wed, 26 Mar 2025, Ilpo Järvinen wrote:
> >>
> >>> You don't need to "pause" for the merge window, in some subsystem
> >>> there's mandatory pause during merge window but I find that unnecessary.
> >>> I know people on pdx86 do review during merge window so no need to wait
> >>> when working with patches related to pdx86. Just don't expect patches
> >>> get applied during the merge window or right after it (the latter tends to
> >>> be the most busiest time of cycle for me) :-).
> >>>
> >>> It's more about the frequency, how often to send a series which is
> >>> relatively large. Large number of versions end up just filling inboxes
> >>> (and patchwork's pending patches list) and we don't have time to read them
> >>> all through so I suggest waiting like 3 days at minimum between versions
> >>> when the series is large or complex to give time to go through the series.
> >>>
> >>> This is not a hard rule, so if there are e.g. many significant changes,
> >>> feel free to "violate" it in that case.
> >>
> >> Exactly. I am unlikely to do much review during the merge window myself,
> >> but I'll pick up the patchset and followup once the merge window is over,
> >> so feel free to keep discussing and polishing it with me on CC :)
> >>
> >> Thanks,
> >
> > I think we have reached a good point with this series. We can pick up
> > again when you guys are ready.
> >
> > I will switch gears and look a bit into msi-wmi-platform for the MSI
> > Claw with Armin and we can revisit this come rc1.
> >
> > Let's try to get through it early in 6.16 so that Luke can also do
> > what he wants to with the Ally, and let's push the oxpec move as well,
> > so I can get those two off my plate.
>
> I see Ilpo and Jiri mentioned no need to pause development. But it does
> look like everything is in good state so far, and no doubt you might
> have some ideas after a few days (plus that did of helpful info asus
> dropped in my lap).
>
> If you do anything significant and would like someone to test on a few
> variety of laptop please let me know privately and I'll do what I can.

Yeah, I think the comments I got so far I could fix in an hour or so,
so I would like some more to pool in.

It is good we have a way to parse the keyboard check [1] now, but all
this boils down to removing the RGB quirk and tweaking how the result
of that function is parsed.

If you have some deadtime atm, you can check the MSI Claw draft I am
working on [2]. It is still too early to send. The fwupd integration
is causing some issues, such as it being picky and requiring all
optional vars are implemented, and I think the potential interference
with shift mode (platform profile in MSI laptops) will be confusing as
well. But the same issues are present in Asus and Lenovo Legion too,
so MSI is not unique in that regard.

Antheas

[1] https://github.com/torvalds/linux/blob/4e82c87058f45e79eeaa4d5bcc3b38dd3dce7209/drivers/hid/hid-asus.c#L402-L434
[2] https://github.com/bazzite-org/patchwork/tree/msi

> Cheers,
> Luke.
>
> > Antheas
> >
> >> --
> >> Jiri Kosina
> >> SUSE Labs
> >>
>

Powered by blists - more mailing lists