Re: Sound Blaster USB X-Fi configuration problem
On 20.07.2013 05:44, Alan Stern wrote:
static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
{
u16 buf = 1;
snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
if (buf == 0) {
snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), 0x29,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_OTHER,
1, 2000, NULL, 0);
usb_reset_device(dev);
return -EAGAIN; //-ENODEV;
}
return 0;
}
This is the same as the Audigy function, except for the printk string
and the 2-byte buffer instead of the 1-byte buffer, right? Therefore I
suggest combining them into a single function. You can pass the string
and the buffer size as arguments.
There are the differences you mentioned (2 bytes buffer and printk
function, of course printk is for debugging only) but this is is not the
same as the Audigy since the message is sent twice (I am nor sure
whether it is necessary or not - Windows did that twice and so did I)
and a kind of reset is needed at the end in case of X-Fi
initialization (I made usb_reset_device(dev) but I am not sure whether
it is the only or optimal way - I have seen also other resets used in
other quirk functions). Without this reset card was not initialized
properly. This reset does not exist in case of Audigy quirk.
Sure, the 2 functions can be combined in one with some additional
arguments. I wonder only whether I should propose such solution - I have
no experience in kernel and drivers code, especially reading the
following in your message. But if you think I can do that I offer my
help. The only problem can be I do not have Audigy sound card to test it.
+ static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
+ {
+u16 buf = 1;
+
+snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
+
+snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
+USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
+0, 0, buf, 2);
There's a serious problem here. It's present in most or all of the
quirk routines in this file, not just yours.
Namely, buffers used for USB transfers must not be allocated on the
stack; they must be allocated using kmalloc or a related function. The
reason is because some architectures are not capable of performing DMA
to addresses on the stack.
This is a good point which did not come to my mind due to lack of
experience. Fixing one or few functions seems reasonable easy, fixing
all in the whole file seems to be much more serious and responsible work.
Do you feel like fixing up all those routines? I suggest allocating
and deallocating a buffer in the function that calls the quirk
routines, and have it pass the buffer as an extra argument.
This is probably question to the community not just to me?
--
Best regards
Mariusz Grecki
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
Alan Stern wrote: On Sat, 20 Jul 2013, Mariusz Grecki wrote: +u16 buf = 1; + +snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a, +USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER, +0, 0, buf, 2); There's a serious problem here. It's present in most or all of the quirk routines in this file, not just yours. Namely, buffers used for USB transfers must not be allocated on the stack; they must be allocated using kmalloc or a related function. This is what snd_usb_ctl_msg() does. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
On Sat, 20 Jul 2013, Clemens Ladisch wrote: Alan Stern wrote: On Sat, 20 Jul 2013, Mariusz Grecki wrote: + u16 buf = 1; + + snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a, + USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER, + 0, 0, buf, 2); There's a serious problem here. It's present in most or all of the quirk routines in this file, not just yours. Namely, buffers used for USB transfers must not be allocated on the stack; they must be allocated using kmalloc or a related function. This is what snd_usb_ctl_msg() does. Argh! I misread the code -- didn't see the snd_ prefix. :-( Never mind. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
On Sat, 20 Jul 2013, Mariusz Grecki wrote: This is the same as the Audigy function, except for the printk string and the 2-byte buffer instead of the 1-byte buffer, right? Therefore I suggest combining them into a single function. You can pass the string and the buffer size as arguments. There are the differences you mentioned (2 bytes buffer and printk function, of course printk is for debugging only) but this is is not the same as the Audigy since the message is sent twice (I am nor sure whether it is necessary or not - Windows did that twice and so did I) You could try sending it once and see if it still works. and a kind of reset is needed at the end in case of X-Fi initialization (I made usb_reset_device(dev) but I am not sure whether it is the only or optimal way - I have seen also other resets used in Most likely it is the best way. other quirk functions). Without this reset card was not initialized properly. This reset does not exist in case of Audigy quirk. Adding a reset to the Audigy quirk probably won't hurt. But the only way to be sure is to try it with real hardware. Sure, the 2 functions can be combined in one with some additional arguments. I wonder only whether I should propose such solution - I have no experience in kernel and drivers code, especially reading the following in your message. But if you think I can do that I offer my help. The only problem can be I do not have Audigy sound card to test it. Under the circumstances, I guess we have to err on the safe side and keep the two functions separate. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
Hi Alan,
thanks for the fast response and useful infos. Unfortunately your patch
does not work but triggered by it I made it working.
The changes as as follows:
First we should diverse between Audigy and X-Fi in snd_usb_apply_boot_quirk:
case USB_ID(0x041e, 0x30df):
/* X-Fi Surround 5.1 */
return snd_usb_sb_x_fi_boot_quirk(dev);
and then additional function
static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
{
u16 buf = 1;
snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
if (buf == 0) {
snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), 0x29,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_OTHER,
1, 2000, NULL, 0);
usb_reset_device(dev);
return -EAGAIN; //-ENODEV;
}
return 0;
}
about this quirk function I am not sure. I tried to follow recorded
initialization process from WinXP running on virtual machine. I made it
finally running but without real understanding why it should be like
that. I noticed that initialization process takes a while (~2 sec.). I
do not care about that. If you think there is a smarter way to do it
just suggest and I will test it.
The patch combining these two is as follows:
===
mgrecki@mgpc:/usr/src/linux-3.9.2/sound/usb$ diff -c quirks.c.org quirks.c
===
*** quirks.c.org2013-07-20 00:06:51.246927975 +0200
--- quirks.c2013-07-20 00:07:28.067690027 +0200
***
*** 374,379
--- 374,401
return 0;
}
+ static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
+ {
+ u16 buf = 1;
+
+ snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
+
+ snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
+ 0, 0, buf, 2);
+ snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
+ 0, 0, buf, 2);
+ if (buf == 0) {
+ snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), 0x29,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_OTHER,
+ 1, 2000, NULL, 0);
+ usb_reset_device(dev);
+ return -EAGAIN; //-ENODEV;
+ }
+ return 0;
+ }
+
static int snd_usb_fasttrackpro_boot_quirk(struct usb_device *dev)
{
int err;
***
*** 733,738
--- 755,764
/* SB Audigy 2 NX needs its own boot-up magic, too */
return snd_usb_audigy2nx_boot_quirk(dev);
+ case USB_ID(0x041e, 0x30df):
+ /* X-Fi Surround 5.1 quirk for HS operation*/
+ return snd_usb_sb_x_fi_boot_quirk(dev);
+
case USB_ID(0x10f5, 0x0200):
/* C-Media CM106 / Turtle Beach Audio Advantage Roadie */
return snd_usb_cm106_boot_quirk(dev);
===
In case you would like me to perform additional tests just let me know.
Many thanks for your help. That was exactly what I was looking for.
Mariusz Grecki
PS. I still do not understand why the card was initialized to HS without
that. I really seen that once... But this is probably not important,
just a curiosity...
On 04.07.2013 18:26, Alan Stern wrote:
As Oliver Neukum suggested earlier, your device appears to need the
same magic message as the SoundBlaster Audigy 2 NX. This patch for
3.10 should do it. Let me know how it works.
Index: usb-3.10/sound/usb/quirks.c
===
--- usb-3.10.orig/sound/usb/quirks.c
+++ usb-3.10/sound/usb/quirks.c
@@ -744,6 +744,8 @@ int snd_usb_apply_boot_quirk(struct usb_
case USB_ID(0x041e, 0x3020):
/* SB Audigy 2 NX needs its own boot-up magic, too */
+ case USB_ID(0x041e, 0x30df):
+ /* Same for the X-Fi Surround 5.1 */
return snd_usb_audigy2nx_boot_quirk(dev);
case USB_ID(0x10f5, 0x0200):
--
Best regards
Mariusz Grecki
_
| |
| Dr. Mariusz Grecki |
| Deutsches Elektronen-Synchrotron DESY |
| Notkestraße 85, 22607 Hamburg, Geb. 3/109a |
| tel.: +49 40 89985489 fax: +49 40 89983282
Re: Sound Blaster USB X-Fi configuration problem
On Sat, 20 Jul 2013, Mariusz Grecki wrote:
Hi Alan,
thanks for the fast response and useful infos. Unfortunately your patch
does not work but triggered by it I made it working.
The changes as as follows:
First we should diverse between Audigy and X-Fi in snd_usb_apply_boot_quirk:
case USB_ID(0x041e, 0x30df):
/* X-Fi Surround 5.1 */
return snd_usb_sb_x_fi_boot_quirk(dev);
and then additional function
static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
{
u16 buf = 1;
snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
0, 0, buf, 2);
if (buf == 0) {
snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), 0x29,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_OTHER,
1, 2000, NULL, 0);
usb_reset_device(dev);
return -EAGAIN; //-ENODEV;
}
return 0;
}
This is the same as the Audigy function, except for the printk string
and the 2-byte buffer instead of the 1-byte buffer, right? Therefore I
suggest combining them into a single function. You can pass the string
and the buffer size as arguments.
about this quirk function I am not sure. I tried to follow recorded
initialization process from WinXP running on virtual machine. I made it
finally running but without real understanding why it should be like
that. I noticed that initialization process takes a while (~2 sec.). I
do not care about that. If you think there is a smarter way to do it
just suggest and I will test it.
Doing what Windows does is usually the best strategy.
+ static int snd_usb_sb_x_fi_boot_quirk(struct usb_device *dev)
+ {
+ u16 buf = 1;
+
+ snd_printk(KERN_ERR X-Fi Surround 5.1 newer quirk\n);
+
+ snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), 0x2a,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
+ 0, 0, buf, 2);
There's a serious problem here. It's present in most or all of the
quirk routines in this file, not just yours.
Namely, buffers used for USB transfers must not be allocated on the
stack; they must be allocated using kmalloc or a related function. The
reason is because some architectures are not capable of performing DMA
to addresses on the stack.
Do you feel like fixing up all those routines? I suggest allocating
and deallocating a buffer in the function that calls the quirk
routines, and have it pass the buffer as an extra argument.
Many thanks for your help. That was exactly what I was looking for.
You're welcome.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
On Thu, 4 Jul 2013, Mariusz Grecki wrote: Hi all, I have made some experiments and things looks much more clear. Although I do not understand why once a time the device was initialized by Linux to HS operation but probably this is not so important. It seems that some additional configuration is needed. When I run native (without driver) Windows XP (in real hardware or in Virtualbox - does not matter) the sound card is initialized to FS. After driver installation it is in both cases (hardware and virtual environment) initialized to HS. I have recorded the data streams for both cases (FS and HS configuration) but unfortunately I cannot interpret it (without being enough familiar with USB protocol). If somebody can have a look and propose a patch initializing the device properly that would be great... or maybe I need to provide more data? I am more than willing to help finding the solution. The dumps can be downloaded from (I have provided both wireshark dumps and pure cat versions of each process): http://mgrecki.republika.pl/x-fi/x-fi.12 - FS configuration (Linux 3.9.2) recorded by wireshark (wireshark format) http://mgrecki.republika.pl/x-fi/x-fi.12.out - FS configuration (Linux 3.9.2) recorded by cat command (text format) http://mgrecki.republika.pl/x-fi/x-fi.480 - HS configuration (WinXP running in Virtualbox) recorded by wireshark (wireshark format) http://mgrecki.republika.pl/x-fi/x-fi.480.out - HS configuration (WinXP running in Virtualbox) recorded by cat command (text format) Thanks in advance for your help. As Oliver Neukum suggested earlier, your device appears to need the same magic message as the SoundBlaster Audigy 2 NX. This patch for 3.10 should do it. Let me know how it works. Alan Stern Index: usb-3.10/sound/usb/quirks.c === --- usb-3.10.orig/sound/usb/quirks.c +++ usb-3.10/sound/usb/quirks.c @@ -744,6 +744,8 @@ int snd_usb_apply_boot_quirk(struct usb_ case USB_ID(0x041e, 0x3020): /* SB Audigy 2 NX needs its own boot-up magic, too */ + case USB_ID(0x041e, 0x30df): + /* Same for the X-Fi Surround 5.1 */ return snd_usb_audigy2nx_boot_quirk(dev); case USB_ID(0x10f5, 0x0200): -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
Mariusz Grecki wrote: Does anybody have any idea what can be the problem? The card is recognized as HS device by MS Windows (XP version) without any exceptions... When you say Windows, do you mean Windows itself, or a driver from Creative that you installed and that can send some vendor-specific initialization command? Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
W dniu 06/28/2013 09:00 AM, Clemens Ladisch pisze: Mariusz Grecki wrote: Does anybody have any idea what can be the problem? The card is recognized as HS device by MS Windows (XP version) without any exceptions... When you say Windows, do you mean Windows itself, or a driver from Creative that you installed and that can send some vendor-specific initialization command? Regards, Clemens I mean MS Windows with installed driver from Creative. As far as I remember, without the specific driver the card is not configured by native Windows as a sound card. I can check and confirm that but earliest on Monday. I will also make sure it is not hardware related problem (I am convinced it is not, but there were few suggestions so far I want to check and prove that) and try to capture the data flow during configuration by Windows and Linux to have more infos. Many thanks to all involved people. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
On Wed, Jun 26, 2013 at 10:43:39PM +0200, Mariusz Grecki wrote: The problem relates directly to the old one: http://thread.gmane.org/gmane.linux.usb.general/20816/focus=20850 The problem is, that usually (in fact all the time with one! exception so far) the card is recognized by operating system as a full-speed (FS) device not the high-speed (HS) one. This is weird, but once I have seen it was recognized as high-speed device at my CPU. But that happened once - I have no idea how and why. My suspicions is that during initialization there is a kind of races that usually lead to full-speed configuration. The FS operation is not enough since the card performance is limited or (worse) the card is not possible to use since there are other USB devices connected (not enough bandwidth). Perhaps the card realizes this and this is why it only offers up the lower speed? One of the possible cause given in the mentioned thread was that the card requires special initialization. This is not the case in my opinion since I have seen it was initialized as a HS device with completely different characteristics (more high precision and high sampling rate modes of operation). The kernel only takes the device descriptor directly from the device, it doesn't have a way to change it. If you run 'usbmon' can you see anything different from when it is detected in the two different ways? The computer to which the card is connected is uTCA embedded CPU with high-speed USB hub. It runs Ubuntu 10.04 (Linux mskcpucmtb1 2.6.32-45-generic #102-Ubuntu SMP Wed Jan 2 22:38:04 UTC 2013 x86_64 GNU/Linux). I have checked the same behavior with pure 3.9.2 kernel compiled by me - for all cases FS device was configured. The only case when the device was configured as HS device happened once with other machine (not available at this moment). But it is not related to this particular machine since I have tried many times on this machine later and always it was configured as FS device. What happens if you don't use a USB hub and just plug it in directly to the root USB hub? How about on a normal desktop computer running Linux? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound Blaster USB X-Fi configuration problem
On Wed, 26 Jun 2013, Mariusz Grecki wrote: The problem relates directly to the old one: http://thread.gmane.org/gmane.linux.usb.general/20816/focus=20850 The problem is, that usually (in fact all the time with one! exception so far) the card is recognized by operating system as a full-speed (FS) device not the high-speed (HS) one. This is weird, but once I have seen it was recognized as high-speed device at my CPU. But that happened once - I have no idea how and why. My suspicions is that during initialization there is a kind of races that usually lead to full-speed configuration. Speed determination is performed in hardware, not in software. You mentioned below that the card was plugged into a hub, not directly into the computer. Therefore the speed was determined by a negotiation between the hub and the card. The CPU was not involved. The FS operation is not enough since the card performance is limited or (worse) the card is not possible to use since there are other USB devices connected (not enough bandwidth). One of the possible cause given in the mentioned thread was that the card requires special initialization. This is not the case in my opinion since I have seen it was initialized as a HS device with completely different characteristics (more high precision and high sampling rate modes of operation). Instead of guessing, you really need to find out if Windows uses any special initialization. The computer to which the card is connected is uTCA embedded CPU with high-speed USB hub. It runs Ubuntu 10.04 (Linux mskcpucmtb1 2.6.32-45-generic #102-Ubuntu SMP Wed Jan 2 22:38:04 UTC 2013 x86_64 GNU/Linux). I have checked the same behavior with pure 3.9.2 kernel compiled by me - for all cases FS device was configured. The only case when the device was configured as HS device happened once with other machine (not available at this moment). But it is not related to this particular machine since I have tried many times on this machine later and always it was configured as FS device. I have read several problem reports concerning these cards at Internet (most of them seem to be related to FS configuration). Certainly I can provide more information (logs, CPU setup etc.). None of that will help. But there is one possibility you should take into account: Maybe the hub or the card isn't getting enough electrical power. Does anybody have any idea what can be the problem? The card is recognized as HS device by MS Windows (XP version) without any exceptions... What happens if you run Linux on the Windows machine (for example, boot from a Live CD)? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sound Blaster USB X-Fi configuration problem
The problem relates directly to the old one: http://thread.gmane.org/gmane.linux.usb.general/20816/focus=20850 The problem is, that usually (in fact all the time with one! exception so far) the card is recognized by operating system as a full-speed (FS) device not the high-speed (HS) one. This is weird, but once I have seen it was recognized as high-speed device at my CPU. But that happened once - I have no idea how and why. My suspicions is that during initialization there is a kind of races that usually lead to full-speed configuration. The FS operation is not enough since the card performance is limited or (worse) the card is not possible to use since there are other USB devices connected (not enough bandwidth). One of the possible cause given in the mentioned thread was that the card requires special initialization. This is not the case in my opinion since I have seen it was initialized as a HS device with completely different characteristics (more high precision and high sampling rate modes of operation). The computer to which the card is connected is uTCA embedded CPU with high-speed USB hub. It runs Ubuntu 10.04 (Linux mskcpucmtb1 2.6.32-45-generic #102-Ubuntu SMP Wed Jan 2 22:38:04 UTC 2013 x86_64 GNU/Linux). I have checked the same behavior with pure 3.9.2 kernel compiled by me - for all cases FS device was configured. The only case when the device was configured as HS device happened once with other machine (not available at this moment). But it is not related to this particular machine since I have tried many times on this machine later and always it was configured as FS device. I have read several problem reports concerning these cards at Internet (most of them seem to be related to FS configuration). Certainly I can provide more information (logs, CPU setup etc.). Does anybody have any idea what can be the problem? The card is recognized as HS device by MS Windows (XP version) without any exceptions... Below I have enclosed a part of lsusb -v dump for both cases (FS and HS configuration). The dumps were taken on different occasions therefore the bus numbers etc. are different. = lsusb -v (part of, with FS configuration) Bus 001 Device 008: ID 041e:30df Creative Technology, Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x041e Creative Technology, Ltd idProduct 0x30df bcdDevice1.00 iManufacturer 1 Creative Technology Ltd iProduct2 SB X-Fi Surround 5.1 Pro iSerial 3 04vk bNumConfigurations 1 = lsusb -v (part of, with HS configuration) Bus 003 Device 005: ID 041e:30df Creative Technology, Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x041e Creative Technology, Ltd idProduct 0x30df bcdDevice1.00 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 The full HS dump I can provide of course (I have stored it), but I doubt whether I can again establish again this mode of operation on request... Thanks in advance for any help. Mariusz Grecki -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
