Re: [PATCH v4 1/2] usb: core: Add quirk for 255-bytes initial config read
Nikhil Solanke <[email protected]>
| Newsgroups | org.kernel.vger.linux-usb,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <CAFgddhLNOVPqnZW89W8XvD5W9nOPK51grBdraOeQcCe1_+WVFw@mail.gmail.com> |
On Tue, 28 Jul 2026 at 07:29, Alan Stern <[email protected]> wrote: > > Also, it's odd that you add the quirk flag to the kernel without adding > a new quirk entry for the Xbox 360-compatible devices. That doesn't > have to be done in this patch, though; it can be done in a follow-up. > (But note that without a followup this patch doesn't actually fix > anything, since a true fix would require user intervention.) > Well the device I am using spoofs Microsoft's device IDs directly. I avoided adding it because the official xbox controllers work out of the box. It won't break their functionality, but it kinda falls into the category of "if it ain't broken, why fix it". Other clone devices use different VID:PID pair as well, like with what happened Ishaan's device (his reply to my previous patch revision). I believe they should be added here instead. Since there are many such devices, gathering all the IDs would take considerable time and community work. Also, the kernel's own xpad module is slightly behind some changes or so I have heard. There are a few community maintained kernel modules/drivers with many changes that are required for these devices to actually function. There is some magic packet that needs to be sent after the usb device has initialized along with doing a bunch of other things like mapping out buttons, etc. These drivers are also required for a device to fully function in most cases (the builtin xpad also works in some cases). So just by adding a device to the quirk list wouldn't truly fix it. There's still a lot of issues that need to be addressed in the kernel driver space to "truly" fix Xbox 360-compatible devices (majorly, hid-generic or other drivers claim the devices before these out-of-tree modules due to race conditions). My patch is just the first step. > > Finally, a really minor nit: The two patches in this series are > completely independent; either one can be applied without the other. > That means they don't really belong in a series, that is, they should be > submitted as two separate patches. Obviously that doesn't matter at all > in practice; it's just a matter of principle. > > Anyway, for both patches 1 and 2: > > Acked-by: Alan Stern <[email protected]> > > If you want to rewrite and resubmit them along the lines mentioned > above, you can add my Acked-by to the new submissions. > > Alan Stern Thanks! I would like to know your thoughts on the above points as to what should be preferably done moving forward. If it happens that I should send in another patch, I will address the nits and add the Acked-By as well. Thanks, Nikhil Solanke