Re: [BUG] usbcore: EPROTO on first-stage Config Descriptor read (ShanWan clone, 2563:028e)

On Mon, 20 Jul 2026 09:46:57 -0400, Alan Stern wrote:
> On Mon, Jul 20, 2026 at 08:50:49AM +0300, Anon wrote:
> > Rapoo V600SE / ShanWan-family chipset -- X-input persona (2563:028E)
> > fails USB enumeration one stage earlier than the known Switch Pro
> > fallback bug
> > 
> > Hardware
> > --------
> > Product: Rapoo V600SE Dual-Mode Vibration Gamepad (marketed with
> > Hall-effect sticks/triggers, X/D/A mode switching)
> > Underlying chipset family: ShenZhen ShanWan Technology Co., Ltd.
> > (confirmed via multiple vendor IDs observed from the same physical
> > unit: 0x2563, 0x20BC)
> > System: CachyOS (Arch-based), systemd-boot bootloader, kernel 7.1.3-2-cachyos
> > USB controller: xHCI (xhci_hcd)
> > 
> > Summary
> > -------
> > This controller presents at least four distinct USB identities from
> > the same physical hardware, depending on mode-button state and
> > connection type. Three of these are already individually documented in
> > various places (ArchWiki, xpad issue tracker, hid-shanwan project) as
> > instances of a known ShanWan firmware bug: a malformed response to the
> > two-stage USB Configuration Descriptor read causing -71 EPROTO
> > (sometimes -32 EPIPE), leading to enumeration failure and a silent
> > firmware-side fallback to a lower-capability "Android" persona.  
> 
> > Root cause (confirmed at byte level via raw usbmon)
> > -----------------------------------------------------
> > This matches the general failure mode already described on the
> > ArchWiki Gamepad page (https://wiki.archlinux.org/title/Gamepad) for
> > ShanWan-family devices: during enumeration, the host requests the
> > Configuration Descriptor in two stages -- a 9-byte header first (to
> > learn wTotalLength), then the full descriptor. Some ShanWan firmware
> > responds to the first request by sending the full descriptor anyway,
> > which is a USB spec violation, and strict host controllers reject it
> > with EPROTO/EPIPE. Windows tolerates this; Linux (by default) does
> > not, and the device firmware silently re-enumerates into a
> > lower-capability fallback persona after the failure.

That's speculation by somebody on Arch Linux wiki, we were under
impression that the mechanism (at least in other similar case) is
different. Also, device sending more than requested is expected to
yield -EOVERFLOW, not -EPROTO.

Curiously, wiki claims that some existing quirks solve this issue.
Did you try them?

> 
> > What I'm hoping for
> > --------------------
> > - Has anyone seen this specific earlier-stage (first 9-byte header)
> > EPROTO failure on a ShanWan-family device, as opposed to the more
> > commonly documented second-stage failure? Is there a known fix?
> > - Would a patch that increases retry attempts specifically around
> > EPROTO on the Configuration Descriptor's first stage (perhaps gated to
> > known-bad VID:PID ranges, similar to how hid-shanwan and hid-sony's
> > existing ShanWan quirks are scoped) be a reasonable ask, or is this
> > considered out of scope for mainline given it's cloned/unofficial
> > hardware?
> > - I'm not a kernel developer, but I'm willing to test patches, provide
> > more capture data, or run a device on a spare machine if that's useful
> > to anyone actively working on hid-shanwan or xpad.  
> 
> This message might be relevant:
> 
> https://lore.kernel.org/linux-usb/[email protected]/
> 
> You would have to add a quirk entry for your particular device, for 
> example (added to the boot command line):
> 
> 	usbcore.quirks=2563:028e:r

This new quirk is now on the way to mainline:
https://patch.msgid.link/[email protected]

As is the first patch to enable it on some device ID:
https://patch.msgid.link/[email protected]

You could send a similar patch if the quirk works for you.

Regards,
Michal