On Thu, Nov 8, 2012 at 3:38 PM, Bjørn Mork <bjorn@xxxxxxx> wrote:
> Linus Walleij <linus.walleij@xxxxxxxxxx> writes:
>> One of them is an MTP interface, and will respond to MTP traffic.
>> I think the magic OS handshake make that come into play...
>> So Linux erroneously tries to use MSC on it, and we have to
>> use libusb_detach_kernel_driver() and then use the interface.
>>
>> And then it works.
>>
>> This type of misbehaviour is not uncommon, I just took some
>> device at random, there are literally millions of these.
>
> That may be. But I absolutely refuse thinking about the possibility of
> some udev rule probing all mass storage devices just because of
> completely broken devices like this one...
No, in this case I only use whitelisting, so we know of these
specific devices.
> OK, filtering on 3 endpoint mass storage devices will eliminate most of
> the false positives, but still. Ugly.
Is there a way to write a udev rule to only probe devices
with 3 endpoints? I have tried this but never found any :-(
>> (...)
>> # Autoprobe vendor-specific, communication and PTP devices
>> ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1",
>> ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes",
>> ATTR{bDeviceClass}=="00|02|06|ef|ff", PROGRAM="mtp-probe
>> /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1",
>> SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
>
> I believe this rule is dangerously broad. It probes so many non MTP
> devices that I honestly do not understand why you need to except any
> device at all. Your config avoids probing a few whitelisted MTP devices
> but ends up probing evey other type of USB device instead. That does
> not make sense.
I'm only probing class 00, 02, 06, ef and ff.
>> So that rather horrible rule avoids probing:
>>
>> - Devices we just detected in the whitelist
>> - Color measurement or scanner devices (these have been
>> prone to errors...)
>> - Then check only the classes we mentioned
>
> Yes, but "only the classes we mentioned" includes *all* composite
> devices out there. To me that seems completely unacceptable, but others
> may disagree.
Well, the thing is that this is actually what Windows is doing.
If you insert any kind of device into a Windows machine, and Windows
does not find a .inf file for it, it will be probed for the OS descriptor.
I think it avoids anything with != 3 endpoints of the right type
though.
And basically that is how MTP devices "just work" on Windows,
as far as I can tell.
> IMHO, you should limit the probing to the devices which you have reason
> to believe may support MTP. That is
> - devices with one or more PTP interfaces
> - possibly devices with 3 endpoint Mass Storage interfaces, like the
> one you showed above
>
> The rest will have to be witelisted based on pid:vid.
So the current code means the probe program will actually
exit if it doesn't find the right number of endpoints and
the right type of endpoints.
> But this is my opinion, only..
Yeah, if it was only me I would prefer to only have a
whitelist. But then I also package this for Fedora, and
it turns out that users want MTP devices to "just work"
just like they "just work" on Windows. And for that this
program is crucial...
>>> Do you know if these early devices support the typical Microsoft
>>> descriptors? I.e. the 0xee string descriptor with "MSFT100<code>"
>>> and its friends?
>>
>> Almost all devices support this. (There are exceptions even to this.)
>> So this is what we do as a last resort, if we can't figure it out
>> some other way.
>
> I do not understand why that has to be the last resort. I would expect
> this method to be very reliable since Microsoft has been heavily
> involved all the way here. It's an ugly non-standard method of course,
> but being pragmatic we do have to use whatever method the vendors have
> implemented and *tested*. Which most likely is what they have observed
> som random Windows version doing.
So there are devices that crash if you ask for descriptor 0xEE.
The way Windows gets around it is *probably* by using some
of the heuristics above, like making sure that there is an interface
with 3 endpoints and so on.
I don't know for sure :-(
I also think that a few devices actually crash on Windows.
But they have this concept of an .inf file, so the first time
you insert an alien device, you are asked for an .inf file
with some driver information. Then you can bind that
VID+PID to a specific driver, and then they will not look
further the next time the same device is plugged in again.
They will just load the driver given from the .inf file.
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.
I don't know if that approach would be any popular...
>> The problem appear when you ask a device which is not MTP
>> for that descriptor, some of them just die, so I cannot do
>> that.
>
> Really? You ask for a string descriptor and the device dies? Won't
> those devices also die if they are connected to a Windows system?
No, for the above reason, reliance on requesters to
the user and .inf files for any alien device.
I think they also have a big device library (sort of like
the libmtp udev rule file).
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
