RE: [PATCH] HID: usbhid: enable remote wakeup for mice

[Limonciello, Mario]

[AMD Official Use Only - General]



> -----Original Message-----
> From: Oliver Neukum <oneukum@xxxxxxxx>
> Sent: Thursday, February 23, 2023 06:02
> To: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>; Michael Wu
> <michael@xxxxxxxxxxxxxxxxx>
> Cc: jikos@xxxxxxxxxx; benjamin.tissoires@xxxxxxxxxx; linux-
> usb@xxxxxxxxxxxxxxx; linux-input@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; Limonciello, Mario <Mario.Limonciello@xxxxxxx>;
> Gong, Richard <Richard.Gong@xxxxxxx>
> Subject: Re: [PATCH] HID: usbhid: enable remote wakeup for mice
> 
> On 23.02.23 12:23, Greg KH wrote:
> 
> >> I just want to explain the background of my patch, to prove we could use
> a
> >> similar way to avoid such a "disturbing" situation.
> >> To reduce the influence, my patch enables remote wakeup for USB
> mouse
> >> devices refer to what keyboard do.
> >
> > Keyboards are not mice :)
> >
> 
> OK, let me explain, why I never proposed switching on autosuspend
> for mice or using them as a system wakeup source. The reasons are very
> similar.
> 
> Basically the standard gives us no way to ask a device what constitutes
> a wakeup event for it. We just get the blanket statement of support
> or no support.
> 
> For runtime PM I would want my mouse to generate a remote wakeup
> whenever a button is pressed or the mouse is moved. Under this
> premise runtime PM with a mouse works wonderfully. Testing that,
> however, is a challenge.
> It turns out that mice that claim that they support remote wakeup
> by and large deactivate their LED/laser when you send them into
> suspension. Hence they react only to buttons being pressed or mouse
> wheels moved.
> 
> 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.

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"
* 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

With that type of policy on how to handle the suspend call in place
perhaps we could set it to enabled by default?

> 
> I suspect that most, but _not_ _all_ mice, are designed for use
> with a system that ties power management to the screen saver.
> That is a mode of operation that due to the lack of coupling
> between GUI and kernel is hard to copy.
> 
> Frankly given these constraints the only default safe in every
> case seems to me to leave the kernel's default at off and
> put the work into udev's hwdb. Not that that is a good solution,
> merely the best I can come up with.
> 
> 	Regards
> 		Oliver

Turning on "autosuspend" for USB mice makes them behave pretty
similarly to how they work when they're marked for remote wakeup.

On some mice the lasers turn off, and they only wakeup when you
press a button or roll a wheel.