From: Michael Wu <michael@allwinnertech.com>
To: Greg KH <gregkh@linuxfoundation.org>
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: Fri, 24 Feb 2023 15:02:04 +0800 [thread overview]
Message-ID: <28256d02-e84f-46ec-3802-f1e8497cb281@allwinnertech.com> (raw)
In-Reply-To: <Y/dMq2KKYfdMdrjh@kroah.com>
Dear Greg:
On 2/23/2023 7:23 PM, Greg KH wrote:
> 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 :)
Sorry, What I wanted to say is that we registered the mouse wake-up
source by referring to the practice of the keyboard.
>
>>>> 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 for your advises. I'm clear now. I will try it in userspace.
>
> thanks,
>
> greg k-h
--
Regards,
Michael Wu
next prev parent reply other threads:[~2023-02-24 7:03 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
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 [this message]
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=28256d02-e84f-46ec-3802-f1e8497cb281@allwinnertech.com \
--to=michael@allwinnertech.com \
--cc=benjamin.tissoires@redhat.com \
--cc=gregkh@linuxfoundation.org \
--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=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;
as well as URLs for NNTP newsgroup(s).