On Sun, Feb 02, 2020 at 08:28:16PM -0300, edes wrote: > > el 2020-02-02 a las 14:41 Johan Hovold escribió: > > > I realised I forgot the test to match on the device descriptor when > > applying the blacklist. It doesn't matter currently since I only enable > > the quirk for your device, but if you haven't tested the patch already, > > would you mind testing the below patch instead? > > Hi, Johan, thank you for looking into this. I tested your patch, and it > works! (5.4.11 and 5.5.0). > > I haven't performed extensive tests, but the card is again recognized as > both playback and capture device. Thank you! Perfect, thanks for testing. Do you have a full name I can use to give you credit in the commit message for reporting and testing? > Is this and acceptable solution and will this patch be integrated into the > kernel? Yes, I think so. We've already had one related report so far, and the blacklist mechanism should be generic enough to handle any further devices like this. Either way, we'll have this fixed in stable in one way or another in a couple of weeks. > OTOH, you said: > > > Ok, so the device has a broken altsetting 3 for interface 1, where > > endpoint 0x85 is declared as an isochronous endpoint, despite being used > > by interface 2 as an audio endpoint: > [...] > > Note that the broken altsetting probably should be using endpoint 0x81 > > just like the other altsettings for that interface, > > I can't say I understand exactly what you're saying, but do you think it > could be worth contacting the company and see if they are willing to fix > this with a new firmware? Yes, I guess that wouldn't hurt. The device used to work mostly by chance as two interfaces aren't allowed to claim the same endpoint. Fortunately, this would only ever be an issue in one particular configuration of the device (when altsetting 3 of interface 1 was selected) and that may be one that was never used on Linux. Takashi may know more about how/if that third altsetting could ever end up being set. Johan
