[snip]
Clemens/Daniel,
Does this seem more complete given that DFU and Midi are Class compliant
my guess at the interface purposes from David's post are:
Interface 0 is a DFU firmware upgrade // looks usb class compliant. Interface 1 is really custom (perhaps some sort of custom control/management thing tho I would of thought they'd use midi sysex for that) Interface 2 is the midi //looks 100% standards compliant (works?) Interface 3 looks like maybe a usb mixer without a descriptor? but that's a guess. Interface 4 is potentially usb2 audio output // looks similar to the maudioi fast track isosyncronous outputs Interface 5 is potentially usb2 audio input. // ""
So that all said.
can USB_DEVICE_VENDOR_SPEC deal with out of order compliant/quirked interfaces or only sequencial??
Would this look more like it using USB_DEVICE_VENDOR_SPEC?
USB_DEVICE_VENDOR_SPEC(0x0dba, 0xb011), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Digidesign", .product_name = "Eleven Rack", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = & (const struct snd_usb_audio_quirk[]) { { .ifnum = 1, .type = QUIRK_IGNORE_INTERFACE },
{ .ifnum = 3, .type = QUIRK_AUDIO_STANDARD_MIXER }, { .ifnum = 4, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 5, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = -1 } } } }
Will a quirk with no usbid work (assuming david didn't edit what clemens posted) ?
My gut feeling is that the mixer is missing all the endpoint and route stuff so we'll need to build a model of the mixer by sniffing the usb.
Grant.