Summary: | [snd_uaudio] [patch] Not possible to record with Plantronics DSP-400 USB headset | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Henrik Gulbrandsen <henrik> | ||||||
Component: | usb | Assignee: | freebsd-usb (Nobody) <usb> | ||||||
Status: | Open --- | ||||||||
Severity: | Affects Only Me | ||||||||
Priority: | Normal | ||||||||
Version: | 7.0-BETA1 | ||||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Description
Henrik Gulbrandsen
2007-10-28 11:10:01 UTC
What you experience is very common and I think that a quirk would be useless. How about assuming ASYNC by default ? --HPS On Sun, 2007-10-28 at 14:27 +0200, Hans Petter Selasky wrote:
> What you experience is very common and I think that a quirk would be useless.
> How about assuming ASYNC by default ?
Well, I couldn't think of a good reason not to, so that's why you'll
find a "#define UAUDIO_ASSUME_ASYNC" at the beginning of the patch.
I just wanted to make it easy to turn it off, just in case someone else
could think of a good reason why that would be better - and the quirk
fix is there to ensure that my own headset keeps working in that case.
I wouldn't have added the quirk flag if it wasn't for the fact that it
was already there. In a case like this, I'd prefer to work around the
problem once and for all. See the usb/78984 patch for example. That was
never applied, by the way. I probably missed some administrative detail.
/Henrik
If the patch is reliable (eg, we get no false positives from the printf), then we should eliminate the quirk. Warner On Sun, 2007-10-28 at 07:50 -0600, M. Warner Losh wrote:
> If the patch is reliable (eg, we get no false positives from the
> printf), then we should eliminate the quirk.
True, but this would require at least a small leap of faith, since I
haven't analyzed the consequences in detail. All I know is that we are
currently handling this as an error situation and return USBD_INVAL.
Assuming an asynchronous endpoint and continuing will work around the
problem if this is indeed what the device expects, but it may lead to
other bugs if the core problem is something else.
My qualified guess is that this will probably help more often than it
hurts, so I enabled UAUDIO_ASSUME_ASYNC by default. If we check this in
and nobody complains in the near future, then it's probably safe to do
as you say and eliminate the quirk (and the printf) in a later version.
/Henrik
P.S. The patch is virtually unreadable in the web version, so I'm
attaching it again, hoping to get better formatting this time.
you may be interested in recent changes to OpenBSD's uaudio(4). http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uaudio.c?only_with_tag=MAIN and also http://marc.info/?l=openbsd-tech&m=125518948020717&w=2 and http://marc.info/?l=openbsd-tech&m=125560448608713&w=2 for more background on the change. For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped |