Re: [PATCH 0/2] Add nokbdwakeup quirk and enable it for MSI Claw

[Matthew Schwartz]

> On Jun 17, 2025, at 2:45 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> 
> On Tue, Jun 17, 2025 at 02:33:34PM -0700, Matthew Schwartz wrote:
>> 
>> 
>>> On Jun 17, 2025, at 1:50 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
>>> 
>>> Hi Matthew,
>>> 
>>> On Mon, Jun 16, 2025 at 10:19:28PM -0700, Matthew Schwartz wrote:
>>>> This patch series aims to solve an issue on the MSI Claw, a series of
>>>> handheld gaming PCs, where their volume buttons will wake the system out
>>>> of s2idle because they are registered via an i8042 keyboard device. This
>>>> is not expected behavior on a handheld device that lacks an actual
>>>> keyboard, as it is very easy to press the volume buttons while handling
>>>> the device in its suspended state. 
>>>> 
>>>> To solve this, introduce a new quirk based on DMI match that will disable
>>>> the wakeup property of an i8042 keyboard device and enable it for current
>>>> MSI Claw models.
>>> 
>>> Why does this need to be done in kernel instead of having a udev rule
>>> to toggle this through sysfs:
>>> 
>>> /sys/devices/platform/i8042/serio0/power/wakeup
>>> 
>>> Thanks.
>> 
>> Yes this would work, but it would also mean relying on individual
>> distros to discover such a udev rule is necessary and figure out how
>> to ship this as a device specific workaround within userspace such
>> that it won’t apply to other devices that do want to maintain i8042
>> keyboard wakeup functionality.
> 
> If you submit the rule to systemd repository then distributions will
> get it when they update to the new systemd release. Very similar to the
> kernel.
> 
> 
>> I will investigate implementing this
>> via udev in some sort of packaged fashion, but a kernel quirk seemed
>> like the better option here in my opinion, especially because a quirk
>> system is already in place for i8042 within the kernel.
>> 
> 
> Quirks in the kernel should be used when they are needed for booting.
> When configuration can be delayed to [early] userspace then we should
> try to use userspace solutions. This way we are not wasting unswappable
> kernel memory.

I see, I will look into implementing this via systemd in that case. Thanks!

> 
> Thanks.
> 
> -- 
> Dmitry