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
- 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 |