From: Johan Hovold <johan@kernel.org>
To: Lauri Jakku <lauri.jakku@pp.inet.fi>
Cc: Jiri Kosina <jikos@kernel.org>, Johan Hovold <johan@kernel.org>,
Lauri Jakku <lja@iki.fi>,
oneukum@suse.com, benjamin.tissoires@redhat.com,
linux-input@vger.kernel.org, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH v2] USB: HID: random timeout failures tackle try.
Date: Tue, 4 Feb 2020 16:05:16 +0100 [thread overview]
Message-ID: <20200204150516.GN26725@localhost> (raw)
In-Reply-To: <3bb9f515-a5c6-3162-be5d-f9f984969882@pp.inet.fi>
On Tue, Feb 04, 2020 at 02:55:41PM +0200, Lauri Jakku wrote:
>
> On 4.2.2020 14.43, Jiri Kosina wrote:
> > On Tue, 4 Feb 2020, Johan Hovold wrote:
> >
> >>> Why modify usb-hid-core: No need to modify driver by driver.
> >> Because you cannot decide how every use should handle timeouts.
> >>
> >> Just fix up the driver that needs this.
>
> I think that if the device is left to errorneus state without
> re-trying, it shows up to user very annoying. For example:
> My mouse now has the problem with buttons: if i click left
> button -> nothing may happen, and it is not functioning until
> right button is pressed once. I make adaption to divide the
> timeout by 100, and keep the try-loop in core.
>
> I dont have list all the drivers that needs this -> better fix at
> one common place.
No, that's precisely my point. You cannot force this behaviour onto
every user of control requests.
Different devices need different handling, that's why this must be per
driver or possibly implemented as a device quirk as Jiri suggested.
But we need a better description of the problem first. Is this an issue
also during enumeration, or only after when you use your mouse?
And exactly which control requests are failing here? Your example above
doesn't seem to involve any such requests (only interrupt URB
completions).
> > I believe it will actually not be a particular driver, but perhaps a set
> > of devices with b0rked USB implementation, and we could just introduce
> > (another, oh well) per-device quirk list if needed.
> >
> > Do we have any idea / indication how many devices out there actually
> > require this?
> Well i'd say quite many.
What do you base that on?
Johan
prev parent reply other threads:[~2020-02-04 15:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 11:06 [PATCH v2] USB: HID: random timeout failures tackle try Lauri Jakku
2020-02-04 12:35 ` Johan Hovold
2020-02-04 12:43 ` Jiri Kosina
2020-02-04 12:55 ` Lauri Jakku
2020-02-04 15:05 ` Johan Hovold [this message]
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=20200204150516.GN26725@localhost \
--to=johan@kernel.org \
--cc=benjamin.tissoires@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jikos@kernel.org \
--cc=lauri.jakku@pp.inet.fi \
--cc=linux-input@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lja@iki.fi \
--cc=oneukum@suse.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).