Linus Walleij wrote: > > Windows requests the 0xee string descriptor from *every* device, > > unless the same vid and pid has been seen before on the system. > > I had no clue about that... have you seen this from USB traces? I didn't look at traces, but Microsoft documents it, and testing shows their documentation to match reality. http://msdn.microsoft.com/en-us/library/windows/hardware/ff537430(v=vs.85).aspx The 0xee string is read starting from Windows XP. > I have seen devices crash when 0xee is requested, but it might > be that we're clearing the stall in the wrong way when it's not > there. I'm not saying that devices will not crash. I'm saying that it is completely expected that lots of devices will crash, and that the only solution is to do what Microsoft does; remember when devices have already been queried for the MOD and never do it again. > I was certainly under the impression that Windows does not > do this for devices it has seen before... Yes, that is what I am confirming. Quoting myself: > > unless the same vid and pid has been seen before on the system. Microsoft also describes it on their page which I linked to above. > We could do it for all devices but it might be that we're doing > something wrong with libusb so that several devices crash > when doing this. Nothing that can be done to a USB device from userspace (I'd say even from the kernel) is legitimate reason for a device to crash. USB firmware however seems very difficult to write for many vendors, and plenty of devices crash for all sorts of reasons even though they should not. Windows works around this by never quering the same device more than once. I'd treat the Microsoft page as the canonical documentation. > Currently we do it like this: It's fine, but I would call libusb_get_string_descriptor() instead of libusb_get_descriptor() for a bit more clarity. > I have some vague indications that their DRM system for > USB mass storage is also using the special 0xee descriptor > to identify devices with such capabilities, but I have no > clue as to how this actually works. (You can see this from > the above code: we need to check that the returned descriptor > actually start with "MTP", it *could* say something else...) If you read the MS documentation (it's a little labyrinth:ey so you'll have to click around a bit) they might have a list of the handful device types which use a MOD to guide Windows to the correct driver. There is one, but I'm not sure on exactly what page. Starting with Windows 8 they even have WinUSB as one device type, meaning that a USB device can use a MOD to get WinUSB.sys bound to it automatically on attach, and userspace applications which use libusb-1.0 can access the device without the user needing to replace the driver. It's very nice that plug and play has arrived also to Windows, it sure took a while to get there. > > End result: A given device only ever crashes exactly once on a given > > Windows system. > > Yep this is as far as I've understood as well. > > But now you're contradicting the first paragraph of your > mail, so which one is it? Hm, I don't think so? > >> So I could mimic this by starting to cache away any > >> successfully initiated MTP devices in some /var/libmtp > >> file and just OK them the next time they are plugged in. > > > > You'll have to cache *every* device, so that you do not make a > > given device crash more than once, like Windows. > > Hm, need to figure out how to do this then... Before asking for 0xee make sure that the same device has not been seen by the program in a previous invocation. 1. create device identifier (suggest like the MS vvvvpppprrrrr) 2. search for identifier in cache 3. if found, do not send 0xee request but use information from cache 4. if not found, write identifier with empty information to cache 5. get 0xee string and perform device/vendor control request 6. if successful response, update information in cache 7. if device crashes, tell user to reconnect device When the device crashes on reading the 0xee string and no other automated method is available to match the device against libmtp the only remaining option to make the device functional that I can think of is a whitelist. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
