On Mon, 9 Feb 2004, Frank Barknecht wrote: > Hallo, > Bill Unruh hat gesagt: // Bill Unruh wrote: > > > As I understand this this a "mislabeling" problem, one if taken > > literally could result in overwriting the ends of an array. There would > > seem to be two reactions-- kill anything that does that, or make the > > array larger. Yes, the latter "wastes" memory, but is the memory wasted > > really that precious a resource? > > According to USB spec 1.1, a device has to tell the number of > alternative settings it has. Each setting then is numbered starting > from zero. So in a device with seven alt settings these have > identifiers [0,1,2,3,4,5,6] > > But the Quattro has configurations, where it tells the kernel: "I got > two alt settings, dude." The kernel and all applications now know that > those are [0,1], because that's what the standard says. But in the > case of the Quattro they are [0,4]! Every configuration of the Quattro > is broken in this way. Some say, they would have 4 settings and those > are [0,1,3,4]! This has nothing to do with the lenghth of the array but > with the allowed values it can included.
Well, my guess was that the usb would ask it for a device setting corresponding to some characteristic. It would come back with setting 4. But it had previously reported that there were a totoal of 4, so the system would then look at array element setting[4] which would of course fall off the end of the array with bad consequences. This was what I meant as bad arrays. However the uncomfortable thing is that Windows does seem to be able to handle this. and the Standard that the windows USB driver was written to was surely the same one as the Linux one. Thus this card should also break in windows ( which should make M-audion sit up and take notice, even if they regard Linux with distain). > > I don't know the USB system in the kernel, so I'm guessing a bit here: > The kernel checks this early on and rejects this device, because it > doesn't know what might break later on in code paths that rely on the > alt settings being correctly identified. Such path aren't hard to > think of, they could for example be loops like this > (Python-pseudocode): > > numSettings = kernel.getAltSettings() > # numSetting now is an int like 2 > > for setting in range(0,numSettings): > doSomethingWith(setting) That would not be as bad as driver[kernel.getSettingNumber(3)] > > You would never reach the Quattro's setting 4 inside such loops, > because it has reported the number of settings as 2. This might not be > that important, you just wouldn't be able to set setting 4, but it > also might wreck everything. > > > I may misunderstand the problem entirely, such that it is impossible > > to write a USB bus driver which could compensate for maudio or other > > manufacturer's stupididty. But an overstrict interpretation of the > > rules seems an inappropriate reaction of writers (especially since > > Linux USB itself seems to have some peculiarities of its own). > > Among 20 USB sound devices only my Quattro failed on 2.6. It caused > many people lots of trouble in the path, if you search the archives. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
