[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lgedr3vr65tlmdt6p7gsd4cqlhgtadu5gj63ibwpzjuaxgrnwt@vlp3utkui3fh>
Date: Tue, 17 Jun 2025 14:45:31 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Matthew Schwartz <matthew.schwartz@...ux.dev>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Add nokbdwakeup quirk and enable it for MSI Claw
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@...il.com> 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.
Thanks.
--
Dmitry
Powered by blists - more mailing lists