[PATCH v2] HID: usbhid: set mouse as a wakeup resource

[PATCH v2] HID: usbhid: set mouse as a wakeup resource

[Mario Limonciello]

The USB HID transport layer doesn't set mice for wakeup by default so users
can not wake system from s2idle using wired USB mouse. However, users can
wake the same system from Modern Standby on Windows with the same wired
USB mouse.

Microsoft documentation indicates that all USB mice and touchpads should
be waking the system from Modern Standby. To align expectations from users
make this behavior the same when the system is configured by the OEM and
the user to use s2idle in Linux.

Link: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-wake-sources#input-devices-1
Link: https://lore.kernel.org/linux-usb/20220404214557.3329796-1-richard.gong@amd.com/
Suggested-by: Richard Gong <richard.gong@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
More people keep coming to us confused that they couldn't wake a Linux system
up from sleep using a mouse, so this patch is being revived.

Microsoft documentation doesn't indicate any allowlist for this behavior, and
they actually prescribe it for all USB mice and touchpads.
v1->v2:
 * Resubmit by Mario
 * Update commit message
 * Only activate on systems configured by user and OEM for using s2idle

 drivers/hid/usbhid/hid-core.c | 36 ++++++++++++++++++++++++-----------
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 4490e2f7252a..3a1214ecec49 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -12,6 +12,7 @@
 /*
  */
 
+#include <linux/acpi.h>
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/init.h>
@@ -26,6 +27,7 @@
 #include <linux/wait.h>
 #include <linux/workqueue.h>
 #include <linux/string.h>
+#include <linux/suspend.h>
 
 #include <linux/usb.h>
 
@@ -1176,17 +1178,29 @@ static int usbhid_start(struct hid_device *hid)
 		usb_autopm_put_interface(usbhid->intf);
 	}
 
-	/* Some keyboards don't work until their LEDs have been set.
-	 * Since BIOSes do set the LEDs, it must be safe for any device
-	 * that supports the keyboard boot protocol.
-	 * In addition, enable remote wakeup by default for all keyboard
-	 * devices supporting the boot protocol.
-	 */
-	if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT &&
-			interface->desc.bInterfaceProtocol ==
-				USB_INTERFACE_PROTOCOL_KEYBOARD) {
-		usbhid_set_leds(hid);
-		device_set_wakeup_enable(&dev->dev, 1);
+	if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT) {
+		switch (interface->desc.bInterfaceProtocol) {
+		/* Some keyboards don't work until their LEDs have been set.
+		 * Since BIOSes do set the LEDs, it must be safe for any device
+		 * that supports the keyboard boot protocol.
+		 * In addition, enable remote wakeup by default for all keyboard
+		 * devices supporting the boot protocol.
+		 */
+		case USB_INTERFACE_PROTOCOL_KEYBOARD:
+			usbhid_set_leds(hid);
+			device_set_wakeup_enable(&dev->dev, 1);
+			break;
+#ifdef CONFIG_ACPI
+		/* Setup remote wakeup by default for mice supporting boot
+		 * protocol if the system supports s2idle
+		 */
+		case USB_INTERFACE_PROTOCOL_MOUSE:
+			if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0 &&
+			    pm_suspend_default_s2idle())
+				device_set_wakeup_enable(&dev->dev, 1);
+			break;
+#endif
+		}
 	}
 
 	mutex_unlock(&usbhid->mutex);
-- 
2.34.1

Re: [PATCH v2] HID: usbhid: set mouse as a wakeup resource

[Greg KH]

On Thu, Jun 16, 2022 at 01:31:42PM -0500, Mario Limonciello wrote:
> The USB HID transport layer doesn't set mice for wakeup by default so users
> can not wake system from s2idle using wired USB mouse. However, users can
> wake the same system from Modern Standby on Windows with the same wired
> USB mouse.
> 
> Microsoft documentation indicates that all USB mice and touchpads should
> be waking the system from Modern Standby. To align expectations from users
> make this behavior the same when the system is configured by the OEM and
> the user to use s2idle in Linux.
> 
> Link: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-wake-sources#input-devices-1
> Link: https://lore.kernel.org/linux-usb/20220404214557.3329796-1-richard.gong@amd.com/
> Suggested-by: Richard Gong <richard.gong@amd.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> More people keep coming to us confused that they couldn't wake a Linux system
> up from sleep using a mouse, so this patch is being revived.

How many different devices did you test this on?

> 
> Microsoft documentation doesn't indicate any allowlist for this behavior, and
> they actually prescribe it for all USB mice and touchpads.
> v1->v2:
>  * Resubmit by Mario
>  * Update commit message
>  * Only activate on systems configured by user and OEM for using s2idle
> 
>  drivers/hid/usbhid/hid-core.c | 36 ++++++++++++++++++++++++-----------
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 4490e2f7252a..3a1214ecec49 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -12,6 +12,7 @@
>  /*
>   */
>  
> +#include <linux/acpi.h>
>  #include <linux/module.h>
>  #include <linux/slab.h>
>  #include <linux/init.h>
> @@ -26,6 +27,7 @@
>  #include <linux/wait.h>
>  #include <linux/workqueue.h>
>  #include <linux/string.h>
> +#include <linux/suspend.h>
>  
>  #include <linux/usb.h>
>  
> @@ -1176,17 +1178,29 @@ static int usbhid_start(struct hid_device *hid)
>  		usb_autopm_put_interface(usbhid->intf);
>  	}
>  
> -	/* Some keyboards don't work until their LEDs have been set.
> -	 * Since BIOSes do set the LEDs, it must be safe for any device
> -	 * that supports the keyboard boot protocol.
> -	 * In addition, enable remote wakeup by default for all keyboard
> -	 * devices supporting the boot protocol.
> -	 */
> -	if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT &&
> -			interface->desc.bInterfaceProtocol ==
> -				USB_INTERFACE_PROTOCOL_KEYBOARD) {
> -		usbhid_set_leds(hid);
> -		device_set_wakeup_enable(&dev->dev, 1);
> +	if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT) {
> +		switch (interface->desc.bInterfaceProtocol) {
> +		/* Some keyboards don't work until their LEDs have been set.
> +		 * Since BIOSes do set the LEDs, it must be safe for any device
> +		 * that supports the keyboard boot protocol.
> +		 * In addition, enable remote wakeup by default for all keyboard
> +		 * devices supporting the boot protocol.
> +		 */
> +		case USB_INTERFACE_PROTOCOL_KEYBOARD:
> +			usbhid_set_leds(hid);
> +			device_set_wakeup_enable(&dev->dev, 1);
> +			break;
> +#ifdef CONFIG_ACPI

Why a #ifdef?

> +		/* Setup remote wakeup by default for mice supporting boot
> +		 * protocol if the system supports s2idle
> +		 */
> +		case USB_INTERFACE_PROTOCOL_MOUSE:
> +			if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0 &&

That seems odd, there's no acpi/pm call for this instead?

> +			    pm_suspend_default_s2idle())
> +				device_set_wakeup_enable(&dev->dev, 1);
> +			break;
> +#endif

thanks,

greg k-h

Re: [PATCH v2] HID: usbhid: set mouse as a wakeup resource

[Limonciello, Mario]

On 6/16/2022 16:28, Greg KH wrote:
> On Thu, Jun 16, 2022 at 01:31:42PM -0500, Mario Limonciello wrote:
>> The USB HID transport layer doesn't set mice for wakeup by default so users
>> can not wake system from s2idle using wired USB mouse. However, users can
>> wake the same system from Modern Standby on Windows with the same wired
>> USB mouse.
>>
>> Microsoft documentation indicates that all USB mice and touchpads should
>> be waking the system from Modern Standby. To align expectations from users
>> make this behavior the same when the system is configured by the OEM and
>> the user to use s2idle in Linux.
>>
>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdesign%2Fdevice-experiences%2Fmodern-standby-wake-sources%23input-devices-1&data=05%7C01%7Cmario.limonciello%40amd.com%7C98b9958eb5304304fcbf08da4fdf1cdf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910116925045711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZI7wX9jq38V0bNZFjca2qbVZrU4frillcrZ6WEGEn%2FQ%3D&reserved=0
>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-usb%2F20220404214557.3329796-1-richard.gong%40amd.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C98b9958eb5304304fcbf08da4fdf1cdf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910116925045711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tt1eHDJqtKybfNw8XDF9ZFCuAMJJEotOB2NnGuXItA8%3D&reserved=0
>> Suggested-by: Richard Gong <richard.gong@amd.com>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>> More people keep coming to us confused that they couldn't wake a Linux system
>> up from sleep using a mouse, so this patch is being revived.
> 
> How many different devices did you test this on?

I tested it on all the mice I have at my disposal and the AMD systems I 
have that support s2idle on top of 5.19-rc2.  As the code path doesn't 
run without s2idle any more I didn't look at that.

Mostly Logitech, a few no-name brands.  Both wireless (via a proprietary 
dongle) and wired.
Richard tested (the earlier version of it) on what he had available to 
him.  A few other people in AMD tested a variant of it with the mice 
they had as well.

I know you have concerns from the previous version on test coverage and 
I feel that if this is accepted it will get a lot more testing in the 
various labs from other companies as well.  We can put some explicit 
calls to testing on this early on in in the RC cycle to try to encourage 
more testing.

> 
>>
>> Microsoft documentation doesn't indicate any allowlist for this behavior, and
>> they actually prescribe it for all USB mice and touchpads.
>> v1->v2:
>>   * Resubmit by Mario
>>   * Update commit message
>>   * Only activate on systems configured by user and OEM for using s2idle
>>
>>   drivers/hid/usbhid/hid-core.c | 36 ++++++++++++++++++++++++-----------
>>   1 file changed, 25 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
>> index 4490e2f7252a..3a1214ecec49 100644
>> --- a/drivers/hid/usbhid/hid-core.c
>> +++ b/drivers/hid/usbhid/hid-core.c
>> @@ -12,6 +12,7 @@
>>   /*
>>    */
>>   
>> +#include <linux/acpi.h>
>>   #include <linux/module.h>
>>   #include <linux/slab.h>
>>   #include <linux/init.h>
>> @@ -26,6 +27,7 @@
>>   #include <linux/wait.h>
>>   #include <linux/workqueue.h>
>>   #include <linux/string.h>
>> +#include <linux/suspend.h>
>>   
>>   #include <linux/usb.h>
>>   
>> @@ -1176,17 +1178,29 @@ static int usbhid_start(struct hid_device *hid)
>>   		usb_autopm_put_interface(usbhid->intf);
>>   	}
>>   
>> -	/* Some keyboards don't work until their LEDs have been set.
>> -	 * Since BIOSes do set the LEDs, it must be safe for any device
>> -	 * that supports the keyboard boot protocol.
>> -	 * In addition, enable remote wakeup by default for all keyboard
>> -	 * devices supporting the boot protocol.
>> -	 */
>> -	if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT &&
>> -			interface->desc.bInterfaceProtocol ==
>> -				USB_INTERFACE_PROTOCOL_KEYBOARD) {
>> -		usbhid_set_leds(hid);
>> -		device_set_wakeup_enable(&dev->dev, 1);
>> +	if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT) {
>> +		switch (interface->desc.bInterfaceProtocol) {
>> +		/* Some keyboards don't work until their LEDs have been set.
>> +		 * Since BIOSes do set the LEDs, it must be safe for any device
>> +		 * that supports the keyboard boot protocol.
>> +		 * In addition, enable remote wakeup by default for all keyboard
>> +		 * devices supporting the boot protocol.
>> +		 */
>> +		case USB_INTERFACE_PROTOCOL_KEYBOARD:
>> +			usbhid_set_leds(hid);
>> +			device_set_wakeup_enable(&dev->dev, 1);
>> +			break;
>> +#ifdef CONFIG_ACPI
> 
> Why a #ifdef?

AFAICT acpi_gbl_FADT is only available when CONFIG_ACPI is defined.  I 
didn't think it was reasonable to make usbhid depend on ACPI.

> 
>> +		/* Setup remote wakeup by default for mice supporting boot
>> +		 * protocol if the system supports s2idle
>> +		 */
>> +		case USB_INTERFACE_PROTOCOL_MOUSE:
>> +			if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0 &&
> 
> That seems odd, there's no acpi/pm call for this instead?

No, there's not.  You'll find checking of this bit in about 8 other 
places too.

I probably should explain the difference from this and 
pm_suspend_default_s2idle:

acpi_gbl_FADT-> There is a bit in here indicating that the system 
supports low power idle.
This bit is set by the OEM and is used to indicate that the system
should use the special ACPI LPS0 device and should prefer s2idle over
s3 if both are present.

pm_suspend_default_s2idle-> This means that the system has been 
configured to s2idle after processing the kernel command line.
If the system offers both S3 and S2idle, users can override what's in
the FADT to set the default as they desire.
This is also how i8042 decides to set keyboard wakeups only in s2idle
mode.

> 
>> +			    pm_suspend_default_s2idle())
>> +				device_set_wakeup_enable(&dev->dev, 1);
>> +			break;
>> +#endif
> 
> thanks,
> 
> greg k-h

Re: [PATCH v2] HID: usbhid: set mouse as a wakeup resource

[Alan Stern]

On Thu, Jun 16, 2022 at 11:28:05PM +0200, Greg KH wrote:
> On Thu, Jun 16, 2022 at 01:31:42PM -0500, Mario Limonciello wrote:
> > The USB HID transport layer doesn't set mice for wakeup by default so users
> > can not wake system from s2idle using wired USB mouse. However, users can
> > wake the same system from Modern Standby on Windows with the same wired
> > USB mouse.
> > 
> > Microsoft documentation indicates that all USB mice and touchpads should
> > be waking the system from Modern Standby. To align expectations from users
> > make this behavior the same when the system is configured by the OEM and
> > the user to use s2idle in Linux.
> > 
> > Link: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-wake-sources#input-devices-1
> > Link: https://lore.kernel.org/linux-usb/20220404214557.3329796-1-richard.gong@amd.com/
> > Suggested-by: Richard Gong <richard.gong@amd.com>
> > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > ---
> > More people keep coming to us confused that they couldn't wake a Linux system
> > up from sleep using a mouse, so this patch is being revived.
> 
> How many different devices did you test this on?

Another issue is whether wakeup for a mouse means pressing a button or 
just moving the mouse.  For a mouse that uses LEDs to sense motion, 
moving it won't generate a wakeup request -- USB suspend does not allow 
the mouse to use enough current to keep the LEDs illuminated.  On the 
other hand, there's no reason why wakeup by pressing a button shouldn't 
always work.

Also, the patch description doesn't seem to appreciate the difference 
between the default value for the wakeup setting and actually supporting 
wakeup.  As long as the hardware supports it, the default wakeup setting 
doesn't matter all that much, because the user can change the setting 
during system startup or whenever he wants.  But if the hardware doesn't 
support wakeup then the default setting makes no difference at all.

Alan Stern

RE: [PATCH v2] HID: usbhid: set mouse as a wakeup resource

[David Laight]

From: Alan Stern
> Sent: 17 June 2022 16:05
...
> Another issue is whether wakeup for a mouse means pressing a button or
> just moving the mouse.  For a mouse that uses LEDs to sense motion,
> moving it won't generate a wakeup request -- USB suspend does not allow
> the mouse to use enough current to keep the LEDs illuminated.  On the
> other hand, there's no reason why wakeup by pressing a button shouldn't
> always work.

I'm not even sure I want a system to wake up because it's mouse
gets knocked.
I guess a mouse could include accelerometers so that you can shake it!

I've an idea that one of my systems manages to boot if the mouse
is knocked (and it was last shutdown from windows).
At least, that it why I think it is sometimes booting up.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH v2] HID: usbhid: set mouse as a wakeup resource

[Limonciello, Mario]

On 6/17/2022 10:39, David Laight wrote:
> From: Alan Stern
>> Sent: 17 June 2022 16:05
> ...
>> Another issue is whether wakeup for a mouse means pressing a button or
>> just moving the mouse.  For a mouse that uses LEDs to sense motion,
>> moving it won't generate a wakeup request -- USB suspend does not allow
>> the mouse to use enough current to keep the LEDs illuminated.  On the
>> other hand, there's no reason why wakeup by pressing a button shouldn't
>> always work.
> 

At least one of the Logitech wireless mice I have here works to wake 
either by clicking the buttons or moving the mouse, presumably because 
the mouse is battery powered.  One of my wired ones works only by 
clicking (which is as you describe).

I don't believe there is going to be a way to have granularity of which 
type of event will wake the system; it will be hardware dependent.

> I'm not even sure I want a system to wake up because it's mouse
> gets knocked.
> I guess a mouse could include accelerometers so that you can shake it!
> 

I'm completely opposite.  As soon as I sit down at my desk which has a a 
closed docked laptop, the first thing I do is use the mouse which will 
wake the system.

And if you take a step further and consider desktops if you *don't* do 
this you'll have to find your power button or use the keyboard.

> I've an idea that one of my systems manages to boot if the mouse
> is knocked (and it was last shutdown from windows).
> At least, that it why I think it is sometimes booting up.
> 

It was probably hibernated from Windows rather than shutdown.  Windows 
tends to make this "invisible" to the user.  Some systems can wake from 
S4 on certain devices, and I would expect some registers on your system 
have been programmed to work that way.

Re: [PATCH v2] HID: usbhid: set mouse as a wakeup resource

['Alan Stern']

On Fri, Jun 17, 2022 at 11:06:05AM -0500, Limonciello, Mario wrote:
> On 6/17/2022 10:39, David Laight wrote:
> > From: Alan Stern
> > > Sent: 17 June 2022 16:05
> > ...
> > > Another issue is whether wakeup for a mouse means pressing a button or
> > > just moving the mouse.  For a mouse that uses LEDs to sense motion,
> > > moving it won't generate a wakeup request -- USB suspend does not allow
> > > the mouse to use enough current to keep the LEDs illuminated.  On the
> > > other hand, there's no reason why wakeup by pressing a button shouldn't
> > > always work.
> > 
> 
> At least one of the Logitech wireless mice I have here works to wake either
> by clicking the buttons or moving the mouse, presumably because the mouse is
> battery powered.  One of my wired ones works only by clicking (which is as
> you describe).
> 
> I don't believe there is going to be a way to have granularity of which type
> of event will wake the system; it will be hardware dependent.

Precisely.  So if the point of the patch is to match users' 
expectations, and some users expect to be able to wake up their systems 
by moving the mouse but their mouse is like yours, then the situation is 
hopeless and the patch won't help.

> > I'm not even sure I want a system to wake up because it's mouse
> > gets knocked.
> > I guess a mouse could include accelerometers so that you can shake it!
> > 
> 
> I'm completely opposite.  As soon as I sit down at my desk which has a a
> closed docked laptop, the first thing I do is use the mouse which will wake
> the system.
> 
> And if you take a step further and consider desktops if you *don't* do this
> you'll have to find your power button or use the keyboard.

The usual counterexample is laptop-in-a-knapsack.  You don't want the 
laptop to wake up just because the knapsack was picked up and that 
jostled the mouse.

Overall, it seems like this patch needs a better justification.

Alan Stern

> > I've an idea that one of my systems manages to boot if the mouse
> > is knocked (and it was last shutdown from windows).
> > At least, that it why I think it is sometimes booting up.
> > 
> 
> It was probably hibernated from Windows rather than shutdown.  Windows tends
> to make this "invisible" to the user.  Some systems can wake from S4 on
> certain devices, and I would expect some registers on your system have been
> programmed to work that way.

Re: [PATCH v2] HID: usbhid: set mouse as a wakeup resource

[Limonciello, Mario]

On 6/17/2022 12:39, 'Alan Stern' wrote:
> On Fri, Jun 17, 2022 at 11:06:05AM -0500, Limonciello, Mario wrote:
>> On 6/17/2022 10:39, David Laight wrote:
>>> From: Alan Stern
>>>> Sent: 17 June 2022 16:05
>>> ...
>>>> Another issue is whether wakeup for a mouse means pressing a button or
>>>> just moving the mouse.  For a mouse that uses LEDs to sense motion,
>>>> moving it won't generate a wakeup request -- USB suspend does not allow
>>>> the mouse to use enough current to keep the LEDs illuminated.  On the
>>>> other hand, there's no reason why wakeup by pressing a button shouldn't
>>>> always work.
>>>
>>
>> At least one of the Logitech wireless mice I have here works to wake either
>> by clicking the buttons or moving the mouse, presumably because the mouse is
>> battery powered.  One of my wired ones works only by clicking (which is as
>> you describe).
>>
>> I don't believe there is going to be a way to have granularity of which type
>> of event will wake the system; it will be hardware dependent.
> 
> Precisely.  So if the point of the patch is to match users'
> expectations, and some users expect to be able to wake up their systems
> by moving the mouse but their mouse is like yours, then the situation is
> hopeless and the patch won't help.
> 
>>> I'm not even sure I want a system to wake up because it's mouse
>>> gets knocked.
>>> I guess a mouse could include accelerometers so that you can shake it!
>>>
>>
>> I'm completely opposite.  As soon as I sit down at my desk which has a a
>> closed docked laptop, the first thing I do is use the mouse which will wake
>> the system.
>>
>> And if you take a step further and consider desktops if you *don't* do this
>> you'll have to find your power button or use the keyboard.
> 
> The usual counterexample is laptop-in-a-knapsack.  You don't want the
> laptop to wake up just because the knapsack was picked up and that
> jostled the mouse.

But who puts their laptop into their bag with a USB mouse plugged in?

I could see leaving your Logitech dongle plugged in and forgetting to 
turn off the mouse before you tossed it in your bag.  However, the same 
problem can happen with a travel USB keyboard you forgot to turn off.
That's already set to wakeup by default today.

> 
> Overall, it seems like this patch needs a better justification.
> 
> Alan Stern
> 
>>> I've an idea that one of my systems manages to boot if the mouse
>>> is knocked (and it was last shutdown from windows).
>>> At least, that it why I think it is sometimes booting up.
>>>
>>
>> It was probably hibernated from Windows rather than shutdown.  Windows tends
>> to make this "invisible" to the user.  Some systems can wake from S4 on
>> certain devices, and I would expect some registers on your system have been
>> programmed to work that way.