次の方法で共有


Device.Input Requirements

Device.Input.FingerPrintReader

Requirements under this category apply to the following OS:

Device.Input.FingerPrintReader.BaseLegacy: Windows 7 x86/x64; Windows 8 x86/x64

Device.Input.FingerPrintReader.ManagementAppsLegacy: Windows 7 x86/x64; Windows 8 x86/x64

Device.Input.FingerPrintReader.SensorEngineDBLegacy: Windows 7 x86/x64; Windows 8 x86/x64

Device.Input.FingerPrintReader.WBDILegacy: Windows 7 x86/x64; Windows 8 x86/x64

Device.FingerPrintReader.Base: Windows 8.1 x86/x64/ARM

Device.FingerPrintReader.Extensions: Windows 7 x86/x64; Windows 8 x86/x64; Windows 8.1 x86/x64/ARM

Device.FingerPrintReader.ManagementApps: Windows 8.1 x86/x64/ARM

Device.FingerPrintReader.SensorEngineDB: Windows 8.1 x86/x64/ARM

Device.FingerPrintReader.WBDIBID: Windows 8.1 x86/x64/ARM

None of the requirements in this list apply to Windows 8 ARM

Related Requirements
Device.Input.FingerPrintReader.Base
Device.Input.FingerPrintReader.BaseLegacy
Device.Input.FingerPrintReader.Extensions
Device.Input.FingerPrintReader.ManagementApps
Device.Input.FingerPrintReader.ManagementAppsLegacy
Device.Input.FingerPrintReader.SensorEngineDB
Device.Input.FingerPrintReader.SensorEngineDBLegacy
Device.Input.FingerPrintReader.WBDI
Device.Input.FingerPrintReader.WBDILegacy

Device.Input.FingerPrintReader.Base

Biometric Fingerprint Reader General Requirement

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Biometric fingerprint readers certified under this program must be exposed through the Windows Biometric Framework (WBF). WBF plug-in components must implement all entry points and adhere to the WBF plug-in interfaces that are documented on MSDN (https://msdn.microsoft.com/library/dd401553(VS.85).aspx).

The following general criteria must be met:

The following general criteria must be met:

The driver package must contain a WBDI driver, a combination of plug-in adapters.

Devices that operate in advanced mode may implement a compound adapter. A compound adapter may contain a proprietary sensor, engine, and database adapter, or any combination of these adapters.

The WBDI driver and plug-in components must not contain any malicious software such as Trojan horse or backdoor software.

The plug-in components must not contain any malicious software such as Trojan horse or backdoor software.

The following table lists the hardware requirements for fingerprint sensors.

Requirement
Justification/Notes
Sensor Type
Touch recommended if implemented
Touch sensor type is preferred option compare to swipe sensor. Due to the nature, placement and fixed orientation of swipe sensors especially on devices that can have multiple orientations (such as tablets that can function in landscape and portrait mode), they result in ergonomic challenges for the user which may result in failure to capture an accurate fingerprint thereby resulting in the need for multiple swipes.
Power Consumption
Operating (during capture) 100mW
Required for Connected Standby devices and recommended for others.
When the fingerprint reader is not capturing fingerprint images regardless of if the system itself is in the sleep state or not - 1mW
Required for Connected Standby devices and recommended for others.
Performance
Recommended <1%FRR @ 0.01% FAR as defined by fingerprint sensor specification
Liveness Detection
Recommended to be able to provide a minimum of one of the anti-spoofing measures based on the fingerprint sensor specification
WBF Compliant with HCK
Yes

Design Notes

Biometric devices measure an unchanging physical characteristic to uniquely identify an individual. Fingerprints are one of the most common biometric characteristic measured. Beginning with Windows7, a new set of components, the Windows Biometric Framework, provides support for fingerprint biometric devices. These components, created using the Windows Biometric Framework API, can perform the following tasks:

Capture biometric samples and use them to create a template.

Securely save and retrieve biometric templates.

Map each template to a unique identifier such as a GUID (globally unique identifier) or SID (system identifier).

Enroll new biometric templates.

For more complete information about WBF and its components, see the "Introduction to the Windows Biometric Framework (WBF)" white paper at https://msdn.microsoft.com/library/windows/hardware/gg463089.aspx

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers.
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.BaseLegacy

Biometric Fingerprint Reader General Requirement for pre Windows 8.1 OS versions.

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Biometric fingerprint readers certified under this program must be exposed through the Windows Biometric Framework (WBF). Biometric fingerprint reader drivers must expose and adhere to the Windows Biometric Driver Interface (WBDI), as documented on MSDN (https://msdn.microsoft.com/library/windows/hardware/aa973504.aspx). WBF plug-in components must implement all entry points and adhere to the WBF plug-in interfaces that are documented on MSDN (https://msdn.microsoft.com/library/dd401553(VS.85).aspx).

The following general criteria must be met:

The driver package must contain a WBDI driver, a combination of plug-in adapters, and a fingerprint management application (FMA) that are required all of which are required to enroll a user and log on to Windows.

Devices that operate in advanced mode may implement a compound adapter. A compound adapter may contain a proprietary sensor, engine, and database adapter, or any combination of these adapters.

The WBDI driver and plug-in components must not contain any malicious software such as Trojan horse or backdoor software.

Design Notes

Biometric devices measure an unchanging physical characteristic to uniquely identify an individual. Fingerprints are one of the most common biometric characteristic measured. Beginning with Windows7, a new set of components, the Windows Biometric Framework, provides support for fingerprint biometric devices. These components, created using the Windows Biometric Framework API, can perform the following tasks:

Capture biometric samples and use them to create a template.

Securely save and retrieve biometric templates.

Map each template to a unique identifier such as a GUID (globally unique identifier) or SID (system identifier).

Enroll new biometric templates.

To expose a device through WBF, the device must be exposed through a driver that implements the WBDI driver and an appropriate combination of Sensor, Engine, and Database plug-in components. For more complete information about WBF and its components, see the "Introduction to the Windows Biometric Framework (WBF)" white paper at https://msdn.microsoft.com/library/windows/hardware/gg463089.aspx

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC and common integration points for third party applications on the control panel. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers. The framework is also extensible and customizable. This allows OEMs to provide their own branded enrolment and logon experiences. It also allows OEMs and IHVs to extending the API for additional features they may wish to support (for example: PBA).
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.Extensions

Vendor-supplied drivers or other extension components must not wrap other extension components

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Drivers and adapter plug-ins that extend the Windows Biometric Framework must not wrap other drivers or adapter plug-ins unless the practice is explicitly permitted by the component documentation supplied by Microsoft.

Additional Information

Business Justification
Wrapping extension components that do not support wrapping can result in system instability, security vulnerabilities and loss of customer data.
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.ManagementApps

Biometric Fingerprint Reader Management Applications

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

ARM devices
x86/x64 devices
Enrollment experience (FMA)
Not allowed. An inbox enrollment experience integrated with user settings page will be available on Windows 8.1 and onwards.
Not recommended. The enrollment experience is provided inbox and integrated with the user settings page. A custom enrollment experience MAY be included with the WBF package and installed on the system however it will not be integrated into user settings page or Control Panel.
Custom enrollment experience is not allowed to enroll non-domain users.

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers.
Exceptions
Devices targeted for consumer use MUST not have any 3rd party FMA installed. 3rd party FMAs may be installed and enabled on Windows devices targeted towards business (enterprise and small/medium businesses). In such instances, the user should be clearly notified if core inbox experiences will be negatively impacted by use of the 3rd party FMA during enrollment. This exception is granted for Windows 8.1 release ONLY and will be withdrawn for subsequent OS releases at which point no 3rd party FMA will be allowed on the device.
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.ManagementAppsLegacy

Biometric Fingerprint Reader Management Applications

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A fingerprint management application (FMA) must be included in the driver package and should follow the guidelines in "Designing Windows Biometric Framework (WBF) Fingerprint Management Applications" at https://msdn.microsoft.com/library/windows/hardware/gg463085.aspx

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC and common integration points for third party applications on the control panel. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers. The framework is also extensible and customizable. This allows OEMs to provide their own branded enrolment and logon experiences. It also allows OEMs and IHVs to extending the API for additional features they may wish to support (for example: PBA).
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.SensorEngineDB

Fingerprint Reader Sensor, Engine and Storage Plug-in requirement

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All interface entry points must be implemented, and each element must adhere to the definition of its respective adapter plug-in interface.

Plug-in components must support the sequenced invocation of their interfaces that result from invoking all the top-level Windows Biometric Framework (WBF) APIs.

The sequence of WBF API calls used by the WBF credential provider for Windows logon must be completed in 1.5 seconds or less.

All adapters must be digitally signed, as described in the Windows Biometric Framework: Code-Signing Guidelines white paper at https://msdn.microsoft.com/library/windows/hardware/gg463093.aspx.

The adapter must run under Application Verifier without generating any errors.

A driver package can support multiple devices but must pass the certification criteria for each of the supported fingerprint readers separately. A separate submission must be made for each supported device.

Adapter requirements
Notes
Engine adapter
Required unless the device is an advanced device that can match on device.
Storage adapter
Relying on inbox storage adapter recommended unless there is a specific need to include a custom storage adapter such as for advanced sensors.
Sensor adapter
Relying on inbox sensor adapter is recommended unless there is a specific need to include a custom sensor adapter.

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers. Enrollment and logon experiences. It also allows OEMs and IHVs to extending the API for additional features they may wish to support (for example: PBA).
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.SensorEngineDBLegacy

Fingerprint Reader Sensor, Engine and Database Plug-in requirement

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

All interface entry points must be implemented, and each element must adhere to the definition of its respective adapter plug-in interface.

Plug-in components must support the sequenced invocation of their interfaces that result from invoking all the top-level Windows Biometric Framework (WBF) APIs.

The sequence of WBF API calls used by the WBF credential provider for Windows logon must be completed in 1.5 seconds or less.

All adapters must be digitally signed, as described in the Windows Biometric Framework: Code-Signing Guidelines white paper at https://msdn.microsoft.com/library/windows/hardware/gg463093.aspx.

The adapter must run under Application Verifier without generating any errors.

A WBDI driver and plug-in components can support multiple devices but must pass the certification criteria for each of the supported fingerprint readers separately. A separate submission must be made for each supported device.

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC and common integration points for third party applications on the control panel. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers. The framework is also extensible and customizable. This allows OEMs to provide their own branded enrolment and logon experiences. It also allows OEMs and IHVs to extending the API for additional features they may wish to support (for example: PBA).
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.WBDI

Biometric Fingerprint Reader WBDI Driver Requirement

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows Biometric Driver Interface (WBDI) drivers must adhere to the following criteria:

All mandatory IOCTLs must be fully implemented and adhere to the WBDI specification.

If an optional IOCTL is implemented, it must adhere to the WBDI specification.

The WBDI driver must support the biometric IOCTL calling sequence.

If the biometric fingerprint reader is not a PnP device, it must create arrival and departure events as recommended in the WBDI specification.

The WBDI INF installer must set up the associated plug-in components and fingerprint management applications that are included in the driver package.

Guidelines in this requirement apply equally well to the kernel-mode and user-mode drivers. The following must be supported:

Backward and forward compatibility. Drivers must have a mechanism that determines different versions of user-mode and kernel-mode components. When two versions of the same driver have been installed on the PC, the kernel component must determine the correct driver to talk to. In remoting scenarios, the mismatch may occur even with a single driver.

The following items must not be used:

Out-of-band communications. Because the user-mode and kernel-mode drivers are running on the same PC, they might be coupled together through channels different from the I/O manager APIs. The goal is to ensure that drivers do not have out-of-band communication, implicit or explicit.

Here are some specific examples that would prevent terminal services redirection:

Shared memory must not be used directly between user-mode applications and either user-mode or kernel-mode drivers. For every data item sent and received, there must be a corresponding I/O request. Share the memory either through a mapped file or through locked pages of one direct I/O call.

Registry communication (that is, any registry keys that are set from user-mode drivers and read from kernel-mode drivers or vice versa). It is problematic when an application is running on the server and drivers are loaded on the client because the registry is set on the server but not on the client.

Kernel objects (passing any kernel object handles in I/O buffers, such as handles to events or semaphores).

Data pointers (passing data pointers in I/O buffers). For example, a driver may try to read a linked list or other complicated data structure from the kernel.

Incompatibility between 32-bit and 64-bit platform implementations of the I/O request packet (IRP) requests (fields in the data structures that are compiled differently, depending on the bitness). Incompatibility of the structures based on bitness results in different offsets and data size for these structures. The data will not be interpreted correctly when a terminal services client and server are not the same platform.

Reliance on a strict timing expectation about how fast the kernel driver responds. Because drivers are remoting over the network, additional latency is added to the response from the hardware. That latency may range from 10 ms to several seconds. A possible cause for this could be slow network or packet losses. If a driver is programmed for a response that comes in time less than usual network latency, the remoting fails.

Setting an access control list (ACL) or any other run-time security check that would prevent any application from opening a device driver. For example, a driver is allowed to accept calls only from particular service. Because all the calls are done on a TS client PC under security context of the remoting client process, they can fail.

Design Notes Biometric devices measure an unchanging physical characteristic to uniquely identify an individual. Fingerprints are the most common biometric characteristic measured. Beginning with Windows7, a new set of components, the Windows Biometric Framework (WBF), provides support for fingerprint biometric devices. These components, created with the WBF API can perform the following tasks:

Capture biometric samples and uses them to create a template.

Securely save and retrieve biometric templates.

Map each template to a unique identifier such as a GUID (globally unique identifier) or SID (system identifier).

Enroll new biometric templates.

To expose a device through WBF, the device must be exposed through a driver that implements the WBDI driver as well as an appropriate combination of sensor, engine, and database plug-in components. For more complete information about WBF and its components, see the "Introduction to the Windows Biometric Framework (WBF)" white paper at https://msdn.microsoft.com/library/windows/hardware/gg463089.aspx.

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC and common integration points for third party applications on the control panel. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers. The framework is also extensible and customizable. This allows OEMs to provide their own branded enrolment and logon experiences. It also allows OEMs and IHVs to extending the API for additional features they may wish to support (for example: PBA).
Enforcement Date
Jun. 26, 2013

Device.Input.FingerPrintReader.WBDILegacy

Biometric Fingerprint Reader WBDI Driver Requirement

Target Feature
Device.Input.FingerPrintReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Windows Biometric Driver Interface (WBDI) drivers must adhere to the following criteria:

All mandatory IOCTLs must be fully implemented and adhere to the WBDI specification.

If an optional IOCTL is implemented, it must adhere to the WBDI specification.

The WBDI driver must support the biometric IOCTL calling sequence.

If the biometric fingerprint reader is not a PnP device, it must create arrival and departure events as recommended in the WBDI specification.

The WBDI INF installer must set up the associated plug-in components and fingerprint management applications that are included in the driver package.

Guidelines in this requirement apply equally well to the kernel-mode and user-mode drivers. The following must be supported:

Backward and forward compatibility. Drivers must have a mechanism that determines different versions of user-mode and kernel-mode components. When two versions of the same driver have been installed on the PC, the kernel component must determine the correct driver to talk to. In remoting scenarios, the mismatch may occur even with a single driver.

The following items must not be used:

Out-of-band communications. Because the user-mode and kernel-mode drivers are running on the same PC, they might be coupled together through channels different from the I/O manager APIs. The goal is to ensure that drivers do not have out-of-band communication, implicit or explicit.

Here are some specific examples that would prevent terminal services redirection:

Shared memory must not be used directly between user-mode applications and either user-mode or kernel-mode drivers. For every data item sent and received, there must be a corresponding I/O request. Share the memory either through a mapped file or through locked pages of one direct I/O call.

Registry communication (that is, any registry keys that are set from user-mode drivers and read from kernel-mode drivers or vice versa). It is problematic when an application is running on the server and drivers are loaded on the client because the registry is set on the server but not on the client.

Kernel objects (passing any kernel object handles in I/O buffers, such as handles to events or semaphores).

Data pointers (passing data pointers in I/O buffers). For example, a driver may try to read a linked list or other complicated data structure from the kernel.

Incompatibility between 32-bit and 64-bit platform implementations of the I/O request packet (IRP) requests (fields in the data structures that are compiled differently, depending on the bitness). Incompatibility of the structures based on bitness results in different offsets and data size for these structures. The data will not be interpreted correctly when a terminal services client and server are not the same platform.

Reliance on a strict timing expectation about how fast the kernel driver responds. Because drivers are remoting over the network, additional latency is added to the response from the hardware. That latency may range from 10 ms to several seconds. A possible cause for this could be slow network or packet losses. If a driver is programmed for a response that comes in time less than usual network latency, the remoting fails.

Setting an access control list (ACL) or any other run-time security check that would prevent any application from opening a device driver. For example, a driver is allowed to accept calls only from particular service. Because all the calls are done on a TS client PC under security context of the remoting client process, they can fail.

Design Notes Biometric devices measure an unchanging physical characteristic to uniquely identify an individual. Fingerprints are the most common biometric characteristic measured. Beginning with Windows7, a new set of components, the Windows Biometric Framework (WBF), provides support for fingerprint biometric devices. These components, created with the WBF API can perform the following tasks:

Capture biometric samples and uses them to create a template.

Securely save and retrieve biometric templates.

Map each template to a unique identifier such as a GUID (globally unique identifier) or SID (system identifier).

Enroll new biometric templates.

To expose a device through WBF, the device must be exposed through a driver that implements the WBDI driver as well as an appropriate combination of sensor, engine, and database plug-in components. For more complete information about WBF and its components, see the "Introduction to the Windows Biometric Framework (WBF)" white paper at https://msdn.microsoft.com/library/windows/hardware/gg463089.aspx.

Additional Information

Business Justification
The Windows Biometric Framework provides a common driver and application interface for enrolling, identifying and verifying users as well as a set of common user experiences to allow control of basic settings and offering standard experiences around logon and UAC and common integration points for third party applications on the control panel. The framework offers a common API that allows applications to be developed independent of hardware manufacturer. This in turn allows the OEM more flexibility in selecting hardware and software suppliers. The framework is also extensible and customizable. This allows OEMs to provide their own branded enrolment and logon experiences. It also allows OEMs and IHVs to extending the API for additional features they may wish to support (for example: PBA).
Enforcement Date
Jun. 26, 2013

Device.Input.GameController.CommonController

Device supports use as a Common Controller Game Device

Related Requirements
Device.Input.GameController.CommonController.XInput

Device.Input.GameController.CommonController.XInput

Microsoft Common Controller for Windows API support (XINPUT)

Target Feature
Device.Input.GameController.CommonController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

  1. Microsoft Common Controller for Windows complies with requirements defined in the XUSB specification:A common controller must meet all requirements and comply with the XUSB Specification. Support for audio is optional for the common controller. If the controller supports audio, it must also comply with the device interfaces for audio defined in the XUSB Specification.2. Microsoft Common Controller for Windows uses the XUSB22.SYS driver:The common controller must use the Microsoft provided XUSB22.SYS driver to interface with Windows. Custom drivers or filters are not allowed.3. Microsoft Common Controller for Windows functions in conjunction with the XInput application programming interfaces:The common controller must function correctly when interfacing with the Microsoft XInput APIs.

Additional Information

Business Justification
The Microsoft Common Controller Driver is a game input standard that is used for both the Xbox360 console and for Microsoft Windows. The Xbox360 controller or any controllers that utilize this standard will enable the device to be used on Windows as well.
Enforcement Date
Jun. 01, 2007

Device.Input.GameController.GenericController

Device supports use as a generic USB game controller

Related Requirements
Device.Input.GameController.GenericController.DirectInput

Device.Input.GameController.GenericController.DirectInput

Generic USB Game Controller API Support (DINPUT)

Target Feature
Device.Input.GameController.GenericController
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64

Description

An input gaming device must be HID-compliant. The driver must support required functionality defined for Direct Input.

Additional Information

Business Justification
The Microsoft Common Controller driver is a game input standard that is used for both the Xbox360 console and for Microsoft Windows. The Xbox360 controller or any controllers that utilize this standard will enable the device to be used on Windows as well.
Enforcement Date
Jun. 01, 2006

Device.Input.HID

Related Requirements
Device.Input.HID.I2CProtocolSpecCompliant
Device.Input.HID.UsbSpecificationCompliant

Device.Input.HID.I2CProtocolSpecCompliant

All HID devices connected over I2C must comply with MSFT HID I2C Protocol specification

Target Feature
Device.Input.HID
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All HID over I2C compatible devices should comply with the Microsoft published documentation for the HID I2C protocol specificationDesign Notes: See Microsoft published HID I2C protocol specification (link not provided yet)

Additional Information

Exceptions
This requirement is only enforced for HID I2C devices and not generalized for SPB.
Business Justification
To maintain a standardized way in which HID I2C devices report data and so that all HId I2C device vendors and OEMs can utilize the Microsoft provided HID I2C miniport driver instead of writing and using multiple third party drivres
Enforcement Date
Mar. 01, 2012

Device.Input.HID.UsbSpecificationCompliant

All HID devices that are connected over USB , should comply with the USB HID Specification (V1.1 or later)

Target Feature
Device.Input.HID
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2008 x86, x64

Description

Version 5: Defines WMC AQ requirements

For WMC AQ, this requirement is

REQUIRED for Desktop systems

REQUIRED for Laptop systems if Laptop system includes remote and receiver.

For non AQ systems, this requirement is

REQUIRED If system (either Desktop or Laptop) includes remote and receiver.

IR Receivers (input only) and IR Transceivers (input and IR emitting/learning) interface with the Windows Media Center class driver. In a system with a TV tuner, IR Transceivers must be used that support all functions of the Remote Control and Receiver-Transceiver Specifications and Requirements for Windows Media Center in Windows Operating Systems document.

For tunerless systems with an IR receiver only IR Input and wake functions are required. The IR learning and emitting functions are optional.

DVB-T solutions are not required to support learning and emitting. These functions are optional.

In locales that do not use set top boxes, the learning and emitting functions are optional.

In those regions that support secondary 10 foot application, the IR Receiver/Transceivers are not required to meet the IR Learning requirement.

In those regions that support DVB-S Microsoft strongly recommends the use of IR Transceivers (input and IR emitting/learning)

If shipping a laptop system, IR learning and IR emitting is optional

For IR receivers (input only) that use Microsoft authorized IR protocols and all IR Transceiver (input and emitter functions), the device will return IR waveform envelope to software for software decoding of IR signal. IR signal cannot be decoded in the hardware. The only exception to this is the "wake-from-remote" power key.

An IR receiver (input only) is allowed to perform hardware decoding of an IR signal. These IR receivers (input only) must not receive and respond to any currently authorized Microsoft IR protocol. IR receivers that use hardware decoding of IR signal also need to support the "wake-from-remote" functionality. These devices must comply with the Remote Control and Receiver-Transceiver Specifications and Requirements for Windows Media Center in Windows Operating Systems document.

Design Notes:Microsoft recommends that IR cables be labeled and well documented for end users. An insert showing a small diagram of the IR control cable and how it connects to the digital cable or satellite receiver could help prevent support calls.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.Keyboard

Logo requirements detailing the implementation details of a keyboard important to Microsoft Operating Systems

Related Requirements
Device.Input.Keyboard.BrowserMultimediaKeysUseMSApis
Device.Input.Keyboard.CharmsKey
Device.Input.Keyboard.DynamicKeyboards
Device.Input.Keyboard.HotKeyFunctionAPI
Device.Input.Keyboard.KernelModeDriversUseWdfKmdf
Device.Input.Keyboard.LogoFlagKey
Device.Input.Keyboard.MultipleKeyboard
Device.Input.Keyboard.ScanCode

Device.Input.Keyboard.BrowserMultimediaKeysUseMSApis

Keys for Internet browser and multimedia use Microsoft APIs

Target Feature
Device.Input.Keyboard
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

If a keyboard or peripheral implements multimedia or Internet browser keys, it must use the registry keys associated with the WM_APPCOMMAND API to access those functions as described in the Windows Driver Kit. Registry keys can be programmed by using INF files to install special entries as defaults or through a customized interface provided to the user.Design Notes:See the Microsoft Platform SDK, "WM_APPCOMMAND."

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.Keyboard.CharmsKey

Title:If any of the Windows Charms keys are implemented on keyboards, then it must implement the correct scan codes and proper glypths.

Target Feature
Device.Input.Keyboard
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Keyboards that implement buttons to launch any of the Windows 8 Charms must use the correct scan codes and glyphs on those buttons. The glyphs that go on the buttons are defined in the Windows 8 Glyphs addendum to the Windows Logo License agreement for Hardware available at https://go.microsoft.com/fwlink/?LinkId=279574.

The charm button must send the correct scan code corresponding to the charm. No other glyph can be used on the button when using a scan code which relates to invoking one of the Windows 8 charms.

Additional Information

Business Justification
The goal of this requirement is to ensure that keyboards that implement any of the Windows 8 charms functionality is consistent. Hardware vendors must comply with these defined values and glyphs.
Enforcement Date
Jun. 26, 2013

Device.Input.Keyboard.DynamicKeyboards

Dynamic Keyboards meet the requirements listed here.

Target Feature
Device.Input.Keyboard
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

When system is displaying the security desktop, a keyboard capable of altering the keycaps to reflect different glyphs or legends dynamically must present a keyboard layout to match the language the current user has active on the system.

When using a keyboard capable of altering the keycaps to reflect different glyphs or legends dynamically, the keyboards must reboot in to the default system language layout as selected in Control Panel -> Regional and Language Options -> Keyboards and Languages.

When using a keyboard capable of altering the keycaps to reflect different glyphs or legends dynamically, the keyboards must change keyboard layout and language as selected by a user at the login screen

When using a keyboard capable of altering the keycaps to reflect different glyphs or legends dynamically, the keyboards reflect the currently selected layout and language preference when the Windows desktop has focus.

When using a keyboard capable of altering the keycaps to reflect different glyphs or legends dynamically, the keyboard may allow for the repositioning of the Windows key, however that key must remain visible to user in all configurations/layouts. By default this key must be present in the lower left of the keyboard, between the control and alternate keys when at a login, welcome or password entry screen. Once the user has logged in the location of the key may be repositioned by user preference.

When using a keyboard capable of altering the keycaps to reflect different glyphs or legends dynamically, the displayed keyboard layout and language match the installed language of the Operating System.

A self-powered keyboard capable of altering the keycaps to reflect different glyphs or legends dynamically, must allow for the keyboard to be reset via a switch or keystroke sequence, independently of a software reset or power cycling of the device.

Additional Information

Business Justification
For login accessibility, if a user needs to enter a password, the keyboard layout should represent the current language layout for text input. There are implications with passwords in a networked environment as well, not every system may be equipped the same type of keyboard. When a system is rebooted a Dynamic Key-cap keyboard to go allow any user to walk up and enter login credentials based on a "standard" layout. This is especially true for 'self-powered' keyboards which may not be reset during a system reboot. If the user changes the keyboard layout while the security desktop is active, the keyboard should respond to the layout change Keyboard shortcuts must function when "Windows" has focus. Keyboard must give the user a standard input set as recognized by the OS. Usability and Marketing value of having the Windows key consistently located in the lower quadrant of the keyboard is rationale for the positioning of the key. User preferences can be reflected but only when the system is in an unlocked state. Safe Mode is a diagnostic level of the operating system, designed to provide the customer an environment to make system changes and/or repairs. Maintaining a layout reflecting the OS language choice during install on a keyboard helps maintain the basic functionality expected in safe mode. Keyboards that are self-powered will not necessarily be reset when a system reboots. If the keyboard is 'stuck' in a broken state without the ability to reset the keyboard after a reboot the only recourse for the user is to power cycle the keyboard.
Enforcement Date
Jun. 26, 2013

Device.Input.Keyboard.HotKeyFunctionAPI

Devices that implement Hot-Key functionality implement the corresponding API notifications.

Target Feature
Device.Input.Keyboard
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Pointing and Drawing devices and Keyboards, that implement buttons used as application or function hot keys for which there exists WM_APPCOMMAND API shall implement the corresponding API notification. This includes but is not limited to the following functions:

Volume Up/Down

Mute

Browser Back/Forward

Play/Pause

Design Notes: Best practices for supporting Pointing and Drawing devices and Keyboards can be found at https://msdn.microsoft.com/library/ms997498.aspx. API for WM_APPCOMMAND notifications can be found at https://msdn.microsoft.com/library/ms646275(VS.85).aspx. HID Usage Page and ID information for these functions can be found at https://www.microsoft.com/whdc/archive/scancode.mspx and https://www.usb.org/developers/hidpage.

Additional Information

Business Justification
The goal of this requirement is to ensure the devices work before additional drivers or software are installed. The scroll wheel working and standard buttons like the calculator key or media keys to work immediately after the device is plugged in. If IHVs have generic buttons, or extra functionality we want it enable it with value add software.
Enforcement Date
Dec. 01, 2010

Device.Input.Keyboard.KernelModeDriversUseWdfKmdf

Keyboard kernel-mode drivers use the WDF-KMDF

Target Feature
Device.Input.Keyboard
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Third-party keyboard kernel-mode drivers must be ported to the WDF KMDF model.

Additional Information

Business Justification
KMDF provides a well-defined object model and controls the lifetime of objects and memory allocations.
Enforcement Date
Jun. 01, 2006

Device.Input.Keyboard.LogoFlagKey

Windows Logo flag key is implemented on all keyboards supporting more than 50 keys, the Windows Start Button design is required after June 30th 2007

Target Feature
Device.Input.Keyboard
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

All keyboards supporting more than 50 keys must implement the Windows Logo flag key. The printed Windows flag logo version of the key design may be logo qualified on mobile systems and standalone keyboards until the transition date. The Windows flag trademark must be clearly distinguished on the key top according to The Microsoft Windows Logo Key Logo License Agreement and the "Key Support, Keyboard Scan Codes, and Windows" document at https://go.microsoft.com/fwlink/?LinkId=116451. Mobile systems and keyboards must implement the new Windows Vista Start Button and logo artwork on the required Windows flag key (start key) by the transition date above. The keyboard must support the dome, graphics and other design requirements as defined in The Microsoft Windows Logo Key Logo License Agreement, and the "Key Support, Keyboard Scan Codes, and Windows" and "Windows Vista Hardware Start Button" documents. Vendors of systems or keyboards are encouraged to implement the dome design prior to this date. All designs must meet the requirements outlined in the specifications. It is recommended that keyboards supporting 50 or fewer keys implement a Windows Vista Start Button. Design Notes:The requirements defined in the "Windows Vista Hardware Start Button" paper call for a polished dome with a chamfer and a monochrome Windows Logo applied. The dome can be molded directly into the keycap. Optionally a domed full color Windows Flag insert can be implemented instead of the polished dome. Laptop and ultra mobile PC options are also defined. All Windows Flag keys on a keyboard must use the same design implementation option. The updated Windows Vista Hardware Start Button is implemented using the same PS/2 Scan Codes and USB Usages as the previous Windows Key. A draft of the "Windows Vista Hardware Start Button" white paper can obtained on the WHDC website at https://go.microsoft.com/fwlink/?linkid=3757.

Additional Information

Business Justification
The Start button is designed to be an easily discoverable to launch both the Windows Start menu and other experiences in Microsoft Windows starting with Windows Vista and newer operating systems.
Enforcement Date
Jun. 01, 2006

Device.Input.Keyboard.MultipleKeyboard

No interference occurs between multiple keyboards

Target Feature
Device.Input.Keyboard
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

If the system includes more than one keyboard, there must be no conflicts. For example, a docked mobile computer can have more than one keyboard attached to the system. The keyboard ports on a mobile computer and a docking station must be able to resolve conflicts between the two ports when the mobile computer is docked.

Additional Information

Business Justification
Microsoft Windows supports multiple keyboards connected through the registry and determines which keyboard to enable.
Enforcement Date
Jun. 01, 2006

Device.Input.Keyboard.ScanCode

Scan codes comply with industry standard

Target Feature
Device.Input.Keyboard
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

The following are requirements for a keyboard design that includes any Windows logo keys:

The keyboard must be developed according to technical requirements in "Key Support, Keyboard Scan Codes, and Windows."

The keyboard must be compatible at the Windows virtual key-code level.

The Windows logo key must function as a modifier (CTRL, SHIFT, or ALT).

Keyboard manufacturers must use consumer control or vendor-specific, top-level collections for HID hot buttons.

Design Notes:See "Key Support, Keyboard Scan Codes, and Windows" at https://go.microsoft.com/fwlink/?LinkId=36767. Additional software or drivers can be written to provide software remapping functionality.

Additional Information

Business Justification
Microsoft has defined extended scan codes for PS/2-compatible multimedia keyboards, and the USB HID Device Working Group has defined the consumer controls page. Hardware vendors must comply with these defined values and use their default functionality to ensure a good user experience following an upgrade or if the user doesn't install any supplemental software.
Enforcement Date
Jun. 01, 2006

Device.Input.PointDraw

Applies to Mice, touch pads, and other input devices used to move the pointer

Related Requirements
Device.Input.PointDraw.KernelModeDriversUseWdfKmdf

Device.Input.PointDraw.KernelModeDriversUseWdfKmdf

Mouse kernel-mode drivers use the WDF-KMDF

Target Feature
Device.Input.PointDraw
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64
Windows 8.1 Client x86, x64
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Third-party mouse kernel-mode drivers must be ported to the WDF KMDF model.

Additional Information

Business Justification
KMDF drivers require minimal common code for default operations because most such code resides in the framework, where Microsoft can ensure that it is compatible with each successive release of Windows.
Enforcement Date
Jun. 01, 2006

Device.Input.PrecisionTouchpad

Precision Touchpad requirements applicable for Windows 8.1. Windows Precision Touchpads are a new class of input device deeply integrated in to the Windows platform to provide a consistent, reliable and high-performing user experience. A Windows precision touchpad is an integrated device that is internally connected as part of a clamshell/convertible system or as part of an attachment that provides both keyboard and touchpad functionality.

Related Requirements
Device.Input.PrecisionTouchpad.Buffering
Device.Input.PrecisionTouchpad.BusType
Device.Input.PrecisionTouchpad.FieldFirmwareUpdateable
Device.Input.PrecisionTouchpad.ThirdPartyDrivers
Device.Input.PrecisionTouchpad.WakeFunctionality
Device.Input.PrecisionTouchpad.WakeSource

Device.Input.PrecisionTouchpad.Buffering

Device.Input.PrecisionTouchpad.Buffering

Target Feature
Device.Input.PrecisionTouchpad
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

USB connected Windows precision touchpads shall implement an input report buffer capable of handling >= 100ms of data based on the maximum number of contacts supported by the device

Input report buffer size (in bytes):

= Maximum # of Contacts Supported * Input Report Size * (100ms/Maximum Report Rate)

While this requirement applied to USB devices, it is recommended that I2C devices also implement an input report buffer to avoid interrupt processing glitches that can occur.

Additional Information

Business Justification
In order to ensure user interactions and subsequent input reports are not lost while the USB host controller is resuming from selective suspend, a USB connected Windows precision touchpad device shall implement a buffer that allows these reports to be retrieved from the host once the host controller is ready.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.BusType

Device.Input.PrecisionTouchpad.BusType

Target Feature
Device.Input.PrecisionTouchpad
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

The Bus type for Precision Touchpads must be I2C or USB.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.FieldFirmwareUpdateable

Device.Input.PrecisionTouchpad.FieldFirmwareUpdateable

Target Feature
Device.Input.PrecisionTouchpad
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall be field firmware updateable.

Additional Information

Business Justification
In order to ensure that devices in the field can be updated with bug fixes or additional functionality, devices shall be field firmware upgradeable.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.ThirdPartyDrivers

Device.Input.PrecisionTouchpad.ThirdPartyDrivers

Target Feature
Device.Input.PrecisionTouchpad
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall be fully functional through solely utilizing inbox drivers. Third party drivers are not permitted including but not limited to filter drivers, mini-port drivers, etc.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.WakeFunctionality

Device.Input.PrecisionTouchpad.WakeFunctionality

Target Feature
Device.Input.PrecisionTouchpad
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads must be capable of waking a host from S3 and Connected Standby while meeting all power consumption requirements.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.WakeSource

Device.Input.PrecisionTouchpad.WakeSource

Target Feature
Device.Input.PrecisionTouchpad
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads must be capable of waking from both surface contacts and a device interpreted button press while meeting all power consumption and noise requirements.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Hardware

Requirements that are specific to the physical hardware used in Windows precision touchpads.

Related Requirements
Device.Input.PrecisionTouchpad.Hardware.Bezel
Device.Input.PrecisionTouchpad.Hardware.Clickpad
Device.Input.PrecisionTouchpad.Hardware.ClickpadPress
Device.Input.PrecisionTouchpad.Hardware.Length
Device.Input.PrecisionTouchpad.Hardware.PressurePadPress
Device.Input.PrecisionTouchpad.Hardware.Width

Device.Input.PrecisionTouchpad.Hardware.Bezel

Device.Input.PrecisionTouchpad.Hardware.Bezel

Target Feature
Device.Input.PrecisionTouchpad.Hardware
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall have a digitizer surface approximately flush with the palm deck.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Hardware.Clickpad

Device.Input.PrecisionTouchpad.Hardware.Clickpad

Target Feature
Device.Input.PrecisionTouchpad.Hardware
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall either be a click-pad or report button state based on surface pressure.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Hardware.ClickpadPress

Device.Input.PrecisionTouchpad.Hardware.ClickpadPress

Target Feature
Device.Input.PrecisionTouchpad.Hardware
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

(If Implemented) Click-pad based Windows precision touchpads shall depress and report a button down state when exerted pressure exceeds 150g-180g.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Hardware.Length

Device.Input.PrecisionTouchpad.Hardware.Length

Target Feature
Device.Input.PrecisionTouchpad.Hardware
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall be >= 64mm in length (horizontal measurement of touchpad).

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Hardware.PressurePadPress

Device.Input.PrecisionTouchpad.Hardware.PressurePadPress

Target Feature
Device.Input.PrecisionTouchpad.Hardware
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

(If Implemented) Non-Click-pad based Windows precision touchpads shall report a button down state when exerted pressure exceeds 150g-180g.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Hardware.Width

Device.Input.PrecisionTouchpad.Hardware.Width

Target Feature
Device.Input.PrecisionTouchpad.Hardware
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall be >= 32mm in width (vertical measurement of touchpad).

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance

Requirements that are specific to HID compliance and reporting for Windows precision touchpads.

Related Requirements
Device.Input.PrecisionTouchpad.HIDCompliance.DefaultMode
Device.Input.PrecisionTouchpad.HIDCompliance.DeviceType
Device.Input.PrecisionTouchpad.HIDCompliance.HIDCompliance
Device.Input.PrecisionTouchpad.HIDCompliance.MouseMode
Device.Input.PrecisionTouchpad.HIDCompliance.PTPHQA
Device.Input.PrecisionTouchpad.HIDCompliance.SelectiveReporting
Device.Input.PrecisionTouchpad.HIDCompliance.SwitchableMode
Device.Input.PrecisionTouchpad.HIDCompliance.Timestamp
Device.Input.PrecisionTouchpad.HIDCompliance.TouchpadMode
Device.Input.PrecisionTouchpad.HIDCompliance.ValidRange

Device.Input.PrecisionTouchpad.HIDCompliance.DefaultMode

Device.Input.PrecisionTouchpad.HIDCompliance.DefaultMode

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall default to reporting via the HID mouse collection until a host has indicated otherwise. A device is not required to maintain its reporting mode across a power cycle.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.DeviceType

Device.Input.PrecisionTouchpad.HIDComplianceDeviceType

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall report their device type (pressure-pad, click-pad, etc.) via a HID feature report.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.HIDCompliance

Device.Input.PrecisionTouchpad.HIDCompliance.HIDCompliance

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads must be HID compliant and conform to the HID specific requirements for the bus used for connectivity. This requirement includes, but is not limited to implementing a compliant device descriptor, bus descriptor (if applicable) and report descriptor that defines the mandatory HID collections.

Additional Information

Business Justification
Windows precision touchpads shall implement all necessary HID requirements for full compatibility with the inbox HID class driver.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.MouseMode

Device.Input.PrecisionTouchpad.HIDCompliance.MouseMode

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall report as a mouse device via the HID mouse collection.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.PTPHQA

Device.Input.PrecisionTouchpad.HIDCompliance.PTPQHA

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall be able to report a 256 byte blob of data at the host s request attesting to the device s certification status. This is referred to as the Windows Precision TouchPad Hardware Quality Assurance (PTPHQA) mechanism.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.SelectiveReporting

Device.Input.PrecisionTouchpad.HIDCompliance.SelectiveReporting

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall support the hosts request via a HID feature report to selectively report digitizer contacts and button presses. The host may request to receive reports for either digitizer contacts or button presses, neither or both. Windows precision touchpads shall optimize their power consumption based on host selection.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.SwitchableMode

Device.Input.PrecisionTouchpad.HIDCompliance.SwitchableMode

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads default to reporting via the HID mouse collection, however upon issuance of a properly formed HID feature report via the HID configuration collection, the device shall report via the HID precision touchpad collection. The host may issue a properly formed report that explicitly defines the mode to be switched to, mouse or precision touchpad.

Additional Information

Business Justification
In order to enable compatibility with BIOS and legacy OS environments, Windows precision touchpads will always default to a compatible mode, however when the OS is capable of leveraging the rich data stream of a precision touchpad, it shall indicate as such to the device.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.Timestamp

Device.Input.PrecisionTouchpad.HIDCompliance.Timestamp

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall provide a 2-byte timestamp in each input report indicating when the reported frame was scanned by the digitizer. The granularity of the timestamp shall be 100us with rollover permitted. A frame is defined as the collection of contacts scanned and subsequently reported simultaneously.

Additional Information

Business Justification
Windows precision touchpads shall provide the timestamp to permit host applications to perform accurate velocity calculations.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.TouchpadMode

Device.Input.PrecisionTouchpad.HIDCompliance.TouchpadMode

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall provide input reports via the HID precision touchpad collection when in precision touchpad mode where the mode is indicated by the host via a HID feature report. These input reports shall be compliant with the mandatory usages defined for the HID precision touchpad collection.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.HIDCompliance.ValidRange

Device.Input.PrecisionTouchpad.HIDCompliance.ValidRange

Target Feature
Device.Input.PrecisionTouchpad.HIDCompliance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall ensure that all values reported for a given usage via a defined HID report (of type input or feature) do not lie outside of the reported valid range.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.I2C

Requirements that are specific to I2C connected Windows precision touchpads.

Related Requirements
Device.Input.PrecisionTouchpad.I2C.ActivePowerConsumption
Device.Input.PrecisionTouchpad.I2C.ActiveToIdleTimeout
Device.Input.PrecisionTouchpad.I2C.BusSpeed
Device.Input.PrecisionTouchpad.I2C.ColdBootLatency
Device.Input.PrecisionTouchpad.I2C.ConnectedStandbyPowerConsumption
Device.Input.PrecisionTouchpad.I2C.IdlePowerConsumption

Device.Input.PrecisionTouchpad.I2C.ActivePowerConsumption

Device.Input.PrecisionTouchpad.I2C.ActivePowerConsumption

Target Feature
Device.Input.PrecisionTouchpad.I2C
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Active power consumption for I2C connected Windows Precision Touchpads shall conform to the following overall power consumption formula reflecting usage:

0.9 x (Idle Power Consumption in mW) + 0.1 x (Active Power Consumption in mW) <= 25 mW

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.I2C.ActiveToIdleTimeout

Device.Input.PrecisionTouchpad.I2C.ActiveToIdleTimeout

Target Feature
Device.Input.PrecisionTouchpad.I2C
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

I2C connected Windows precision touchpads shall internally transition from the active power state to the idle power state after 120 seconds of inactivity and gate power accordingly.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.I2C.BusSpeed

Device.Input.PrecisionTouchpad.I2C.BusSpeed

Target Feature
Device.Input.PrecisionTouchpad.I2C
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

I2C connected Windows precision touchpads shall support an I2C bus speed of at least 400KHz.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.I2C.ColdBootLatency

Device.Input.PrecisionTouchpad.I2C.ColdBootLatency

Target Feature
Device.Input.PrecisionTouchpad.I2C
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

I2C connected Windows precision touchpads shall have a cold boot latency of <=100ms where cold boot is defined as the period from application of power to the controller until the controller is ready to accept HID I2C commands.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.I2C.ConnectedStandbyPowerConsumption

Device.Input.PrecisionTouchpad.I2C.ConnectedStandbyPowerConsumption

Target Feature
Device.Input.PrecisionTouchpad.I2C
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

I2C connected Windows precision touchpads shall consume <=1mW while in sleep mode (and wake capable) and conform to Device.Input.PrecisionTouchpad.WakeFunctionality and Device.Input.PrecisionTouchpad.WakeSource.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.I2C.IdlePowerConsumption

Device.Input.PrecisionTouchpad.I2C.IdlePowerConsumption

Target Feature
Device.Input.PrecisionTouchpad.I2C
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Idle power consumption for I2C connected Windows Precision Touchpads shall conform to the following overall power consumption formula reflecting usage:

0.9 x (Idle Power Consumption in mW) + 0.1 x (Active Power Consumption in mW) <= 25 mW

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Performance

Requirements that are specific to the hardware performance of Windows precision touchpads.

Related Requirements
Device.Input.PrecisionTouchpad.Performance.ActiveTouchdownLatency
Device.Input.PrecisionTouchpad.Performance.IdleTouchdownLatency
Device.Input.PrecisionTouchpad.Performance.MinMaxContacts
Device.Input.PrecisionTouchpad.Performance.MinSeparation
Device.Input.PrecisionTouchpad.Performance.PanLatency
Device.Input.PrecisionTouchpad.Performance.ReportRate

Device.Input.PrecisionTouchpad.Performance.ActiveTouchdownLatency

Device.Input.PrecisionTouchpad.Performance.ActiveTouchdownLatency

Target Feature
Device.Input.PrecisionTouchpad.Performance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall have <= 25ms touch down latency in the active state. Touch down latency is defined as the time between contact with the digitizer and the subsequent input report being received by the host.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Performance.IdleTouchdownLatency

Device.Input.PrecisionTouchpad.Performance.IdleTouchdownLatency

Target Feature
Device.Input.PrecisionTouchpad.Performance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads connected via I2C shall have <= 50ms touch down latency in the idle state.

Windows precision touchpads connected via USB shall have <= 50ms touch down latency in the idle state excluding USB host controller resume latency.

Touch down latency is defined as the time between contact with the digitizer and the subsequent input report being received by the host.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Performance.MinMaxContacts

Device.Input.PrecisionTouchpad.Performance.MinMaxContacts

Target Feature
Device.Input.PrecisionTouchpad.Performance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall not report being capable of supporting more than a maximum of 5 unique contacts. Windows precision touchpads shall report being capable (and be capable) of supporting a minimum of 3 unique contacts.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Performance.MinSeparation

Device.Input.PrecisionTouchpad.Performance.MinSeparation

Target Feature
Device.Input.PrecisionTouchpad.Performance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall not alias two contacts aligned vertically or horizontally at a minimum separation of 10mm.

Windows precision touchpads shall not alias two contacts aligned diagonally at a minimum separation of 13mm.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Performance.PanLatency

Device.Input.PrecisionTouchpad.Performance.PanLatency

Target Feature
Device.Input.PrecisionTouchpad.Performance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall have panning latency <= 15ms. Panning latency is defined as the period between the movement of a contact and subsequent receipt of the report by the host correlating the move.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Performance.ReportRate

Device.Input.PrecisionTouchpad.Performance.ReportRate

Target Feature
Device.Input.PrecisionTouchpad.Performance
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall report at >= 125Hz (and no greater than 250Hz) when a single contact is on the digitizer. Windows precision touchpads shall report all contacts at >= 100Hz (and no greater than 250Hz) when a multiple contacts are on the digitizer.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision

Requirements that are specific to the hardware precision of Windows precision touchpads.

Related Requirements
Device.Input.PrecisionTouchpad.Precision.ContactDivergence
Device.Input.PrecisionTouchpad.Precision.DiagonalInputSeparation
Device.Input.PrecisionTouchpad.Precision.EdgeDetection
Device.Input.PrecisionTouchpad.Precision.Geometry
Device.Input.PrecisionTouchpad.Precision.HVInputSeparation
Device.Input.PrecisionTouchpad.Precision.InputResolution
Device.Input.PrecisionTouchpad.Precision.Linearity
Device.Input.PrecisionTouchpad.Precision.MaxReportZHeight
Device.Input.PrecisionTouchpad.Precision.MotionJitter
Device.Input.PrecisionTouchpad.Precision.Position
Device.Input.PrecisionTouchpad.Precision.StationaryJitter

Device.Input.PrecisionTouchpad.Precision.ContactDivergence

Device.Input.PrecisionTouchpad.Precision.ContactDivergence

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall support convergence and divergence of two contacts without swapping contact IDs at a minimum center-to-center contact distance of 10mm horizontally and vertically.

Windows precision touchpads shall support convergence and divergence of two contacts without swapping contact IDs at a minimum center-to-center contact distance of 13mm diagonally.

Additional Information

Business Justification
Windows precision touchpads shall deliver a consistent user experience and ensure that each unique contact is reported correctly to the host.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.DiagonalInputSeparation

Device.Input.PrecisionTouchpad.Precision.DiagonalInputSeparation

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall support two contacts travelling in parallel at a minimum center-to-center contact distance of 13mm diagonally without swapping contact IDs.

Additional Information

Business Justification
Windows precision touchpads shall deliver a consistent user experience and ensure that each unique contact is reported correctly to the host.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.EdgeDetection

Device.Input.PrecisionTouchpad.Precision.EdgeDetection

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall detect and report contacts within a maximum of 2mm of the edge of the digitizer surface.

Additional Information

Business Justification
Windows precision touchpads shall deliver a consistent user experience and ensure reporting of contacts involved in edge based gesture detection.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.Geometry

Device.Input.PrecisionTouchpad.Precision.Geometry

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

(Geometry reporting is OPTIONAL, If implemented, this requirement applies)

Windows precision touchpads shall report the height and width of each contact s associated bounding box around its center of mass within +/- 2mm of actual dimensions.

Windows precision touchpads shall report the location of the center of mass (Cx and Cy) in addition to the intended contact location (Tx and Ty).

Additional Information

Business Justification
Windows precision touchpads shall deliver both a consistent user experience and developer experience involving contact geometry.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.HVInputSeparation

Device.Input.PrecisionTouchpad.Precision.HVInputSeparation

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall support two contacts travelling in parallel at a minimum center-to-center contact distance of 10mm horizontally and vertically without swapping contact IDs.

Additional Information

Business Justification
Windows precision touchpads shall deliver a consistent user experience and ensure that each unique contact is reported correctly to the host.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.InputResolution

Device.Input.PrecisionTouchpad.Precision.InputResolution

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall report a logical maximum for x linearly proportional to the width of the touchpad and shall report a logical maximum for y linearly proportional to the length of the touchpad. The top left corner of the touchpad shall be the origin (0,0). All Windows precision touchpads are at least 300dpi, therefore for the minimum size Windows precision touchpads, the logical maximum for x shall be >= 767 and the logical maximum for y shall >= 384.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.Linearity

Device.Input.PrecisionTouchpad.Precision.Linearity

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall maintain linearity within 0.5mm for all contacts reported across edge to edge travel horizontally, vertically, and diagonally. Within 3.5mm of any edge, precision touchpads shall maintain linearity within 1.5mm for all contacts reported.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.MaxReportZHeight

Device.Input.PrecisionTouchpad.Precision.MaxReportZHeight

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall not report contacts > 0.5mm above the digitizer surface.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.MotionJitter

Device.Input.PrecisionTouchpad.Precision.MotionJitter

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall not report any backward motion jitter for contacts in motion. Backward jitter is defined as a subsequent report of contact location in the opposite direction of contact travel.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.Position

Device.Input.PrecisionTouchpad.Precision.Position

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall report the absolute digitizer position accurately for all contacts.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Precision.StationaryJitter

Device.Input.PrecisionTouchpad.Precision.StationaryJitter

Target Feature
Device.Input.PrecisionTouchpad.Precision
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall not report any jitter for all stationary precision contacts.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Reliability

Requirements that are specific to the hardware reliability of Windows precision touchpads.

Related Requirements
Device.Input.PrecisionTouchpad.Reliability.ContactsReported
Device.Input.PrecisionTouchpad.Reliability.ContactSuppression
Device.Input.PrecisionTouchpad.Reliability.FalseContacts
Device.Input.PrecisionTouchpad.Reliability.PowerStates

Device.Input.PrecisionTouchpad.Reliability.ContactsReported

Device.Input.PrecisionTouchpad.Reliability.ContactsReported

Target Feature
Device.Input.PrecisionTouchpad.Reliability
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Contact with any and all areas of a Windows precision touchpad digitizer surface shall result in a reported contact.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Reliability.ContactSuppression

Device.Input.PrecisionTouchpad.Reliability.ContactSuppression

Target Feature
Device.Input.PrecisionTouchpad.Reliability
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall stop reporting if the number of contacts exceeds the maximum number of supported contacts reported to the host. In this condition, Windows precision touchpads, shall report an up for all previously reported contacts and then cease reporting until the number of contacts is back within the supported range.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Reliability.FalseContacts

Device.Input.PrecisionTouchpad.Reliability.FalseContacts

Target Feature
Device.Input.PrecisionTouchpad.Reliability
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

No ghost contacts shall be reported by Windows precision touchpads under both AC and DC power conditions.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.Reliability.PowerStates

Device.Input.PrecisionTouchpad.Reliability.PowerStates

Target Feature
Device.Input.PrecisionTouchpad.Reliability
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Windows precision touchpads shall function correctly across power state transitions with contacts and/or button down.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.USB

Requirements that are specific to USB connected Windows precision touchpads.

Related Requirements
Device.Input.PrecisionTouchpad.USB.ActivePowerConsumption
Device.Input.PrecisionTouchpad.USB.BusSpeed
Device.Input.PrecisionTouchpad.USB.ColdBootLatency
Device.Input.PrecisionTouchpad.USB.IdlePowerConsumption
Device.Input.PrecisionTouchpad.USB.SelectiveSuspend
Device.Input.PrecisionTouchpad.USB.SleepPowerConsumption

Device.Input.PrecisionTouchpad.USB.ActivePowerConsumption

Device.Input.PrecisionTouchpad.USB.ActivePowerConsumption

Target Feature
Device.Input.PrecisionTouchpad.USB
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Active power consumption for USB connected Windows Precision Touchpads shall conform to the following overall power consumption formula reflecting usage:

0.9 x (Idle Power Consumption in mW) + 0.1 x (Active Power Consumption in mW) <= 25 mW

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.USB.BusSpeed

Device.Input.PrecisionTouchpad.USB.BusSpeed

Target Feature
Device.Input.PrecisionTouchpad.USB
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

USB connected Windows precision touchpads shall support Full Speed or greater.

Additional Information

Business Justification
In order for Windows precision touchpads to communicate the rich input data stream to the host, minimum bandwidth requirements need to be met.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.USB.ColdBootLatency

Device.Input.PrecisionTouchpad.USB.ColdBootLatency

Target Feature
Device.Input.PrecisionTouchpad.USB
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

USB connected Windows precision touchpads shall have a cold boot latency <= 250ms where cold boot is defined as the period from application of power to the controller until the controller is ready to accept HID USB commands.

Additional Information

Business Justification
Windows precision touchpads shall be highly responsive and ready to use after a system power state transition.
Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.USB.IdlePowerConsumption

Device.Input.PrecisionTouchpad.USB.IdlePowerConsumption

Target Feature
Device.Input.PrecisionTouchpad.USB
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Idle power consumption for USB connected Windows Precision Touchpads shall conform to the following overall power consumption formula reflecting usage:

0.9 x (Idle Power Consumption in mW) + 0.1 x (Active Power Consumption in mW) <= 25 mW

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.USB.SelectiveSuspend

Device.Input.PrecisionTouchpad.USB.SelectiveSuspend

Target Feature
Device.Input.PrecisionTouchpad.USB
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

USB connected Windows precision touchpads shall be selective suspend capable supporting remote wake and report these capabilities via the OS descriptor to the host.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.PrecisionTouchpad.USB.SleepPowerConsumption

Device.Input.PrecisionTouchpad.USB.SleepPowerConsumption

Target Feature
Device.Input.PrecisionTouchpad.USB
Applies to
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

USB connected Windows precision touchpads shall consume <=1mW while in sleep mode (and wake capable) and conform to Device.Input.PrecisionTouchpad.WakeFunctionality and Device.Input.PrecisionTouchpad.WakeSource.

Additional Information

Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.Accelerometer

Related Requirements
Device.Input.Sensor.Accelerometer.SensorDataType
Device.Input.Sensor.Accelerometer.SensorReportInterval
Device.Input.Sensor.Accelerometer.ShakeEvent

Device.Input.Sensor.Accelerometer.SensorDataType

Accelerometer device drivers shall accurately report the right Data Types for Accelerometers as defined for the Sensors and Location Platform

Target Feature
Device.Input.Sensor.Accelerometer
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All accelerometer class sensors need to ensure that they accurately report the following Data Types to be seamlessly integrated with Windows (through the sensors platform) and exposed to applications.

Data type
Type
Meaning
SENSOR_DATA_TYPE_ACCELERATION_X_G
VT_R8
X-axis acceleration, in gs.
SENSOR_DATA_TYPE_ACCELERATION_Y_G
VT_R8
Y-axis acceleration, in gs.
SENSOR_DATA_TYPE_ACCELERATION_Z_G
VT_R8
Z-axis acceleration, in gs.

*Clarify what G = Gravitational Constant = 32.2 ft/sec2 and 9.8 m/sec2Note: Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED for hardware that is built-in to the PC enclosure.For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Additional Information

Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.Accelerometer.SensorReportInterval

Accelerometer function driver and firmware report data with minimum report interval of 16ms (for a 60Hz frequency for gaming)

Target Feature
Device.Input.Sensor.Accelerometer
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All accelerometer class sensors need to ensure that they accurately report the data at the required sampling rates to be efficient for gaming applications as well as power managed when not in full use.

Sensor Property
Type
Meaning
SENSOR_PROPERTY_MIN_REPORT_INTERVAL
VT_R8
The minimum elapsed time setting that the hardware supports for sensor data report generation, in milliseconds
Application Scenario
Fidelity
Hertz
Report Interval (msec)
Augmented Reality / Rich Gaming
High_Fidelity
60
16
Casual Gaming
Medium_Fidelity
30
33
Rotation Manager
Low_Fidelity
15
67

All accelerometer type sensors must support these report intervals to ensure a consistent experience for application categories. Intermediate report intervals may be optionally supported.

Additional Information

Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.Accelerometer.ShakeEvent

If an accelerometer device driver (optionally) supports a shake gesture, it must use the correct Event ID and expose to the Sensors and Location Platform.

Target Feature
Device.Input.Sensor.Accelerometer
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

An accelerometer (or related) sensors may optionally report a shake gesture to the sensor platform, when the user shakes the embedded sensor in the system. The following is the Data Event to be seamlessly integrated with Windows (through the sensor's platform) and exposed to applications.

Data Event
Meaning
SENSOR_EVENT_ACCELEROMETER_SHAKE
The user has shaken the system to trigger an application event.

This is validated in code by calling: ISensor::SupportsEvent()For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Additional Information

Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.ALS

Related Requirements
Device.Input.Sensor.ALS.CalibrationTest
Device.Input.Sensor.ALS.SupportRequiredData

Device.Input.Sensor.ALS.CalibrationTest

ALS Calibration Test

Target Feature
Device.Input.Sensor.ALS
Applies to
Windows 8.1 Client ARM (Windows RT 8.1)

Description

ALS should report lux values within 10% accuracy when a 100 lux light source is aimed directly into the ALS aperture. ALS should report lux values within 50% attenuation when the light source is aimed at an angle of 35 degrees from the ALS aperture.

Additional Information

Business Justification
There have been multiple cases where system designs did not account for shadow effects which occur when the ALS hole is either too deep or too small in diameter. This causes incorrect light level readings which in turn cause Windows to incorrectly dim the screen.
Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.ALS.SupportRequiredData

Ambient Light Sensors must support and generate the required data

Target Feature
Device.Input.Sensor.ALS
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

Data Field Support for Ambient Light Sensor

Ambient light sensors identify themselves as SENSOR_TYPE_AMBIENT_LIGHT though Device Driver Interfaces ISensorDriver::OnGetSupportedSensorObjects and ISensorDriver::OnGetProperties()).

Ambient Light sensors must support light readings in lux to ensure all light-aware applications can expect consistent data. This data is queried from Device Driver Interface ISensorDriver::OnGetSupportedDataFields() and ISensorDriver::OnGetDataFields()).

Built in ambient light sensors can be used by the Adaptive Brightness feature in Windows if they also set the SENSOR_PROPERTY_CONNECTION_TYPE property (of data type VT_UI4) to SENSOR_CONNECTION_TYPE_PC_INTEGRATED. This is optional, but recommended for built-in sensors.

Data field
Data type
Definition
SENSOR_DATA_TYPE_LIGHT_LEVEL_LUX
VT_R4
The current light level being measured (in lux).

The requirements below ensure that the driver raises ALS report events in the correct manner. If the correct behavior is not followed, client applications will not receive data.Generating Reports

The device must be able to generate a series of reports containing SENSOR_DATA_TYPE_LIGHT_LEVEL_LUX.

Verify Sensor can provide dynamic data report demonstrating a decrease and subsequent increase in LUX.

Design Notes: The new Sensor and Location Platform enables sensor and location devices to be easily accessible through two new API's: the Sensor API and the Location API. The Sensor API provides consistent access to information from physical and logical sensor devices. The Location API is built on the Sensor API and streamlines access to location specific information.The Sensor and Location Platform will rely on data provided to the platform via device drivers that have implemented the Sensor Device Driver Interface. This document details the Windows Logo tests which will be applied against devices (and their supporting drivers) applying for logo certification for the Sensor and Location Platform. In most cases devices will be verified by using the Sensor and Location Platform.Ambient Light sensors must comply with Logo Requirement INPUT-0048 (Sensor and Location Platform devices must properly support the required set of data and properties) in addition to the requirements described here. These requirements are designed to help ensure the following goals are met:

Sensor devices have high quality hardware and drivers.

Sensor devices interact with the APIs in a consistent and reliable manner.

Additional Information

Business Justification
To ensure the ALS sensor drivers that receive a logo meet a high quality bar, it is necessary that the requirements include tests for the behavior of the device. The proposed additions ensure that the driver raises ALS report events in the correct manner. If the correct behavior is not followed, client applications will not receive data.
Enforcement Date
Jun. 01, 2009

Device.Input.Sensor.Base

Related Requirements
Device.Input.Sensor.Base.DataEvents
Device.Input.Sensor.Base.GNSSTestProperties
Device.Input.Sensor.Base.PowerState
Device.Input.Sensor.Base.SupportDataTypesAndProperties

Device.Input.Sensor.Base.DataEvents

Data Events

Target Feature
Device.Input.Sensor.Base
Applies to
Windows 8.1 Client ARM (Windows RT 8.1)

Description

If a client sets the change sensitivity to 0, or when the change sensitivity is not applicable (e.g. for location), data events shall not fire more often than 80% of the CRI. The device also shall not miss more than 5% of the data reports, both for short (e.g. <= 1 sec) and long (e.g. > 1 minute) values of the current report interval.

Data events should not be fired if the current report interval and change sensitivity (when applicable) are not met.

Data events should not be fired at a rate less than the minimum report interval

Additional Information

Business Justification
If data events are not fired when change sensitivity or current report interval values are satisfied there can be power and performance degradation. These tests make sure that sensors fire data when they are expected to.
Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.Base.GNSSTestProperties

Location GNSS Test Properties

Target Feature
Device.Input.Sensor.Base
Applies to
Windows 8.1 Client ARM (Windows RT 8.1)

Description

GPS devices shall support Assisted GPS (A-GPS). It is up to the device which A-GPS solution e.g. internet based, mobile operator based solution to implement.

While the GPS driver can utilize the other devices on the system for enhancements e.g. faster Time-To-Fix (TTF), GPS device shall continue to function when such devices are disabled, went into low power states or their radios are turned off.

In order to enable AGPS testing and cold starting the device when needed, GNSS Drivers must support SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA.

In order to allow turning on and turning off NMEA sentences in data reports, GNSS Driver must support SENSOR_PROPERTY_TURN_ON_OFF_NMEA. NMEA lines shall not be included in data reports by default.

//{e1e962f4-6e65-45f7-9c36-d487b7b1bd34}

DEFINE_GUID(SENSOR_PROPERTY_TEST_GUID, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34);

DEFINE_PROPERTYKEY(SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 2); //[VT_UI4]

DEFINE_PROPERTYKEY(SENSOR_PROPERTY_TURN_ON_OFF_NMEA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 3); //[VT_UI4]

#define GNSS_CLEAR_ALL_ASSISTANCE_DATA 0x00000001

SENSOR_PROPERTY_ CLEAR_ASSISTANCE_DATA
(PID = 2)
VT_UI4
Write. The assistance data to be cleared.
Setting a value of GNSS_CLEAR_ALL_ASSISTANCE_DATA signals the driver to clear all assistance data, including time, almanac, ephemeris and last position.
WHCK tests can set this value to clear the assistance data before a cold start test, AGPS tests or independently before running simulator tests where time and location is simulated. If A-GPS capabilities e.g. SUPL, LTO is supported, driver can try to utilize them after this operation by using the network connection. However, it should be in a state where no assistance data is saved in the device or on the system. Any assistance data elements shall be downloaded again.
SENSOR_PROPERTY_TURN_ON_OFF_NMEA
(PID = 3)
VT_UI4
Read/Write. If set to TRUE, NMEA sentence shall be included in data reports. If set to False, NMEA sentence shall not be included in data reports.
WHCK tests can use this property to instruct the device to start sending NMEA data or stop including it in data reports.

Additional Information

Business Justification
In order to test Time-To-Fix performance characteristics of a GPS device e.g. whether A-GPS is supported or Time-To-First-Fix after a cold start , it is needed to instruct the driver to clear the assistance data. Since there is no user scenario for apps to clear the assistance data, which will increase the time to fix, this is a test only property and is not exposed via API.
Adding NMEA sentence with all data reports notably increases the data being passed to upper layers. SENSOR_PROPERTY_TURN_ON_OFF_NMEA allows the test app to ask for inclusion of this data only when needed.
Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.Base.PowerState

Power State

Target Feature
Device.Input.Sensor.Base
Applies to
Windows 8.1 Client ARM (Windows RT 8.1)

Description

GPS devices shall support Assisted GPS (A-GPS). It is up to the device which A-GPS solution e.g. internet based, mobile operator based solution to implement.

While the GPS driver can utilize the other devices on the system for enhancements e.g. faster Time-To-Fix (TTF), GPS device shall continue to function when such devices are disabled, went into low power states or their radios are turned off.

In order to enable AGPS testing and cold starting the device when needed, GNSS Drivers must support SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA.

In order to allow turning on and turning off NMEA sentences in data reports, GNSS Driver must support SENSOR_PROPERTY_TURN_ON_OFF_NMEA. NMEA lines shall not be included in data reports by default.

//{e1e962f4-6e65-45f7-9c36-d487b7b1bd34}

DEFINE_GUID(SENSOR_PROPERTY_TEST_GUID, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34);

DEFINE_PROPERTYKEY(SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 2); //[VT_UI4]

DEFINE_PROPERTYKEY(SENSOR_PROPERTY_TURN_ON_OFF_NMEA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 3); //[VT_UI4]

#define GNSS_CLEAR_ALL_ASSISTANCE_DATA 0x00000001

SENSOR_PROPERTY_ CLEAR_ASSISTANCE_DATA
(PID = 99)
VT_UI4
Write. The assistance data to be cleared.
Setting a value of GNSS_CLEAR_ALL_ASSISTANCE_DATA signals the driver to clear all assistance data, including time, almanac, ephemeris and last position.
WHCK tests can set this value to clear the assistance data before a cold start test, AGPS tests or independently before running simulator tests where time and location is simulated. If A-GPS capabilities e.g. SUPL, LTO is supported, driver can try to utilize them after this operation by using the network connection. However, it should be in a state where no assistance data is saved in the device or on the system. Any assistance data elements shall be downloaded again.
SENSOR_PROPERTY_TURN_ON_OFF_NMEA
(PID = 3)
VT_UI4
Read/Write. If set to TRUE, NMEA sentence shall be included in data reports. If set to False, NMEA sentence shall not be included in data reports.
WHCK tests can use this property to instruct the device to start sending NMEA data or stop including it in data reports.

Additional Information

Business Justification
If a sensor cannot enter a low power when all clients are disconnected, Windows will not be able to achieve power savings.
If a sensor cannot power up when a client is connected, the machine cannot function properly.
Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.Base.SupportDataTypesAndProperties

Sensor and Location Platform devices support the set of data types and properties as defined in this requirement.

Target Feature
Device.Input.Sensor.Base
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All sensor devices that implement the Sensor Device Driver Interface must meet the following requirements. See any additional requirements that are specific to the sensor type being tested. For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Required Properties

Sensor devices should show accurate data. The data being provided must follow the guidelines described in MSDN for each property and device type.

These properties are queried using Device Driver Interfaces ISensorDriver::OnGetSupportedSensorObjects, ISensorDriver::OnGetSupportedProperties() and ISensorDriver::OnGetProperties(). Explicit type matching is required for data types and properties. The types must be the same as in the charts below.

Property
Data type
Static
Details
WPD_FUNCTIONAL_OBJECT_CATEGORY
VT_CLSID
Static
SENSOR_PROPERTY_TYPE
VT_CLSID
Static
SENSOR_PROPERTY_STATE
VT_UI4
Not static
SENSOR_PROPERTY_PERSISTENT_UNIQUE_ID
VT_CLSID
Static
SENSOR_PROPERTY_MANUFACTURER
VT_LPWSTR
Static
SENSOR_PROPERTY_MODEL
VT_LPWSTR
Static
SENSOR_PROPERTY_SERIAL_NUMBER
VT_LPWSTR
Static
SENSOR_PROPERTY_FRIENDLY_NAME
VT_LPWSTR
Static
SENSOR_PROPERTY_MIN_REPORT_INTERVAL
VT_UI4
Static
SENSOR_PROPERTY_CONNECTION_TYPE
VT_UI4
Static

Required Static Properties

The following properties must not change value over time, so that the Sensor and Location Platform (and applications) can use them to select and manage sensors. These properties are queried using Device Driver Interfaces ISensorDriver::OnGetSupportedProperties() and ISensorDriver::OnGetProperties().

Data types for these properties must match those in the following chart.

The properties must be implemented following the guidelines described in MSDN.

Settable Properties

Applications can use settable properties to configure the driver (such as optimize for power or other factors). Other settable properties can be exposed besides the following ones, but if this property is exposed, it must be settable.

Setting SENSOR_PROPERTY_CURRENT_REPORT_INTERVAL < SENSOR_PROPERTY_MIN_REPORT_INTERVAL does not change the current report interval and setting SENSOR_PROPERTY_CHANGE_SENSITIVITY < 0 does not change the change sensitivity.The sensor shall be able to handle changes to the current report interval and change sensitivity for a single and multiple clients.

The sensor should be able to respond to a client asking to be removed from calculation of the effective current report interval and change sensitivity. Clients can set CS to VT_NULL but there isn t an API to be removed. CRI/CS set by multiple clients needs to respect that most sensitive request.Sensors shall follow the current report interval and change sensitivity (when applicable) documentation found on MSDN:https://msdn.microsoft.com/library/windows/hardware/hh706201(v=vs.85).aspx

GPS devices shall support property value for SENSOR_PROPERTY_MIN_REPORT_INTERVAL at one second or less and be capable of sending events at this interval.

Sensor drivers and firmware must support and adhere to the following Settable Properties: in the Sensor API.

Property
Data type
Details
SENSOR_PROPERTY_CURRENT_REPORT_INTERVAL
VT_UI4
Sets the minimum frequency (in milliseconds) that a client wants to receive data reports from the sensor.
This property should be tracked on a per client basis.
SENSOR_PROPERTY_CHANGE_SENSITIVITY
VT_UNKNOWN
Sets the threshold of how much a data field must change before an event is fired.

The current report interval and change sensitivity retrieved must be within the tolerances listed below:

Single client (or multiple clients with only one client setting CRI):

Set Value
Expected value
0
Default CRI
0< value <(Min CRI)
Not changed, sensor reports error
(Min CRI) <= value
(where value = (Min CRI)*N+T where T is 0<T<(Min CRI))
(Min CRI)*N <= value <= (Min CRI)*N + T where T is 0<T<(Min CRI)

Multiple clients:

Set Value
Expected value
0 (Default CRI)
No change if client set value greater than effective CRI. New effective CRI if based on CRI set by other clients.
Effective CRI is smallest CRI of those set by clients but >= Min CRI
0< value <(Min CRI)
Not changed, sensor reports error
(Min CRI) <= value < effective CRI
(where value = (Min CRI)*N+T where T is 0<T<(Min CRI))
(Min CRI)*N <= value <= (Min CRI)*N + T where T is 0<T<(Min CRI))
> effective CRI
Not changed

Data Fields

Sensor devices are useful only when they report data. Each device must report at least one data field in addition to SENSOR_DATA_TYPE_TIMESTAMP (VT_FILETIME). Data fields are exposed to the Sensor API by using Device Driver Interface ISensorDriver::OnGetSupportedDataFields() and ISensorDriver::OnGetDataFields().

GPS testing shall be performed in availability of GPS signal.

GPS devices shall provide accurate latitude, longitude and altitude values within the specified error radius.

GPS devices shall be able to report horizontal accuracy of 15 meters and vertical accuracy of 100 meters at 95% of the time under clear sky conditions. This applies to both static or mobile test scenarios.

Clear sky conditions: GNSS satellites signals are received without obstruction from above or surrounding environment down to an elevation mask of 5 degrees above the horizon. All signal levels consistent with unobstructed signal levels at the ground and not to be lower than -131 dBm for 4 or more satellites.

GPS devices shall be able to report speed in knots with +-20% accuracy.

GPS devices shall be able to report true heading degrees with +-20% accuracy.

GPS Shall support the following data fields:

Data Field
Type
SENSOR_DATA_TYPE_LATITUDE_DEGREES
VT_R8
SENSOR_DATA_TYPE_LONGITUDE_DEGREES
VT_R8
SENSOR_DATA_TYPE_ERROR_RADIUS_METERS
VT_R8
SENSOR_DATA_TYPE_SATELLITES_USED_COUNT
VT_I4
SENSOR_DATA_TYPE_ALTITUDE_ELLIPSOID_METERS
VT_R8
SENSOR_DATA_TYPE_ALITITUDE_ELLIPSOID_ERROR_METERS
VT_R8
SENSOR_DATA_TYPE_SPEED_KNOTS
VT_R8
SENSOR_DATA_TYPE_TRUE_HEADING_DEGREES
VT_R8
SENSOR_DATA_TYPE_NMEA_SENTENCE
VT_LPWSTR
SENSOR_DATA_TYPE_SATELLITES_IN_VIEW_STN_RATIO
VT_VECTOR VT_UI1

Location may support the following data fields. If they are supported, they must be implemented according to the guidelines in MSDN.

SENSOR_DATA_TYPE_ALTITUDE_SEALEVEL_METERS
VT_R8
SENSOR_DATA_TYPE_MAGNETIC_HEADING_DEGREES
VT_R8
SENSOR_DATA_TYPE_MAGNETIC_VARIATION
VT_R8
SENSOR_DATA_TYPE_FIX_QUALITY
VT_I4
SENSOR_DATA_TYPE_FIX_TYPE
VT_I4
SENSOR_DATA_TYPE_POSITION_DILUTION_OF_PRECISION
VT_R8
SENSOR_DATA_TYPE_HORIZONAL_DILUTION_OF_PRECISION
VT_R8
SENSOR_DATA_TYPE_VERTICAL_DILUTION_OF_PRECISION
VT_R8
SENSOR_DATA_TYPE_SATELLITES_USED_PRNS
VT_VECTOR VT_UI1
SENSOR_DATA_TYPE_SATELLITES_IN_VIEW
VT_I4
SENSOR_DATA_TYPE_SATELLITES_IN_VIEW_PRNS
VT_VECTOR VT_UI1
SENSOR_DATA_TYPE_SATELLITES_IN_VIEW_ELEVATION
VT_VECTOR VT_UI1
SENSOR_DATA_TYPE_SATELLITES_IN_VIEW_AZIMUTH
VT_VECTOR VT_UI1
SENSOR_DATA_TYPE_ADDRESS1
VT_LPWSTR
SENSOR_DATA_TYPE_ADDRESS2
VT_LPWSTR
SENSOR_DATA_TYPE_CITY
VT_LPWSTR
SENSOR_DATA_TYPE_STATE_PROVINCE
VT_LPWSTR
SENSOR_DATA_TYPE_POSTALCODE
VT_LPWSTR
SENSOR_DATA_TYPE_ALTITUDE_SEALEVEL_ERROR_METERS
VT_R8
SENSOR_DATA_TYPE_GPS_SELECTION_MODE
VT_I4
SENSOR_DATA_TYPE_GPS_OPERATION_MODE
VT_I4
SENSOR_DATA_TYPE_GPS_STATUS
VT_I4
SENSOR_DATA_TYPE_GEOIDAL_SEPARATION
VT_R8
SENSOR_DATA_TYPE_DGPS_DATA_AGE
VT_R8
SENSOR_DATA_TYPE_ALTITUDE_ANTENNA_SEALEVEL_METERS
VT_R8
SENSOR_DATA_TYPE_DIFFERENTIAL_REFERENCE_STATION_ID
VT_I4
SENSOR_DATA_TYPE_SATELLITES_IN_VIEW_ID
VT_VECTOR VT_UI1

Missing Properties

The device driver must correctly handle queries and sets for properties that a sensor device does not support. This enables the Sensor and Location Platform to correctly notify applications when sensor properties are missing.

Drivers must return S_FALSE from Device Driver Interfaces ISensorDriver::OnGetProperties and ISensorDriver::OnSetProperties if one or more of the requested properties is not present on the device.

For each missing property the PropVariant for the requested property must have a type of VT_ERROR and a value of HRESULT_FROM_WIN32(ERROR_NOT_FOUND). The driver can return valid values for properties it does have alongside not-valid values.

The follow requirements ensure the sensor drivers that receive a certification can report data reliably, obey the sensor driver state model and implement data timestamps correctly.

Reliability

The driver must continue to operate after four hours of reporting data and "get data", "get property" calls.

The driver must continue to operate when readable/writeable properties are set and read.

The driver must provide data and properties after completion of sleep/resume or hibernation/resume cycle(s).

The driver shall be able to handle concurrent PnP, radio (if GPS), power operations and multiple clients entering and exiting.

Timestamp

The driver must report an accurate relative timestamp with each report.The timestamp shall be in Coordinated Universal Time (UTC) format. This timestamp must be greater than the initial prompt to provide a timestamp and must be less than or equal to the time the event is received.

Ready State Validation

Sensors shall not transition to the SENSOR_STATE_READY state until valid data is available.

Sensors must complete power-up initialization tasks and transition to the SENSOR_STATE_READY after being opened by a client or resuming from system standby within the following times:

Sensor Type
Maximum time allowed to enter ready state
Accelerometer
1 second
Gyro meter
3 seconds
Compass
3 seconds
Inclinometer
3 seconds
Orientation sensor
5 seconds
GPS
See following table

GPS Startup requirements under clear sky conditions

Startup type
Time elapsed from position request (in seconds)
Acceptable sensor states
Acceptable error radius
Cold start
0
SENSOR_STATE_INITIALIZING
n/a
45
SENSOR_STATE_READY
Under 50 meters
Warm start (powered off with assistance data)
0
SENSOR_STATE_INITIALIZING
n/a
10
SENSOR_STATE_READY
Under 300 meters
20
SENSOR_STATE_READY
Under 50 meters
Hot start
0
SENSOR_STATE_INITIALIZING or SENSOR_STATE_READY depending if fix was maintained
Under 300 meters
2
SENSOR_STATE_READY
Under 50 meters

Cold Start TTFF: Time Unknown, Current ephemeris unknown, position unknown

If GPS device supports D3 Cold, it should be able to gracefully go into and wake from D3 Cold. The overhead caused by waking form D3 Cold should not be more than 6 seconds for the First Fix after wake. This is in comparison from the wake from D3 Hot.

Hot Start TTFF: Time known, Almanac known, Ephemeris known, Position within 100km of last fix

GPS devices shall be able to acquire first fix under two seconds when 1) The radio is on, 2) Flight Mode is off, and 3) Under clear sky conditions.

GPS devices under clear sky conditions shall be able to report position from a cold start within 45 seconds.

A-GPS devices shall be able to report position within 10 seconds with 100-300 meter accuracy and within 20 seconds with 30 meter or less accuracy.

Location device shall be in initializing state after it is enabled and change to ready after acquiring the current position.

Location devices shall fire valid location data events with valid location data when in the ready state.

Location devices shall not fire data events when the device is not in either ready state or initializing state.Accuracy Requirements:

Sensor
Accuracy requirement
Accelerometer
+/- 0.1 G
Gyro
+/- 10 degrees per second square
Inclinometer
+/- 10 degrees
Compass
+/- 10 degrees
Orientation
Vector is +/- 15 degrees from true vector

Additional Information

Business Justification
To ensure the sensor drivers that receive a logo meet a high quality bar, it is necessary that the requirements include tests for the behavior of the device. The proposed additions ensure that the driver can report data reliably, obey the sensor driver state model and implement data timestamps correctly.
Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.Base.HID

Base feature for HCK requirements relating to HID, such as FW testing or type validation.

Related Requirements
Device.Input.Sensor.Base.HID.ReportDescriptor

Device.Input.Sensor.Base.HID.ReportDescriptor

HID Report Descriptor

Target Feature
Device.Input.Sensor.Base.HID
Applies to
Windows 8.1 Client ARM (Windows RT 8.1)

Description

Any sensor device that uses the inbox SensorsHIDClassDriver.dll must be compliant with all recommendations in the Sensors HID Annotation document. In the course of executing the sensor, no ETW error events should be raised by the SensorsHIDClassDriver.dll.

Additional Information

Business Justification
The HID sensor is widely used and the underlying firmware must be checked for proper operation.
Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.Compass

Related Requirements
Device.Input.Sensor.Compass.InclinometerDataType
Device.Input.Sensor.Compass.SensorDataType
Device.Input.Sensor.Compass.SensorReportInterval

Device.Input.Sensor.Compass.InclinometerDataType

A tilt compensated compass device driver shall accurately report the right Data Types for an inclinometer (leveraging the accelerometer and compass together) as defined for the Sensors and Location Platform

Target Feature
Device.Input.Sensor.Compass
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

A device that exposes a tilt compensated compass shall also properly expose a 3D accelerometer and a 3D inclinometer. This enables the platform to obtain 3D inclinometer data types. This will be calculated in hardware (or device driver) using the accelerometer and compass data elements and reported to the sensor platform using the Data Types below.

Data Type
Type
Mandatory / Optional
Meaning
SENSOR_DATA_TYPE_TILT_X_DEGREES (Pitch)
VT_R8
Mandatory
Pitch inclination, in degrees
SENSOR_DATA_TYPE_TILT_Y_DEGREES (Roll)
VT_R8
Mandatory
Roll inclination, in degrees
SENSOR_DATA_TYPE_TILT_Z_DEGREES (Yaw)
VT_R8
Mandatory
Yaw inclination, in degrees

Please follow this order for operation:Z, then X, then Y (Yaw , then Pitch , then Roll)http://dev.w3.org/geo/api/spec-source-orientation.htmlNote: Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED for hardware that is built-in to the PC enclosure.For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Additional Information

Business Justification
To ensure the accelerometer and compass reports data in the standardized windows Data Types. This will enable smooth integration into the windows rotation manager and exposed to applications. Critical for gaming scenarios.
Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.Compass.SensorDataType

A tilt compensated compass sensor shall accurately report the right data types for a tilt compensated compass as defined for the Sensors and Location Platform

Target Feature
Device.Input.Sensor.Compass
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All tilt compensated compass class sensors need to ensure that they accurately report the following Data Types to be seamlessly integrated with Windows (through the sensors platform) and exposed to applications. A tilt compensated compass must be able to report degrees while tilted at angles, requiring internal accelerometer data to orient the compass when held at an angle.

Data type
Type
Mandatory / Optional
Meaning
SENSOR_DATA_TYPE_MAGNETIC_HEADING_COMPENSATED_MAGNETIC_NORTH_DEGREES
VT_R4
Mandatory
Tilt compensated compass reading with respect to Magnetic North, in degrees.
SENSOR_DATA_TYPE_MAGNETIC_HEADING_COMPENSATED_TRUE_NORTH_DEGREES
VT_R4
Optional
Tilt compensated compass reading with respect to True North, in degrees.(if the device and/or driver have access to location data).

Note: Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED for hardware that is built-in to the PC enclosure.Tilt compensation is performed by means of integration with 3D accelerometer hardware.For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Additional Information

Business Justification
To ensure the compass reports data in the standardized windows Data Types. This will enable smooth integration into the windows location and heading projections to applications.
Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.Compass.SensorReportInterval

Compass function driver and firmware report data with minimum report interval of 200ms (5Hz frequency) as minimum - this value can have a lower (faster) value

Target Feature
Device.Input.Sensor.Compass
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All compass class sensors need to ensure that they accurately report the data at the required sampling rates to be efficient for mapping applications as well as power managed when not in full use.

Sensor Property
Type
Meaning
SENSOR_PROPERTY_CURRENT_REPORT_INTERVAL
VT_R8
The current elapsed time for sensor data report generation, in milliseconds.
Application Scenario
Fidelity
Hertz
Report Interval (msec)
Mapping
Low_Fidelity
5
200

Compass sensors may report data more frequently if the hardware capabilities exist, but they must meet the above requirement as a minimum reporting rate.

Additional Information

Business Justification
Ensure the compass and inclinometer reports data in the standardized way that all applications can rely on. These categories of report intervals (sampling rate) should satisfy majority of the application categories. Vertical solutions are allowed to support other report interval rates needed for the specific application.
Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.DeviceOrientation

Related Requirements
Device.Input.Sensor.DeviceOrientation.SensorDataType

Device.Input.Sensor.DeviceOrientation.SensorDataType

A device that contains a Gyroscope, Compass and Accelerometer, shall accurately report the right Data Types of the individual sensors along with a singular Device Orientation Data Type as defined for the Sensors and Location Platform

Target Feature
Device.Input.Sensor.DeviceOrientation
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All device that exposes a device orientation sensor (SENSOR_TYPE_AGGREGATED_DEVICE_ORIENTATION) needs to ensure that it accurately report the following Data Types to be seamlessly integrated with Windows (through the sensors platform) and exposed to applications. Sensor data types

SENSOR_DATA_TYPE_ROTATION_MATRIX
{1637D8A2-4248-4275-865D-558DE84AEDFD}, 16
Please see "Integrating Motion and Orientation Sensors with PC Hardware Running Windows 8" whitepaper for more details regarding data formatting for this datafield.
SENSOR_DATA_TYPE_QUATERNION
{1637D8A2-4248-4275-865D-558DE84AEDFD}, 17
Please see "Integrating Motion and Orientation Sensors with PC Hardware Running Windows 8" whitepaper for more details regarding data formatting for this datafield.

Note: Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED for hardware that is built-in to the PC enclosure.For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK), and the "Integrating Motion and Orientation Sensors with PC Hardware Running Windows 8" whitepaper located at: https://go.microsoft.com/fwlink/?LinkId=247811/ .

Additional Information

Business Justification
To ensure the combined sensors (Gyroscope, Compass, Accelerometer) sensor reports data in the standardized windows Data Types.
Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.Gyroscope

Related Requirements
Device.Input.Sensor.Gyroscope.SensorDataType
Device.Input.Sensor.Gyroscope.SensorReportInterval

Device.Input.Sensor.Gyroscope.SensorDataType

Gyroscope device drivers shall accurately report the right Data Types for Gyroscopes as defined for the Sensors and Location Platform

Target Feature
Device.Input.Sensor.Gyroscope
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All gyroscope class sensors need to ensure that they accurately report the following Data Types to be seamlessly integrated with Windows (through the sensors platform) and exposed to Modern Applications.

Data type
Type
Meaning
SENSOR_DATA_TYPE_ANGULAR_VELOCITY_X_DEGREES_PER_SECOND
VT_R8
Angular velocity around X-axis , in degrees per second.
SENSOR_DATA_TYPE_ANGULAR_VELOCITY_Y_DEGREES_PER_SECOND
VT_R8
Angular velocity around Y-axis , in degrees per second.
SENSOR_DATA_TYPE_ANGULAR_VELOCITY_Z_DEGREES_PER_SECOND
VT_R8
Angular velocity around Z-axis , in degrees per second.

Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED for hardware that is built-in to the PC enclosure.For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Additional Information

Business Justification
To ensure the gyroscope reports data in the standardized windows Data Types. If a sensor does not report these data fields, it will not be treated as a gyroscope and will not be exposed to applications as a gyroscope sensor.
Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.Gyroscope.SensorReportInterval

Gyroscope function driver and firmware report data with minimum report interval of 16ms (for a 60Hz frequency for gaming)

Target Feature
Device.Input.Sensor.Gyroscope
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All gyroscope class sensors need to ensure that they accurately report the data at the required sampling rates to be efficient for gaming applications as well as power managed when not in full use.

Sensor Property
Type
Meaning
SENSOR_PROPERTY_CURRENT_REPORT_INTERVAL
VT_R8
The current elapsed time for sensor data report generation, in milliseconds.
Application Scenario
Fidelity
Hertz
Report Interval (msec)
Augmented Reality / Rich Gaming
High_Fidelity
60
16
Casual Gaming
Medium_Fidelity
30
33
Rotation Manager
Low_Fidelity
15
67

All gyroscope type sensors must support these report intervals to ensure a consistent experience for application categories. Intermediate report intervals may be optionally supported.

Additional Information

Business Justification
To ensure the gyroscope reports data in the standardized way that all apps can rely on. These categories of report intervals (sampling rate) should satisfy majority of the application categories. Vertical solutions are allowed to support other report interval rates needed for the targeted application.
Enforcement Date
Mar. 01, 2012

Device.Input.Sensor.Location

Related Requirements
Device.Input.Sensor.Location.GNSSRFSensitivity
Device.Input.Sensor.Location.SupportRequiredDataFieldsForReport

Device.Input.Sensor.Location.GNSSRFSensitivity

GNSS RF Sensitivity

Target Feature
Device.Input.Sensor.Location
Applies to
Windows 8.1 Client ARM (Windows RT 8.1)

Description

GPS device and antenna shall have Over the Air (OTA) acquisition sensitivity as -142 dB or better. For OTA tracking sensitivity, it should be better than -145 dB.

Interference with other components in the system shall not cause degradation from these sensitivity goals. Display, Camera, other radios e.g. NFC, Bluetooth, WiFi, Mobile Broadband are some of the potential components which can cause interference. Active usage of such components shall not degrade GPS RF sensitivity.

Human hands holding the device one of the common positions shall not degrade GPS RF Sensitivity. Device shall be able to maintain OTA acquisition sensitivity at -142 dBm and OTA tracking sensitivity of -145 dBm when the system is held in common positions.

Additional Information

Business Justification
Poor RF performance of the device or poor antenna selection, placement and wiring of the antenna can prevent GPS devices from getting a fix even in good signal conditions. GPS signals being weak when they reach to the ground and them being very prone to interference make GPS RF sensitivity particularly important in order to have well performing GPS devices.
Enforcement Date
Jun. 26, 2013

Device.Input.Sensor.Location.SupportRequiredDataFieldsForReport

Location Sensors must support and generate the required data fields for at least one built-in report

Target Feature
Device.Input.Sensor.Location
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All location devices need to ensure that they report location data at the required report interval taking into account the application desired accuracy to provide location data as efficiently as possible. Location devices should maintain the lowest power state possible when not in use. Location devices should enter a low power state (if possible) when not in the process of acquiring location data.Data Field Support for Location Reports The Location API exposes location data through standard built-in reports. These reports are populated from location sensors that the Location API manages automatically. Location sensor devices that report their category as SENSOR_CATEGORY_LOCATION (though Device Driver Interfaces ISensorDriver::OnGetSupportedSensorObjects and ISensorDriver::OnGetProperties()) must support one of the built-in reports so that the location API can manage the sensor and report its data. Each built-in report has a set of expected data fields (though Device Driver Interface ISensorDriver::OnGetSupportedDataFields() and ISensorDriver::OnGetDataFields()) that the Location API looks for. As stated in Logo Requirement Device.Input.Sensor.Base.SupportDataTypesAndProperties, all built-in reports require SENSOR_DATA_TYPE_TIMESTAMP to be provided in addition to the designated fields. This field reports the time the data was collected in UTC. The Location API supports two built-in reports: LatLongReport and CivicAddressReport. A sensor can support either or both of these reports simultaneously. Important: If a sensor supports both reports, the data reported to each should correspond to the same location. For example, don't report a latitude and longitude that does not match the civic address data.Lattitude/Longitude (lat/long) sensors are required. LatLongReport is required for all location sensors. To support LatLongReport, the following fields are required.

Data field
Data type
Details
SENSOR_DATA_TYPE_LATITUDE_DEGREES
VT_R8
Shows the current latitude in degrees, which must be in the range [-90, +90]
SENSOR_DATA_TYPE_LONGITUDE_DEGREES
VT_R8
Shows the current longitude in degrees, which must be in the range [-180, +180]
SENSOR_DATA_TYPE_ERROR_RADIUS_METERS
VT_R8
The actual latitude and longitude must be within a circle, with this radius (in meters) drawn around the reported (latitude, longitude). Enables the Location API to prioritize sensors; it should be updated dynamically and must be non-zero and positive.

 As part of the LatLongReport, the following fields are optional, but must be reported when available.

Optional Data field
Data type
Details
SENSOR_DATA_TYPE_ALTITUDE_ELLIPSOID_METERS
VT_R8
The altitude with regards to the WGS84 ellipsoid (in meters)
SENSOR_DATA_TYPE_ALTITUDE_ELLIPSOID_ERROR_METERS
VT_R8
The error of the current altitude measurement (in meters)

Important: The Location API supports an additional set of data fields (which correspond to NMEA data fields). For more information, see the Sensors topic in the Device and Driver Technologies section of the WDK.  All CivicAddressReport reports must contain the SENSOR_DATA_TYPE_COUNTRY_REGION property:

Data field
Data type
Details
SENSOR_DATA_TYPE_COUNTRY_REGION
VT_LPWSTR
Shows the ISO 3166 string representation of the country or region where the sensor is located.

 As part of the CivicAddressReport, the following fields are optional, but must be reported when available.

Optional Data field
Data type
Details
SENSOR_DATA_TYPE_ADDRESS1
VT_LPWSTR
Shows the 1st line of the address where the sensor is located.
SENSOR_DATA_TYPE_ADDRESS2
VT_LPWSTR
Shows the 2nd line of the address where the sensor is located.
SENSOR_DATA_TYPE_CITY
VT_LPWSTR
Shows the city where the sensor is located.
SENSOR_DATA_TYPE_STATE_PROVINCE
VT_LPWSTR
Shows the state or province where the sensor is located.
SENSOR_DATA_TYPE_POSTALCODE
VT_LPWSTR
Shows the postal code where the sensor is located.

The requirement below ensures that the driver raises location report events in the correct manner. If the correct behavior is not followed, the Location API will block the sensor, and client applications will not receive data.Generating Sensor Data Reports Device must be able to generate a series of valid ISensorDataReports for one of or both of the two Location Reports types. Each report generated must contain at least the minimum data fields for the report type. The Sensor and Location Platform will rely on data provided to the platform via device drivers that have implemented the Sensor Device Driver Interface. In most cases devices will be verified by using the Sensor and Location Platform.Location sensors must comply with Logo Requirement Requirement-Device.Input.Sensor.Base.SupportDataTypesAndProperties (Sensor and Location Platform devices must properly support the required set of data and properties) in addition to the requirements described here. These requirements are designed to help ensure the following goals are met: Sensor devices have high quality hardware and drivers. Sensor devices interact with the APIs in a consistent and reliable manner.Sensor drivers must monitor connect client count and put their respective device into the lowest power state possible (preferably D3) when connected clients = 0 as illustrated in the HID Sensor Sample in the WDK.Notes about settable properties: The following settable properties must be utilized in the device driver as filtering and power management criteria. Both properties must be tracked on a per-client basis.  The properties are required to be implemented as settable.

Property
Data type
Details
SENSOR_PROPERTY_CURRENT_REPORT_INTERVAL
VT_UI4
From Requirement-Device.Input.Sensor.Base.SupportDataTypesAndProperties - Sets the minimum frequency (in milliseconds) that a client wants to receive data reports from the sensor.
SENSOR_PROPERTY_LOCATION_DESIRED_ACCURACY
VT_UI4
Sets a hint as to how accurate the driver should strive to be. DESIRED_ACCURACY_DEFAULT: The sensor should optimize power and other cost considerations. GPS sensors will not be enumerated by the Location API unless location data is unavailable from other providers on the system or data accuracy is less than 500m.DESIRED_ACCURACY_HIGH: The sensor should deliver the highest accuracy report possible. The Location API will always connect to all location sensors (including GPS) in order to acquire the most accurate position possible.

Additional Information

Business Justification
To ensure the location sensor drivers that receive a logo meet a high quality bar, it is necessary that the requirements include tests for the behavior of the device. The proposed additions ensure that the driver raises location report events in the correct manner. If the correct behavior is not followed, the Location API will block the sensor, and client applications will not receive data.
Enforcement Date
Jun. 01, 2009

Device.Input.Sensor.Presence

Related Requirements
Device.Input.Sensor.Presence.SensorDataType

Device.Input.Sensor.Presence.SensorDataType

Human Presence device drivers shall accurately report the right Data Types for Human Presence as defined for the Sensors and Location Platform

Target Feature
Device.Input.Sensor.Presence
Applies to
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

All human presence class sensors need to ensure that they accurately report the following Data Types to be seamlessly integrated with Windows (through the sensors platform).

Data type
Type
Meaning
SENSOR_DATA_TYPE_HUMAN_PRESENCE
VT_BOOL
Boolean value indicating presence of an object (presumed to be a human). The possible values are: VARIANT_TRUE and VARIANT_FALSE
SENSOR_DATA_TYPE_HUMAN_PROXIMITY_METERS
VT_R8
[Optional]Range value indicating distance of an object (presumed to be a human) from the proximity sensor. Value reported in meters.The value 0.0 meters should only be used for situations where zero-distance events (such as a case closing on tablet) have been detected).

Note: Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED for hardware that is built-in to the PC enclosure. Note that presence sensors with connection type = SENSOR_CONNECTION_TYPE_PC_ATTACHED can also be used for power management features (if integrated into connected peripheral).For detailed information regarding sensor driver development, please see the Sensors topic in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Additional Information

Business Justification
To ensure the human presence sensor reports data in the standardized windows Data Types. If a sensor does not report these data fields, it will not be treated as a human presence sensor and will not be exposed to applications as a human presence sensor.
Enforcement Date
Mar. 01, 2012

Device.Input.SmartCardMiniDriver

MiniDriver program for SmartCards

Related Requirements
Device.Input.SmartCardMiniDriver.DoNotStopWhenResourcesAreUnavailable
Device.Input.SmartCardMiniDriver.SpecsAndCertifications
Device.Input.SmartCardMiniDriver.SupportMultipleInstancesOnASystem

Device.Input.SmartCardMiniDriver.DoNotStopWhenResourcesAreUnavailable

Smart card driver does not stop the system if required resources are not available

Target Feature
Device.Input.SmartCardMiniDriver
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A smart card driver must not interrupt system operation if resources that are required by the reader are not available.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardMiniDriver.SpecsAndCertifications

Windows Smart Card Minidrivers meet Windows Smart Card Minidriver Version 5 Specifications and Certification Criteria

Target Feature
Device.Input.SmartCardMiniDriver
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

Smart Card Minidrivers are pluggable security components that provide an abstraction layer between the base CSP and the smartcard to provide secure storage for cryptographic keys and certificates.Smart Card Minidrivers perform secure cryptographic operations including encryption, decryption, key establishment, key exchange and digital signatures. Smart Card Minidrivers also include other form factors, such as a USB tokens or other personal trusted devices.Smart Card Minidrivers must adhere to the following specifications:

Smart Card Minidriver Specification for Windows Base Cryptographic Service Provider (Base CSP) and Smart Card Key Storage Provider (KSP), Version 5.06 (or later).

Smart Card Minidriver Certification Criteria, Version 5.06 (or later).

Smart Card Minidrivers must adhere to the following basic criteria:

If the device submitted for testing is a smart card and has a ISO 7816 ID-1 smart card form factor, it must be tested with a smart card reader that has passed the WHQL Testing Requirements for smart cards.

If the device is a multi-function device, it must pass the logo requirements for each device category if a Windows certification program exists.

The card minidriver may not implement additional functionality beyond that specified in the Card Minidriver specification.

The card minidriver may not contain any Trojan's or "backdoors".

The card minidriver may not present any UI to the end user.

All cryptographic operations must take place on the device.

All cryptographic keys must be stored on the device and must not be exportable from the device.

Smart Card Minidrivers must adhere to the following general criteria in the Card Minidriver Certification Criteria:

Card Minidriver Management and Installation

Card Minidriver Logical File System Requirements

Card Minidriver General Conventions

Card Minidriver Memory Management

Optional General Requirements

Smart Card Minidriver must adhere to the criteria governing each of the Functional Exports for each function in the Card Minidriver specification, including:

Functionality

Performance

Error Handling

Smart Card Minidrivers must support the sequenced invocation of card minidriver functions.A Smart Card Minidriver may support multiple smart cards, but must pass the certification criteria for each of the supported smart cards separately.Design Notes: See Smart Card Minidriver Specification for Windows Base Cryptographic Service Provider (Base CSP) and Smart Card Key Storage Provider (KSP), Version specifications at https://msdn.microsoft.com/windows/hardware/gg487500.aspx See Smart Card Minidriver Certification Criteria, at https://msdn.microsoft.com/windows/hardware/gg487504.The following table describes the minimum and maximum specification version that must be supported on any given OS family:

Operating system family
Allowed specification versions
Windows 7 client
5,6,7 (any combination allowed such as 5 and 7 only, 5 only, 7 only, 5 and 6 only, 6 and 7 only etc.)
Windows Server 2008
5,6,7 (any combination allowed such as 5 and 7 only, 5 only, 7 only, 5 and 6 only, 6 and 7 only etc.)
Windows 8 client
6,7,8 (any combination allowed such as 6 and 8 only, 6 only, 7 only, 6 and 6 only, 7 and 8 only etc.)
Windows Server v.Next
6,7,8 (any combination allowed such as 6 and 8 only, 6 only, 7 only, 6 and 6 only, 7 and 8 only etc.)

Additional Information

Enforcement Date
Jan. 31, 2008

Device.Input.SmartCardMiniDriver.SupportMultipleInstancesOnASystem

Smart card driver can support multiple instances of the same device on a system

Target Feature
Device.Input.SmartCardMiniDriver
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

The smart card driver must be able to function properly if more than one instance of the devices is installed on a system. Functionality of each device instance must be consistent, loading a separate instance cannot reduce functionality.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader

Related Requirements
Device.Input.SmartCardReader.PinDataEntryKeyboardCompliesWithIso
Device.Input.SmartCardReader.SmartCardService
Device.Input.SmartCardReader.Supports258And259BytePackets
Device.Input.SmartCardReader.SupportsDirectAndInverseConvention
Device.Input.SmartCardReader.SupportsInsertionAndRemovalMonitor
Device.Input.SmartCardReader.SupportsMinClockFrequency
Device.Input.SmartCardReader.SupportsMinDataRateOf9600bps
Device.Input.SmartCardReader.SupportsNegotiableAndSpecificModes
Device.Input.SmartCardReader.SupportsResetCommand
Device.Input.SmartCardReader.UsbCcidCompliesWithUsbDeviceClassSpec
Device.Input.SmartCardReader.UsbCcidIssuesNak

Device.Input.SmartCardReader.PinDataEntryKeyboardCompliesWithIso

Input device that implements a PIN data-entry keyboard complies with ISO

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

An input device that uses a keyboard for PIN entry must comply with ISO 13491-1:1998 Banking--Secure Cryptographic Devices (retail) Part 1: Concepts, Requirements, and Evaluation Methods.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.SmartCardService

Smart Card Service must start after Smart Card inserted into reader

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

The Smart Card Service must be started after a Smart Card is inserted into the Smart Card reader.

Additional Information

Business Justification
This requirement is necessary for reliability of the smart card function.
Enforcement Date
Mar. 01, 2012

Device.Input.SmartCardReader.Supports258And259BytePackets

Reader supports 258-byte packets in T=0 and 259-byte packets in T=1

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A smart card reader must support the exchange of the following in a single transmission:

.258-byte packets in T=0; that is, 256 data bytes plus the two status words SW1 and SW2.

259-byte packets in T=1; that is, 254 information bytes plus node address, packet control bytes, length, and two error detection code bytes.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.SupportsDirectAndInverseConvention

Reader supports direct and inverse-convention smart cards

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A smart card reader must support both direct and inverse-convention smart cards either in hardware or in the operating system driver.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.SupportsInsertionAndRemovalMonitor

Reader supports smart card insertion and removal monitor

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A smart card reader must be able to detect and report smart card insertions and removals with no user intervention other than removing or inserting the smart card itself. The reader must use an interrupt mechanism to report the smart card insertion or removal to the system. A driver polling method to detect smart card insertion and removals is not an acceptable way to meet this requirement.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.SupportsMinClockFrequency

Reader supports 3.5795-MHz minimum clock frequency

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A smart card reader must support a minimum clock frequency of 3.5795 MHz.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.SupportsMinDataRateOf9600bps

Reader supports minimum data rate of 9600 bps

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A smart card reader must be able to transfer data at a rate of 9600 bps or higher.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.SupportsNegotiableAndSpecificModes

Reader supports negotiable and specific modes according to the ISO/IEC specification

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

To support multiple-protocol smart cards and smart cards that use higher data rates and higher clock frequencies, the reader must support negotiable and specific modes according to ISO/IEC 7816-3 (1997-12-15), Sections5.4 and7.The Power Down command for ISO 7816-3 is optional, but the Reset command is required.PTS is not required.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.SupportsResetCommand

Reader supports Reset command

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

A smart card reader must support the asynchronous protocols T=0 and T=1 as described in either the hardware or the driver. Both protocols must be fully supported. The smart card reader and the driver must support cards that can handle both protocols. Support is not required for protocols other than T=0 and T=1.The following protocol rules apply for the T=1 protocol:

A transmission is defined as sending a command to a smart card by using one or more T=1 blocks and receiving the corresponding answer by using one or more T=1 blocks as defined in ISO/IEC 7816-3.

For cards that support IFSC requests, the first transmission after a reset of the smart card must begin with an IFSD request, as defined in ISO/IEC 7816-3, Amendment 1, Section9.5.1.2.

For cards that do not support an IFSD request (that is, the card replies with an R-Block indicating "Other error"), the transmission must continue with an I-Block.

After a successful RESYNCH request, the transmission must restart from the beginning with the first block with which the transmission originally started.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.UsbCcidCompliesWithUsbDeviceClassSpec

USB smart card CCID reader complies with USB Device Class Specification for USB Chip/Smart Card Interface Devices

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

If the reader supports USB connectivity, CCID is required. To ensure that USB smart card readers function properly with the USB host, smart card CCID readers must comply with USB Device Class: Smart Card Specification for Integrated Circuit(s) Cards Interface Devices, Revision1.00 or later.

Additional Information

Enforcement Date
Jun. 01, 2006

Device.Input.SmartCardReader.UsbCcidIssuesNak

USB CCID reader issues NAK on interrupt pipe if device has no interrupt data to transmit

Target Feature
Device.Input.SmartCardReader
Applies to
Windows 7 Client x86, x64
Windows 8 Client x86, x64, ARM (Windows RT)
Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
Windows Server 2012 R2 x64
Windows Server 2008 x86, x64,
Windows Server 2008 Release 2 x64
Windows Server 2012 x64

Description

USB CCIDs must issue NAK on interrupt pipe, unless the state changes. This prevents the necessity of repeatedly polling the device for status.Design Notes: See USB Device Class Specification for USB Chip/Smart Card Interface Devices, Revision1.00 or later, Chapter3. See USB Specification, Revision1.1 or later, Sections 5.7.4 and 8.5.4.

Additional Information

Enforcement Date
Jun. 01, 2006