Linus Walleij <linus.walleij@xxxxxxxxxx> writes: > 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. Yes, I feared so. But it still seemed likely that the non conforming ones could be managed as a whitelist, if only most of the new ones were using the standard class codes. > 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 Thanks. That looks somewhat useful, except that you only seem to collect the device codes and not the interface codes. I am wondering if that is much of the problem here? You seem to only look at the device when in fact most of the new MTP devices are composite devices (phones)? > 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 Ouch. Yes, not much else to do there than using vid:pid or probing. > 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... Do you know if these early devices support the typical Microsoft descriptors? I.e. the 0xee string descriptor with "MSFT100<code>" and its friends? I assume even the most buggy devices will survive asking for a string descriptor... > 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... Sure you can and should check the interface class. Do a grep bInterfaceClass /lib/udev/rules.d/* and you will hopefully see a couple of examples. And I still wonder about the libusb_open screwing up devices. It does not touch the device at all. And you can get the configuration descriptor without communicating with the device. The OS has already cached that for you. So how come you think libusb_open screws up anything? If it did, then the device would already be dead when the Linux USB core enumerated it. > 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 I assume that is in combination with subclass 02 and protocol 01, which specifies "Interface Association Descriptor" and will be common for phones and modems. See http://www.usb.org/developers/whitepapers/iadclasscode_r10.pdf It's just another "unspecified, check interfaces" really. > ff = as per above Those are always going to be a problem. But I was hoping they were only older devices. The rest of your list of device classes should have meaningful interface class/subclass/protocol codes. Don't they? But no, you cannot do device class matching. That will naturally not work on any composite device, as they by definiton support more than one set of codes. > 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. Yes, that's what I gathered from the MTP spec. > 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. Nice. But how are you then going to deal with PTP devices crashing? Blacklist them by vid:pid? Or is this only a problem with MTP devices? Bjørn -- 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
