2010/4/19 Steve Calfee <stevecalfee@xxxxxxxxx>: > For 6 months, a while ago, I was working on virtual USB stuff for a > company. I did analyser traces of many devices including many MS > devices (mice, webcam, keyboard, joystick), and never found any device > from MS or anyone that supported that command. All devices that I saw > just replied (properly) with a STALL - and Winxp would just continue > on and handle the device. I don't think they add it to that kind of devices. Only MTP players for what I've seen. Maybe some weirdo RNDIS stuff use it too? But as you see Windows issues this command to absolutely everything you plug in, I've been thinking about how we could emulate the same behaviour in Linux but actually I think it's a bit insane and only take extra time to send that command to whatever you plug in. Still it would be nice to know directly from userspace if a device that was plugged in was MTP or not, especially we need this for udev rules (or HAL, DeviceKit etc, whatever) that want to make the device read/writable for the console user when it's plugged in. > When you say "older windowses", which one; the only earlier ones with > USB was 98 and descendants and somewhat 95. Especially the Win98 and Win2000 stuff that comes with the Windows Media Player has to respond to it. Actually Windows probably has some internal list of devices and specific quirks it has to use for them to work properly, but I'm not sure. (I asked them about it I think, but didn't get any replies.) > Also have you found a device that actually responds to the "get > osdescriptor" request? Almost all MTP devices out there does, check the logs here: http://libmtp.cvs.sourceforge.net/viewvc/libmtp/libmtp/logs/ If the device responds with something sane for command 0xee the MTP stack will go on to issue special commands, you can find our code for this here: http://libmtp.cvs.sourceforge.net/viewvc/*checkout*/libmtp/libmtp/src/libusb-glue.c?revision=1.284 Basically it's a simple libusb command we issue: /* Read the special descriptor */ ret = usb_get_descriptor(devh, 0x03, 0xee, buf, sizeof(buf)); // Dump it, if requested if (dumpfile != NULL && ret > 0) { fprintf(dumpfile, "Microsoft device descriptor 0xee:\n"); data_dump_ascii(dumpfile, buf, ret, 16); } It typically looks like this: Microsoft device descriptor 0xee: 0000: 1203 4d00 5300 4600 5400 3100 3000 3000 ..M.S.F.T.1.0.0. 0010: 1c00 .. Microsoft device response to control message 1, CMD 0x1c: 0000: 2800 0000 0001 0400 0100 0000 0000 0000 (............... 0010: 0001 4d54 5000 0000 0000 3030 0000 0000 ..MTP.....00.... 0020: 0000 0000 0000 0000 ........ Potential MTP Device with VendorID:22b8 and ProductID:6415 responded to control message 2 with a response that was too short. Problems may arrise but continuing Device info: But Ziilabs Egg actually reply properly to the second control message: Microsoft device descriptor 0xee: 0000: 1203 4d00 5300 4600 5400 3100 3000 3000 ..M.S.F.T.1.0.0. 0010: 0100 .. Microsoft device response to control message 1, CMD 0x01: 0000: 2800 0000 0001 0400 0100 0000 0000 0000 (............... 0010: 0001 4d54 5000 0000 0000 0000 0000 0000 ..MTP........... 0020: 0000 0000 0000 0000 ........ Microsoft device response to control message 2, CMD 0x01: 0000: 0c00 0000 0001 0500 0000 0000 ............ A special oddity is devices that *require* you to probe the device descriptor and won't even work if you don't: ZiiLabs Egg, several SanDisk Sansas, and some LGE phones display this behaviour. Since the devices are only ever tested with Windows nobody notice that they don't work properly without the probing... There are some more generic USB misbehaviour displayed by these devices I can list if you're interested. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
