On Mon, 29 Mar 2021 08:23:52 +0200, Ikjoon Jang wrote:
On Wed, Mar 24, 2021 at 8:49 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 24 Mar 2021 13:03:14 +0100, Ikjoon Jang wrote:
On Wed, Mar 24, 2021, 7:16 PM Joakim Tjernlund Joakim.Tjernlund@infinera.com wrote:
On Wed, 2021-03-24 at 18:51 +0800, Ikjoon Jang wrote: > Logitech ConferenceCam Connect is a compound USB device with UVC and > UAC. Not 100% reproducible but sometimes it keeps responding STALL to > every control transfer once it receives get_freq request. > > This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 > Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Most Logitech USB headset I got needs a delay in snd_usb_ctl_msg_quirk() Have you tried to add say 20 ms delay in there?I didn't try that. But it sounds reasonable to me.
let me try that quirk here. If that is the case, HID might need that delay also. Logitech Group webcam had a similar problem on control xfer of get_report from an another interface for HID.
The Logitech devices with 046d:* should be covered generally in snd_usb_ctl_msg_quirk(), so I guess it's a different problem. But please check it first.
And 20ms can be too long if it's applied to every control transfer. I will test the device with shorter delay if you didn't try it before.
Actually the delay applied to Logitech devices is from 1 to 2ms, not 20ms. The 20ms delay is applied for some other devices. But if extending the delay fixes the problem, we need to reconsider the delay length.
I tested this Logitech device with various delays 2..20ms in snd_usb_ctl_msg_quirk() but it didn't help.
Disregarding the delay between control transfers, This device is always stuck at get_cur, responding STALL to all control transfers.
[ 24.045618] usb 1-1.2.1.1: 1:1: cannot get freq at ep 0x82 [ 24.167475] usb 1-1.2.1.1: 2:0: cannot get min/max values for control 2 (id 2) [ 24.287393] usb 1-1.2.1.1: 6:0: cannot get min/max values for control 2 (id 6) [ 24.289854] usbcore: registered new interface driver snd-usb-audio [ 24.877073] usb 1-1.2.1.1: 2:1: usb_set_interface failed (-32)
And I've also found that in some other platforms (with the same kernel), this device fails at get_freq - timeout with NYETs or NAKs (instead of STALL), and succeeded in following set_interface even without any delays I've tried but couldn't find any differences between the two. ;-(
So until now, I think this approach of skipping get_rate is the only one possible workaround for Logitech Connect.
OK, that makes sense, then. I applied your patch now.
Thanks!
Takashi