Messages in this thread | | | From | "Limonciello, Mario" <> | Subject | RE: [PATCH] HID: usbhid: enable remote wakeup for mice | Date | Tue, 28 Feb 2023 18:50:18 +0000 |
| |
[Public]
> -----Original Message----- > From: Oliver Neukum <oneukum@suse.com> > Sent: Tuesday, February 28, 2023 03:03 > To: Limonciello, Mario <Mario.Limonciello@amd.com>; Oliver Neukum > <oneukum@suse.com>; Greg KH <gregkh@linuxfoundation.org>; Michael > Wu <michael@allwinnertech.com> > Cc: jikos@kernel.org; benjamin.tissoires@redhat.com; linux- > usb@vger.kernel.org; linux-input@vger.kernel.org; linux- > kernel@vger.kernel.org; Gong, Richard <Richard.Gong@amd.com> > Subject: Re: [PATCH] HID: usbhid: enable remote wakeup for mice > > On 23.02.23 20:41, Limonciello, Mario wrote: > > Hi, > > >> As a system wakeup source a mouse that generates events when > >> it is moved, however, would make the system unsuspendable, whenever > >> even > >> a bit of vibration is acting on the system. > >> And as S4 is used in many setups to prevent an uncontrolled shutdown > >> at low power, this must work. > > > > At least in my version of the series, this is part of the reason that it was > > only intended to be used with s2idle. > > Yes, that is sensible. If these patches are to be taken at all, that will > be a necessary condition to meet. But it is not sufficient.
Ack.
> > > The kernel driver is well aware of what power state you're in the suspend > > callback (pm_suspend_target_state). > > > > What about if we agreed to treat this one special by examining that? > > > > If the sysfs is set to "enabled" > > If user space needs to manipulate sysfs at all, we can have user space > tell kernel space exactly what to do. Hence I see no point in > conditional interpretations values in sysfs at that point. > > We are discussing the kernel's default here.
Right, I was meaning if the kernel defaulted to enabled or if userspace changed it to enabled to follow this behavior.
> > > * During suspend if your target is s2idle -> program it > > * During suspend if your target is mem -> disable it > > * During suspend if your target is hibernate -> disable it > > To my mind these defaults make sense. > However, do they make much more sense than what we are doing now?
If you're talking about purely "policy default", I think it makes more sense.
Userspace can still change it, and it better aligns with what Windows does out of the box.
> > > With that type of policy on how to handle the suspend call in place > > perhaps we could set it to enabled by default? > > It pains me to say, but I am afraid in that regard the only > decision that will not cause ugly surprises is to follow Windows. > Yet, what is wrong about the current defaults?
I still keep getting inquiries about this where teams that work on the same hardware for Windows and Linux complain about this difference during their testing.
I keep educating them to change it in sysfs (or to use a udev rule), but you have to question if you keep getting something asked about policy over and over if it's actually the right policy.
| |