USB gadget with drivers "on board"

USB gadget with drivers "on board"

[Michał Nazarewicz]

Hello everyone,

I need to create an USB gadget with drivers for Windows included
"on board".  In particular, when the gadget is connected to Windows
host it is detected as mass storage and mounted drive include the
drivers.  However, when the drivers are installed, it is detected
as some other device.

Now, it seems that a simple composite device with two configurations
is enough -- the first containing mass storage and the second other
functions.  My tests show that Windows manages to set the first
configuration and detect the mass storage interface.

Unfortunately, Linux does the same thing -- chooses the first
configuration and detects the mass storage interface.  What I'd
like to see is Linux choosing the second configuration which is
more functional.

Is there any way to accomplish that?

I came up with an idea of swapping bConfigurationValues (so that mass
storage configuration has it set to 2 and the other configuration
has it set to 1) but still retaining the order those are given to
host (a bit like with g_ether).

This however did not work, as Linux pretty much ignores those values
when choosing configuration.

So can it be done differently?

I think the following change would achieve the result I am seeking:

diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
index bdf87a8..38fd44e 100644
--- a/drivers/usb/core/generic.c
+++ b/drivers/usb/core/generic.c
@@ -121,21 +121,22 @@ int usb_choose_configuration(struct usb_device *udev)
                   		else if (udev->descriptor.bDeviceClass !=
                   						USB_CLASS_VENDOR_SPEC &&
                   				(!desc || desc->bInterfaceClass !=
                   						USB_CLASS_VENDOR_SPEC)) {
                   			best = c;
                   			break;
                   		}

                   		/* If all the remaining configs are vendor-specific,
                   		 * choose the first one. */
-		else if (!best)
+		else if (!best || best->desc.bConfigurationValue > c->desc.bConfigurationValue)
                   			best = c;
                   	}

                   	if (insufficient_power > 0)
                   		dev_info(&udev->dev, "rejected %d configuration%s "
                   			"due to insufficient available bus power\n",
                   			insufficient_power, plural(insufficient_power));

                   	if (best) {
                   		i = best->desc.bConfigurationValue;

Or maybe it'd be a good idea to prefer configurations with bigger
number of interfaces?

So what do you think? Does anyone know a (better) solution?

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

Re: USB gadget with drivers "on board"

[Daniel Mack]

On Mon, Apr 26, 2010 at 10:29:05AM +0200, Michał Nazarewicz wrote:
> I need to create an USB gadget with drivers for Windows included
> "on board".  In particular, when the gadget is connected to Windows
> host it is detected as mass storage and mounted drive include the
> drivers.  However, when the drivers are installed, it is detected
> as some other device.
> 
> Now, it seems that a simple composite device with two configurations
> is enough -- the first containing mass storage and the second other
> functions.  My tests show that Windows manages to set the first
> configuration and detect the mass storage interface.

Why are you using two configurations on this device instead of one 
configuration with two interfaces? Interfaces are not allowed to share 
endpoints within one configuration, so they can be used simultaniously.

Daniel

Re: USB gadget with drivers "on board"

[Michał Nazarewicz]

> On Mon, Apr 26, 2010 at 10:29:05AM +0200, Michał Nazarewicz wrote:
>> I need to create an USB gadget with drivers for Windows included
>> "on board".  In particular, when the gadget is connected to Windows
>> host it is detected as mass storage and mounted drive include the
>> drivers.  However, when the drivers are installed, it is detected
>> as some other device.
>>
>> Now, it seems that a simple composite device with two configurations
>> is enough -- the first containing mass storage and the second other
>> functions.  My tests show that Windows manages to set the first
>> configuration and detect the mass storage interface.

On Mon, 26 Apr 2010 16:16:05 +0200, Daniel Mack <daniel@caiaq.de> wrote:
> Why are you using two configurations on this device instead of one
> configuration with two interfaces? Interfaces are not allowed to share
> endpoints within one configuration, so they can be used simultaniously.

Ideally, I would like to use two configurations on its own just like
g_ether that is one configuration with RNDIS and some other functionality
and another with CDC ECM and some other functionality.

It seems however that such gadgets are not properly detected by Windows
as composite devices and thus require a driver (I imagined a single INF
should be enough but now I'm not even sure of that) and so I tried adding
another configuration with just the mass storage function and this seems
to be handled correctly.

Now, even if I were to ignore the other RNDIS/ECM multiple personality
disorder and sticking to a single configuration with RNDIS there's still
an issue (or challenge if you will) of a "Found new driver" dialog
popping up like crazy when the device is inserted but the drivers from
mass storage didn't have time to install.  This is especially true since
it was my experience that RDNIS is able to freeze Windows if it's not
the first interface.

So in the end, I'm looking for a method to get a device that can be
plugged in and report as mass storage with drivers but when drivers
are installed report as something else.  I know it is possible since
I encountered several devices that do exactly that.


PS. There seem to be some mass with the To and Cc headers in my
original message.  Sorry about that.

-- 
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: USB gadget with drivers "on board"

[Daniel Mack]

On Mon, Apr 26, 2010 at 04:42:17PM +0200, Michał Nazarewicz wrote:
> >On Mon, Apr 26, 2010 at 10:29:05AM +0200, Michał Nazarewicz wrote:
> >>I need to create an USB gadget with drivers for Windows included
> >>"on board".  In particular, when the gadget is connected to Windows
> >>host it is detected as mass storage and mounted drive include the
> >>drivers.  However, when the drivers are installed, it is detected
> >>as some other device.
> >>
> >>Now, it seems that a simple composite device with two configurations
> >>is enough -- the first containing mass storage and the second other
> >>functions.  My tests show that Windows manages to set the first
> >>configuration and detect the mass storage interface.
> 
> On Mon, 26 Apr 2010 16:16:05 +0200, Daniel Mack <daniel@caiaq.de> wrote:
> >Why are you using two configurations on this device instead of one
> >configuration with two interfaces? Interfaces are not allowed to share
> >endpoints within one configuration, so they can be used simultaniously.
> 
> Ideally, I would like to use two configurations on its own just like
> g_ether that is one configuration with RNDIS and some other functionality
> and another with CDC ECM and some other functionality.

If you do that, the configuration which is chosen eventually purely
relies on the driver stack and/or user setting.

> It seems however that such gadgets are not properly detected by Windows
> as composite devices and thus require a driver (I imagined a single INF
> should be enough but now I'm not even sure of that) and so I tried adding
> another configuration with just the mass storage function and this seems
> to be handled correctly.

Maybe Windows just selects the interface it has a driver for already?
On the other hand, that would be giving a hint of some sort of
intelligence, which I can't believe either as their USB stack is totally
screwed. Not a single detail in its implementation seems to make any
sense.

> Now, even if I were to ignore the other RNDIS/ECM multiple personality
> disorder and sticking to a single configuration with RNDIS there's still
> an issue (or challenge if you will) of a "Found new driver" dialog
> popping up like crazy when the device is inserted but the drivers from
> mass storage didn't have time to install.

Yeah, great technology. Even if you install the driver (which you have
to do even for USB sticks), you'll be prompted for the same action again
once you dare to plug in the device in some other port. This is because
Windows registeres its USB drivers under the USB host port in the device
tree, and hence once the same device is connected anywhere else, it's
completely new to the system again.

> This is especially true since
> it was my experience that RDNIS is able to freeze Windows if it's not
> the first interface.

Sic!

> So in the end, I'm looking for a method to get a device that can be
> plugged in and report as mass storage with drivers but when drivers
> are installed report as something else.  I know it is possible since
> I encountered several devices that do exactly that.

Are you sure they don't do exactly that by running two interfaces in
the same configuration? In theory, Windows should (as any other OS
as well) recognize the interfaces it has drivers for and handle them
automatically (after this stupid wizard tortured you of course). And if
there is an interface that needs special attention, you will need to
install a driver for it. But I haven't dealt with Windows for a longer
time, so I can only give hints at this point.

Daniel

Re: USB gadget with drivers "on board"

[Michał Nazarewicz]

> On Mon, Apr 26, 2010 at 04:42:17PM +0200, Michał Nazarewicz wrote:
>> Ideally, I would like to use two configurations on its own just like
>> g_ether that is one configuration with RNDIS and some other functionality
>> and another with CDC ECM and some other functionality.

On Mon, 26 Apr 2010 16:16:05 +0200, Daniel Mack <daniel@caiaq.de> wrote:
> If you do that, the configuration which is chosen eventually purely
> relies on the driver stack and/or user setting.

Granted, but since RDNIS needs an INF anyway there should be little or no
problems in specifying which configuration we are interested in.  And Linux
has a special case for RNDIS so there should be no problems here.

>> It seems however that such gadgets are not properly detected by Windows
>> as composite devices and thus require a driver (I imagined a single INF
>> should be enough but now I'm not even sure of that) and so I tried adding
>> another configuration with just the mass storage function and this seems
>> to be handled correctly.

> Maybe Windows just selects the interface it has a driver for already?

No.  Windows has a driver for composite gadget which acts as a bus for
other USB drivers connected to interfaces.  However, in order for Windows
to treat a gadget as composite several rules need to be adhered to.  Those
include specific class, subclass and protocol as well as requirement that
the gadget can have only one configuration.  The rules are described at
<URL:http://msdn.microsoft.com/en-us/library/ff537109.aspx>.

> On the other hand, that would be giving a hint of some sort of
> intelligence, which I can't believe either as their USB stack is totally
> screwed. Not a single detail in its implementation seems to make any
> sense.

Yes, I think we all agree on that. ;)

>> Now, even if I were to ignore the other RNDIS/ECM multiple personality
>> disorder and sticking to a single configuration with RNDIS there's still
>> an issue (or challenge if you will) of a "Found new driver" dialog
>> popping up like crazy when the device is inserted but the drivers from
>> mass storage didn't have time to install.

> Yeah, great technology. Even if you install the driver (which you have
> to do even for USB sticks), you'll be prompted for the same action again
> once you dare to plug in the device in some other port.

Hopefully, then the drivers are installed Windows will be able to find them
on its own, but this goes even beyond that.  When the device is connected
for the first time there will be no drivers and the full blown "Found
New Hardware" dialog will be shown.

On the other hand, if I ware able to make Windows treat me as a mass
storage gadget when drivers are not installed, this will solve (some of)
my problems.

>> So in the end, I'm looking for a method to get a device that can be
>> plugged in and report as mass storage with drivers but when drivers
>> are installed report as something else.  I know it is possible since
>> I encountered several devices that do exactly that.

> Are you sure they don't do exactly that by running two interfaces in
> the same configuration?

Yes, I'm sure.  I've investigated an USB GSM modem which, when plugged
for the first time reports as mass storage (single configuration, single
interface) and when drivers are installed as a full blown composite
gadget.  I still haven't figured out how it does that.

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

Re: USB gadget with drivers "on board"

[Josua Dietze]

Michał Nazarewicz schrieb:

> On Mon, 26 Apr 2010 16:16:05 +0200, Daniel Mack <daniel@caiaq.de> wrote:
>> Are you sure they don't do exactly that by running two interfaces in
>> the same configuration?
> 
> Yes, I'm sure.  I've investigated an USB GSM modem which, when plugged
> for the first time reports as mass storage (single configuration, single
> interface) and when drivers are installed as a full blown composite
> gadget.  I still haven't figured out how it does that.


These are the notorious mode switching devices. In Windows, they 
obviously install a special storage driver doing one specific action 
on each following plugging.
This action - some storage or control command - will "flip" the 
device, making it "disconnect" and returning as a completely different 
composite device.

Storage commands used for this procedure range from "SCSI rezero" over 
"passthrough" to "SCSI eject", or involve vendor specific stuff.


Josua Dietze

Re: USB gadget with drivers "on board"

[Alan Stern]

On Mon, 26 Apr 2010, Josua Dietze wrote:

> Michał Nazarewicz schrieb:
> 
> > On Mon, 26 Apr 2010 16:16:05 +0200, Daniel Mack <daniel@caiaq.de> wrote:
> >> Are you sure they don't do exactly that by running two interfaces in
> >> the same configuration?
> > 
> > Yes, I'm sure.  I've investigated an USB GSM modem which, when plugged
> > for the first time reports as mass storage (single configuration, single
> > interface) and when drivers are installed as a full blown composite
> > gadget.  I still haven't figured out how it does that.
> 
> 
> These are the notorious mode switching devices. In Windows, they 
> obviously install a special storage driver doing one specific action 
> on each following plugging.
> This action - some storage or control command - will "flip" the 
> device, making it "disconnect" and returning as a completely different 
> composite device.
> 
> Storage commands used for this procedure range from "SCSI rezero" over 
> "passthrough" to "SCSI eject", or involve vendor specific stuff.

I was going to say the same thing.  For ease of use, I recommend using
a "SCSI eject" to trigger the mode change.  That way, Linux users who
don't have the usb-modeswitch program installed can get the same effect
by running eject.

Alan Stern

Re: USB gadget with drivers "on board"

[Josua Dietze]

Alan Stern schrieb:

> On Mon, 26 Apr 2010, Josua Dietze wrote:
>> These are the notorious mode switching devices. In Windows, they 
>> obviously install a special storage driver doing one specific action 
>> on each following plugging.
>> This action - some storage or control command - will "flip" the 
>> device, making it "disconnect" and returning as a completely different 
>> composite device.
>>
>> Storage commands used for this procedure range from "SCSI rezero" over 
>> "passthrough" to "SCSI eject", or involve vendor specific stuff.
> 
> I was going to say the same thing.  For ease of use, I recommend using
> a "SCSI eject" to trigger the mode change.  That way, Linux users who
> don't have the usb-modeswitch program installed can get the same effect
> by running eject.


Important for the Linux handling is that "mode 1" is clearly 
distinguishable from "mode 2", either by using a different product ID 
or by setting a different class for the device or interface 0 (will 
most likely be "8" for the install mode).

And it might be a good idea not to re-use any known ID for the install 
mode, like the 05c6:1000 which my Samsung phone and loads of other 
devices are using.
This makes switch handling complicated (though not impossible).


Josua Dietze

Re: USB gadget with drivers "on board"

[Michał Nazarewicz]

>> On Mon, 26 Apr 2010, Josua Dietze wrote:
>>> These are the notorious mode switching devices. In Windows, they
>>> obviously install a special storage driver doing one specific action
>>> on each following plugging.
>>> This action - some storage or control command - will "flip" the
>>> device, making it "disconnect" and returning as a completely different
>>> composite device.
>>>
>>> Storage commands used for this procedure range from "SCSI rezero" over
>>> "passthrough" to "SCSI eject", or involve vendor specific stuff.

> Alan Stern schrieb:
>> I was going to say the same thing.  For ease of use, I recommend using
>> a "SCSI eject" to trigger the mode change.  That way, Linux users who
>> don't have the usb-modeswitch program installed can get the same effect
>> by running eject.

On Mon, 26 Apr 2010 22:14:54 +0200, Josua Dietze <digidietze@draisberghof.de> wrote:

> Important for the Linux handling is that "mode 1" is clearly
> distinguishable from "mode 2", either by using a different product ID
> or by setting a different class for the device or interface 0 (will
> most likely be "8" for the install mode).

So it will be enough to change the USB device class for the zeroth
interface for udev to recognise the mass storage to be ejected?  Note
that I will use mass storage in the second mode as well.

Also, I think that it might be a good idea to make some "standardised"
mechanism for all such devices so that a generic udev code could be
written.  Adding things to the descriptors may be difficult in a way,
but maybe adding "[NoCD]" to the interface name would be enough.

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

Re: USB gadget with drivers "on board"

[Michał Nazarewicz]

>>> On Mon, 26 Apr 2010, Josua Dietze wrote:
>>>> These are the notorious mode switching devices. In Windows, they
>>>> obviously install a special storage driver doing one specific action
>>>> on each following plugging.
>>>> This action - some storage or control command - will "flip" the
>>>> device, making it "disconnect" and returning as a completely different
>>>> composite device.

>> Alan Stern schrieb:
>>> I was going to say the same thing.  For ease of use, I recommend using
>>> a "SCSI eject" to trigger the mode change.  That way, Linux users who
>>> don't have the usb-modeswitch program installed can get the same effect
>>> by running eject.

On Wed, 28 Apr 2010 10:46:12 +0200, Michał Nazarewicz <m.nazarewicz@samsung.com> wrote:
> Also, I think that it might be a good idea to make some "standardised"
> mechanism for all such devices so that a generic udev code could be
> written.  Adding things to the descriptors may be difficult in a way,
> but maybe adding "[NoCD]" to the interface name would be enough.

It got me thinking that maybe, it would be cool to do things in a generic
way in Linux by using the iConfiguration.  A, let's call it' NoCD-capable
device would have the first configuration named "Foo Installation Disc
[NoCD]" end while enumerating Linux would prefer configurations which
don't have the tag over the ones that have it.  At the same time, for
older kernels an udev rule would be provided.  And of course, non
NoCD-capable devices (or Linux-unaware if you will) devices would be
handled the way they are handled now.

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

Re: USB gadget with drivers "on board"

[Josua Dietze]

Michał Nazarewicz schrieb:
> On Mon, 26 Apr 2010 22:14:54 +0200, Josua Dietze 
> <digidietze@draisberghof.de> wrote:
> 
>> Important for the Linux handling is that "mode 1" is clearly
>> distinguishable from "mode 2", either by using a different product ID
>> or by setting a different class for the device or interface 0 (will
>> most likely be "8" for the install mode).
> 
> So it will be enough to change the USB device class for the zeroth
> interface for udev to recognise the mass storage to be ejected?  Note
> that I will use mass storage in the second mode as well.

This is often the case with the common "zero-cd" devices, but 
they have the storage on upper interface numbers after switching.

The point is to enable udev or any other tool to distinguish 
between "unswitched" and "switched"; otherwise the procedure 
for switching will be executed on *both* modes which might 
disturb the device or the system.

A change in one of the attributes like iProduct or iSerial 
could be detected as well of course.

> Also, I think that it might be a good idea to make some "standardised"
> mechanism for all such devices so that a generic udev code could be
> written.  Adding things to the descriptors may be difficult in a way,
> but maybe adding "[NoCD]" to the interface name would be enough.

That is up to the (countless) manufacturers of course; on the 
other hand, the Windows drivers need to recognize the mode as 
well so there should always be one way or the other to 
accomplish that.


Josua Dietze

Re: USB gadget with drivers "on board"

[Michał Nazarewicz]

> Michał Nazarewicz schrieb:
>> Also, I think that it might be a good idea to make some "standardised"
>> mechanism for all such devices so that a generic udev code could be
>> written.  Adding things to the descriptors may be difficult in a way,
>> but maybe adding "[NoCD]" to the interface name would be enough.

On Wed, 28 Apr 2010 13:41:09 +0200, Josua Dietze <digidietze@draisberghof.de> wrote:
> That is up to the (countless) manufacturers of course; on the
> other hand, the Windows drivers need to recognize the mode as
> well so there should always be one way or the other to
> accomplish that.

Windows most likely recognises the device by vendor and product ID after the
drivers are installed.  On Linux you add a rule to udev (if I understand
correctly) which is a bit of a burden because (i) it takes time and (ii) the
list must be updated.  What I'm thinking is creating a generic way of marking
"install mode" devices so that no such list is necessary.  Of course, it'll
take time for vendors to recognise this scheme but maybe over time some major
players will.

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

Re: USB gadget with drivers "on board"

[Alan Stern]

On Wed, 28 Apr 2010, [utf-8] Michał Nazarewicz wrote:

> So it will be enough to change the USB device class for the zeroth
> interface for udev to recognise the mass storage to be ejected?  Note
> that I will use mass storage in the second mode as well.

No, you also have to go through a disconnect-reconnect cycle on the USB 
bus.  When you do, changing the bInterfaceClass value will be 
sufficient to tell the kernel that the device needs to be 
re-enumerated.

> Also, I think that it might be a good idea to make some "standardised"
> mechanism for all such devices so that a generic udev code could be
> written.  Adding things to the descriptors may be difficult in a way,
> but maybe adding "[NoCD]" to the interface name would be enough.

I seriously doubt you'll be able to convince all the other
manufacturers to agree to a standardized convention for this.

Alan Stern