From: Greg KH <gregkh@linuxfoundation.org>
To: Michal Pecio <michal.pecio@gmail.com>
Cc: "Johannes Brüderl" <johannes.bruederl@gmail.com>,
linux-usb@vger.kernel.org, A1RM4X <dev@a1rm4x.com>,
"Vyacheslav Vahnenko" <vahnenko2003@gmail.com>
Subject: Re: [PATCH v2] usb: core: add USB_QUIRK_NO_BOS for devices that hang on BOS descriptor
Date: Fri, 5 Jun 2026 08:15:25 +0200 [thread overview]
Message-ID: <2026060544-roundup-mobster-8fcd@gregkh> (raw)
In-Reply-To: <20260604165619.592c4e24.michal.pecio@gmail.com>
On Thu, Jun 04, 2026 at 04:56:19PM +0200, Michal Pecio wrote:
> On Mon, 8 Dec 2025 06:12:15 +0900, Greg KH wrote:
> > Ok, I can duplicate this here. Maybe we just don't ask for the BOS
> > descriptor if no one needs/asks for it. I can play with that later
> > and see if that helps as I'm sure this isn't going to be the only
> > device that can't handle the BOS descriptor if Windows isn't querying
> > for it, so we don't want to make a huge quirk table if we don't have
> > to.
>
> Hi Greg and others,
>
> The workaround is now in, but if somebody is interested in getting rid
> of it, it might suffice to make kernel BOS requests more Windows-like,
> since these devices work fine with Windows (and Windows queries BOS).
>
> By monitoring Windows 10 in a VM I found two key differences: Windows
> fetches BOS *after* the configuration descriptor, and it requests 255
> bytes at once in its first attempt (there is likely a second attempt
> if BOS length exceeds 255, but I don't have such a device to test).
>
> Any chance that the change below is enough for these video grabbers?
Have you tried it? I'm away from my device for a few more weeks and
can't do it myself.
thanks,
greg k-h
next prev parent reply other threads:[~2026-06-05 15:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-07 0:00 [PATCH] usb: core: add USB_QUIRK_NO_BOS for devices that hang on BOS descriptor Johannes Brüderl
2025-12-07 0:15 ` Greg KH
2025-12-07 1:20 ` [PATCH v2] " Johannes Brüderl
2025-12-07 6:19 ` Lars Melin
2025-12-07 9:02 ` [PATCH v3 1/1] " Johannes Brüderl
2026-01-07 16:06 ` Greg KH
2025-12-07 7:40 ` [PATCH v2] " Michal Pecio
2025-12-07 9:22 ` Johannes Brüderl
2025-12-07 9:45 ` Michal Pecio
2025-12-07 10:47 ` Johannes Brüderl
2025-12-07 11:00 ` Greg KH
2025-12-07 21:12 ` Greg KH
2025-12-07 22:06 ` Michal Pecio
2025-12-08 8:58 ` Oliver Neukum
2025-12-08 20:46 ` Greg KH
2025-12-28 12:54 ` Johannes Brüderl
2025-12-28 13:18 ` Greg KH
2026-06-04 14:56 ` Michal Pecio
2026-06-05 6:15 ` Greg KH [this message]
2025-12-07 0:37 ` [PATCH] " Michal Pecio
2025-12-07 0:59 ` Greg KH
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=2026060544-roundup-mobster-8fcd@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=dev@a1rm4x.com \
--cc=johannes.bruederl@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=michal.pecio@gmail.com \
--cc=vahnenko2003@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.