Linus Walleij <linus.walleij@xxxxxxxxxx> writes:
> /* Check if device responds to control message 1 or if there is an error */
> cmd = buf[16];
> ret = libusb_control_transfer (devh,
> LIBUSB_ENDPOINT_IN | LIBUSB_RECIPIENT_DEVICE | LIBUSB_REQUEST_TYPE_VENDOR,
> cmd,
> 0,
> 4,
> buf,
> sizeof(buf),
> USB_TIMEOUT_DEFAULT);
>
> // Dump it, if requested
> if (dumpfile != NULL && ret > 0) {
> fprintf(dumpfile, "Microsoft device response to control message
> 1, CMD 0x%02x:\n", cmd);
> data_dump_ascii(dumpfile, buf, ret, 16);
> }
>
> /* If this is true, the device either isn't MTP or there was an error */
> if (ret <= 0x15) {
> /* TODO: If there was an error, flag it and let the user know somehow */
> /* if(ret == -1) {} */
> libusb_close(devh);
> return 0;
> }
>
> /* Check if device is MTP or if it is something like a USB Mass Storage
> device with Janus DRM support */
> if ((buf[0x12] != 'M') || (buf[0x13] != 'T') || (buf[0x14] != 'P')) {
> libusb_close(devh);
> return 0;
> }
>
> /* After this point we are probably dealing with an MTP device */
Not really relevant to this discussion, but this parsing is too simple
and will fail to detect composite devices with MTP functions unless the
MTP function is listed first in the Microsoft pseudo-descriptor.
You should really verify the header and look through *all* returned
function sections.
It's not clear from this, but I do hope you parse the MTP function
interface number later in the code?
>> It would mean that Linux systems must start keeping track of every
>> device that a system has seen. It's atrocious.
>>
>> But I don't think there's another way. Of course, it could be part of
>> a non-core package, so that only when the MTP software is installed
>> will there be some database.
>
> This is how it works today. The probing comes with libmtp,
> which also provide the udev rules and thus notify userspace
> that listen to the udev events.
I don't think that keeping track of all possible MTP devices a system
has seen would be that extra-ordinary. My Debian system has a few such
examples already:
- /lib/udev/write_cd_rules creates persistent cdrom names by writing a
rule to /etc/udev/rules.d/70-persistent-cd.rules for every CD device
seen
- /lib/udev/write_net_rules creates persistent network device names by
writing a rule to /etc/udev/rules.d/70-persistent-net.rules for every
So following the same pattern, the MTP tools could let the probe write
new dynamic rules which (by setting enviroment variables):
1) prevents further probing of the same device
2) sets a MTP supported flag on all MTP interfaces (note: NOT DEVICE).
This would make the probing a one time per device affair, which might
let you ignore crashing devices (since it will only happen once) and
it will let you point the MTP tools directly to the interfaces
supporting MTP.
Note that this will work with devices with configurable PTP or MTP
support, because they are made to work with Windows which also does the
above. Such devices will therefore typically switch device IDs when
switching modes, although they could just have used unique interface
numbers I guess.
>> For most (I'm not sure I dare say all) other devices, it would add no
>> value on Linux.
>
> I fully agree ... well, Microsoft actually intended the device
> descriptor to be used also for things like WiFi and Bluetooth
> but it seems they never did that.
Luckily the USB-IF have standardized proper descriptors for those
devices.
It's too bad they didn't have the power or guts to prevent Microsoft
from creating their parallell universe. Which was created solely as an
attempt to prevent other OSes from using USB devices. It would have been
in the USB-IFs best interest to strike that down before it had a chance
to be implemented by anyone.
If you dont' believe me, then let me quote from Microsofts own
documentation of the "Extended Compat ID OS Feature Descriptor":
The Microsoft OS Descriptor Specification and any accompanying
materials (the “Specification”) provided by Microsoft is for your
personal use only, and may be used solely for the purpose of
implementing the Microsoft OS Descriptor set to interface with (i) a
Microsoft OS Descriptor enabled operating system or (ii) other systems
authorized by Microsoft to retrieve and use this information. THE
SPECIFICATION (OR ANY OF ITS CONTENTS) MAY NOT BE COPIED OR
DISTRIBUTED.
It's not even like they try to hide their agenda. They just document
their evil intent like that...
Luckily, AFAICS, Linux qualifies as "a Microsoft OS Descriptor enabled
operating system", as it is perfectly able to use Microsoft OS
Descriptors :-)
But IANAL, and you may want to consider your local legal advisor before
trying to use my interpretation of that documentation license...
> 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...)
Yes, and be aware that even it it starts with something else, it could
in fact have multiple such strings. "MTP" doesn't necessarily have to be
first.
>>> 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...
See proposal above.
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
