On Mon, May 16, 2011 at 4:55 AM, Grant Diffey gdiffey@gmail.com wrote:
On Mon, May 16, 2011 at 7:30 AM, Daniel Mack zonque@gmail.com wrote:
Attached is a patch that adds some debug output. If you could apply that and report what the kernel logs during the probe of the device, that would be appreciated.
Nothing is leaping out at me after building with he patch above...
Ok, so the reason is clear now to me and it has to do with the way the device is matched by the driver. Basically, the only thing the drivers matches on is a standard audio control interface. If that is found, the USB core calls it to handle that specific interface. Once a control header is found, it is iterated and MIDI devices are created when a specific interface associated to the control header is found.
The problem in your case is that the device is matched with a USB_DEVICE() macro now with no further hints in the quirks table, which makes the USB core hand over the whole device to the driver, and not individual interfaces. Because the assumption is that if a driver announces to handle the whole thing, it knows what it's doing.
In the USB audio driver though, we handle that case by defining a fix behaviour, which is that only interfaces listed in the quirk are actually being looked at.
In earlier versions of the driver, the whole quirk for this device was missing, and hence the last, more generic quirk to look for MIDI_STREAMING interfaces was applied (the last one in quirks-table.h). Hence it worked back then but not today.
The solution is most probably rather simple by handling the Fasttrack as composite device that has non-standard and standard interfaces mixed. There is a macro for that which we just need to use.
Can you give the attached patch a change?
HTH, Daniel