On Mon, Nov 5, 2012 at 11:31 PM, Bjørn Mork <bjorn@xxxxxxx> wrote: > Linus Walleij <linus.walleij@xxxxxxxxxx> writes: > Excuse my lack of knowlegde here, but I have to ask why that is? > > I looked briefly at the MTP v1.1 spec from So all MTP devices manufactured before that spec, and numerous produced after that spec came out, and several still being produced don't use the class code, i.e. they violate the spec. But we still have to detect them somehow. Here are some device logs I've been collecting: http://libmtp.git.sourceforge.net/git/gitweb.cgi?p=libmtp/libmtp;a=tree;f=logs;hb=HEAD Early devices look like this: 9 Interface has a kernel driver attached. 10 bcdUSB: 512 11 bDeviceClass: 255 12 bDeviceSubClass: 0 13 bDeviceProtocol: 0 14 idVendor: 041e 15 idProduct: 4130 16 IN endpoint maxpacket: 512 bytes 17 OUT endpoint maxpacket: 512 bytes 18 Raw device info: 19 Bus location: 2 20 Device number: 12 21 Device entry info: 22 Vendor: Creative 23 Vendor id: 0x041e 24 Product: ZEN Micro (MTP mode) 25 Vendor id: 0x4130 26 Device flags: 0x20000001 This is the lsusb -v: Bus 003 Device 004: ID 041e:4130 Creative Technology, Ltd Zen Micro (mtp) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x041e Creative Technology, Ltd idProduct 0x4130 Zen Micro (mtp) bcdDevice 1.00 iManufacturer 1 Creative Technology Ltd iProduct 2 Creative Zen Micro iSerial 3 01052551C6038F82 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 16 Configuration 1 bmAttributes 0xc0 Self Powered MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 33 MTP Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 4 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x128a (Bus Powered) Remote Wakeup Enabled The story goes that Microsoft was not allowed to use the scheme in the specification before publication, so they stuck a custom scheme in there and fallback methods to figure out if a device is MTP. And since device manufacturers only test their devices against Windows, and since the Windows MTP stack is *very* tolerant all kinds of weird stuff exist out there. And we get to deal with it... So for not-so-bad behaved devices this question is relevant: > I realize that you still have to probe to find out whether it supports > MTP or just PTP, but won't it help if this probing could be limited to > only 06/01/01 interfaces? So in the current device rule we have to match: ATTR{bDeviceClass}=="00|02|06|ef|ff" 00 = unspecified, check interfaces, which cannot currently be done by udev rules, I think, so we need to perform libusb_open() which will screw up some devices... 02 = comms device class, a lot of phones use this 06 = yay! PTP yes among others... ef = no idea why this is used, but it is ff = as per above While this cuts out a number of devices it still gives plenty of room to screw others up. To check if a device with class 6 is PTP or MTP the only trusted way is to open a PTP session and check for a specific descriptor actually. Problem: you cannot open a session to an MTP device in say a udev script, then close it and open another session later, because many devices crash when a session is closed. This is of course yet another spec violation, but comes from the fact that Windows never close sessions, it keeps the device hogged until it's plugged out or the host is shut down. Yours, Linus Walleij -- 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
