| CATEGORII DOCUMENTE |
| Bulgara | Ceha slovaca | Croata | Engleza | Estona | Finlandeza | Franceza |
| Germana | Italiana | Letona | Lituaniana | Maghiara | Olandeza | Poloneza |
| Sarba | Slovena | Spaniola | Suedeza | Turca | Ucraineana |
Portable Device Installation Considerations
App Note
Author: Windows Media Devices Group
Version:
1.1
Devices with proprietary communications stack
Compatibility with USB Class ID
Retrieving the OS String Descriptor
Verifying the Integrity of the OS Descriptor
Microsoft OS String Descriptor Constraints
Retrieving an OS Feature Descriptor
Microsoft OS Feature Descriptor Constraints
Structure of the MTP Feature Descriptor
Extended Device Class Identification
MTP Identifier (wpdusb.sys or similar component)
Windows Media Player 10 (WMP10) Installed
WMP10 (or MTP Drivers) Installed
WMP10 (or MTP Drivers) Not Installed
Device Installation Guidelines
USB Mass Storage Class Bulk-Only Transport
This document contains information for review by Microsofts internal teams and partners working with Microsofts MTP technology. This is a draft proposal that is subject to broader review. As such this document does not reflect a booked plan. This document and the subject matter herein is strictly confidential and is to be disclosed only to people who have agreed to the terms in the MTP PK EULA.
This document is intended as a guide for those working with Microsofts MTP technology. MTP is an extension to the industry standard PTP, which was developed to provide richer communications between PCs and digital still cameras. The MTP extensions to PTP provide for similar rich communications between PCs a wider variety of digital media devices (e.g. portable media players and cell phones).
To support MTP devices, Microsoft has developed a class driver that will provide improved stability and true plug and play for all MTP devices. The class driver initially shipped with Windows Media Player 10. It will also ship in future versions of Windows .
Microsoft is currently in the process of obtaining a USB class ID for MTP devices. However, at the time the first MTP devices were scheduled to ship, a class ID was not available. Without this class ID, the PC has no way of automatically detecting that an MTP device has been connected and thus no way of automatically installing the MTP class driver. Until a class driver is obtained and supported in the OS, Microsoft is recommending that MTP device manufacturers use Microsofts proprietary OS descriptor technology. This document outlines the impact on portable device manufacturers and end users, of using the OS descriptor technology as a (temporary) replacement for a USB class ID for MTP capable devices.
It also discusses installation requirement scenarios based on different device/OS configurations.
Devices with proprietary communications stack
Devices that have their own proprietary communications stack are not part of the scope of this document.
The following information was gathered from various OS descriptor documents. More information can be found in the USB FAQ on the Microsoft Web site.
The Microsoft OS Descriptor is a tool that enables hardware vendors to include additional information in their devices, which can be retrieved by a Microsoft OS Descriptor, enabled operating system. The information that needs to be stored in the device will have to comply with the format of the feature descriptors designed by Microsoft. No Feature Descriptor can be Defined or implemented without Microsofts consent.
The Microsoft OS Descriptor is a term used to describe the information embedded in the device that can be retrieved by a Microsoft OS Descriptor Enabled operating system. The format of the data must be in alliance with the Feature Descriptors defined by Microsoft.
The Microsoft OS Descriptor is broken up into the following segments:
The Microsoft OS String Descriptor is a special string that is embedded at a fixed string index. The purpose of this string is to inform the operating system of the presence of the Microsoft OS Descriptor along with additional information.
The Feature Descriptors are fixed format descriptors that have been defined and allocated by Microsoft.
A device can have both a USB Class ID and an OS Descriptor.
When a device with both a MS OS descriptor and a USB class ID connects to a PC with an OS that supports an MS OS descriptor, the OS will give priority to the OS descriptor. In Windows Vista, if the device does not report to be USB 2.0 in their device descriptor the OS descriptor will not be read.
When a device with both a MS OS descriptor and a USB class ID connects to a PC with an OS that does not support an MS OS descriptor, the OS will use the USB class ID.
To support the OS descriptor, the device must implement the following:
The Microsoft OS String Descriptor is a string that is stored at string index 0xEE. The format of this string is well defined.
The Microsoft OS String Descriptor is used to achieve the following objectives:
There will only be one Microsoft OS String Descriptor stored on the device. The following sections narrate the structure of the Microsoft OS String Descriptor and its retrieval procedure.
The structure of the string descriptor is specified below.
|
Field |
Length (Bytes) |
Value |
Description |
|
bLength |
1 |
0x12 |
Length of the descriptor |
|
bDescriptorType |
1 |
0x03 |
String Descriptor |
|
qwSignature |
14 |
MSFT100 |
Signature field (4D00530046005400310030003000) |
|
bMS_VendorCode |
1 |
Vendor Code |
Vendor code to fetch other OS Feature Descriptors |
|
bPad |
1 |
0x00 |
Pad field |
Table 1: Structure of the Microsoft OS String Descriptor
The structure of the Microsoft OS String Descriptor is fixed for version 1.00 and has an overall length of 18 bytes. The version number of the Microsoft OS String Descriptor is listed in the qwSignature field.
The information stored in the bMS_VendorCode field must be a single byte value. It will be used to retrieve Microsoft OS Feature Descriptors, and this byte value is used in the bmRequest field in section 3.1.
To retrieve the information stored in the string, a standard GET_DESCRIPTOR request must be issued to the device. The format of the request is specified below.
|
bmRequestType |
bRequest |
wValue |
wIndex |
wLength |
Data |
|
1000 0000B |
GET_DESCRIPTOR |
0x03EE |
0x0000 |
0x12 |
Returns the string. |
Table 2: Standard Get_Descriptor String Request
The bmRequestType field is a bitmap composed of three parts direction of data transfer, descriptor type, and recipient. As per the Universal Serial Bus Specifications, the value of bmRequestType is set to 1000 0000b (0x80).
The bRequest field should be set to a standard GET_DESCRIPTOR request.
For a GET_DESCRIPTOR request, the wValue field is split into two parts. The high byte stores the descriptor type and the low byte stores the descriptor index. To retrieve the Microsoft OS String Descriptor, the high byte should be set to retrieve a string descriptor, hence 0x03. Since the Microsoft OS String Descriptor is always stored at index 0xEE, this string index should be stored in the lower byte of the wValue field.
The wIndex is used to store the Language ID, but it must be set to zero for a Microsoft OS String Descriptor.
The wLength field is used to indicate the length of the string descriptor to be retrieved. The device should respond to any valid range from 0x02-0xFF.
If a device does not have a valid descriptor at the corresponding address (0xEE), it will respond with a Request Error/Stall. Devices that do NOT respond with a stall, a single-ended Zero reset will be issued to the device (to recover it, if it should go into an unknown state).
Since vendors are allowed to use any string ID to store information, the operating system must verify that the string stored in index 0xEE is indeed the Microsoft OS String Descriptor. To verify this, the following tests will be conducted. Failure of either will inhibit retrieval of the Microsoft OS Feature Descriptors.
If a vendor stores a string in index location 0xEE, the operating system will retrieve the string and query it to see if it is the Microsoft OS String. This can be verified by comparing the signature field in the string to the signature field entry specified above. A mismatch would prevent further parsing of the string.
The second test will include a verification of the length of the string based on the version number specified in the signature field. The version number specified (in the string MSFT100) is 1.00. This corresponds to an 18-byte string descriptor.
The following constraints apply to Microsoft OS String Descriptors and its retrieval:
A Feature Descriptor is a fixed format descriptor that has been defined for a specific purpose.
To retrieve a Microsoft OS Feature Descriptor, a special GET_MS_DESCRIPTOR request needs to be issues to the device. The format of the request is specified below.
|
bmRequestType |
bRequest |
wValue |
wIndex |
wLength |
Data |
|
1100 0000b |
GET_MS_DESCRIPTOR |
X |
Feature Index |
Length |
Returns descriptor |
Table 3: Standard Device Request format
The bmRequestType field is a bitmap composed of three parts direction of data transfer, descriptor type, and recipient and is in accordance with the Universal Serial Bus Specification Document. The Microsoft OS Feature Descriptor is a vendor specific descriptor and the direction of data transfer is from the device to the host. Hence the value of bmRequestType is set to 1100 0000b (0xC0).
The bRequest Field is used to indicate the format of the request. In order to retrieve a Microsoft OS Feature Descriptor, the bRequest field should be populated with a special GET_MS_DESCRIPTOR byte. The value of this byte is indicated by the bMS_VendorCode, which is retrieved from the Microsoft String Descriptor. Refer to section 3.3.1.2, which refers to the retrieval of the Microsoft OS String Descriptor.
The wValue field is put to special use and is broken up in to a high byte and a low byte. The high byte will be used to store the interface number. This is essential for storing Feature Descriptors on a per interface basis, especially for composite devices, or devices with multiple interfaces. In most cases, interface 0 will be used. The low byte will be used to store a page number. This feature prevents descriptors from having a size boundary of 64KB (a limit set by the size of the wLength field). A descriptor will be fetched with the page value initially set to zero. If a full descriptor (size is 64KB) is received, the page value will be incremented by one and the request for the descriptor will be sent again (this time with the incremented page value). This process will repeat till a descriptor of size less than 64KB is received. Note that the maximum number of pages is 255, placing a limit of 16MB on the descriptor size.
The wIndex field will store the Feature index number for the Microsoft OS Feature Descriptor being retrieved. Microsoft will maintain this list of Microsoft OS Feature Descriptors and indexes. To learn more about Microsoft OS Feature Descriptors refer to the supplementary document titled Supported Microsoft Feature Descriptors.
The wLength field specifies the length of the descriptor to be fetched. If the descriptor is longer than the number of bytes stated in the wLength field, only the initial bytes of the descriptor are returned. If it is shorter than the value specified in the wLenght field, a short packet is returned.
If a particular OS descriptor is not present, the device will issue a Request Error or stall.
The following constraints apply to Microsoft OS Feature Descriptors and their retrieval:
The OS descriptor technology is supported in Windows XP SP1, Windows Server 2003 and beyond.
To identify itself as capable of supporting MTP, a device must also support the Extended Configuration Descriptor which is one of the defined feature descriptors. The structure of this descriptor is as follows
The Header Section stores information about the rest of the Extended Configuration Descriptor. The dwLength field contains the total length of the entire Extended Configuration Descriptor. The Header section also contains a version number, which will be initially set to 1.00 (0100H). Future revisions of this descriptor may be released at a later stage. It must be noted that future versions of the Extended Configuration Descriptor might also need to increase the number of entries in the Header section, so please verify that this number is accurately stored in the device and read by the operating system.
|
Offset |
Field |
Size |
Value |
Description |
|
0 |
dwLength |
4 |
Unsigned DWord |
The length field describes the length of the Extended Configuration Descriptor in bytes. |
|
4 |
bcdVersion |
2 |
BCD |
Extended Configuration Descriptor release number in Binary Coded Decimal (i.e. version 1.00 is 0100H) |
|
6 |
wIndex |
2 |
Word |
Fixed = 0x0004 |
|
8 |
bCount |
1 |
Byte |
Total number of Function Sections that follow the Header Section = 0x01 |
|
9 |
RESERVED |
7 |
RESERVED |
Table 4: Extended Configuration Descriptor Header Section
The Function Section provides two important pieces of information. It groups consecutive interfaces, serving a similar purpose, into function groups, and provides Compatible and SubCompatible IDs for each function. The format of the Function Section (including values that should be used by an MTP device) is listed below.
|
Field |
Size |
Value |
Description |
|
|
0 |
bFirstInterfaceNumber |
1 |
Byte |
Starting Interface Number for this function = 0x00 |
|
1 |
bInterfaceCount |
1 |
Byte |
Total number of Interfaces that must be included to from this function = 0x01 |
|
2 |
compatibleID |
8 |
Bytes |
The Compatible ID for this function as defined by Microsoft = MTP |
|
10 |
subCompatibleID |
8 |
Bytes |
The Sub Compatible ID value as defined by Microsoft = 0 |
|
18 |
RESERVED |
6 |
RESERVED = 0 |
Table 5: Extended Configuration Descriptor Funciton Section
For computers running Windows Vista or Windows XP with Windows Media Player 11, the WPD driver allows MTP devices to identify themselves as a device class so that Windows may associate the proper generic icon with the device. This device class identification is a subcomponent of the MTP OS Descriptor identifier.
Three types of icons can be displayed for a given device. Vendor-provided icons take highest priority, followed by device class icons, with the generic icon being used in the absence of any icon information. Vendor-provided icons are strongly recommended for the best user experience.
Vendor icons take the highest priority for device icons in Windows. Vendor icons allow device vendors to attach branding and a device-specific icon to the MTP device. More information regarding vendor-provided icons can be found in the Vendor Provided Icons Speclet found in the Media Transfer Protocol Porting Kit.
Device class icons have been introduced for Windows Vista and Windows XP with Windows Media Player 11. Device class icons provide device vendors a chance to identify an MTP device as a particular class of devices so that a more specific icon can be provided. For example, a device can now identify itself specifically as a mobile phone and receive a generic mobile phone icon instead of the generic MTP icon. Examples of three device class icons are located below:
Legacy devices that do not provide a vendor-specified icon or identify themselves as part of a device class will be represented with a generic MTP icon. A minimum of device class identification is highly recommended for an improved user experience.
Seven device classes exist, identified by various subcomponents. To identify as a device class, the Microsoft OS Descriptor should be modified as shown in Table 6: MTP Subcomponent Identifiers.
|
MTP subcomponent identifier |
Perceived Device Type (MTP Device Property) |
Device class |
|
MS_COMP_MTP&MS_SUBCOMP_01 |
0x0 |
MTP generic |
|
MS_COMP_MTP&MS_SUBCOMP_02 |
0x1 |
MTP digital still camera |
|
MS_COMP_MTP&MS_SUBCOMP_03 |
0x2 |
MTP audio/video player |
|
MS_COMP_MTP&MS_SUBCOMP_04 |
0x3 |
MTP mobile handset |
|
MS_COMP_MTP&MS_SUBCOMP_05 |
0x5 |
MTP personal digital assistant (PDA) |
|
MS_COMP_MTP&MS_SUBCOMP_06 |
0x4 |
MTP digital video camera |
|
MS_COMP_MTP&MS_SUBCOMP_07 |
0x6 |
MTP audio recorder |
Table 6: MTP Subcomponent Identifiers
MTP drivers are currently shipping in Windows Media Player 10. However, Windows Media Player 10 can only be installed on PCs running a version of the OS later than Windows XP.
In order to allow device manufacturers to develop devices that can still be used on PCs running earlier versions of an operating system, Microsoft is proposing one of two solutions.
Microsoft is in the process of developing a service provider that will allow applications that use the WMDM9 API set to talk to MTP devices. Microsofts current plan is to make this service provider available for device manufacturers to ship in box with their devices so that it can be installed on applicable PCs. This service provider is currently scheduled to be available in Q4 2004.
Other solution that device companies may choose to consider is a dual-mode device. Many devices already support MSC today. Microsoft has developed a solution whereby a device can detect the configuration of the PC to which it is connected and automatically switch to the appropriate mode of communication.
At a high level, the solution works by taking advantage of the fact that dual mode devices will support both an MSC USB class ID (0x08 and Microsofts proprietary OS descriptor (see section on OS Descriptor).
When a device is connected to the PC, the following installation steps take place:
In versions of the OS that support the OS descriptor, presence of the OS descriptor (on a device) takes precedence over a USB class ID. When the OS descriptor is detected during the install process, the PnP system will attempt to find a matching driver. If the MTP communications stack has been installed, a matching driver will be found and loaded (wpdusb.sys or similar component). If the MTP communications stack has not been installed, no matching driver will be found and the PC will revert to the MSC class ID and load the USB MSC driver (usbstor.sys)
Once a driver has been loaded it will initiate communications with the device. Microsoft is proposing that by taking advantage of the unique nature of the communications initiated by each of these drivers, the device can determine which communication mode needs to be supported.
The USB Mass Storage Class Bulk-Only Transport spec requires that every MSC Command Block Wrapper (CBW) start with a DWORD signature, 0x43425355. Microsofts MSC driver (usbstor.sys) complies with this requirement. A MSC device could use this signature and/or other information (e.g. size of the command) to differentiate a CBW/MSC driver from other protocols/drivers.
Refer to the official USB documentation for more details on the specifics of CBWs
As outlined in the MTP spec, GetDeviceInfo must be issued to the device prior to any other operation. The Microsoft MTP class driver conforms to this requirement.
The bit pattern:
0000000C 0001 1001 xx xx xx xx
(where the last 4 bytes are indeterminate) corresponds to the structure of the generic USB container packet for the GetDeviceInfo operation
Note: the above hex string is big-endian. Given that USB connections are always little-endian the pattern to look for is actually: 0c 00 00 00 01 00 01 10 xx xx xx xx
There are certain scenarios where MSC offers advantages over MTP. One example of this is HDD defragmentation. Once a dual mode device has been installed on a PC as an MTP device, it is not easy to have it reconnect as a MSC device.
An optional addition to a dual mode device is a Safe Boot Mode. This mode would be manually selectable by the user and set the device to present itself as a MSC device only. I.e. it would not respond to the OS descriptor requests sent by the PC. A device supporting this optional MSC only mode should ensure that it correctly configures its USB product IDs. See the following section for more information.
In order to enable auto switching to the correct communications mode, the device must watch for the unique pattern(s) described earlier. In doing so, it should be possible for devices to implement the following switching logic:
If (foundMTPUniqueString())
else
Note the above pseudo code is provided as a guide only and is not intended to represent real code existing on the device.
When a device supports multiple configurations it is usually required that the device support a different product ID (PID) for each consideration. In the case of a dual mode device, Microsoft recommends the following:
The following device configurations will be supported on the Windows platforms.
Note: Only devices that are truly backward compatible with PTP should also report support for the PTP class ID.
.
When device type 1 is connected to an OS that supports the OS descriptor, the end user will be provided with a true plug and play experience. I.e. no installation will be required.
When device type 2 is connected to an OS that supports the OS descriptor it will initially install as a backward compatible PTP device and the PTP class driver is installed.
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
When device type 3 is connected to an OS that supports the OS descriptor it will initially show as an unknown device.
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
When device type 4 is connected to an OS that supports the OS descriptor, the end user will be provided with a true plug and play experience. I.e. no installation will be required. The device will connect in MTP mode and take advantage of all WMP10s device enhancements.
If WMP10 is not installed on the PC, then the following components will not be installed.
Without the above components installed, device type 1 will install as a PTP device.
After WMP10 has been installed, device class 1 will automatically be upgraded to an MTP device the next time device enumeration occurs (e.g. reboot machine, device reconnection, etc.)
Without the above components installed, device type 2 will install as a PTP device.
After WMP10 install, the device will still show as a PTP device because the PTP class ID takes precedence over the device VID&PID. The user will therefore have to manually update the device driver to use MTP.
Note: Because the device does not contain an OS descriptor, IHVs need to provide a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
Without the above components installed, device type 3 will show up as an unknown device and the user will be required to perform one of the potential installations steps:
Note: Because the device does not contain an OS descriptor, IHVs need to provide a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
Without the above components installed, device type 4 will install as a MSC device, limiting the usage scenarios to those of legacy devices.
To enjoy the enhanced device features provided by WMP10 a user will have to:
Note: At the time of install existing dev-nodes for the MTP devices will be removed and the USB bus rescanned to allow connected device to be reinstalled as an MTP device.
Note: XP Gold is included in this section
When device type 1 is connected to an OS that doesnt support the OS descriptor it will initially install as a backward compatible PTP device and the PTP class driver is installed.
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
When device type 2 is connected to an OS that doesnt support the OS descriptor it will initially install as a backward compatible PTP device and the PTP class driver is installed.
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
When device type 3 is connected to an OS that doesnt support the OS descriptor it will initially show as an unknown device.
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
Because the OS descriptor is not supported, device type 4 will install as a MSC device, limiting the usage scenarios to those of legacy devices.
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
Existing products
If WMP10 is not installed on the PC, then the following components will not be installed.
Without the above components installed, device type 1 will install as a PTP device.
After WMP10 install, the device will still show as a PTP unless the following is done:
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
Without the above components installed, device type 2 will install as a PTP device.
After WMP10 install, the device will still show as a PTP unless the following is done:
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
Without the above components installed, device type 3 will show up as an unknown device and the user will be required to perform one of the potential installations steps:
After WMP10 install, the device will still show as an unknown device unless the following is done:
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
Without the above components installed, device type 4 will install as a MSC device, limiting the usage scenarios to those of legacy devices.
To enjoy the enhanced device features provided by WMP10 a user will have to:
However, because the OS descriptor is not supported, device type 4 will still install as a MSC device.
For the device to install as an MTP device, the IHV must provide the following a setup application either on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a .INF file for more information.
MTP devices are normally identified and installed by using the wpdmtp.inf file installed with Windows Media Player 10. This provides a true Plug and Play user experience because no drivers are needed to get the device running. However, in some cases, device manufacturers may need to provide an additional proprietary INF file.
This document only describes the parts of an INF file that apply specifically to MTP device installation. For full documentation on the INF file format, see the INF documentation on MSDN.
The INF file supplied, wpdmtp.inf, relies on the MS_COMP_MTP USB OS descriptor to identify MTP devices. Device installation by an OS descriptor has been supported in Windows starting with Windows XP Service Pack 1 (SP1). If the correct OS descriptor cannot be exposed by a device, a device manufacturer will need to provide a proprietary INF file relying on VID&PID to identify the device. More information on OS descriptors can be found in the USB FAQ on the Microsoft Web site.
The following sample INF file text installs a device and registers the standard Microsoft MTP driver. If you use this, you will not need to provide your own driver. The INF file itself is the only thing that you must provide. This INF file installs an MTP device the same way as wpdmtp.inf, except it relies on VID&PID for device identification. Obtain a digital signature for your INF file from Windows Hardware Quality Labs (WHQL), and supply a catalog file with the signature and the INF file.
Be sure to replace the following placeholders (shown in boldface in the following code) before using the INF file:
[Version]
Signature='$WINDOWS NT$'
Class=WPD
ClassGUID=
Provider=%Provider%
DriverVer=01/01/2004,1.0.0.0
[Manufacturer]
%MfgName%=AbcInc
[AbcInc]
%AbcInc.DeviceDesc%=AbcInc_MTP, USBVID_XXXX&PID_YYYY
[AbcInc_MTP]
Include = wpdmtp.inf
Needs = WPD.MTP.CopyFiles
[AbcInc_MTP.hw]
Include = wpdmtp.inf
Needs = WPD.MTP.Registration
[AbcInc_MTP.Services]
Include = wpdmtp.inf
Needs = WPD.MTP.Services
[Strings]
AbcInc.DeviceDesc = 'ABC Inc. MTP Device'
MfgName = 'ABC Inc.'
Provider = 'ABC Inc.'
The following section was taken from the WPD Device Installation Specification (see references section)
For a PC to talk to an MTP device, the following components need to be installed on the PC:
After the required components listed above have been successfully installed to the system, WPD device driver installation may now begin. Using the WPD MTP driver as an example, the following diagram illustrates the WPD device install sequence:
Figure 1: MTP Device Install Sequence
An MTP device is physically connected to the USB bus.
The USB bus driver detects this newly connected device, retrieves the advertised hardware ID and propagates a PnP notification event that eventually reaches the user-mode PnP manager service. As a result, the service spawns a process presenting the familiar Hardware Update Wizard dialog box to the user.
The user progresses through the wizard until a list-box appears, with selections representing the INF files whose device IDs match (or are compatible with) the USB device hardware ID discovered by the kernel-mode USB bus driver. In the case of WMP10 and an MTP device, the ID is USBMS_COMP_MTP. In accordance with the USB specification (see https://www.usb.org/developers/docs ), this OS Descriptor ID takes precedence over the PTP class ID (USBClass_06&SubClass_01&Prot_01) that is also returned from MTP devices so they can also be used as a down-level compatible PTP device. The WMP10 update contains a modified USB kernel-mode bus driver that recognizes this descriptor and is able to identify the device as a true MTP device. This all results in the following behavior:
a. Pre- WMP10 update: the MTP device will install as either a MSC or PTP imaging device (depending upon the class of device) Applications may communicate with it using legacy API sets such as the WMDM (using the MSC SP) or WIA.
b. Post-WMP10 update with a device that does return the MS OS Descriptor ID: device appears as a WPD MTP device. Applications may communicate it using the MTP protocol. WMP10 contains an updated USB bus driver, wpdusb.sys. This driver recognizes the OS Descriptor ID and consequently exposes the device with this ID using the MTP compatible interface class.
c. Post-WMP10 update with a device that does not return the MS OS Descriptor ID: driver install requires some additional help. As mentioned in preceding section End User Experience, this can take the form of an IHV-supplied .inf file containing a device compatible ID entry that refers to the generic MTP install section in WpdMtp.inf. Alternatively the IHV can work with MS to provide the relevant device VID&PID entry in WpdMtp.inf itself.
Following confirmation of the driver selection by the user, driver installation begins:
d. The WPD class installer receives new device install notification (DIF_INSTALL), starting the umwdf service if its not already running. After this, the startup type for umwdf is changed to auto-start. This ensures a running uWDF manager even after a system reboot so that clients may bind to registered user-mode drivers. Any failure encountered in the above aborts the install.
e. The directives contained in wpdmtp.inf are parsed and carried out. As a result: driver files are copied to the system, registry entries to make the MTP driver endpoint visible to uWDF are added, and the kernel-mode WpdUsb is AddServiced.
The device manufacturer and device name are queried from the MTP device and used to the set the friendly name device property.
Driver installation is now complete and the MTP driver endpoint is ready for connection to a WPD API client.
For a PC to talk to an MTP device, the following components need to be installed on the PC:
After the required components listed above have been successfully installed to the system, WPD device driver installation may now begin. Using the WPD MTP driver as an example, the following diagram illustrates the WPD device install sequence:
Figure 1: MTP Device Install Sequence
USB FAQ on the Microsoft Web site.
https://www.microsoft.com/whdc/driver/install/default.mspx
https://www.microsoft.com/whdc/ddk/winddk.mspx
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 3510
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved