Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Linus Walleij]

Hi Felipe,

> The following two patches are RFC because we still have
> a few open questions regarding them.

sorry for responding so late on this patch set. I've been working
on MTP for some years from the host side of the MTP pipe,
with the initiator library libmtp.

I would appreciate if future patch sets are CC:ed to
libmtp-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org where we have an MTP
initiator community, thanks.

The patch has some small basic problems due to it's actual
paradigm/use model not being described, and that should be part
of the patch so as to open up for a wider discussion.

The intention of this patch is not to provide any MTP or PTP
gadget drivers at all really, it is about creating a stub driver for
MTP that can be used from userspace, where the actual protocol
implementation is supposed to reside. So this is the PTP/MTP
equivalent of TAP or TUN. This should be clear from the
description of the patch and go in the comments of the file
itself as well so as not to confuse anyone.

The actual background to the driver being a stub is that vendors
are deploying the (proprietary) MTP stack implementation from
Microsoft in userspace on top of a driver like this. (This exact same
work has been duplicated in a few places across the device
manufacturer world.) This rationale should also be clear from the
patch and the files.

It is of course possible to implement a *real* MTP gadget driver in
kernelspace, directly accessing the file system etc, not needing
to involve userspace for any MTP transfers at all. There is an
official USB IF specification for MTP which can be used to that end.
Some day somebody will come along and do just that, I've been sort
of hoping that some company like Google could jump in and actually
do that.

I know this is all absolutely crystal clear to you, but it's not going to
be for everyone else in the world, that why all the words...

Naming the function driver f_mtp.c is confusing since it does not
implement MTP, it should be named f_mtpstub.c (and mtpstub.c) so
that when someone one day really want to implement the protocol in the
kernel, they can use f_mtp.c.

Has the driver been designed with PTP in mind as well? There
are several cameras running PTP on Linux in this world, for example
the stuff from SONY. They have a userspace PTP stack in the same
fashion I believe. I think it would just work with PTP as well after a
quick review, but please give it a second thought.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Linus Walleij]

2010/4/18 Linus Walleij <linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

> The following two patches are RFC because we still have
> a few open questions regarding them.

Further comments: there is apparently a driver floating around this list
for supporting PTP through the gadgetfs. How does this work relate
to that, and why can't you use gadgetfs?

Second: after looking at this, I think that atleast the part of functionality
called "OS descriptor" should be in the kernel and not in userspace,
is the OS descriptor the reason to why you want to expose EP0 to
userspace, or are you using this for other things in the MTP stack?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Felipe Balbi]

On Mon, Apr 19, 2010 at 06:10:52PM +0200, ext Linus Walleij wrote:
>2010/4/18 Linus Walleij <linus.ml.walleij@gmail.com>:
>
>> The following two patches are RFC because we still have
>> a few open questions regarding them.
>
>Further comments: there is apparently a driver floating around this list
>for supporting PTP through the gadgetfs. How does this work relate
>to that, and why can't you use gadgetfs?

dude, can't you read ? gadgetfs prevents us from combining into a 
composite gadget. We went throught that already. Please follow the 
thread before commenting.

>Second: after looking at this, I think that atleast the part of functionality
>called "OS descriptor" should be in the kernel and not in userspace,
>is the OS descriptor the reason to why you want to expose EP0 to
>userspace, or are you using this for other things in the MTP stack?

OS descriptor is MS specific crap, it's not on the USB-IF mtp spec and 
most like MS has some patent on that.

-- 
balbi

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Michał Nazarewicz]

> On Mon, Apr 19, 2010 at 06:10:52PM +0200, ext Linus Walleij wrote:
>> Further comments: there is apparently a driver floating around this list
>> for supporting PTP through the gadgetfs. How does this work relate
>> to that, and why can't you use gadgetfs?

On Mon, 19 Apr 2010 18:26:11 +0200, Felipe Balbi <felipe.balbi-xNZwKgViW5g@public.gmane.orgm> wrote:
> dude, can't you read ? gadgetfs prevents us from combining into a
> composite gadget. We went throught that already. Please follow the
> thread before commenting.

On related news, I've just posted FunctionFS driver. :) It's still imperfect
but appears to be working.

-- 
Best regards,                                           _     _
   .o. | Liege of Serenely Enlightened Majesty of       o' \,=./ `o
   ..o | Computer Science,  Michał "mina86" Nazarewicz     (o o)
   ooo +---[mina86-deATy8a+UHjQT0dZR+AlfA@public.gmane.org]---[mina86-/eSpBmjxGS4dnm+yROfE0A@public.gmane.org]---ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Greg KH]

On Mon, Apr 19, 2010 at 06:55:53PM +0200, Michał Nazarewicz wrote:
> > On Mon, Apr 19, 2010 at 06:10:52PM +0200, ext Linus Walleij wrote:
> >> Further comments: there is apparently a driver floating around this list
> >> for supporting PTP through the gadgetfs. How does this work relate
> >> to that, and why can't you use gadgetfs?
> 
> On Mon, 19 Apr 2010 18:26:11 +0200, Felipe Balbi <felipe.balbi@nokia.com> wrote:
> > dude, can't you read ? gadgetfs prevents us from combining into a
> > composite gadget. We went throught that already. Please follow the
> > thread before commenting.
> 
> On related news, I've just posted FunctionFS driver. :) It's still imperfect
> but appears to be working.

Yes, that should solve the gadgetfs issue for you, right Felipe?

thanks,

greg k-h

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Felipe Balbi]

On Mon, Apr 19, 2010 at 07:15:34PM +0200, ext Greg KH wrote:
>On Mon, Apr 19, 2010 at 06:55:53PM +0200, Michał Nazarewicz wrote:
>> > On Mon, Apr 19, 2010 at 06:10:52PM +0200, ext Linus Walleij wrote:
>> >> Further comments: there is apparently a driver floating around this list
>> >> for supporting PTP through the gadgetfs. How does this work relate
>> >> to that, and why can't you use gadgetfs?
>>
>> On Mon, 19 Apr 2010 18:26:11 +0200, Felipe Balbi <felipe.balbi@nokia.com> wrote:
>> > dude, can't you read ? gadgetfs prevents us from combining into a
>> > composite gadget. We went throught that already. Please follow the
>> > thread before commenting.
>>
>> On related news, I've just posted FunctionFS driver. :) It's still imperfect
>> but appears to be working.
>
>Yes, that should solve the gadgetfs issue for you, right Felipe?

sure it should. Will take a look at it :-)

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Michał Nazarewicz]

>> On Mon, Apr 19, 2010 at 06:55:53PM +0200, Michał Nazarewicz wrote:
>>> On related news, I've just posted FunctionFS driver. :) It's still imperfect
>>> but appears to be working.

> On Mon, Apr 19, 2010 at 07:15:34PM +0200, ext Greg KH wrote:
>> Yes, that should solve the gadgetfs issue for you, right Felipe?

On Mon, 19 Apr 2010 19:24:04 +0200, Felipe Balbi <felipe.balbi@nokia.com> wrote:
> sure it should. Will take a look at it :-)

As I've said it's still imperfect.  In particular the throughput won't be
impressive but that's on the TODO list (I first want to put a real driver
on top of FunctionFS before optimising the code) and in particular u_char
seem to be a good piece to steal code from. ;)  Still, as said, I haven't
analysed possible optimisations just yet.

All in all, I believe FunctionFS can work for you as you will handle data
transfers in user space anyway.  At the same time FunctionFS solves evens
end setup requests communication (I'm still wondering whether it would be
better to use separate file for events and for setup requests).

-- 
Best regards,                                           _     _
  .o. | Liege of Serenely Enlightened Majesty of       o' \,=./ `o
  ..o | Computer Science,  Michał "mina86" Nazarewicz     (o o)
  ooo +---[mina86@mina86.com]---[mina86@jabber.org]---ooO--(_)--Ooo--

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Felipe Balbi]

On Mon, Apr 19, 2010 at 08:57:18PM +0200, ext Michał Nazarewicz wrote:
>>> On Mon, Apr 19, 2010 at 06:55:53PM +0200, Michał Nazarewicz wrote:
>>>> On related news, I've just posted FunctionFS driver. :) It's still imperfect
>>>> but appears to be working.
>
>> On Mon, Apr 19, 2010 at 07:15:34PM +0200, ext Greg KH wrote:
>>> Yes, that should solve the gadgetfs issue for you, right Felipe?
>
>On Mon, 19 Apr 2010 19:24:04 +0200, Felipe Balbi <felipe.balbi@nokia.com> wrote:
>> sure it should. Will take a look at it :-)
>
>As I've said it's still imperfect.  In particular the throughput won't be
>impressive but that's on the TODO list (I first want to put a real driver

yeah, I saw that you allocate the memory whenever you get 
read()/write(). That's a good choice IMO. It would be nice if you would 
have a vmalloc()ed kfifo instead and use that a ring buffer. Then you 
unload in smaller chunks.

>on top of FunctionFS before optimising the code) and in particular u_char
>seem to be a good piece to steal code from. ;)  Still, as said, I haven't
>analysed possible optimisations just yet.

go for it :-)

It's free software anyways :-D

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Michał Nazarewicz]

> On Mon, Apr 19, 2010 at 08:57:18PM +0200, ext Michał Nazarewicz wrote:
>> on top of FunctionFS before optimising the code) and in particular u_char
>> seem to be a good piece to steal code from. ;)  Still, as said, I haven't
>> analysed possible optimisations just yet.

On Mon, 19 Apr 2010 22:04:57 +0200, Felipe Balbi <felipe.balbi-xNZwKgViW5g@public.gmane.orgm> wrote:
> go for it :-)

I only started wondering whether buffering won't break some drivers.
Queuing the requests and buffering the data may be good from speed
point of view, but it may lead to user space driver loosing control
over the transmission.

My understanding of USB protocol is not perfect so I may use wrong
terms here, but please bare with me.

fsync() solves the issue of not knowing when the data is sent but
there is no similar mechanism for reading.

In particular how can we stall on read? Say protocol is designed in
such a way, that host sends a request on EP0 and some data on EP1.
Now, after handling the control request from EP0 we would like to
stall no EP1 but by the time we try to do that the data from host
has already been received and buffered in FunctionFS.

-- 
Best regards,                                           _     _
  .o. | Liege of Serenely Enlightened Majesty of       o' \,=./ `o
  ..o | Computer Science,  Michał "mina86" Nazarewicz     (o o)
  ooo +---[mina86-deATy8a+UHjQT0dZR+AlfA@public.gmane.org]---[mina86-/eSpBmjxGS4dnm+yROfE0A@public.gmane.org]---ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Linus Walleij]

2010/4/19 Felipe Balbi <felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>:
>> 2010/4/18 Linus Walleij <linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

>> Further comments: there is apparently a driver floating around this list
>> for supporting PTP through the gadgetfs. How does this work relate
>> to that, and why can't you use gadgetfs?
>
> dude, can't you read ? gadgetfs prevents us from combining into a composite
> gadget. We went throught that already. Please follow the thread before
> commenting.

Yeah sorry, I'm trying to catch up and miss some pieces here and there.
I'm mainly reading it from the MTP side of things.

>> Second: after looking at this, I think that atleast the part of
>> functionality
>> called "OS descriptor" should be in the kernel and not in userspace,
>> is the OS descriptor the reason to why you want to expose EP0 to
>> userspace, or are you using this for other things in the MTP stack?
>
> OS descriptor is MS specific crap, it's not on the USB-IF mtp spec and most
> like MS has some patent on that.

...so I read you like it's not going to be supported with the proposed
solution?

I think that if you want you gadget to work with older Windowses,
you simply have to support this.

Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Felipe Balbi]

On Mon, Apr 19, 2010 at 09:23:46PM +0200, ext Linus Walleij wrote:
>...so I read you like it's not going to be supported with the proposed
>solution?
>
>I think that if you want you gadget to work with older Windowses,
>you simply have to support this.

if you're willing to pay the Royalty fees, let me know :-p

seriously, we just can't support it. AFAICT, M$ has patents over the OS 
Descriptor thingy (I could wrong though) and we don't want to give linux 
foundation a law suit, do we ? :-)

There's no simple way to support old windows OSes. We could provide 
another .inf file on the kernel source for that at least.

-- 
balbi

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Greg KH]

On Mon, Apr 19, 2010 at 11:07:27PM +0300, Felipe Balbi wrote:
> On Mon, Apr 19, 2010 at 09:23:46PM +0200, ext Linus Walleij wrote:
> >...so I read you like it's not going to be supported with the proposed
> >solution?
> >
> >I think that if you want you gadget to work with older Windowses,
> >you simply have to support this.
> 
> if you're willing to pay the Royalty fees, let me know :-p
> 
> seriously, we just can't support it. AFAICT, M$ has patents over the
> OS Descriptor thingy (I could wrong though) and we don't want to
> give linux foundation a law suit, do we ? :-)

If you know the patent numbers, please send them to me.  There are very
simple methods of routing around patents.  Also, the USB-IF is very
interested in patents that cover USB related things, as they could
possibly violate the USB-IF agreement that companies are forced to sign
to join it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Felipe Balbi]

On Tue, Apr 20, 2010 at 12:44:51AM +0200, ext Greg KH wrote:
>If you know the patent numbers, please send them to me.  There are very
>simple methods of routing around patents.  Also, the USB-IF is very
>interested in patents that cover USB related things, as they could
>possibly violate the USB-IF agreement that companies are forced to sign
>to join it.

you might have better contacts than I do. Last time I contacted them 
regarding MS problems - at that time, I was complaining that Windows 
doesn't fetch all config descriptors - they replied that "other devices 
have passed USB Certification, so why can't you?"

It's too bad when the Specification authority doesn't want to hear about 
mis-implementations of their own specification. Anyways...

Take a look here:

http://www.microsoft.com/whdc/connect/usb/os_desc.mspx

it doesn't say the patent number but it does say that "Microsoft agrees 
to grant a nonexclusive, royalty-free, world-wide license under these 
copyrights, patents or applications solely to implement the Microsoft OS 
Descriptor Specification to interface with (i) a Microsoft OS Descriptor 
enabled operating system or (ii) other systems authorized by Microsoft 
to retrieve and use this information, on condition that you agree not to 
assert any intellectual property rights against Microsoft or other 
companies for their implementation of the Specification."

We just need to check whether Linux falls into the "other systems 
authorized by Microsoft" category. I would guess not :-p

-- 
balbi

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Greg KH]

On Tue, Apr 20, 2010 at 09:22:41AM +0300, Felipe Balbi wrote:
> On Tue, Apr 20, 2010 at 12:44:51AM +0200, ext Greg KH wrote:
> >If you know the patent numbers, please send them to me.  There are very
> >simple methods of routing around patents.  Also, the USB-IF is very
> >interested in patents that cover USB related things, as they could
> >possibly violate the USB-IF agreement that companies are forced to sign
> >to join it.
> 
> you might have better contacts than I do. Last time I contacted them
> regarding MS problems - at that time, I was complaining that Windows
> doesn't fetch all config descriptors - they replied that "other
> devices have passed USB Certification, so why can't you?"
> 
> It's too bad when the Specification authority doesn't want to hear
> about mis-implementations of their own specification. Anyways...
> 
> Take a look here:
> 
> http://www.microsoft.com/whdc/connect/usb/os_desc.mspx
> 
> it doesn't say the patent number but it does say that "Microsoft
> agrees to grant a nonexclusive, royalty-free, world-wide license
> under these copyrights, patents or applications solely to implement
> the Microsoft OS Descriptor Specification to interface with (i) a
> Microsoft OS Descriptor enabled operating system or (ii) other
> systems authorized by Microsoft to retrieve and use this
> information, on condition that you agree not to assert any
> intellectual property rights against Microsoft or other companies
> for their implementation of the Specification."
> 
> We just need to check whether Linux falls into the "other systems
> authorized by Microsoft" category. I would guess not :-p

It might, now that Microsoft has code in the Linux kernel :)

I'll ask around and see what I can find out.

thanks,

greg k-h

Re: [Libmtp-discuss] [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Felipe Balbi]

Hi,

On Fri, Apr 23, 2010 at 03:02:31PM +0200, ext pouly amaury wrote:
>Those two patents may apply:
>System and method to specify extended configuration descriptor 
>information in USB devices
>System and method to specify device specific user interface information 
>in the firmware of a USB device

exactly, those are the ones. Thanks a lot for finding that out.

-- 
balbi

DefectiveByDesign.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Steve Calfee]

On Mon, Apr 19, 2010 at 12:23 PM, Linus Walleij
<linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2010/4/19 Felipe Balbi <felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>:
>>> 2010/4/18 Linus Walleij <linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>

>
>>> Second: after looking at this, I think that atleast the part of
>>> functionality
>>> called "OS descriptor" should be in the kernel and not in userspace,
>>> is the OS descriptor the reason to why you want to expose EP0 to
>>> userspace, or are you using this for other things in the MTP stack?
>>
>> OS descriptor is MS specific crap, it's not on the USB-IF mtp spec and most
>> like MS has some patent on that.
>
> ...so I read you like it's not going to be supported with the proposed
> solution?
>
> I think that if you want you gadget to work with older Windowses,
> you simply have to support this.
>
Interesting.

For 6 months, a while ago, I was working on virtual USB stuff for a
company. I did analyser traces of many devices including many MS
devices (mice, webcam, keyboard, joystick), and never found any device
from MS or anyone that supported that command. All devices that I saw
just replied (properly) with a STALL - and Winxp would just continue
on and handle the device.

When you say "older windowses", which one; the only earlier ones with
USB was 98 and descendants and somewhat 95.

Also have you found a device that actually responds to the "get
osdescriptor" request?

Regards, Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Linus Walleij]

2010/4/19 Steve Calfee <stevecalfee@gmail.com>:

> For 6 months, a while ago, I was working on virtual USB stuff for a
> company. I did analyser traces of many devices including many MS
> devices (mice, webcam, keyboard, joystick), and never found any device
> from MS or anyone that supported that command. All devices that I saw
> just replied (properly) with a STALL - and Winxp would just continue
> on and handle the device.

I don't think they add it to that kind of devices. Only MTP players
for what I've seen. Maybe some weirdo RNDIS stuff use it too?

But as you see Windows issues this command to absolutely everything
you plug in, I've been thinking about how we could emulate the same
behaviour in Linux but actually I think it's a bit insane and only take
extra time to send that command to whatever you plug in.

Still it would be nice to know directly from userspace if a device that
was plugged in was MTP or not, especially we need this for udev
rules (or HAL, DeviceKit etc, whatever) that want to make the device
read/writable for the console user when it's plugged in.

> When you say "older windowses", which one; the only earlier ones with
> USB was 98 and descendants and somewhat 95.

Especially the Win98 and Win2000 stuff that comes with the Windows
Media Player has to respond to it.

Actually Windows probably has some internal list of devices and
specific quirks it has to use for them to work properly, but I'm not
sure. (I asked them about it I think, but didn't get any replies.)

> Also have you found a device that actually responds to the "get
> osdescriptor" request?

Almost all MTP devices out there does, check the logs here:
http://libmtp.cvs.sourceforge.net/viewvc/libmtp/libmtp/logs/

If the device responds with something sane for command 0xee
the MTP stack will go on to issue special commands, you can find
our code for this here:
http://libmtp.cvs.sourceforge.net/viewvc/*checkout*/libmtp/libmtp/src/libusb-glue.c?revision=1.284

Basically it's a simple libusb command we issue:

/* Read the special descriptor */
ret = usb_get_descriptor(devh, 0x03, 0xee, buf, sizeof(buf));

// Dump it, if requested
if (dumpfile != NULL && ret > 0) {
  fprintf(dumpfile, "Microsoft device descriptor 0xee:\n");
  data_dump_ascii(dumpfile, buf, ret, 16);
}

It typically looks like this:

Microsoft device descriptor 0xee:
        0000: 1203 4d00 5300 4600 5400 3100 3000 3000   ..M.S.F.T.1.0.0.
        0010: 1c00                                      ..
Microsoft device response to control message 1, CMD 0x1c:
        0000: 2800 0000 0001 0400 0100 0000 0000 0000   (...............
        0010: 0001 4d54 5000 0000 0000 3030 0000 0000   ..MTP.....00....
        0020: 0000 0000 0000 0000                       ........
Potential MTP Device with VendorID:22b8 and ProductID:6415 responded
to control message 2 with a response that was too short. Problems may
arrise but continuing
Device info:

But Ziilabs Egg actually reply properly to the second control message:

Microsoft device descriptor 0xee:
	0000: 1203 4d00 5300 4600 5400 3100 3000 3000	..M.S.F.T.1.0.0.
	0010: 0100                                   	..
Microsoft device response to control message 1, CMD 0x01:
	0000: 2800 0000 0001 0400 0100 0000 0000 0000	(...............
	0010: 0001 4d54 5000 0000 0000 0000 0000 0000	..MTP...........
	0020: 0000 0000 0000 0000                    	........
Microsoft device response to control message 2, CMD 0x01:
	0000: 0c00 0000 0001 0500 0000 0000          	............

A special oddity is devices that *require* you to probe the
device descriptor and won't even work if you don't:
ZiiLabs Egg, several SanDisk Sansas, and some LGE phones
display this behaviour.

Since the devices are only ever tested with Windows nobody notice
that they don't work properly without the probing...

There are some more generic USB misbehaviour displayed by these
devices I can list if you're interested.

Yours,
Linus Walleij

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Roger Quadros]

ext Linus Walleij wrote:
> 2010/4/19 Steve Calfee <stevecalfee@gmail.com>:
> 
>> For 6 months, a while ago, I was working on virtual USB stuff for a
>> company. I did analyser traces of many devices including many MS
>> devices (mice, webcam, keyboard, joystick), and never found any device
>> from MS or anyone that supported that command. All devices that I saw
>> just replied (properly) with a STALL - and Winxp would just continue
>> on and handle the device.
> 
> I don't think they add it to that kind of devices. Only MTP players
> for what I've seen. Maybe some weirdo RNDIS stuff use it too?
> 
> But as you see Windows issues this command to absolutely everything
> you plug in, I've been thinking about how we could emulate the same
> behaviour in Linux but actually I think it's a bit insane and only take
> extra time to send that command to whatever you plug in.
> 
> Still it would be nice to know directly from userspace if a device that
> was plugged in was MTP or not, especially we need this for udev
> rules (or HAL, DeviceKit etc, whatever) that want to make the device
> read/writable for the console user when it's plugged in.
> 
>> When you say "older windowses", which one; the only earlier ones with
>> USB was 98 and descendants and somewhat 95.
> 
> Especially the Win98 and Win2000 stuff that comes with the Windows
> Media Player has to respond to it.
> 
> Actually Windows probably has some internal list of devices and
> specific quirks it has to use for them to work properly, but I'm not
> sure. (I asked them about it I think, but didn't get any replies.)
> 
>> Also have you found a device that actually responds to the "get
>> osdescriptor" request?
> 
> Almost all MTP devices out there does, check the logs here:
> http://libmtp.cvs.sourceforge.net/viewvc/libmtp/libmtp/logs/
> 
> If the device responds with something sane for command 0xee
> the MTP stack will go on to issue special commands, you can find
> our code for this here:
> http://libmtp.cvs.sourceforge.net/viewvc/*checkout*/libmtp/libmtp/src/libusb-glue.c?revision=1.284
> 

Do you know if these older Windows OSes request the OS descriptor when the 
device uses a standard USB class code?

AFAIK the MTP device device should use PTP Class, Subclass and protocol codes 
(i.e. 6:1:1). In this case Windows XP treats it as a PTP device (even if the 
device implements OS descriptors).
I'm sure all MTP devices in the market that implement OS descriptors use Vendor 
Specific class (i.e. 0xff:0:0) which is not the right thing to do after MTP has 
been standardized by usb.if.

cheers,
-roger

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Linus Walleij]

2010/4/20 Roger Quadros <roger.quadros-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>:

>> http://libmtp.cvs.sourceforge.net/viewvc/*checkout*/libmtp/libmtp/src/libusb-glue.c?revision=1.284
>
> Do you know if these older Windows OSes request the OS descriptor when the
> device uses a standard USB class code?

I haven't tested, but I think Windows will attempt to always use the OS
descriptor first and foremost.

> AFAIK the MTP device device should use PTP Class, Subclass and protocol
> codes (i.e. 6:1:1). In this case Windows XP treats it as a PTP device (even
> if the device implements OS descriptors).
>
> I'm sure all MTP devices in the market that implement OS descriptors use
> Vendor Specific class (i.e. 0xff:0:0) which is not the right thing to do
> after MTP has been standardized by usb.if.

Yes they should, but still very few devices, if any, use the PTP class code.

The reason behind, and the reason to why they use the OS descriptor at all,
if I understood correctly, was that Microsoft actually *wanted* to use the PTP
class for MTP devices, but to do that the MTP extensions had to pass
through the USB IF standardization process which took some three years or
so. In the meantime USB IF forbade them to use the PTP class code for
something that was not officially a PTP extension.

So these devices all are class 0xff  "vendor specific" or 0x00 "defined at
interface level". (One device mistakedly use class code 111 decimal!)
I haven't however looked at what they're using as bInterfaceClass really,
perhaps there are MTP devices out there that define themselves as PTP,
I've never heard of one, other than the experimental device that was used
to implement the proper detection algorithm in libmtp.

I think Windows only knows they are MTP devices by either
probing the OS descriptor or having a built-in table of MTP-compliant
vendor/device ID pairs. Probably both, because some of the very earliest
"PMC" (Portable Media Center) models didn't even have OS descriptors.

I guess Felipe may have first-hand experience with using the PTP class
code only? Maybe this works in the latest Windowses, post-USB IF
standardization? No idea.

Maybe tagging a device with the PTP class  and subclass 0x01 will make
it always fall back to PTP mode only under Windows, MTP features disabled,
this would not surprise me one bit.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Roger Quadros]

ext Linus Walleij wrote:
> 2010/4/20 Roger Quadros <roger.quadros-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>:
> 
>>> http://libmtp.cvs.sourceforge.net/viewvc/*checkout*/libmtp/libmtp/src/libusb-glue.c?revision=1.284
>> Do you know if these older Windows OSes request the OS descriptor when the
>> device uses a standard USB class code?
> 
> I haven't tested, but I think Windows will attempt to always use the OS
> descriptor first and foremost.
> 
>> AFAIK the MTP device device should use PTP Class, Subclass and protocol
>> codes (i.e. 6:1:1). In this case Windows XP treats it as a PTP device (even
>> if the device implements OS descriptors).
>>
>> I'm sure all MTP devices in the market that implement OS descriptors use
>> Vendor Specific class (i.e. 0xff:0:0) which is not the right thing to do
>> after MTP has been standardized by usb.if.
> 
> Yes they should, but still very few devices, if any, use the PTP class code.
> 
> The reason behind, and the reason to why they use the OS descriptor at all,
> if I understood correctly, was that Microsoft actually *wanted* to use the PTP
> class for MTP devices, but to do that the MTP extensions had to pass
> through the USB IF standardization process which took some three years or
> so. In the meantime USB IF forbade them to use the PTP class code for
> something that was not officially a PTP extension.
> 
> So these devices all are class 0xff  "vendor specific" or 0x00 "defined at
> interface level". (One device mistakedly use class code 111 decimal!)
> I haven't however looked at what they're using as bInterfaceClass really,
> perhaps there are MTP devices out there that define themselves as PTP,
> I've never heard of one, other than the experimental device that was used
> to implement the proper detection algorithm in libmtp.
> 
> I think Windows only knows they are MTP devices by either
> probing the OS descriptor or having a built-in table of MTP-compliant
> vendor/device ID pairs. Probably both, because some of the very earliest
> "PMC" (Portable Media Center) models didn't even have OS descriptors.
> 
> I guess Felipe may have first-hand experience with using the PTP class
> code only? Maybe this works in the latest Windowses, post-USB IF
> standardization? No idea.
> 
> Maybe tagging a device with the PTP class  and subclass 0x01 will make
> it always fall back to PTP mode only under Windows, MTP features disabled,
> this would not surprise me one bit.
> 
I can confirm this. Using PTP class code for an MTP device and no OS 
descriptors, falls back to PTP mode on Windows XP. On Windows 7 it works as MTP 
device. Need to confirm on Vista though.

On Linux (Ubuntu 9.04) it works as PTP device.

-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Linus Walleij]

2010/4/21 Roger Quadros <roger.quadros-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>:

[MTP device with PTP class and MTP extension code]

> On Linux (Ubuntu 9.04) it works as PTP device.

If you have libmtp 1.0.1 or later it should work as MTP with some
client program like Rhythmbox or Amarok or Banshee, unless some
PTP handler hogs it first.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Felipe Balbi]

On Mon, Apr 19, 2010 at 11:03:24PM +0200, ext Steve Calfee wrote:
>Also have you found a device that actually responds to the "get
>osdescriptor" request?

any mtp device pre-USB-IF spec will do it.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches

[Roger Quadros]

ext Linus Walleij wrote:
> 2010/4/19 Felipe Balbi <felipe.balbi@nokia.com>:
>>> 2010/4/18 Linus Walleij <linus.ml.walleij@gmail.com>:
> 
>>> Further comments: there is apparently a driver floating around this list
>>> for supporting PTP through the gadgetfs. How does this work relate
>>> to that, and why can't you use gadgetfs?
>> dude, can't you read ? gadgetfs prevents us from combining into a composite
>> gadget. We went throught that already. Please follow the thread before
>> commenting.
> 
> Yeah sorry, I'm trying to catch up and miss some pieces here and there.
> I'm mainly reading it from the MTP side of things.
> 
>>> Second: after looking at this, I think that atleast the part of
>>> functionality
>>> called "OS descriptor" should be in the kernel and not in userspace,
>>> is the OS descriptor the reason to why you want to expose EP0 to
>>> userspace, or are you using this for other things in the MTP stack?
>> OS descriptor is MS specific crap, it's not on the USB-IF mtp spec and most
>> like MS has some patent on that.
> 
> ...so I read you like it's not going to be supported with the proposed
> solution?
> 
> I think that if you want you gadget to work with older Windowses,
> you simply have to support this.
> 

The device can simply fall back to PTP mode on older Windows.

cheers,
-roger