public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: 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, mario.limonciello@amd.com,
	richard.gong@amd.com
Subject: Re: [PATCH] HID: usbhid: enable remote wakeup for mice
Date: Thu, 23 Feb 2023 12:23:23 +0100	[thread overview]
Message-ID: <Y/dMq2KKYfdMdrjh@kroah.com> (raw)
In-Reply-To: <9bf4463c-6541-a6cb-9bbc-6d070118509a@allwinnertech.com>

On Thu, Feb 23, 2023 at 07:18:12PM +0800, Michael Wu wrote:
> Dear Greg,
> 
> On 2/22/2023 2:04 PM, Greg KH wrote:
> > On Wed, Feb 22, 2023 at 09:39:44AM +0800, Michael Wu wrote:
> > > This patch fixes a problem that USB mouse can't wake up the device that
> > > enters standby.
> > 
> > This not a problem, it is that way by design.
> 
> I got it, maybe it's a little problem to say that.

It is.

> > > At present, the kernel only checks whether certain USB manufacturers
> > > support wake-up, which will easily cause inconvenience to the
> > > development work of other manufacturers and add unnecessary work to the
> > > maintenance of kernel.
> > > 
> > > The USB protocol supports judging whether a usb supports the wake-up
> > > function, so it should be more reasonable to add a wake-up source by
> > > directly checking the settings from the USB protocol.
> > 
> > But you do not do that in this patch, why not?
> 
> 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 :)

> > > There was a similar issue on the keyboard before, which was fixed by
> > > this patch (3d61510f4eca), but now the problem happened on the mouse.
> > > This patch uses a similar idea to fix this problem.
> > > 
> > > Signed-off-by: Michael Wu <michael@allwinnertech.com>
> > > ---
> > >   drivers/hid/usbhid/hid-core.c | 8 ++++++++
> > >   drivers/hid/usbhid/usbmouse.c | 1 +
> > >   2 files changed, 9 insertions(+)
> > > 
> > > diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> > > index be4c731aaa65..d3a6755cca09 100644
> > > --- a/drivers/hid/usbhid/hid-core.c
> > > +++ b/drivers/hid/usbhid/hid-core.c
> > > @@ -1189,6 +1189,14 @@ static int usbhid_start(struct hid_device *hid)
> > >   		device_set_wakeup_enable(&dev->dev, 1);
> > >   	}
> > > +	/**
> > > +	 * NOTE: enable remote wakeup by default for all mouse devices
> > > +	 * supporting the boot protocol.
> > > +	 */
> > > +	if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT &&
> > > +	    interface->desc.bInterfaceProtocol == USB_INTERFACE_PROTOCOL_MOUSE)
> > > +		device_set_wakeup_enable(&dev->dev, 1);
> > 
> > Sorry, but we can not take this unless it is proven that this will work
> > properly for all of these devices.  Other operating systems do not do
> > this last I checked, so there will be problems.
> 
> As Mario Limonciello says, they has confirmed that the Microsoft Windows
> does set a similar policy as well. Can we talk about more in this topic: why
> does Linux not support it?
> Of course, if you have other great idea, I will appreciate that if we can
> have some further discussion.

You need to provide some sort of "proof" that this has been heavily
tested on a huge range of devices before we can change this.

When this was first implemented, Windows did not work this way and many
devices on the market were broken if this were to be enabled.  I'm sure
the mailing list archives from 20+ years ago have many more details,
please dig around there for specifics.

If you feel strongly that this is the way forward, why not do it in
userspace today for your systems as part of testing this out?  It should
not require a kernel change, right?

thanks,

greg k-h

  reply	other threads:[~2023-02-23 11:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22  1:39 [PATCH] HID: usbhid: enable remote wakeup for mice Michael Wu
2023-02-22  6:04 ` Greg KH
2023-02-22 19:50   ` Limonciello, Mario
2023-02-23 11:41     ` Oliver Neukum
2023-02-23 11:18   ` Michael Wu
2023-02-23 11:23     ` Greg KH [this message]
2023-02-23 12:01       ` Oliver Neukum
2023-02-23 19:41         ` Limonciello, Mario
2023-02-28  9:03           ` Oliver Neukum
2023-02-28 18:50             ` Limonciello, Mario
2023-02-28 19:05               ` Greg KH
2023-02-28 19:07                 ` Limonciello, Mario
2023-02-24  7:02       ` Michael Wu
2023-02-22  8:59 ` Sergei Shtylyov
2023-02-23  4:01   ` Michael Wu
2023-02-22  9:34 ` Oliver Neukum
2023-02-23 11:22   ` Michael Wu
2023-02-23 11:47     ` Oliver Neukum
  -- strict thread matches above, loose matches on Subject: below --
2011-10-14  7:54 Benson Leung
2011-10-14  8:18 ` Oliver Neukum
2011-10-14 13:56   ` Alan Stern
2011-10-14 14:00     ` Jiri Kosina
2011-10-14 14:58       ` Benson Leung
2011-10-14 15:09         ` Alan Stern
2011-10-15  9:43           ` Oliver Neukum
2011-10-15 19:07             ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y/dMq2KKYfdMdrjh@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=michael@allwinnertech.com \
    --cc=richard.gong@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox