B12.1.4 Multifunction Devices - Windows Experience
Design Guideline References:
"Designing Multifunction Devices for Windows" at http://www.microsoft.com/hwdev/tech/MF/mfdesign.asp
B12.1.4.1 Separate drivers are required for separate functions with no start order dependencies between separate function drivers
The operating system must be able to configure and manage functions in any order, so no function on a multifunction device can depend on another function to be started before the function can be started by the operating system.
Note that a supervisory driver that loads different drivers for the individual functions does not work well with Windows. In particular, driver support is likely to be lost in cases of operating system re-installation or upgrade, or with distribution of new drivers via Windows Update. Therefore, these supervisory drivers must be avoided.
B12.1.4.2 MFP devices correctly implement driver and Plug and Play support B12.1.4.2.1 Resource requirements of one functional unit are not expressed in terms of another functional unit.
Each function or device on the multifunction add-on device that is individually enumerated must provide a device ID for the bus it uses.
Exceptions to individual ID requirement for MF devices [Logo Program Clarification]
-
Multiple devices of the same device class, such as a multiline serial device.
-
Dependent video devices, such as a graphics accelerator on a video card.
-
Devices that are generated by an accelerator or auxiliary processor and that do not have independent hardware I/O. That processor must have an ID; under Windows XP, Mf.sys must be used to enumerate the dependent devices.
B12.1.4.2.2 Operation of one functional unit does not affect or interfere with the operation of another functional unit.
This applies whether the functional unit is on the multifunction device or on the system as a whole. Windows must be able to separately access each logical device that is individually enumerated, configure the device resources independently, and disable individual devices in the event of a conflict.
B12.1.4.2.3 Each functional unit is enumerated and its resource requirements communicated to the operating system.
This ensures Windows can load the necessary drivers and assign resources to the different units in any order.
For each individually enumerated device, resource configuration requirements are the same as for an equivalent device on a separate expansion card. This requirement means that registers cannot be shared among individually enumerated devices on a multifunction add-on device, but it does not supersede device requirements among different bus classes.
B12.1.4.3 Each independent function can be used concurrently, with no hidden dependencies
Separate functional units must be able to operate concurrently, without interfering with each other or with other devices on the system.
B12.1.4.4 Each function can be power managed independently
Each functional unit in a multifunction device must separately meet the power management device class specifications for its device class and be independently power managed. Each functional unit must be able to successfully complete a system sleep/wake transition (where the unit transitions from D0 to D3 to D0) without losing functionality and without requiring user intervention to restore functionality. All functional units on PCI devices that support wakeup capabilities must correctly support wake from D3cold.
B12.1.5 Multifunction Devices - FAQs B12.1.5.1 Current general FAQs
See http://www.microsoft.com/winlogo/hardware/.
B12.1.5.2 Updated at B12.1.4 B12.1.5.3 Updated at B12.1.4.2.1 B12.1.R Multifunction Devices - Future Requirements
Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/
B12.1.R.2 DELETED
|
