Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
---
sound/usb/usbquirks.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h
index f6f201e..e98ff4c 100644
--- a/sound/usb/usbquirks.h
+++ b/sound/usb/usbquirks.h
@@ -80,6 +80,19 @@
.bInterfaceClass = USB_CLASS_AUDIO,
},
+/* JMTek, LLC. SSS USB Headphone Set */
+{
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
+ USB_DEVICE_ID_MATCH_DEV_CLASS |
+ USB_DEVICE_ID_MATCH_INT_CLASS |
+ USB_DEVICE_ID_MATCH_INT_SUBCLASS,
+ .idVendor = 0x0c76,
+ .idProduct = 0x1605,
+ .bDeviceClass = USB_CLASS_PER_INTERFACE,
+ .bInterfaceClass = USB_CLASS_AUDIO,
+ .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
+},
+
/*
* Logitech QuickCam: bDeviceClass is vendor-specific, so generic interface
* class matches do not take effect without an explicit ID match.
--
1.6.5.rc2
At Sat, 10 Oct 2009 13:15:29 +0200,
Lubomir Rintel wrote:
>
> Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
The change look OK (suppose it was tested :)
Could you give your sign-off to merge to the upstream?
thanks,
Takashi
> ---
> sound/usb/usbquirks.h | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h
> index f6f201e..e98ff4c 100644
> --- a/sound/usb/usbquirks.h
> +++ b/sound/usb/usbquirks.h
> @@ -80,6 +80,19 @@
> .bInterfaceClass = USB_CLASS_AUDIO,
> },
>
> +/* JMTek, LLC. SSS USB Headphone Set */
> +{
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
> + USB_DEVICE_ID_MATCH_DEV_CLASS |
> + USB_DEVICE_ID_MATCH_INT_CLASS |
> + USB_DEVICE_ID_MATCH_INT_SUBCLASS,
> + .idVendor = 0x0c76,
> + .idProduct = 0x1605,
> + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> + .bInterfaceClass = USB_CLASS_AUDIO,
> + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
> +},
> +
> /*
> * Logitech QuickCam: bDeviceClass is vendor-specific, so generic interface
> * class matches do not take effect without an explicit ID match.
> --
> 1.6.5.rc2
>
> _______________________________________________
> Alsa-devel mailing list
> [email protected]
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
Signed-off-by: Lubomir Rintel <[email protected]>
---
sound/usb/usbquirks.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h
index f6f201e..e98ff4c 100644
--- a/sound/usb/usbquirks.h
+++ b/sound/usb/usbquirks.h
@@ -80,6 +80,19 @@
.bInterfaceClass = USB_CLASS_AUDIO,
},
+/* JMTek, LLC. SSS USB Headphone Set */
+{
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
+ USB_DEVICE_ID_MATCH_DEV_CLASS |
+ USB_DEVICE_ID_MATCH_INT_CLASS |
+ USB_DEVICE_ID_MATCH_INT_SUBCLASS,
+ .idVendor = 0x0c76,
+ .idProduct = 0x1605,
+ .bDeviceClass = USB_CLASS_PER_INTERFACE,
+ .bInterfaceClass = USB_CLASS_AUDIO,
+ .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
+},
+
/*
* Logitech QuickCam: bDeviceClass is vendor-specific, so generic interface
* class matches do not take effect without an explicit ID match.
--
1.6.2.5
At Mon, 12 Oct 2009 08:42:40 +0200,
Lubomir Rintel wrote:
>
> Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
>
> Signed-off-by: Lubomir Rintel <[email protected]>
Thanks, applied now.
Takashi
> ---
> sound/usb/usbquirks.h | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h
> index f6f201e..e98ff4c 100644
> --- a/sound/usb/usbquirks.h
> +++ b/sound/usb/usbquirks.h
> @@ -80,6 +80,19 @@
> .bInterfaceClass = USB_CLASS_AUDIO,
> },
>
> +/* JMTek, LLC. SSS USB Headphone Set */
> +{
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
> + USB_DEVICE_ID_MATCH_DEV_CLASS |
> + USB_DEVICE_ID_MATCH_INT_CLASS |
> + USB_DEVICE_ID_MATCH_INT_SUBCLASS,
> + .idVendor = 0x0c76,
> + .idProduct = 0x1605,
> + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> + .bInterfaceClass = USB_CLASS_AUDIO,
> + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
> +},
> +
> /*
> * Logitech QuickCam: bDeviceClass is vendor-specific, so generic interface
> * class matches do not take effect without an explicit ID match.
> --
> 1.6.2.5
>
Lubomir Rintel wrote:
> Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
Please add an explaination why this entry is needed. At first glance,
this entry seems to describe a class-compliant device that should not
need a quirk.
> +/* JMTek, LLC. SSS USB Headphone Set */
> +{
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
> + USB_DEVICE_ID_MATCH_DEV_CLASS |
> + USB_DEVICE_ID_MATCH_INT_CLASS |
> + USB_DEVICE_ID_MATCH_INT_SUBCLASS,
> + .idVendor = 0x0c76,
> + .idProduct = 0x1605,
> + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> + .bInterfaceClass = USB_CLASS_AUDIO,
> + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
> +},
Best regards,
Clemens
At Mon, 12 Oct 2009 08:46:26 +0200,
Clemens Ladisch wrote:
>
> Lubomir Rintel wrote:
> > Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
>
> Please add an explaination why this entry is needed. At first glance,
> this entry seems to describe a class-compliant device that should not
> need a quirk.
Ah right. It'd really helpful if Lubomir can give more details...
Takashi
>
> > +/* JMTek, LLC. SSS USB Headphone Set */
> > +{
> > + .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
> > + USB_DEVICE_ID_MATCH_DEV_CLASS |
> > + USB_DEVICE_ID_MATCH_INT_CLASS |
> > + USB_DEVICE_ID_MATCH_INT_SUBCLASS,
> > + .idVendor = 0x0c76,
> > + .idProduct = 0x1605,
> > + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> > + .bInterfaceClass = USB_CLASS_AUDIO,
> > + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
> > +},
>
>
> Best regards,
> Clemens
>
On Mon, 2009-10-12 at 09:18 +0200, Takashi Iwai wrote:
> At Mon, 12 Oct 2009 08:46:26 +0200,
> Clemens Ladisch wrote:
> >
> > Lubomir Rintel wrote:
> > > Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
> >
> > Please add an explaination why this entry is needed. At first glance,
> > this entry seems to describe a class-compliant device that should not
> > need a quirk.
>
> Ah right. It'd really helpful if Lubomir can give more details...
A 2.6.31.1-based kernel on my Fedora 12 workstation at hone seemed to
require that, only the input driver attached to the device when plugged
in, the snd-usb-audio didn't seem to load and did not care about the
device when loaded manually. I did not have an idea why, since "alias:
usb:v*p*d*dc*dsc*dp*ic01isc01ip*" really seemed to match my device.
Nevertheless, after finding out that adding an entry to the quirk table
solves my problem I concluded that my understanding (or lack of thereof)
was wrong and that alias is really not meant to match my device.
Now I plugged the adapter into my work lappy with 2.6.30.8-based Fedora
11 and the audio interfaces on my adapter got instantly recognized and
claimed by snd-usb-audio (and the input interface by the input
subsystem), without modifying anything.
Any clues what could have gone wrong then?
--
Flash is the Web2.0 version of blink and animated gifs.
-- Stephen Smoogen
At Mon, 12 Oct 2009 10:03:53 +0200,
Lubomir Rintel wrote:
>
> On Mon, 2009-10-12 at 09:18 +0200, Takashi Iwai wrote:
> > At Mon, 12 Oct 2009 08:46:26 +0200,
> > Clemens Ladisch wrote:
> > >
> > > Lubomir Rintel wrote:
> > > > Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
> > >
> > > Please add an explaination why this entry is needed. At first glance,
> > > this entry seems to describe a class-compliant device that should not
> > > need a quirk.
> >
> > Ah right. It'd really helpful if Lubomir can give more details...
>
> A 2.6.31.1-based kernel on my Fedora 12 workstation at hone seemed to
> require that, only the input driver attached to the device when plugged
> in, the snd-usb-audio didn't seem to load and did not care about the
> device when loaded manually. I did not have an idea why, since "alias:
> usb:v*p*d*dc*dsc*dp*ic01isc01ip*" really seemed to match my device.
> Nevertheless, after finding out that adding an entry to the quirk table
> solves my problem I concluded that my understanding (or lack of thereof)
> was wrong and that alias is really not meant to match my device.
>
> Now I plugged the adapter into my work lappy with 2.6.30.8-based Fedora
> 11 and the audio interfaces on my adapter got instantly recognized and
> claimed by snd-usb-audio (and the input interface by the input
> subsystem), without modifying anything.
>
> Any clues what could have gone wrong then?
Hm, I don't see any affecting changes between 2.6.30 and 31.
Just as a test, could you copy sound/usb/*.[ch] from 2.6.30 tree to
2.6.31 or 32-rc and check whether the same problem appears?
Takashi
On Mon, 2009-10-12 at 10:08 +0200, Takashi Iwai wrote:
> At Mon, 12 Oct 2009 10:03:53 +0200,
> Lubomir Rintel wrote:
> >
> > On Mon, 2009-10-12 at 09:18 +0200, Takashi Iwai wrote:
> > > At Mon, 12 Oct 2009 08:46:26 +0200,
> > > Clemens Ladisch wrote:
> > > >
> > > > Lubomir Rintel wrote:
> > > > > Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
> > > >
> > > > Please add an explaination why this entry is needed. At first glance,
> > > > this entry seems to describe a class-compliant device that should not
> > > > need a quirk.
> > >
> > > Ah right. It'd really helpful if Lubomir can give more details...
> >
> > A 2.6.31.1-based kernel on my Fedora 12 workstation at hone seemed to
> > require that, only the input driver attached to the device when plugged
> > in, the snd-usb-audio didn't seem to load and did not care about the
> > device when loaded manually. I did not have an idea why, since "alias:
> > usb:v*p*d*dc*dsc*dp*ic01isc01ip*" really seemed to match my device.
> > Nevertheless, after finding out that adding an entry to the quirk table
> > solves my problem I concluded that my understanding (or lack of thereof)
> > was wrong and that alias is really not meant to match my device.
> >
> > Now I plugged the adapter into my work lappy with 2.6.30.8-based Fedora
> > 11 and the audio interfaces on my adapter got instantly recognized and
> > claimed by snd-usb-audio (and the input interface by the input
> > subsystem), without modifying anything.
> >
> > Any clues what could have gone wrong then?
>
> Hm, I don't see any affecting changes between 2.6.30 and 31.
> Just as a test, could you copy sound/usb/*.[ch] from 2.6.30 tree to
> 2.6.31 or 32-rc and check whether the same problem appears?
I did not try that, but updated to a newer snapshot and it works as it
used to again, so I don't thing there's much point in finding out what
went wrong now. I'm very sorry for the noise.
Regards,
Lubo
--
"Excuse all the blood" -- Dead
At Sun, 18 Oct 2009 18:37:28 +0200,
Lubomir Rintel wrote:
>
> On Mon, 2009-10-12 at 10:08 +0200, Takashi Iwai wrote:
> > At Mon, 12 Oct 2009 10:03:53 +0200,
> > Lubomir Rintel wrote:
> > >
> > > On Mon, 2009-10-12 at 09:18 +0200, Takashi Iwai wrote:
> > > > At Mon, 12 Oct 2009 08:46:26 +0200,
> > > > Clemens Ladisch wrote:
> > > > >
> > > > > Lubomir Rintel wrote:
> > > > > > Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
> > > > >
> > > > > Please add an explaination why this entry is needed. At first glance,
> > > > > this entry seems to describe a class-compliant device that should not
> > > > > need a quirk.
> > > >
> > > > Ah right. It'd really helpful if Lubomir can give more details...
> > >
> > > A 2.6.31.1-based kernel on my Fedora 12 workstation at hone seemed to
> > > require that, only the input driver attached to the device when plugged
> > > in, the snd-usb-audio didn't seem to load and did not care about the
> > > device when loaded manually. I did not have an idea why, since "alias:
> > > usb:v*p*d*dc*dsc*dp*ic01isc01ip*" really seemed to match my device.
> > > Nevertheless, after finding out that adding an entry to the quirk table
> > > solves my problem I concluded that my understanding (or lack of thereof)
> > > was wrong and that alias is really not meant to match my device.
> > >
> > > Now I plugged the adapter into my work lappy with 2.6.30.8-based Fedora
> > > 11 and the audio interfaces on my adapter got instantly recognized and
> > > claimed by snd-usb-audio (and the input interface by the input
> > > subsystem), without modifying anything.
> > >
> > > Any clues what could have gone wrong then?
> >
> > Hm, I don't see any affecting changes between 2.6.30 and 31.
> > Just as a test, could you copy sound/usb/*.[ch] from 2.6.30 tree to
> > 2.6.31 or 32-rc and check whether the same problem appears?
>
> I did not try that, but updated to a newer snapshot and it works as it
> used to again, so I don't thing there's much point in finding out what
> went wrong now. I'm very sorry for the noise.
OK, thanks for confirmation.
Takashi