Microsoft Confidential For: Connect User Hardware – Windows Engineering Guide for X86-Based Platforms

Hardware – Windows Engineering Guide for x86-based Platforms

Microsoft Corporation August, 2013

Abstract The Hardware Windows Engineering Guide provides a roadmap to follow through the hardware component sourcing and selection process.

Version: 1.2

Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Microsoft Confidential. © 2013 Microsoft Corporation. All rights reserved. These materials are confidential to and maintained as a trade secret by Microsoft Corporation. Information in these materials is restricted to Microsoft authorized recipients only. Any use, distribution or public discussion of, and any feedback to, these materials are subject to the terms of the attached license. By providing any feedback on these materials to Microsoft, you agree to the terms of that license.

Microsoft Corporation Technical Documentation License Agreement (Standard)

READ THIS! THIS IS A LEGAL AGREEMENT BETWEEN MICROSOFT CORPORATION ("MICROSOFT") AND THE RECIPIENT OF THESE MATERIALS, WHETHER AN INDIVIDUAL OR AN ENTITY ("YOU"). IF YOU HAVE ACCESSED THIS AGREEMENT IN THE PROCESS OF DOWNLOADING MATERIALS ("MATERIALS") FROM A MICROSOFT WEB SITE, BY CLICKING "I ACCEPT", DOWNLOADING, USING OR PROVIDING FEEDBACK ON THE MATERIALS, YOU AGREE TO THESE TERMS. IF THIS AGREEMENT IS ATTACHED TO MATERIALS, BY ACCESSING, USING OR PROVIDING FEEDBACK ON THE ATTACHED MATERIALS, YOU AGREE TO THESE TERMS.

1. For good and valuable consideration, the receipt and sufficiency of which are acknowledged, You and Microsoft agree as follows:

(a) If You are an authorized representative of the corporation or other entity designated below ("Company"), and such Company has executed a Microsoft Corporation Non-Disclosure Agreement that is not limited to a specific subject matter or event ("Microsoft NDA"), You represent that You have authority to act on behalf of Company and agree that the Confidential Information, as defined in the Microsoft NDA, is subject to the terms and conditions of the Microsoft NDA and that Company will treat the Confidential Information accordingly;

(b) If You are an individual, and have executed a Microsoft NDA, You agree that the Confidential Information, as defined in the Microsoft NDA, is subject to the terms and conditions of the Microsoft NDA and that You will treat the Confidential Information accordingly; or

(c)If a Microsoft NDA has not been executed, You (if You are an individual), or Company (if You are an authorized representative of Company), as applicable, agrees: (a) to refrain from disclosing or distributing the Confidential Information to any third party for five (5) years from the date of disclosure of the Confidential Information by Microsoft to Company/You; (b) to refrain from reproducing or summarizing the Confidential Information; and (c) to take reasonable security precautions, at least as great as the precautions it takes to protect its own confidential information, but no less than reasonable care, to keep confidential the Confidential Information. You/Company, however, may disclose Confidential Information in accordance with a judicial or other governmental order, provided You/Company either (i) gives Microsoft reasonable notice prior to such disclosure and to allow Microsoft a reasonable opportunity to seek a protective order or equivalent, or (ii) obtains written assurance from the

2 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

applicable judicial or governmental entity that it will afford the Confidential Information the highest level of protection afforded under applicable law or regulation. Confidential Information shall not include any information, however designated, that: (i) is or subsequently becomes publicly available without Your/Company's breach of any obligation owed to Microsoft; (ii) became known to You/Company prior to Microsoft's disclosure of such information to You/Company pursuant to the terms of this Agreement; (iii) became known to You/Company from a source other than Microsoft other than by the breach of an obligation of confidentiality owed to Microsoft; or (iv) is independently developed by You/Company. For purposes of this paragraph, "Confidential Information" means nonpublic information that Microsoft designates as being confidential or which, under the circumstances surrounding disclosure ought to be treated as confidential by Recipient. "Confidential Information" includes, without limitation, information in tangible or intangible form relating to and/or including released or unreleased Microsoft software or hardware products, the marketing or promotion of any Microsoft product, Microsoft's business policies or practices, and information received from others that Microsoft is obligated to treat as confidential.

2. You may review these Materials only (a) as a reference to assist You in planning and designing Your product, service or technology ("Product") to interface with a Microsoft Product as described in these Materials; and (b) to provide feedback on these Materials to Microsoft. All other rights are retained by Microsoft; this agreement does not give You rights under any Microsoft patents. You may not (i) duplicate any part of these Materials, (ii) remove this agreement or any notices from these Materials, or (iii) give any part of these Materials, or assign or otherwise provide Your rights under this agreement, to anyone else.

3. These Materials may contain preliminary information or inaccuracies, and Microsoft may make changes to the information contained herein. These Materials may not correctly represent any associated Microsoft Product as commercially released. All Materials are provided entirely "AS IS." To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.

4. If You are an entity and (a) merge into another entity or (b) a controlling ownership interest in You changes, Your right to use these Materials automatically terminates and You must destroy them.

5. You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to these Materials. However, any Feedback you voluntarily provide may be used in Microsoft Products and related specifications or other documentation (collectively, "Microsoft Offerings") which in turn may be relied upon by other third parties to develop their own Products. Accordingly, if You do give Microsoft Feedback on any version of these Materials or the Microsoft Offerings to which they apply, You agree: (a) Microsoft may freely use, reproduce, license, distribute, and otherwise commercialize Your Feedback in any Microsoft Offering; (b) You also grant third parties, without charge, only those patent rights necessary to enable other Products to use or interface with any specific parts of a Microsoft Product that incorporate Your Feedback; and (c)

3 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

You will not give Microsoft any Feedback (i) that You have reason to believe is subject to any patent, copyright or other intellectual property claim or right of any third party; or (ii) subject to license terms which seek to require any Microsoft Offering incorporating or derived from such Feedback, or other Microsoft intellectual property, to be licensed to or otherwise shared with any third party.

6. Microsoft has no obligation to maintain confidentiality of any Microsoft Offering, but otherwise the confidentiality of Your Feedback, including Your identity as the source of such Feedback, is governed by Your NDA.

7. This agreement is governed by the laws of the State of Washington. Any dispute involving it must be brought in the federal or state superior courts located in King County, Washington, and You waive any defenses allowing the dispute to be litigated elsewhere. If there is litigation, the losing party must pay the other party's reasonable attorneys' fees, costs and other expenses. If any part of this agreement is unenforceable, it will be considered modified to the extent necessary to make it enforceable, and the remainder shall continue in effect. This agreement is the entire agreement between You and Microsoft concerning these Materials; it may be changed only by a written document signed by both You and Microsoft.

4 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Contents

Introduction ...... 12 About this guide ...... 12 Document updates ...... 13 Choosing a customer segment ...... 14 Choosing a form factor ...... 17 Tablet or convertible ...... 17 Clamshell ...... 20 All-In-One ...... 23 Desktop ...... 26 Building a device with fast startup and shutdown ...... 28 Considerations ...... 28 Firmware ...... 29 Recommended goals ...... 29 SMBIOS 31 Boot Firmware ...... 31 Runtime Firmware ...... 32 Processor ...... 36 Tools and technical reference ...... 36 Solid-State Hybrid Drives (SSHD) ...... 38 Industry Specification AND Windows Hardware Certification Kit (WHCK) ...... 38 WHCK Performance AND Size Requirements ...... 38 SSHD IMPLEMENTATION CONSIDERATIONS...... 39 DRIVER 39 Building a device with a great Windows experience ...... 46 Core System Resources ...... 46 Recommended goals and requirements ...... 47 Out-of-box Extensions (not shipped with Windows) ...... 48

5 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Time of day ...... 48 Security 50 Secure Boot ...... 51 Hardware Security Interface ...... 51 Measured Boot ...... 52 Data Protection (BitLocker) ...... 53 Fingerprint Reader ...... 55 Tools and technical reference ...... 57 Building a great device for browsing ...... 57 Building a great media device...... 57 Graphics Processing Unit (GPU) ...... 57 Windows display Driver model (WDDM) Version ...... 57 DirectX "Feature Level" ...... 58 Multiple GPUs ...... 58 Hybrid Graphics ...... 58 Efficient presentation for redirected bit blt model ...... 64 Efficient presentation for redirected flip model ...... 65 Multimedia ...... 67 Image Capture ...... 95 Building a great device for apps ...... 102 Considerations ...... 103 Random Access Memory (RAM) ...... 103 Tools and technical reference ...... 103 Building a device with great human factors ...... 103 Human Interface Devices ...... 103 Buttons 104 Charms and Hotkeys ...... 106 Keyboard and Pointing Device ...... Error! Bookmark not defined. PRECISION Touchpad ...... Error! Bookmark not defined.

6 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Precision Touchpad ...... Error! Bookmark not defined. DEVICE BUS CONNECTIVITY ...... Error! Bookmark not defined. I2C Devices ...... Error! Bookmark not defined. USB Devices ...... Error! Bookmark not defined. PROTOCOL IMPLEMENTATION ...... Error! Bookmark not defined. REQUIRED HID DESCRIPTORS ...... Error! Bookmark not defined. Touch Error! Bookmark not defined. Overview Error! Bookmark not defined. TOUCH INTERACTION PRINCIPLES ...... Error! Bookmark not defined. GESTURES ...... Error! Bookmark not defined. User experience ...... Error! Bookmark not defined. MANIPULATIONS ...... Error! Bookmark not defined. PALM DETECTION ...... Error! Bookmark not defined. TECHNICAL DETAILS ...... Error! Bookmark not defined. Idle State Error! Bookmark not defined. COVER GLASS CONSIDERATIONS ...... Error! Bookmark not defined. FIRMWARE ...... Error! Bookmark not defined. HARDWARE ...... Error! Bookmark not defined. RELATED CONTENT ...... Error! Bookmark not defined. Pen 109 PEN Behaviors ...... 222 PALM DETECTION ...... 223 PEN BUTTON AND ERASER ...... 223 Pen Button ...... 224 Eraser 224 HARDWARE ...... 224 VALIDATION SCENARIO ...... 227 Inking/Drawing ...... 227 Multi Modal ...... 227

7 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Edge 227 Start Screen ...... 228 Other Navigation ...... 228 Appendix ...... 229 Hardware configurations ...... 229 Detection Range ...... 230 HEAT Management ...... 230 Defining a “Good” THERMAL SOLUTION ...... 231 Thermal Management GUIDELINES ...... 232 Thermal User Experience ...... 232 Thermal Management Requirements Checklist ...... 235 Thermal Management Solutions ...... 236 Building a great device for networking and devices ...... 238 Storage and Boot Sources ...... 247 SD/eMMC Host Controllers ...... 248 Serial-ATA Storage ...... 260 Non-Volatile Memory Express (NVMe) ...... 262 Industry Specification & Windows Hardware Certification Kit (WHCK) ...... 262 NVMe Drivers for Windows ...... 262 StorNVMe Functionality ...... 263 NVME IMPLEMENTATION CONSIDERATIONS ...... 263 Device Drivers Best Practices ...... Error! Bookmark not defined. Driver Availability on Windows Update ...... Error! Bookmark not defined. Related resources – General Drivers ...... Error! Bookmark not defined. Related resources – Print Drivers ...... Error! Bookmark not defined. Networking ...... 264 Windows Networking Infrastructure ...... 264 Bluetooth 265 Ethernet 265

8 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Mobile Broadband (MB) ...... 273 Near Field Proximity ...... 278 Wireless LAN ...... 281 Radio Management ...... 284 Performance ...... 285 Sensors 285 Accelerometer ...... Error! Bookmark not defined. Ambient Light Sensor ...... Error! Bookmark not defined. Magnetometer ...... Error! Bookmark not defined. Gyroscope Error! Bookmark not defined. Fusion sensors ...... Error! Bookmark not defined. Fingerprint Reader ...... Error! Bookmark not defined. Inclinometer...... Error! Bookmark not defined. Orientation Sensor ...... Error! Bookmark not defined. SimpleOrientation Sensor ...... Error! Bookmark not defined. Expansion Ports ...... 285 Universal Serial Bus (USB) ...... 300 Peripheral Component Interface Express (PCIe)...... 307 Simple Peripheral BUS (SPB) ...... Error! Bookmark not defined. General-Purpose Input/output (GPIO) ...... 314 WINDOWS GPIO support ...... 314 GPIO Hardware ...... 315 Firmware 315 GPIO Driver ...... 316 Building an energy efficient device ...... 316 How to build a great connected standby PC ...... 319 Considerations ...... 320 Recommended goals ...... 321 Related resources ...... 322

9 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Form Factor Considerations ...... 322 Energy EfficIency ...... 379 Energy Efficiency Architecture in Windows ...... 380 Processor Power Management...... 381 Device Power Management...... 382 Battery and Charging Subsystems ...... 384 Display Brightness and Dimming Control ...... 414 Building, manufacturing, and deploying a great device ...... Error! Bookmark not defined. Keyboard Availability indicators ...... Error! Bookmark not defined. Introduction ...... Error! Bookmark not defined. General considerations ...... Error! Bookmark not defined. indicator updates: Timing and performance ...... Error! Bookmark not defined. considerations for convertibles ...... Error! Bookmark not defined. Phisical buttons ...... Error! Bookmark not defined. Interface implementation guidance ...... Error! Bookmark not defined. Code samples ...... Error! Bookmark not defined. Logging and investigations ...... Error! Bookmark not defined. Executing test passes ...... Error! Bookmark not defined. Refrences Error! Bookmark not defined. Status indicators ...... Error! Bookmark not defined. Display 238 Device Cover Glass ...... 240 Related resources ...... Error! Bookmark not defined. Debugging Infrastructure ...... 416 Hardware Debugging Transports ...... 416 Additional Requirements ...... 416 Related resources ...... 417 Firmware ...... 418 Related resources ...... 418

10 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Glossary ...... 419

11 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

INTRODUCTION

Building a great Windows device starts with selecting the right hardware. This guide will help you select components for your device that not only meet requirements for running Windows 8.1, but help to provide a great user experience. We’ve reviewed our user research, selected key scenarios that have a big impact on customer ratings, and provided guidelines to help you optimize and enhance these experiences. These guidelines will help you deliver a fast, responsive, secure, and connected device to meet the high expectations of today’s consumers.

Each of the Windows Engineering Guides provides additional information that can help your team explore these scenarios and the overall greatness of your Windows devices. For an overall look at delivering great Windows devices, see the User Experience Windows Engineering Guide.

ABOUT THIS GUIDE

This document is intended for hardware, mechanical, firmware, and software engineers to let them to make full use of Windows features.

This document describes the hardware, firmware, driver, and software for Connected Standby and traditional x86- based PCs running the next version of Windows. This document contains updates for both consumer and commercial recommendations.

This document is for technology enablement purposes only, and does not address business and marketing related topics.

In this document, PC and device refers to the complete firmware and hardware platform with drivers, running the complete and legally licensed version of the next version of Windows sold to the end user. The scope of this document includes the functional components internal and external to the System on Chip (SoC) or core logic inside the device enclosure.

12 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Note: This document is not intended to communicate the Windows logo requirements. This document does not supersede the Windows logo requirements. So if you find guidance information here that is lower than what is documented in the Windows logo requirements document, you must comply with the Windows logo requirement.

We are sharing this document under NDA (Non-Disclosure Agreement), and we ask that you keep it confidential within your organization.

DOCUMENT UPDATES

Version .3 1. First Draft of WEG for the next version of Windows 2. Updated Touch & Pen sections a. Greater details on building a great touch solution. Expectations b. Updated expectations and details on Pen on Windows. 3. Deleted Modern Touch, added Precision Touch Pad a. Precision Touch Pad completely new for Windows 8.1 b. Modern Touch Removed 4. Updated Radios/Communications section 5. Updated Storage and added NVME a. Adding support for NVMe b. Adding support for Hybrid Hard Drives using Superfetch 6. Updated Connected Standby a. Updated information on Connected Standby for x86 systems running 64bit Windows 7. Updated Ethernet 8. Updated Graphics 9. Updated Sensors 10. Updated Fingerprint Readers a. In box Fingerprint Reader support through the Windows Biometric Framework. 11. Updated Audio 12. Updated Cameras 13. Updated Human Interface Devices (HIDs) a. Added Consumer Charms Hotkeys section with corresponding table. b. Added additional buttons with corresponding table.

13 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Version .4 1. Updated Charms 2. Updated Hotkeys 3. Overall (complete) document update to reflect latest HW developments

The structure of this document has been updated. Hardware component goals and considerations are provided for Version 1.1 each of the key user experiences listed in the UX WEG. You can find additional guidance for each of these experience in the Performance, User Experience, and Apps and Store WEG documents. For more information about these scenarios, see the UX Windows Engineering Guide. The following sections have been updated or added in this version:

 USB connectivity  Simple Peripheral Bus  S3/S4  Bluetooth Updates  PTP update  Touch Update  48Hz with added notes on NV QC  Screen rotation update (soft keyboard)  Sensors Update  PTP  Pen  Touch

The following sections have been updated to include recommendation checklists:

1. Building a device with fast startup and shutdown: Firmware 2. Building an energy efficient device: Connected standby 3. Building a device with a great Windows experience: Core system resources

Version 1.2

CHOOSING A CUSTOMER SEGMENT

14 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

You may want to design your Windows device to meet the demands of a specific market. As you review the guidelines in this document, consider the customer segment you want to target in order to prioritize enhancements to your device and select the best hardware to support your user scenarios.

The chart below represents the spectrum of device usage in the consumer and commercial PC segments.

The following table represents a more in-depth view of the commercial segment needs and some of the considerations for prioritizing hardware enhancements for each segment.

15 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

16 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

CHOOSING A FORM FACTOR

Depending on the form factor you choose, there are different requirements for running Windows on the device. Below are the minimum hardware requirements to start with for each type of Windows device you may want to deliver.

TABLET OR CONVERTIBLE

A tablet is a standalone device that combines the PC, display, and rechargeable power source in a single chassis. A tablet doesn't include a permanently attached keyboard and pointing device, but can be connected to a keyboard, port replicator, or dock.

A convertible is a standalone device that combines the PC, display, and rechargeable power source with a mechanically attached keyboard and optional pointing device in a single chassis. A convertible can be transformed into a tablet by hiding or removing the attached input devices, leaving the display as the only input mechanism.

Component Connected Standby Traditional Remarks Firmware Boot UEFI 2.3.1 Runtime ACPI Number of cores Two Display Size >=7" Resolution >=1024x768 Aspect Ratio 4:3, 16:10, 16:9 GPU DX compatibility DX9_3 DX10 Driver Model WDDM 1.2 RAM Size 2 GB 2-4 GB Type Mobile Low Power, DDR3, DDR3L LPDDR2, LPDDR3, DDR3L- RS, etc. Touch Type Projective Capacitive Touch Points >=5 Reporting Rate 100Hz Busses I2C USB

17 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Mouse and Type Wired, Wireless Externally connected accessory keyboard Busses BT (HID), USB(HID) Storage and Interface Type eMMC SATA AHCI 1.1, 1.2 Raw NAND and eSATA are not boot sources supported. Capacity >=32 GB Sensors Type Accelerometer Bus I2C USB Type Ambient Light Sensor Bus I2C USB Type Compass Bus I2C USB Type GNSS Bus I2C or UART USB Type Gyro Bus I2C USB Wireless LAN Type Wi-Fi 802.11n Busses SDIO PCI-e Mobile Type >=3G Broadband Busses USB-HSIC if surface USB-HSIC if surface mounted mounted USB, PCI-e if connector based USB if connector based Near Field Type NFC Proximity Busses I2C, SPI, UART USB Bridging from USB to UART on NFC is typical and recommended for traditional PCs. In some cases, the NFC device may be attached via a connector that is abstracted from the operating system. Bluetooth Version 4.0+LE Busses UART (H4) USB is supported but not recommended. Non-USB/Non-UART (H4) is also supported with vendor-supplied driver. Expansion USB USB (XHCI, EHCI) port also support ports debug Audio Audio Quality THD+N <= 0.05% Dynamic range >= 80 dB

18 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Magnitude response within 0.25 dB of unity from 20Hz to 20kHz Hardware MP3, AAC, WMA Decoders Audio Proc. Driver Sample Rate Conversion Driver Interface PortCls WaveRT that exposes the underlying hardware capabilities to the audio stack Video Hardware H.264 - Baseline, main and high profile. Up to level 4.2 Decoders VC-1 WMV MPEG2/ MPEG1 – Simple, main and high profile. Low, main and high levels. MPEG4, part2 (DIVX) Hardware decoder for format captured by camera. Hardware H.264 – Baseline, constrained Baseline and Main profiles. Encoders Capable of real-time encoding 1920x1080 @ 30 FPS up to 12 Mbps bitrate. Capable of real-time encoding 1280x720 @ 30 FPS up to 5 Mbps bitrate while concurrently decoding 1280x720 @ 30 FPS H.264 using DXVA offload. VC1- Simple, Main, and Advanced profiles. Capable of real-time encoding 720x480 @ 30FPS up to 5 Mbps bitrate. VC1 encoder must be capable of real-time encoding 720x480x30fps up to 5 Mbps while concurrently decoding 720x480x30fps VC1 using DXVA offload. MPEG2 – Simple, Main, and high profile. Capable of real-time encoding 720x480 @ 30 FPS up to 5 Mbps bitrate. Video Proc. Driver Resizer, Color Space Converter, Deinterlacing SubPicture alpha blending Driver Interface AVStream, Hardware MFT or DXVA. Driver depends on video decode, encode or capture. Image/Video Location Rear and front facing capture Resolution >=720P (Front Facing) Resolution >=720P (video) (Rear Facing) >=5 MP (still) Busses MIPI-CSI or I2C MIPI or USB Video out Type HDMI, DisplayPort Battery Capacity >=30Wh >=50Wh

19 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

LAPTOP

A laptop (or clamshell) is a standalone device that combines the PC, display, and rechargeable power source with a permanently attached keyboard and pointing device in a single chassis. Unlike a convertible, a clamshell can't be transformed into a tablet where the attached input devices are hidden or removed.

Component Connected Standby Traditional Remarks Firmware Boot UEFI 2.3.1 Runtime ACPI CPU Number of cores Two or more Display Size >=10.1" Resolution >=1366x768 GPU DX compatibility DX9_3 DX11 Driver Model WDDM 1.2 RAM Size 2 GB 2-4 GB Type Mobile Low Power, DDR3, DDR3L LPDDR2, etc. Multi-Touch Type Projective Capacitive Touch Points >=5 Reporting Rate 100Hz Busses I2C USB Mouse and Type Wired Keyboard Busses I2C (HID), USB(HID) USB (HID) Storage and Interface Type eMMC SATA AHCI 1.1, 1.2 Raw NAND and eSATA are not Boot Sources supported to boot Windows Disk Capacity >=32 GB Optical Drive Type DVD RW, Blu-ray Sensors Type Accelerometer SPI and UART also supported Bus I2C USB Type Ambient Light Sensor Bus I2C USB SPI and UART also supported Type GNSS Bus I2C or UART USB Wireless LAN Type Wi-Fi 802.11n Busses SDIO USB or PCI-e Mobile Type >=3G

20 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Broadband Busses USB-HSIC if surface USB or Mini-PCI USB and SPI are supported. mounted MIPI-HSI is not supported. USB if connector based Near Field Type NFC Proximity Busses I2C, SPI, UART USB Bridging from USB to UART on NFC is typical and recommended for traditional PCs. In some cases, the NFC device may be attached via a connector that is abstracted from the operating system. Bluetooth Version 4.0+LE Busses UART (H4) UART (H4) or USB USB is supported but not recommended. Non-USB/Non-UART (H4) is also supported with vendor-supplied driver.

Expansion USB USB or PCI-e USB (XHCI, EHCI) port must also Ports support debug Audio Audio Quality THD+N <= 0.05% Dynamic range >= 80 dB Magnitude response within 0.25 dB of unity from 20Hz to 20kHz Hardware MP3, AAC, WMA Decoders

21 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

MPEG2 – Simple, Main, and high profile. Capable of real-time encoding 720x480 @ 30 FPS up to 5 Mbps bitrate. Video Proc. Driver Resizer, Color Space Converter, Deinterlacing SubPicture alpha blending Driver Interface AVStream, Hardware MFT or DXVA. Driver depends on video decode, encode or capture. Image/Video Location Front facing Capture Resolution >=720P (video) >=2 MP (still) Busses MIPI-CSI or I2C MIPI-CSI or USB MIPI requires a WDF third party driver Video Out Type HDMI, DisplayPort HDMI, VGA, DisplayPort Battery Capacity >=40Wh >=50Wh

22 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

ALL-IN-ONE

An all-in-one is a desktop device that combines the PC and display in a single chassis but doesn't include a permanently attached keyboard and pointing device.

Component Connected Standby Traditional Remarks Firmware Boot UEFI 2.3.1 Runtime ACPI CPU Number of cores Two or more Display Size >=15" >=17" Resolution >=1366x768 GPU DX compatibility DX9_3 DX11 Driver Model WDDM 1.2 RAM Size 2 GB >=4 GB Type Mobile Low Power, DDR3 LPDDR2, etc. Touch Type Projective Capacitive Touch Points >=5 Reporting Rate 100Hz Busses I2C USB Mouse and Type Wired, Wireless keyboard Busses BT (HID), USB(HID), I2C BT (HID), USB(HID) (HID) Storage and Interface Type eMMC SATA AHCI 1.1, 1.2 Raw NAND and eSATA are not boot sources supported. Disk Capacity >=32 GB >=64 GB Optical Drive Type Blu-ray Sensors

Type Ambient Light Sensor Bus I2C USB SPI and UART also supported Wireless LAN Type Wi-Fi 802.11n Busses SDIO USB or PCI-e Near Field Type NFC Proximity Busses I2C, SPI, UART USB Bridging from USB to UART on NFC is typical and recommended for traditional PCs. In some cases, the NFC

23 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

device may be attached via a connector that is abstracted from the operating system. Bluetooth Version 4.0+LE Busses UART (H4) UART (H4) or USB USB is supported on Connected Standby but not recommended. Non-USB/Non-UART (H4) is also supported with vendor-supplied driver on Connected Standby and Traditional. Expansion USB USB or PCI-e USB (XHCI, EHCI) port also support ports debug Audio Audio Quality THD+N <= 0.05% Dynamic range >= 80 dB Magnitude response within 0.25 dB of unity from 20Hz to 20kHz Hardware MP3, AAC, WMA Decoders

Audio Proc. Driver Sample Rate Conversion Driver Interface PortCls WaveRT that exposes the underlying hardware capabilities to the audio stack Video Hardware H.264 - Baseline, main and high profile. Up to level 4.2 Decoders VC-1 WMV MPEG2/ MPEG1 – Simple, main and high profile. Low, main and high levels. MPEG4, part2 (DIVX) Hardware decoder for format captured by camera. Hardware H.264 – Baseline, constrained Baseline and Main profiles. Encoders Capable of real-time encoding 1920x1080 @ 30 FPS up to 12 Mbps bitrate. VC1- Simple, Main, and Advanced profiles. Capable of real-time encoding 720x480 @ 30FPS up to 5 Mbps bitrate. MPEG2 – Simple, Main, and high profile. Capable of real- time encoding 720x480 @ 30 FPS up to 5 Mbps bitrate. Video Proc. Driver Resizer, Color Space Converter, Deinterlacing SubPicture alpha blending Driver Interface AVStream, Hardware MFT or DXVA. Driver depends on video decode, encode or capture.

24 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Image/Video Location Front facing capture Resolution >=720P (video)

Busses USB

25 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

DESKTOP Component Traditional Remarks Firmware Boot UEFI 2.3.1 Runtime ACPI CPU Number of cores Two or more GPU DX compatibility DX11 Driver Model WDDM 1.2 RAM Size >=4 GB Type DDR3 Mouse and Type Wired, Wireless Keyboard Busses BT (HID), USB(HID), I2C (HID) Storage and Boot Interface Type SATA AHCI 1.1, 1.2 Raw NAND and eSATA are not supported to Sources boot Windows Disk Capacity >=32 GB Optical Drive Type Blu-ray

Wireless LAN Type Wi-Fi 802.11n Busses USB or PCI-e USB is supported but not recommended. Near Field Type NFC Proximity Busses ,USB Bridging from USB to UART on NFC is typical and recommended for traditional PCs. In some cases, the NFC device may be attached via a connector that is abstracted from the operating system. Bluetooth Version 4.0+LE Busses UART (H4) or USB Non-USB/Non-UART (H4) is also supported with vendor-supplied driver. Expansion Ports USB or PCI-e USB (XHCI, EHCI) port also support debug Audio Audio Quality THD+N <= 0.05% Dynamic range >= 80 dB Magnitude response within 0.25 dB of unity from 20Hz to 20kHz Hardware Decoders MP3, AAC, WMA Audio Proc. Driver Sample Rate Conversion Driver Interface PortCls WaveRT that exposes the underlying hardware capabilities to the audio stack

26 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Video Hardware Decoders H.264 - Baseline, main and high profile. Up to level 4.2 VC-1 WMV MPEG2/ MPEG1 – Simple, main and high profile. Low, main and high levels. MPEG4, part2 (DIVX) Hardware decoder for format captured by camera. Hardware Encoders H.264 – Baseline, constrained Baseline and Main profiles. Capable of real-time encoding 1920x1080 @ 30 FPS up to 12 Mbps bitrate. VC1- Simple, Main, and Advanced profiles. Capable of real-time encoding 720x480 @ 30FPS up to 5 Mbps bitrate. MPEG2 – Simple, Main, and high profile. Capable of real-time encoding 720x480 @ 30 FPS up to 5 Mbps bitrate. Video Proc. Driver Resizer, Color Space Converter, Deinterlacing SubPicture alpha blending Driver Interface AVStream, Hardware MFT or DXVA. Driver depends on video decode, encode or capture. Video Capture Location Front facing Resolution >=720P (video) Busses USB Video Out Type HDMI, VGA, DisplayPort

27 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

BUILDING A DEVICE WITH FAST STARTUP AND SHUTDOWN

Performance is one of the most important factors in overall customer ratings according to our research. To quantify performance, reviewers use startup time as a key indicator to help them evaluate how well a device performs and therefor how good a device is.

Startup is a big part of the user experience. It is the first experience users have with their device and is a recurrent experience for the lifetime of the device. Devices are turned on and off many times a day. Customer telemetry tells us that users boot and shut down their Windows device at least once a day.

A Windows device should start up in less than 10 seconds. Similarly, a Windows device in low power mode (Sleep or AOAC) should wake up instantly, as soon as it’s grabbed.

Selecting the right hardware and firmware to support it is the first step in delivering a high-performing device that customers can start up quickly.

CONSIDERATIONS

Firmware

The firmware in your device will not only affect the startup and shutdown scenario, but many other aspects of performance as well. You should configure your firmware to support specific hardware and firmware features, set the platform to a well-defined state before launching any boot apps, and protect against direct memory access.

You can also populate the SKU field in the system management bios (SMBIOS) table with a unique value. Microsoft uses this value in our telemetry system as one of the variables for generating reports for our partners. Using this field provides the following benefits:

 Qualifying for the Windows System certification  Providing a key identifier to provide useful telemetry data for the machine model(s)

28 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Providing the ability to accomplish precise system targeting  Linking to the OA3.0 Optional SKU field for matching activation components  Improving integrity of telemetry data on specific system models

Connected standby

If you are designing a connected standby device, a fast startup is key. For more information about hardware recommendations for a connected standby device, see How to build an energy efficient device.

FIRMWARE

RECOMMENDED GOALS

Both connected standby and traditional platforms must support all firmware and hardware features listed below. For additional information, see the Windows Hardware Certification Requirements.

Setting Goal Notes Boot Class 3 or Class Disabled 2 with CSM

Booting Windows Enabled Preinstallation Environment from a USB flash device

Variable services Dedicated* Time services Real-time clock hardware For example, a time source.

29 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

SMBIOS: SKU A unique identifying value This value can consist of any combination of alphanumeric digits up to 64 characters in length. This value can include distinct product, region or locale-based information. This data could then be further parsed based on your company's internal product data infrastructure. SMBIOS: Processor ID A user-friendly name The string should include the processor vendor name, processor model name, and processor core type (such as dual or quad). Boot settings RAS/CAS SDRAM timings SoC pin MUX state and pad configurations Initial clock and power domain configuration for:  Boot device path  Base processor core  Any Core System Resources exposed to Windows through ACPI  Debug port  Secure (measured boot), including authenticationof the Boot Manager

Direct Memory Protect physical memory from all external ports For more information, see the Access protection capable of direct memory access (DMA) until the Security section of this document. operating system powers up DMA ports through related bridge controllers.

30 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

*Variable services requires dedicated storage for the variables used by the operating system. Windows must not access this storage. For platforms where eMMC is the only storage, the firmware caches variables in DRAM or other platform-specific memory until control of the storage is passed to the firmware. Specifically, the firmware will flush variables to the eMMC storage:

 During boot (prior to Windows calling ExitBootServices)  At reset or shutdown (during a Windows call to ResetSystem)  During low-power system transition in which the firmware gains control of the hardware.

SMBIOS

We do not parse this to get at encoded values but treat it as a single entity.

The Processor Vendor string at offset 10H in the SMBIOS Type 4 structure must be filled in with a friendly name since it is exposed to users.

BOOT FIRMWARE

The Unified Extensible Firmware Interface (UEFI) provides the separation and programming contract between Windows and the underlying hardware platform for bootstrapping Windows.

The following table summarizes the UEFI implementation that Windows uses to boot. Core firmware, UEFI Device Drivers, or factory-floor tools and tests may also need other functions and services.

31 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Elements EFI_SYSTEM_TABLE Support

EFI_CONFIGURATION_TABLE ACPI RSDP and SMBIOS Entry Point

EFI_BOOT_SERVICES Some Memory, Protocol Handler, Image and Miscellaneous Services

Boot Manager Include

Secure Boot Include

EFI_RUNTIME_SERVICES Variable Services and Time Services and ResetSystem

EFI_DEVICE_PATH_PROTOCOL Include

EFI_BLOCK_IO_PROTOCOL Include

EFI_GRAPHICS_OUTPUT_PROTOCOL Include

EFI_SIMPLE_TEXT_INPUT_PROTOCOL Include

EFI_STORAGE_SECURITY_PROTOCOL Include if Encrypted Drive is implemented (UEFI 2.3.1, section 12.12)

RUNTIME FIRMWARE

There is no standard system bus for enumeration on some platforms. The Advanced Configuration and Power Interface (ACPI) standard is the virtual primary system bus through which devices on the system are enumerated and their resource use (configuration) determined. Some of the information in this document is not yet part of the ACPI standard. After reviewing feedback from early implementers, we will propose specific changes to the ACPI SIG (http://acpi.info/) for inclusion in the ACPI 5.0 specification.

ACPI defines the following:

32 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Fixed hardware interface. (Optional on target platforms.)  Table-passing mechanism and defined tables for describing the platform hardware.

ACPI classes of tables:

 Statically-loadable tables that describe directly only the hardware necessary for Windows initialization (for example, processors and core system resources).  Static or dynamically-loadable tables that describe the SoC's functional blocks and platform peripherals visible from within Windows using a defined software abstraction called the ACPI Namespace.  An operating system-independent language and operating system-independent execution environment for implementation of the ACPI Namespace. The OS uses the ACPI Namespace to enumerate functional blocks and devices, load the correct device drivers, start and stop them in the proper order, and sequence power operations among layered drivers in the same device stack, which is necessary on target platforms.  The ACPI Namespace itself models the platform hardware topology accurately. The Namespace contains standard objects defined for typical platform functions (for example, enumeration and signaling platform events), and also contains custom objects created by implementers. The ACPI Source Language (ASL) that creates the Namespace is extremely flexible, allowing simple data exchange between the platform and Windows, basic logical and functional programming, and I/O on the platform for low-level control operations.  Pre-defined device objects ("ACPI-defined Devices") for typical platform functions including buttons, batteries, or thermal zones.

The table below lists the ACPI elements.

ACPI 4.0a Section Features Notes

33 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

System 5.2.5 RSDP Accessible through the UEFI Description Configuration Table, per UEFI Table Specification 5.2.7, 5.2.8 Either of RSDT or XSDT preferred XSDT 5.2.9, with changes FADT PCs that support Connected Standby must for ACPI 5.0 provide Revision 5 of the table 5.2.12 with changes Support for Standard for ACPI 5.0 Interrupt Controller in the Multiple APIC Description Table (MADT) None Core System Required on platforms that implement non- Resources Table standard Timers, Interrupt controllers or (CSRT) DMA controllers None Debug Port Table Required on all platforms (DBGP) Platforms with non-standard Debug ports must provide Revision 3 of the table 5.2.11 Differentiated System All devices supported by Windows drivers Description Table must appear in the DSDT (DSDT) Device 6.1 with changes for _HID or _ADR One of these two identification methods is Management ACPI 5.0 required for every device in the DSDT _UID Required if multiple instances of the same device (_HID) appear on the platform 6.2 with changes for _CRS Required for all devices in the DSDT ACPI 5.0

34 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

GPIO New for ACPI 5.0 GPIO Controller Required whether the device is ACPI Devices appear in enumerated or enumerated by another bus ACPI Namespace New for ACPI 5.0 ACPI Events signaled Required for hardware-reduced platforms through GPIO Interrupts New for ACPI 5.0 Peripherals include Required for any enumerated peripheral GPIO IO and Interrupt device that is connected to a GPIO line on Descriptors in _CRS a GPIO controller New for ACPI 5.0 Platform firmware Required if any platform firmware access accesses GPIO to an enumerated GPIO controller is controllers only needed through ASL using GPIO Operation Regions Serial Peripheral New for ACPI 5.0 SPB Controller Necessary whether the device is ACPI Bus (SPB) Devices appear in enumerated or enumerated by another bus ACPI Namespace New for ACPI 5.0 Peripherals include Necessary for any enumerated peripheral SerialBusConnection device that is connected to an SPB Descriptors in _CRS controller New for ACPI 5.0 Platform firmware Necessary if any platform firmware access accesses SPB to an enumerated SPB controller is needed controllers only through ASL using SPB Operation Regions

35 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

ACPI-Defined 9.5 Control Method Power Necessary on devices with a keyboard Devices Button 9.4 Control Method Lid Necessary on devices with a lid Device New for ACPI 5.0 Control Method Time Necessary on platforms that do not support and Alarm device the legacy RTC, or that are hardware- reduced

PROCESSOR

Windows supports the IA-32 Instruction Set Architecture (ISA). For processor guidance, refer to the Hardware Configuration section.

TOOLS AND TECHNICAL REFERENCE

For more information about hardware considerations for a connected standby-capable device, see How to build an energy efficient device.

Title Content Type Description Download Link

Delivering a secure and fast Video MSDN boot experience with UEFI

Windows Deployment with the Article TechNet Windows ADK

Setting Up Kernel-Mode Article Dev Center -

Debugging in Visual Studio Hardware

36 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Setting Up Kernel-Mode Article Dev Center -

Debugging Manually Hardware

ACPI Devices Article with Dev Center -

Corresponding Hardware Documents

Windows Assessment and Executable file Download Center Deployment Kit (Windows ADK) for Windows® 8

37 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

SOLID-STATE HYBRID DRIVES (SSHD)

Solid State Hybrid Drives (SSHD) combine inexpensive rotational media with fast flash storage to provide inexpensive, large-capacity storage without the performance limitations of HDDs. To Windows, this means a SSHD combines rotational media and a non-volatile cache component in a single device. Windows makes effective use of the cache by providing hints with each I/O on where specific data should be placed.

INDUSTRY SPECIFICATION AND WINDOWS HARDWARE CERTIFICATION KIT (WHCK) Item URL SATAIO TBD Windows Hardware Device.Storage.Hd.Sata.HybridInformation.BasicFunction Certification Kit

WHCK PERFORMANCE AND SIZE REQUIREMENTS

A SSHD two most important features are the size of its NVC and the speed at which the NVC can read and write data. The WHCK requires the following:

Requirement Name Description Cache Size The hybrid cache must provide at least 12 GB (12 x 2^30 Bytes) of useable capacity to the host. Sequential Read >= 200 MB/s or 3,200 I/Ops @ 64 KB Sequential Write >= 80 MB/s or 1,280 I/Ops @ 64 KB Random Read >= 10 MB/s or 2,560 I/Ops @ 4 KB (Queue Depth = 1) >= 20 MB/s or 5,120 I/Ops @ 4 KB (Queue Depth = 8) Random Write >= 5 MB/s or 1,280 I/Ops @ 4 KB (Queue Depth = 1) >= 10 MB/s or 2,560 I/Ops @ 4 KB (Queue Depth = 8)

38 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The cache size directly affects how much data can be placed in the NVC and thus increases the average hit-rate on data accesses. The goal is to have a cache hit-rate as high as possible so the user can experience a SSHD properly and perceive it like a SSD. Cache size lower than 12 GB does not give Windows enough space to place critical files in the NVC without sacrificing certain scenarios, such as hibernate or hiberboot. The hiberfile can take up significant amounts of space depending on how the user uses the system.

Sequential read and write speeds are very important for hibernate and hiberboot scenarios. Read speeds directly affect how quickly a system can boot or resume from hibernate. It is important for sequential write speeds to have at least 80 MB/s for Windows to have the option of placing the hiberfile in the NVC and resuming from there without spin-up. If 80 MB/s are not provided in sequential write throughput, the -user may notice shutdown and hibernate performance issues, as it would take too long to write out the whole hiberfile.

Random read and write speeds are where SSHDs can shine over regular HDDs. A typical HDD does not surpass 300 I/Ops @ 4KB, which means that any random access patterns can be boosted by up to an order of magnitude on a SSHD. This not only benefits the system while initializing its BIOS/EFI and booting, but also during normal operations.

SSHD IMPLEMENTATION CONSIDERATIONS

 Supported by in-box driver.  Connected Standby scenarios are not supported at this time.  Sequential scenarios (hiberfile, swapfile) will be enabled on NAND if: o NAND sequential read/write speed exceeds platter sequential read/write speeds

DRIVER

The next version of Windows includes an in-box miniport driver that provides full functionality. The in-box driver capabilities adjust dynamically to a device's flash speed and capacity. If the flash is faster than the rotating disk sequential scenarios, such as “Hiberboot from Flash” will be enabled. In order to qualify as a SSHD, devices are required to pass the WHCK requirements stated under: Device.Storage.Hd.Sata.HybridInformation.BasicFunction

39 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Other driver features include:

 Hiberboot/Hibernate from flash.  Page/Swap files from flash.  More efficient runtime caching.  Write caching.  Bitlocker support.

USB MASS STORAGE (USB-MS) Windows supports USB-MS. The Microsoft USB XHCI in-box drivers provide full support for USB 2.0 and 3.0 mass storage disks on XHCI 1.0 compliant USB host controllers. The Microsoft USB EHCI in-box drivers provide full support for USB 2.0 mass storage devices on EHCI compliant USB host controllers.

USB MASS STORAGE BOOT SUPPORT USB boot is more important than ever. In addition to the traditional USB boot scenarios like Windows Preinstallation Environment, Windows Recovery Environment, and Windows Setup, Windows 8 introduced a new USB boot scenario – Windows To Go, which enables booting a full copy of Windows from an external USB drive.

FIRMWARE SUPPORT FOR USB BOOT

The UEFI firmware must support booting from USB mass storage devices such as USB flash drives. Booting from a USB optical drive is not available. This UEFI support enables boot from USB scenarios for recovery of the operating system using Windows Recovery Environment and for manufacturing.

REPORTING THE USB PORT LOCATION The firmware must contain the ACPI specified USB Port Capabilities (_UPC) and Physical Device Location (_PDL) descriptors that correctly indicate the location of the USB ports. To specify a port that is internal (not user visible) and can be connected to an integrated device, the ACPI properties _UPC.PortIsConnectable byte must be set to 0xFF, and the _PDL.UserVisible bit must be set to 0. For more information, go to MSDN. Windows uses this

40 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

information to determine if the operating system is booted from an external USB device (Windows To Go) and enables key features such as surprise removal mitigation.

WINDOWS TO GO DISK LAYOUT SUPPORT

The following diagram shows the disk layout used by Windows To Go drives.

41 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Figure: Disk Layout Picture

This disk layout allows the use of Windows To Go drive on both UEFI and legacy BIOS systems. Key aspects of this disk layout are:

• Disk is formatted using MBR (Master Boot Record) formatting scheme. • Includes at least two partitions o FAT32 System partition that contains the boot components. o NTFS Windows partition that contains the operating system binaries. • The system partition includes boot components for both UEFI and legacy BIOS

The above disk layout is fully compatible with both UEFI and legacy BIOS. However, since UEFI-based systems have traditionally used GPT (GUID Partition Table) disk layout scheme, Microsoft recommends testing your UEFI firmware to ensure it works well with MBR disk layout as well.

RELIABLE USB DEVICE ENUMERATION For reliable USB boot device enumeration, we recommend the following for system firmware: • Enable USB 3.0 terminations and keep them enabled when VBus is applied to ensure that USB 3.0 device doesn't fall over to USB 2.0. • Reset USB controller's internal state on platform reset to ensure state states not carried over across platform reset and cause boot failures. • Ensure compliance with the enumeration timing requirements in the USB 2.0 and USB 3.0 specifications from USB-IF. For guidance, refer to the following sections in the USB specifications: o Various LTSSM timeout values - table 7-12 Section 7.5 of USB 3.0 specification. o Standard request - Section 10.4.1 of USB 3.0 specification. o Various bus timing parameters – section 7.3.2 of USB 2.0 specification. o Standard request – Section 11.24.1 of USB 2.0 specification. • Correctly handle the peripheral device type (0x0D) in a multi-LUN USB storage device so the correct LUN is targeted for booting.

42 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

• Correctly handle booting from a composite USB device with a USB Mass Storage function. • Build sufficient resiliency to tolerate transient device issues. For example: o Perform retries/resets at different levels (port/hub/controller) when encountering enumeration failures before giving up USB enumeration. o Perform retries when device returns NOT READY in response to TEST_UNIT_READY. This is especially important for USB hard disks (spinning media drives) which often take several seconds to initialize and return the first block of data. o Handle large delays (up to few seconds) in IO operation completion correctly. This is again especially important for USB hard disks (spinning media drives). o The TEST_UNIT_READY/REQUEST_SENSE command should only be sent as appropriate. It is not necessary to send a TEST_UNIT_READY/REQUEST_SENSE after every successful SCSI command.

ADDITIONAL RECOMMENDATIONS Microsoft recommends the following additional guidance around USB boot support.

• Test and validate USB boot support from a USB storage device connected behind at least one level of USB 2.0/3.0 external hub. This helps USB boot implementation in the firmware work reliably with external hubs. • Intermediate hubs in the device path increase the potential for transient hardware failures and negatively impact the reliability of the system if the boot device is connected behind multiple levels of hubs. So, minimizing the hub depth (internal hubs) to the external ports is highly recommended when designing the system. In particular, internally connected USB devices (for example, integrated webcam, smart card reader etc.) should not share an internal hub with external USB ports. • Test and validate USB boot support with multiple USB storage devices (including devices that expose multiple LUNs, spinning media device etc.) to ensure system can reliably boot from broadest set of devices. • Support wake-on-disconnect from S3 in the USB host controller irrespective of system power source – AC or DC. This capability is important for Windows To Go in scenarios where user unplugs the Windows To

43 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Go drive while the system is in S3. If the system supports wake-on-disconnect, Windows To Go operating system will resume and detect that the boot disk is missing and will power down the system. This is a mitigation to prevent system disk corruption on the Windows To Go drive if user uses the drive on another machine and then brings it back to boot on the original machine which is still in S3.

ADDITIONAL TESTING GUIDANCE Unlike traditional USB boot scenarios (Windows Preinstallation Environment, Windows Recovery Environment etc.) Windows To Go scenario involves booting and running a full copy of Windows from an external USB device. We highly recommend comprehensive testing of the system with Windows To Go to ensure the system is fully compatible with Windows running from an external USB device. We recommend that you perform this testing after ensuring that the system meets the following USB boot related HCK requirements and successfully passes the HCK test – "Boot From USB (x86 and x64)". • System.Fundamentals.USBBoot.BootFromUSB • System.Fundamentals.Firmware.UEFIBootEntries • System.Fundamentals.Firmware.FirmwareSupportsUSBDevices • System.Fundamentals.SystemUSB.EHCIToXHCIControllerTransitions

WINDOWS TO GO DRIVES We recommend using only the following two USB drives for this testing as other drives may not work correctly with Windows To Go. • www.supertalent.com/wtg • www.kingston.com/wtg

TEST PROCEDURE 1. Install Windows 8.1 Enterprise build on a system under test. 2. Use Windows To Go Creator to create a Windows To Go drive. a. Search "Windows To Go" -> Settings -> Windows To Go to launch the Creator. Note that Windows To Go Creator is only available in Windows 8 Enterprise build.

44 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

b. When prompted, enter the path to the Windows 8 Enterprise WIM file. 3. Enable Windows To Startup Options to configure the system to boot from USB device at next startup. a. You can enable Windows To Go Startup Options on the last page of the Creator after it completes provisioning the drive. b. Alternatively, search "Windows To Go" -> Settings -> Windows To Go Startup Options 4. Shutdown the system. a. Note: Shutdown (instead of a restart) is an explicit step here to ensure that the system can do a cold boot into the Windows To Go drive. 5. If it’s not plugged in, plug in the Windows To Go drive. 6. Power on the system and make sure the system boots into Windows To Go. The first boot goes through the standard device installation and OOBE experience. 7. Reboot multiple times into the Windows To Go drive to check that the system can perform reliable warm boots into the USB drive. During these multiple reboots, also make sure the system does not boot back into the host operating system. 8. Perform sleep/resume test on Windows To Go. 9. Perform hibernate/resume test on Windows To Go. By default, hibernation is disabled on Windows to Go. Use the following steps to enable hibernation: a. Open Local Group Policy Editor using "gpedit.msc". b. Go to Computer Configuration -> Administrative Templates -> Windows Components -> Portable Operating System. c. Open Allow hibernate (S4) when starting from a Windows To Go workspace, click Enabled, and then click OK. Reboot and hibernation are now on.

DRIVER

The Microsoft USB XHCI in-box drivers provide full support for USB 2.0 and 3.0 mass storage disks on XHCI 1.0 compliant USB host controllers.

45 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The Microsoft USB EHCI in-box drivers provide full support for USB 2.0 mass storage devices on EHCI compliant USB host controllers.

RELATED RESOURCES

Icon Meaning //B Running Windows from an external USB drive with Windows To Go //B Building great USB 3.0 devices //B USB 3.0 in Windows 8 //B Debugging Innovations in Windows 8 //B Windows Certification: improvements to the logo program Universal Serial Bus (USB) Drivers Setting Up a USB 3.0 Connection in Visual Studio Setting Up a USB 3.0 Connection Manually Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

BUILDING A DEVICE WITH A GREAT WINDOWS EXPERIENCE

CORE SYSTEM RESOURCES

Core system resources include interrupt controllers, timers, and Direct Memory Access (DMA) controllers that are shared among devices and managed by the OS. These resources are critical to the operation of the processor and the operating system, and are abstracted by the Hardware Abstraction Layer (HAL) in Windows. Because of their importance to the operating system, these resources must have low-latency access characteristics. They cannot be used if they are external to the chip or connected to the processor through peripheral buses or General Purpose I/O (GPIO) lines.

46 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

RECOMMENDED GOALS AND REQUIREMENTS Resource Goal Timers Local timers* Note: If locally invariant timers aren’t possible and there is an invariant global timer per processor, Windows uses global time. Physical Address Space Supports 32 bits of physical address space DMA Controllers Bus mastering for all devices. All devices support the maximum physical address space of the core logic. Note: If devices using DMA do not support the maximum physical address space, double buffering is used, which negatively impacts performance. Exceptional experience: High performance devices (including paging devices) use dedicated DMA controllers.

System DMA Controllers All channels in the controller must be able to service all devices (request lines) connected to that controller. Memory Management Units TBD (IOMMU / SysMMU)

ACPI tables: standard core Microsoft-defined ACPI tables** system resources Standard ACPI tables The standard ACPI tables enable support for the GIC and the GIT. ACPI tables: non-standard Microsoft-defined ACPI tables** core system resources Time of day Any real-time clock (RTF) with appropriate UEFI and ACPI support (time and alarm device). Exceptional experience: Standard, PC-compatible RTC, accessible through IO ports and CMOS. See Time of day information below. * Windows includes in-box support for generic timer implementation. If the hardware doesn’t have a generic timer , other times can be supported using HAL extensions.

47 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

** The Microsoft-defined ACPI tables enable support for core system resources in the following ways:  The information in the tables helps Windows identify the HAL extension module(s) that need to be loaded to support the hardware implemented on the platform.  The HAL extension gets information from these tables on how the core system resources are implemented and configured on this platform to accommodate any variations among platforms.

OUT-OF-BOX EXTENSIONS (NOT SHIPPED WITH WINDOWS) HAL extension modules that are not part of the shipping Windows image are supported through the same offline servicing model used for drivers. Using this model, the HAL Extensions are acquired directly from the chipset vendor or Microsoft. These extensions are added to an image before it is deployed to a target system.

TIME OF DAY If no RTC support exists, then the system time may not be current until Windows can sync the time after each boot through a timer server or network. A standard RTC may have a reduced feature set. The minimum features are to get and set time, get and set a wake alarm, and the "update in progress" bit. You can locate the stripped-down RTC at I/O ports 70/71. The following table summarizes the RTC register features.

48 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Location Item Configuration Bytes 0x0-0xD Seconds Seconds Alarm Minutes Minutes Alarm Hours Hours Alarm Day Date Month Year Register 0xB Update in Progress Bit Set bit as specified. Rate Select RS3-0 can be hardwired to 0 to indicate no periodic interrupt if clock and profiling sources are already satisfied by other timers. Periodic Interrupt Enable Hardwire to 0. Square Wave Enable Bit Hardwire to 0. Data Mode Hardwire to 1 to indicate BCD mode. 12/24 Hour Mode Hardwire to 1 to indicate 24-hour mode. Daylight Savings Enable Hardwire to 0. Register 0xC Interrupt Request flag Set if Alarm-Interrupt-enabled and fires (AF+AIE). If clock and profiling sources are satisfied, can have no functionality for periodic or end of update cycle interrupts. Periodic Interrupt flag Hardwire to 0 if clock and profiling sources already satisfied by other timers. Alarm Flag Hardwire to 0. As a result, Windows triggers an IRQF interrupt. Update Ended Interrupt Flag Hardwire to 0. Register 0xD Date Alarm a. OK to deprecate; however, system may have reduced wake support.* Wake alarm day and month OK to deprecate; however, system may have reduced wake support. Two 8 bytes lockable RAM OK to deprecate.

49 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Ranges CMOS SRAM OK to deprecate. Leap Year calculation OK to fix to do the right thing on years divided by 100. Century byte and Century OK to deprecate. rollover End of update cycle interrupt OK to deprecate. Periodic interrupt OK to deprecate if clock and profiling interrupts are already satisfied by other timers. * In the case of reduced wake support, the system does not set an alarm more than 24 hours into the future. To support longer periods, the system must wake up every 24 hours to re-arm the wake timer, which may have a negative power impact.

SECURITY

Windows includes several platform integrity and data protection features that rely on the underlying hardware to strengthen the system's security. These include:

 Secure Boot. Helps to ensure the user is running verified, authorized code to prevent malware infection or malicious modifications.  Measured Boot. Securely measures all components that load during boot so the health of a system can be determined and attested to.  Data Protection (BitLocker). Encrypts the full volume to ensure that all user data is protected when a device is lost or stolen.

50 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The underlying hardware and firmware must support a secure boot path, TPM capabilities, and cryptographic offload from the pre-operating system and run-time Windows components. To deliver a robust system performance, a set of defined cryptographic functions must be implemented. To do so, use an acceleration engine or dedicated security processor available within the SoC or core logic chipset or processor.

SECURE BOOT

The firmware requirements for implementing secure boot are:

 The platform exposes an interface that adheres to the profile of UEFI v2.3.1 Section 27.  The platform must come provisioned with the correct keys in the UEFI Signature database (db) to allow Windows to boot. It must also support secure authenticated updates to the db and dbx per the spec.  Storage of secure variables must be isolated from the running operating system such that they cannot be modified without detection.  All firmware components are signed using at least RSA-2048 with SHA-256.  When power is turned on, the system starts executing code in the firmware and uses public key cryptography as per algorithm policy to verify the signatures of all images in the boot sequence, up to and including the Windows Boot Manager.  The system must protect against rollback of firmware to older versions.  The platform provides the EFI_HASH_PROTOCOL (per UEFI v2.3.1) for offloading cryptographic hash operations and the EFI_RNG_PROTOCOL (Microsoft defined) for accessing platform entropy.

HARDWARE SECURITY INTERFACE

X86 SOC systems must implement the New UEFI AIP Protocol Extension, HSI (Hardware Security Interface).

More information TBD from UEFI proposals.

51 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

RELATED RESOURCES

The following table provides links to additional content resources for this section.

Icon Meaning //B Building hardware-based security with a Trusted Platform Module (TPM) //B Building great Windows 8 systems //B Delivering a Secure and Fast Boot Experience with UEFI Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware

MEASURED BOOT

Measured boot requires the following firmware requirements:

 The platform must provide a TCG-compliant TPM implementation available to the pre-operating system and runtime operating system.  During the boot sequence, the boot firmware and software measures all firmware and all software components being loaded into the TPM.  For platform attestation, the SoC vendor must provision an Endorsement Key certificate. The certificate profile is provided separately.

 Support for platform attestation. o Ability to protect register values from within Windows, and sign the values with a platform key.  Support for isolated storage. o Access to isolated non-volatile, sealed storage for storing long term secrets. o Loading and storing key data within sealed storage.

RELATED RESOURCES

The following table provides links to additional content resources for this section.

52 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Icon Meaning Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware

DATA PROTECTION (BITLOCKER)

To support full volume encryption of all data in a manner that does not consume excessive power yet performs well, Advanced Encryption Standard (AES) acceleration within the must be provided to Windows.

A BCrypt provider for the is required to access the platform's cryptographic acceleration capabilities. The BCrypt interface is documented on the MSDN1 website, and provides the base framework for cryptographic operations. A BCrypt provider is used in both user mode and kernel mode to provide the necessary cryptographic run-time services.

ENCRYPTED DRIVE

An encrypted drive is a hardware solution that protects the user's data with BitLocker. It uses the hardware-based encryption solution to provide the user with a seamless end-to-end data security solution.

With Encrypted Drive, you can deliver enhanced security protection out-of-the-box, with near zero-impact to the user. The combination of BitLocker and Encrypted Drive provides immediate encryption support with nonoticeable effect on the user experience. You can set up BitLocker so the user doesn’t have to do anything. Encrypted Drive offers a premium configuration.

To enable support for Encrypted Drive, the PC must meet the following requirements:

1 The primitive functions are defined in http://msdn.microsoft.com/en-us/library/aa833130(v=VS.85).aspx and the required configuration functions in http://msdn.microsoft.com/en-us/library/bb204774(v=VS.85).aspx

53 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Self-encrypting drives that meet industry specifications of IEEE 1667, TCG OPAL (subset), and INCITS T13  UEFI 2.3.1 Class 2 implementation using GPT on the Encrypted Drive (to support boot)  Windows SKUs that support BitLocker  TPM

PREBOOT MEMORY PROTECTION

Before Windows finishes booting and taking control of the system and its buses and ports, the firmware is the go- between for port and bridge controller availability on the platform. However, during the boot process for encrypted operating system volumes, BitLocker handles encryption keys in memory to decrypt the volume containing the Windows loader and the rest of the Windows operating system - these keys must be protected.

The boot firmware must protect physical memory from all DMA-capable external ports prior to boot, during boot or resume from S3 if supported, and until such time as the operating system powers up DMA ports through related bridge controllers. When the device enters a low-power state, the DMA port device context must be saved and restored upon returning to an active state.

If the firmware has the option to enable and disable this protection, the shipping configuration must be with protection enabled, and turning protection off must be protected. For example, platform authentication through the BIOS password.

Note that this requirement precludes the use of attached storage as boot media if it can only be accessed through an external DMA-capable port, such as ExpressCard, CardBus, IEEE 1394, or Thunderbolt interface if supported.

RELATED RESOURCES

Icon Meaning //B Building hardware-based security with a Trusted Platform Module (TPM)

54 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

FINGERPRINT READER

The purpose of this sensor is to let Windows Biometrics Framework (WBF) enable components of the operating system and applications to identify users using their fingerprints.

Fingerprint readers are used for the following scenarios:

SIGN-ON TO THE PC

A user can register their fingerprints on their device’s fingerprint reader to sign-on to their PC. Once registered, the user only needs to place their finger on the reader to allow scanning. This is especially useful on touch devices.

IN-APP AUTHENTICATION

Instead of entering an account password, 1st party (Windows Store, Music etc.) and 3rd party applications can identify and authenticate the user using their fingerprints.

USER CONSENT USING THE CONVENIENCE OF FINGERPRINTS

To make sure the user providing consent is the actual user, fingerprint readers offer a convenient and secure way to verify the user’s identify.

HARDWARE

The following table summarizes the hardware features for the fingerprint reader:

Feature Remarks Size 10mmX10mm Bus USB or SPI

55 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Sensor type Touch Power consumption No more than 100mW when the sensor is capturing a fingerprint. No more than 1 mW for all other cases. Recommended <1%FRR @ 0.01% FAR as defined by fingerprint sensor Performance specification. Recommended to be able to provide a minimum of one of the anti- Liveness Detection spoofing measures based on the fingerprint sensor specification. Must meet the HCK requirements for fingerprint readers published HCK here

DRIVER AND SOFTWARE

The fingerprint reader driver suite must meet Windows Hardware Certification requirements which requires the sensor to have the following:

 WBDI driver  Engine Adapter  Sensor Adapter  Storage Adapter

Most sensors should use the inbox sensor and storage adapters. But, if it is necessary due to technical reasons, a custom sensor and storage adapter may be included as long as it conforms to WBF.

For advanced sensors that offer on-chip matching and storage, the engineer adapter may not be needed.

A fingerprint management application (FMA) is no longer needed and should not be supplied. The enrollment experience is now available out of the box.

Windows Biometrics Framework and all the scenarios mentioned above works the same way on ARM based systems.

56 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

We do not recommend installing any additional value-added software on the PC.

TOOLS AND TECHNICAL REFERENCE

Icon Meaning ACPI Devices

BUILDING A GREAT DEVICE FOR BROWSING

For more information about hardware considerations related to Internet Explorer, see the GPU Hardware Decoding Considerations for HTML5 white paper.

BUILDING A GREAT MEDIA DEVICE

Media apps and experiences on Windows devices are very important to customer satisfaction. In one Microsoft study about the impact different feature areas have on a user’s overall evaluation of a device, media was a significant contributor to negative reviews. Any human-perceivable delay or lag when using a Windows device distracts from a customer’s perception of quality. Media intensive apps and websites such as Netflix, Hulu, Skype, Xbox Music, Spotify, and YouTube rely on good hardware and a well-designed Windows image with compatible drivers and devices to deliver a great customer experience. Media is an area where significant improvements are often possible even on existing systems.

GRAPHICS PROCESSING UNIT (GPU)

WINDOWS DISPLAY DRIVER MODEL (WDDM) VERSION

57 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The device’s WDDM must be WDDM 1.2 compliant.

RELATED RESOURCES

Icon Meaning //B Certifying graphics experiences on Windows 8 //B Understanding the Windows 8 graphics driver model //B Chalk talk: transitioning from XDDM to WDDM //B Introduction to DirectX for Windows Store apps //B 3D Graphics in Windows Store Apps and Games //B Achieving High Performance 2D Graphics with Direct2D //B Taming GPU Compute with C++ AMP //B Tuning GPU Usage for any Form Factor //B Building great Windows 8 systems Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

DIRECTX "FEATURE LEVEL"

The DirectX feature level compliance varies by form factor and user segment. For guidance, refer to the Hardware Configurations.

MULTIPLE GPUS

For information regarding support for multiple GPUs, refer to the Windows Hardware Certification Requirements.

HYBRID GRAPHICS

58 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

We're considering operating system support for "hybrid" graphics systems in a future version of Windows. To make this a first-class feature in the operating system, our goals are:

 By default, almost all apps use a relatively low-power integrated GPU.  Carefully selected graphics-intensive apps, such as high-end games, use a much more powerful discrete GPU by default.  A user does not have to choose the default GPU for an app.  The OS fully supports this feature and is robust and resilient to both driver and operating system upgrade.

HYBRID GRAPHICS DEFINITION

Windows will detect a hybrid graphics configuration at POST time. Any system that matches the following configuration is considered a hybrid candidate system:

 The system contains a single integrated GPU and a single discrete GPU.  It is a design assumption the discrete GPU has significantly higher performance than the integrated GPU.  The discrete GPU is a render-only device and no display outputs are connected to the discrete GPU.  Both GPUs are physically enclosed as part of the system. Hot plugging of GPU is not allowed.

This requirement only applies when the dGPU advertises itself as Microsoft hybrid-capable by setting the cap for the new DDI. A new cap is added to allow a miniport driver to identify itself as a “hybrid discrete” GPU - DXGK_DRIVERCAPS::HybridDiscreteGpu.

When designing the system, OEMs are expected to talk to the IHV partner and communicate the right design. This requirement does not apply to PCs with multiple homogeneous graphics with separate output ports.

Depending on the needs of the application, hybrid systems will exhibit new OS behavior designed to robustly and transparently run applications on either the integrated or discrete GPU. Together, the OS and graphics driver determine which GPU a given application uses by default.

59 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

GPU AND DRIVER REQUIREMENTS  A Microsoft supported hybrid system can only consist of one integrated GPU (iGPU) and one discrete GPU (dGPU)  Cannot have more than two GPUs  Both GPUs must be DX11.0 or higher  Both GPUs driver must be WDDM1.3 or higher  Both GPUs must implement the new standard allocation type added to the KM and associated UM DDIs to support cross adapter shared surfaces.  If each GPU has separate standard drivers, then they must be independent of each other and can be updated independently without breaking hybrid functionality  The dGPU must be equal or higher performance than the iGPU  The iGPU is the adapter that has outputs  The dGPU adapter is one that o sets the new discrete hybrid cap added to the WDDM 1.3 driver o has no outputs

All other multi-GPU configurations do not get Microsoft hybrid support. They will be treated the same way as defined by the “System.Fundamentals.Graphics.MultipleOperatingMode” requirement.

In addition to the above requirements, all graphics drivers (regardless of being hybrid or not) cannot bypass the defined DDI contracts. In addition, the following apply:

 No system level or runtime level API detouring allowed; the driver cannot intercept OS system or runtime calls, modify arguments passed by OS system or runtime APIs, or wrap the objects returned from the API entry points.  Access and use of internal data structures not allowed  No driver layering allowed. Only one user mode/kernel mode driver can load and communicate with the runtime and kernel binaries.

GPU SELECTION POLICY

60 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 GPU selection is automatic. No user control required.  GPU selection is on a per app basis.  By default, all apps run on the iGPU.  GPU selection for an app is based on a pre-populated Discrete-list. o The discrete GPU vendor maintains, validates, and deploys the D-list. The OS is not responsible for selecting apps to run on the dGPU. o The OS provides a DDI through which IHVs may convey the per app GPU selection setting to the OS (D3D runtime). This DDI is explained in detail in the Hybrid DDI doc. o If the IHV provides no information through the D-list DDI, the D3D runtime assumes the app should run on the iGPU. o The GPU selection information is persisted throughout the lifetime of the process and cannot be changed unless the process is terminated. o The D-list lives in a separate DLL provided by the discrete GPU IHV. The DLL has size, access time, and memory requirements. These requirements are TBD.

 The OS reserves the final say in GPU selection and can choose to amend the answer provided by the driver. o This list is primarily used for apps that should never land on the dGPU, which include many system components and some Inbox apps.

61 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

GPU SELECTION FLOW

62 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

63 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

APPS ALLOWED ON THE DISCRETE LIST

The hybrid model supports apps, which could also run on the dGPU.

 Apps built on D3D9 runtime and higher.  Both desktop and Windows Store apps. o All types of Windows Store apps, including HTML/JavaScript apps that are uniquely identifiable to run in hybrid mode.  Full-screen exclusive apps.  OpenGL apps.

HYBRID MODE DEFINED

When the GPU selection lookup in the D-list returns dGPU for a particular app, that app is rendered on the dGPU. The dGPU VRM transfers its frame buffer contents to the system memory and the DWM combines the contents to display on the iGPU. This scenario is called running an app in hybrid mode.

EFFICIENT PRESENTATION REDIRECTION IN HYBRID MODE  The operating system uses a new type of surface — cross-adapter shared surface — to transfer the rendered content from the dGPU to the iGPU.  Hybrid mode requires new kernel and user mode DDI support, which is explained in detail in the Hybrid DDI doc.

EFFICIENT PRESENTATION FOR REDIRECTED BIT BLT MODEL

The following diagram shows the use of cross adapter shared surfaces in making redirected bit blt presentation mode work efficiently in hybrid mode.

64 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Top level windows redirection surface DX app back buffer GDI app (cross adapter on dGPU surface) Present

Render Composition

DWM swap chain DX app on iGPU dGPU

EFFICIENT PRESENTATION FOR REDIRECTED FLIP MODEL

65 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

GDI part of the DX app

Top level Staging windows DX app swap DX app swap resource on redirection chain Surface 1 chain Surface 2 surface dGPU

Render

Cross adapter Present shared surface DX app on iGPU dGPU DWM Composition DWM swap chain on iGPU

POWER MANAGEMENT  The iGPU is always on.  The dGPU should power off after a certain time of inactivity. For the exact requirements, refer to the “System.Fundamental.Graphics.Hybrid.MultiGPU” requirement.

66 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

WINDOWS SUPPORTED HYBRID LOGO REQUIREMENTS  All new PCs running Windows considered hybrid candidates require certification under the Windows Certification Program and must pass all of the new tests for hybrid systems.  Existing Windows 8 hybrid systems must continue to use their existing hybrid implementation and validate against all existing requirements.

MULTIMEDIA

MULTIMEDIA OFFLOADING FRAMEWORK IN WINDOWS

Audio and video can consume large amounts of power. To achieve long battery life for multimedia scenarios, Windows provides the following:

 Comprehensive hardware offload capabilities through the Media Foundation Platform (http://msdn.microsoft.com/en-us/library/ms694197(VS.85).aspx).  Hardware acceleration through DirectX Video Acceleration (DXVA) (http://msdn.microsoft.com/en- us/library/aa965263(VS.85).aspx).  Hardware audio mixing and rendering support built into the audio stack.

To offload multimedia functions, vendors must provide driver-level support to expose their components to Media Foundation APIs, or write native Media Foundation components.

In Windows, Media Foundation provides hardware offload for CPU-intensive audio and video functions, such as decoding, encoding, capturing, and signal processing. It is possible to chain multiple hardware-offloaded components to process data without CPU intervention. Some other common operations, such as parsing and authoring of files, are handled in software only. The multimedia stack in Windows supports parsing/de- multiplexing and authoring for the following file formats:

Format MPEG-4 MPEG-2 PS MPEG-2 TS MP3 AVI WAV ASF ADTS

67 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Parsing Yes Yes Yes Yes Yes Yes Yes Yes Authoring Yes Yes Yes Yes No No Yes No

For a list of the decoders and encoders, see the Appendix of this document.

OFFLOADING OPTIONS

VIDEO

The following table summarizes the video offload functions supported by the various models.

Offload method Decode/Processing Encode Render Capture AVStream/KS Driver No No No Yes DXVA Acceleration H264, MPEG2, VC1 (recommended) No Yes No HMFT with WDDM MPEG4 Pt2 (recommended), MJPEG Yes No No driver (optional)

AUDIO

Windows supports a single audio offloading option, which described in subsequent sections. A PortCls WaveRT driver is required to expose the underlying hardware capabilities to the audio stack.

AUDIO AND VIDEO STREAM

Media Foundation wraps compliant AVStream drivers and exposes them as Media Foundation Transforms (MFTs). The underlying hardware provides the actual functionality, which removes the processing load from the main CPU.

PORT CLASS (PORTCLS) DRIVER

68 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Port Class (PortCls) is a common driver model for DMA-based audio devices. The Port Class Library provides a group (ports) of helper functions for common audio driver operations (for example, DMA and power state control) that simplify the writing of audio drivers. A WaveRT PortCls driver is necessary to expose audio hardware offloading capabilities to Windows.

DIRECTX VIDEO ACCELERATION (DXVA)

DXVA acceleration applies to graphics drivers. Video decoding and processing is available through this model. Windows provides the following DXVA-capable components:

 DXVA decoding o H.264 decode o VC-1 decode o MPEG-1 and 2 decode  DXVA Video Processing o Subpicture / multiple video blending o Deinterlacing o Color-space conversion o Resize o Video rotation

HARDWARE MFT WITH WDDM DRIVER

A hardware encoder CODEC must provide its own Media Foundation Transform (MFT). This hardware MFT (HMFT) must talk directly to the hardware using WDDM.

HMFTs must:

 Implement IMFTransform  Support DX11 User Mode Interface on MFTs

69 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Use MF work queue support (no thread creation) by using IMFRealTimeCLientEx::SetWorkQueue  Support IMF2DBuffer2

RELATED RESOURCES

Icon Meaning Exposing Hardware-Offloaded Audio Processing in Windows Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

AUDIO-SPECIFIC

Audio hardware should support hardware offloading of at least two audio streams, plus an additional host-process stream from the software mixer (in cases where software mixing is necessary). The offloaded streams bypass the software audio engine and proceed directly to the hardware. However, if more audio streams are opened than the number supported by the hardware, the additional audio streams go through the software audio engine to be mixed. The resulting stream proceeds to the hardware through the host-process stream. The audio driver is responsible for exposing the underlying capabilities of the hardware, and supporting the hardware topology shown in the blue box below.

70 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

71 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Figure 1 - Audio Processing

In Error! Reference source not found. above, the audio driver is responsible for representing and exposing all of the offloaded processing capabilities to the operating system. The hardware topology must accept a host-process stream input and at least two offloaded streams. Each offloaded hardware solution must contain a hardware mixer and the ability to accept hardware-offloaded streams directly from the app (for example, not passed through the audio engine) to be processed in hardware. The hardware processor must also accept a system stream, intended to be the final output from the system mixer of all the streams handled in software. The software audio engine is instantiated on this system stream to provide a software LFX/decode/volume solution for all streams that cannot be offloaded in hardware.

Note: Windows does not support offloading of the capture pipeline.

CONTENT PROTECTION OF MEDIA FLOW WITH HARDWARE ACCELERATION

WMDRM and PlayReady decrypters must authenticate downstream decoders, and they must establish a standardized (usually lighter-weight) re-encrypted data flow. This encryption protects the content between modules and at their boundaries. Graphics and audio drivers and hardware are authenticated at strategic points as follows:

 The video decoder establishes trust with the graphics driver or hardware.  The video output management establishes trust with the graphics driver or hardware.  The graphics driver performs a functionality scan to trust the graphics hardware.  The audio driver and plug-in kernel-mode components in the stack are authenticated in a chain.

Windows 7 standardized compressed content flow from the software video decoder to the graphics subsystem for the DXVA case through key exchange and AES encryption. For Windows, the standardized compressed and uncompressed video protections are connected to policy flow from the DRM subsystem plug-in model, and content protection for AVStream drivers and hardware MFTs is comparable to protection for graphics-based acceleration.

72 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

No further audio protections beyond the Windows 7 baseline are being considered for Windows.

To support content protection for AVStream drivers and hardware MFTs:

 PVP-OPM license program must issue certificates and key generation tools compatible with the SAC mechanism.  Decoders must support the SAC and sample protection functionality (IMFSecureChannel and IMFSampleProtection) for input. The underlying functionality may be implemented in either the driver or the hardware and firmware. The functionality is dependent on the type of hardware MFTs. o AVStream: The vendor must implement the core functionality in either the driver or the hardware and firmware, and the Microsoft DevProxy exposes IMFSecureChannel and IMFSampleProtection. o Non-AVStream MFT: The vendor must implement the core functionality in either the driver or the hardware and firmware, and also implement the required IMFSecureChannel and IMFSampleProtection interfaces on the MFT.  Decoder must implement partial stream encryption in driver or hardware and firmware.

RELATED RESOURCES

Icon Meaning

Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

MULTIMEDIA DRIVERS

73 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Driver component Description Notes Video Decode Provide DXVA VLD driver based hardware DXVA decode drivers is required for all CODECs for H.264, VC-1, and MPEG 2. decoders where the DXVA spec is defined (for example, H.264, VC-1, MPEG 2). Provide DX9 and DX11 Hardware MFT driver based hardware CODECs for For all other decoders, we recommend MPEG4 Pt. 2. hardware MFT. Audio with Offloading PortCls WaveRT driver exposing offloaded Driver is responsible for any proprietary Support audio capabilities as per the Windows bus (for example: I2S or AC97) control. audio offload changes. Video Encode Provide HMFTS with WDDM driver to expose encoder through MF as documented on MSDN. Driver must support encoding, streaming, and synching to device for the H.264, VC- 1, and MPEG-2 format. Hardware Video Provided DX11 graphics driver with Video Hardware supports video processor Processor (transcoding) ProcessBlt or DXVAHD functionality. (resizing, de-interlacing, frame rate conversion, color format conversion). Streaming and Still Provide AVStream driver for the camera I2C/CSI bus driver may be needed to Video Capture as documented on MSDN. Expose three expose each of the cameras. Additional separate pins: preview, video and image. camera-specific processing components in hardware (for example, face detection or USB video class compliant image enhancements) must be exposed implementations can use the in-box driver as part of the AVStream driver. if using the USB bus.

If a capture driver supplies an MFT

74 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Capture Plug-in, it must use the same media type exposed by the capture driver. Audio CODEC and MP3 decoder The CODECs listed must be exposed as Processing Support AAC decoder AVStream KsFilters. WMA decoder Sample rate converter

AUDIO AND VIDEO PROCESSING

While using several apps simultaneously, consumers expect a responsive system and glitch-free media performance. When additional processors are available on the PC, for example GPUs and discrete hardware codecs, they can handle audio and video processing. Using additional processors allows the main CPU to be used for other tasks, thus maintaining system responsiveness, ensuring solid media performance, and improving battery life.

 Enhanced media pipeline. Windows includes logic to determine the most appropriate A/V processing path (for example, hardware offload versus multi-core CPU processing) to optimize performance and battery life based on system capabilities. This A/V processing noticeably improves performance in scenarios involving A/V encoding and transcoding, such as streaming Digital Living Network Alliance (DLNA) content, transferring content to portable devices, and uploading content to cloud-based services.  Video processing. We recommend including support for HDMI + high definition content protection (HDCP) to playback protected content. The following table summarizes the recommended options for HDMI:

Feature Remarks HDMI Version 1.4

 Video post-processing. Image stabilization functionality benefits consumers by enhancing user-generated video content from camcorders and cell phones. Automatic image reorientation allows users to capture video while holding capture devices in either portrait or landscape mode.

75 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

MICROPHONE, PRE-AMPLIFIER, DRIVERS, AND SYSTEM

Speech provides several benefits to the user and is an effective input mode for hands-free interaction, social communication, Windows navigation, and text entry. We recommend a microphone that complies with the Microsoft USB Audio 1.0 design guidelines.

The microphone system specifications below are directly measurable in end products. The microphone Hardware and Mechanical guidance reflects component selection and system design rules that have proven important for achieving system performance goals.

You should perform microphone testing in accordance with IEEE Std. 1329-2010, including the specified test table and an anechoic chamber with an overall A-weighted background noise level of less than 29dB(A). Specific test methodologies are described in the Rev G Optimized for Microsoft Lync Logo requirements specs.

For reference, the two figures below describe the test setup for tablets and convertibles. For tablets, use the built- in stand to place the tablet on the table. If no built-in stand is available, you should place the tablet at an angle of 70 degrees as shown in Error! Reference source not found.d.

Figure 2: Test setup for convertibles and clamshells

76 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Figure 3: Test setup for tablets and all-in-ones

HARDWARE Feature Remarks Microphone type At a minimum, provide a single omni-directional microphone.

Optionally, provide two cardioid microphones if dual microphone noise suppression is supported, with one microphone facing forward and the other facing back. Noise cancellation effects must conform to HCK requirements for discovery and end user control. Microphone SNR >60dBA Microphone sensitivity -26dBFS +/- 3dB for digital microphone or analog microphone together with ADC measured at 1kHz with 94dBSPL measured at 0.5m distance from the microphone Microphone frequency response [100,12000] Hz +/- 4 dB Microphone phase response tolerances [100,12000] Hz +/- 10 degrees (only applicable if using front/back microphone combination)

77 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Microphone high-pass filter cut-off -3dB at 100Hz for analog microphone -3dB at 60Hz for digital microphone Microphone high-pass filter slope Better than 18 dB/oct ADC sampling rate (only applicable on 48kHz , synchronized for all ADCs analog microphones) ADC or digital mic sampling Better than 1/64th of the sampling period synchronization (only applicable if using front/back microphone combination) ADC/DAC synchronization or Digital Within 0.2 microseconds mic/DAC synchronization AD/DA anti-aliasing filter Integrated ADC/DAC resolution ≥16bits

MECHANICAL

The following are microphone design considerations.

TABLET FORM FACTOR

If a dual channel noise reduction algorithm is not available, use one omni-directional microphone. You should center it on top of the device (when the device is in landscape orientation) to provide a good pick of speakers in the front and back of the device. This positioning also prevents blocking the microphone and places it the farthest possible distance from the speakers.

78 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Figure 4 - One microphone configuration (front)

If a dual channel noise reduction algorithm is available on the SoC, two cardioid microphones are preferred. The front microphone should face the user and the rear microphone should face away from the user. You should center them on top of the device (when the device is in landscape orientation) to provide good conversational and noise pick up front and back of the device. This also prevents blocking the microphone and places it the farthest possible distance from the loudspeakers. This configuration allows the application of dual microphone noise reduction algorithms, which use one of the microphones as a reference signal for the background noise.

79 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Figure 5 - Two microphone configuration (front)

Figure 6 - Two microphone configuration (rear)

CLAMSHELL FORM FACTOR

80 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Similar to the tablet form factor, choose a single microphone or dual microphone solution based on the availability of a dual channel noise suppression algorithm. Locate it similarly as you would for tablet form factors. See Error! Reference source not found. and Error! Reference source not found. below.

Front mic

Figure 7 - Two microphone configuration for clamshell form factor (front)

81 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Rear mic

Figure 8 - Two microphone configuration for clamshell form factor (rear)

ALL-IN-ONE FORM FACTOR

Similar to the tablet form factor, choose a single microphone or dual microphone solution based on the availability of a dual channel noise suppression algorithm and the location recommendation is the same as for tablet form factors and is shown in Error! Reference source not found. and Error! Reference source not found..

82 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Front mic

Figure 9: All-in-one form factor recommended front microphone position

83 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Rear mic

Figure 10: All-in-one form factor recommended rear microphone position for two-microphone configuration

SYSTEM Feature Remarks DC offset +/-15% of peak value Sampling frequency accuracy Error < 0.02% Glitch frequency No glitches in 5 minutes. Glitch is defined as missing or insertion of one or more audio samples.

84 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Timestamp error2 Timestamp Capture Loo pback Render stream err or stream stream Maximum < 0.5ms <0.5 ms <2 ms err or Standard <0.04 ms < 0.04ms N/A deviation

Mouth to ear latency ≤20ms when using raw capture/render mode (i.e. no on-board processing) and excluding timestamp latency ≤60ms when using raw capture/render mode (i.e. no on-board processing) ≤100ms when including on-board processing Unreported latency by timestamps The microphone and loudspeaker loopback signal timestamps need to be accurate enough so that after aligning the two audio streams, the latency, which is unreported by the timestamps, is between 0 ms and

2 Timestamp

Timestamp is determined by device streaming positions (DevPos), app streaming position (AppPos) and system performance counter (QPC: query performance counter).

 DevPos: Device streaming position is the count of samples that device has captured/rendered. For USB audio devices, this position is reported by USB audio driver. For other types of devices, it is reported by device or driver.  AppPos: App streaming position is the sample counts that app has received from audio APIs (for capture) or sent to audio APIs (for loopback and render).  QPC: Performance counter is used as a high resolution timer. QPC time should be queried at the same time that the device stream position is queried. In practice it is done one after the other.

For any capture or render frame in an app, there is an associated app stream position. Assuming that the audio stream sampling rate is FS, the time stamp is calculated as: TS=QPC+(AppPos-DevPos)/FS.

85 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

20 ms. Analog microphone gain and If digital microphones are used, implement no analog microphone gain microphone boost and microphone boost. This should be verified using the API IAudioEndpointVolume::QueryHardwareSupport Microphone analog gain accuracy ( if +/-3% (per HCK) analog gain is implemented)3 Microphone analog gain app time ≤200 ms delay (if analog gain is implemented) Send directivity The following specifications are given in terms of the attenuation of the IEEE 269-2010 uncompressed male speech signal with respect to the 0 degree position. The test averages the signal power over all frequencies. This should be measured at 30 degree increments measured counter-clockwise from the device center position. The measurement shall be done at 0.5 meters from the device center position.

The directivity requirements must comply in raw mode (i.e. without on-board processing) and default mode (i.e. including and potential on-board processing)

Mic endpoint Desired directivity Front Attenuation within ±30, ±60 degrees: ≤3 dB with respect to 0 degree position (i.e. front beam) Back Attenuation within ±120, ±150, 180 degrees:

3 Microphone analog gain: analog microphone gain support is recommended for analog microphones to accommodate a variety of input signal levels.

86 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

≤3 dB with respect to 0 degree when using front mic endpoint (i.e. back beam) Combined Attenuation for ±30, ±60, ±120, ±150, 180 degrees: ≤3 dB with respect to 0 degree position (i.e. either figure 8 beam or omnidirectional)

Send frequency response (microphone +/- 5dB [100Hz, 12000Hz] and soundcard) Send output level -32dBFS +/- 4dB measured with IEEE 269-2010 uncompressed male speech rendered with an artificial mouth at 0.5m distance. The render signal level at the mouth reference point of the artificial mouth is 89dBSPL. The microphone gain slider exposed by Windows should be used to meet the target level. For analog microphones this should control the gain of the pre-amplifier and for digital microphones the Windows OS will automatically add a digital amplification factor. Send noise ≤-54dBFS, A-weighted Send noise requirement is normalized to -24dBFS speech signal level which is commonly used by VoIP applications. The following formula is applied:

푆푒푛푑 푛표푖푠푒 = 푆푒푛푑 푛표푖푠푒푚푒푎푠푢푟푒푑 − (푆푒푛푑 표푢푡푝푢푡 푙푒푣푒푙푚푒푎푠푢푟푒푑 − 24푑퐵퐹푆) Send single frequency interference ≤-70dBFS, A-weighted Send distortion and noise Send Level at Mouth Send Ratio Send Ratio (measured using 1/3rd octave band reference point at 315 Hz at 400Hz, 800Hz, limited white noise sequences) (MRP) (dB) 1600Hz, 2500Hz (dBSPL) (dB) 74 18 20 79 22 24 84 24 26

87 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

89 24 26 94 24 26 99 24 26

Speaker-microphone coupling total THDN > 32 dB harmonics distortion and noise (Coupling THDN) Coupling clipping No clipping at microphone signal at maximum loudspeaker volume (full scale). If adjustable analog gain is implemented and is exposed to the operating system then the no clipping requirement needs to be met at least at minimum analog gain. Weighted Terminal Coupling Loss 푻푪푳풘 = 푻푪푳풘풎풆풂풔풖풓풆풅 (TCLw) + (푴풆풂풔풖풓풆풅 풔풆풏풅 풍풐풖풅풏풆풔풔 − 풔풆풏풅 풍풐풖풅풏풆풔풔 풓풆풇풆풓풆풏풄풆)

TCLw >-10dB (without acoustic echo canceller) measured at nominal receive output level

TCLw > 45dB (in case an acoustic echo canceller is included in system on chip ) measured at nominal receive output level On-board processing of microphone Any processing needs to conform with the HCK discoverability and signal via multi-microphone algorithms control requirements in the Device.Audio.Base.AudioProcessing requirement.

To allow VoIP applications to take advantage of on-board processing, the hardware ID for the device has to be populated in the system management BIOS (SMBIOS). According to the white paper from the manufacturer, family, product name and SKU number must be populated so Skype and Lync can enable on-board processing for that

88 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

device.

For multi-microphone processing algorithms, the only control exposed to the user is the on/off switch. No customization of the processing is allowed as the applications cannot reverse this user modification via any existing Windows API and this may lead to echo in VoIP calls.

Desired on-board processing characteristics for multi-microphone Mic Endpoint Mode Desired Processing algorithms Front Raw No processing

Default Noise suppression, AEC

Back Raw No processing

Default Noise suppression, AEC

Combined Raw No processing

Default Noise suppression, AEC

Note that the on-board processing also needs to meet the send directivity requirements which are given further above.

89 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

AUDIO AND SPEAKERS

Consumers want high-fidelity sound as it is an integral part of their entertainment, gaming, and social experiences on their PC. It’s important to choose speakers capable of producing high-fidelity and immersive experiences. Business users are more often using devices for audio/video conferencing and also expect the same high fidelity and immersive experience. The following sections provide guidelines to consider when selecting speakers.

The speaker System specifications below are directly measurable in end products. The speaker Hardware and Mechanical guidance reflects component selection and system design rules that have proven important for achieving system performance goals.

You must perform speaker testing e in accordance with IEEE Std. 1329-2010, including the specified test table and an anechoic chamber with an overall A-weighted background noise level of less than 29dB(A). The Rev G “Optimized for Microsoft Lync” logo requirements specs describe specific test methodologies. The test setup is also described in Section Error! Reference source not found..

HARDWARE

Feature Remarks Speaker count Two (stereo) or more

Speaker frequency response [300, 12000]Hz ±4dB

Speaker total harmonic distortion <3% for [300,12000]Hz measured with volume set at 80dB SPL at 0.5m (THD) at 1kHz

DAC sampling rate 48 kHz

90 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

MECHANICAL

TABLET FORM FACTOR

You should point speakers orthogonal to the screen and toward user. Alternatively, you can separate tweeter and mid-range where mid-range is pointing parallel to screen and tweeter is pointing toward user. Refer to the following figures.

Speaker grill open greater than 50 percent

Tweeter

Mid-range Speakers

Figure 11 – Speaker placement

CLAMSHELL FORM FACTOR

Position speakers at the front of the device to achieve maximum separation from the microphones. You should point the speakers towards the user for good acoustic frequency response. They shouldn’t point down towards the table, as this attenuates the high frequencies.

91 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Figure 12: Left: Speaker location for clamshell form factors; Right: speaker grill

For headphones, include a user-accessible 3.5 mm headphone jack that exposes the endpoints as active and available when plugged in, or unplugged when not plugged in.

ALL-IN-ONE FORM FACTOR

The recommended speaker locations for all All-in-one form factor is shown in Error! Reference source not found..

92 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Speakers

Figure 13: All-in-speaker recommended speaker location

SYSTEM

Feature Remarks Glitch frequency No glitches in five minutes; a glitch is defined as missing or insertion of one or more audio samples Receive directivity The following specifications are given in terms of the attenuation of the IEEE 269-2010 uncompressed male speech signal with respect to the 0 degree position. The test averages the signal power over all

93 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

frequencies. . The measurement shall be done at 0.5 meters from the device center position. Attenuation within ±45 ≤3 dB degrees

Receive frequency response (speakers +/-5dB [300Hz, 12000Hz] and sound card) Equalization (EQ) may be used to correct the frequency response if the deviation from the mask is less than ±6dB. If an EQ is used to correct for larger deviations then increased quantization noise may prevent meeting the receive noise recommendations. Receive Loudness >65dBA SPL measured at 0.5m with -24dBFS IEEE 269-2010 uncompressed male speech Receive noise ≤40dBA measured at user position Receive single frequency interference 10dB quieter than receive noise level Receive distortion and noise Receive level at the Receive Ratio at Receive Ratio at (measured using 1/3rd octave band digital interface 315Hz (dB) 400Hz, 800Hz, limited white noise sequences) (dBFS) 1600Hz, 2500Hz (dB) -36 18 24 -31 20 26 -26 20 26 -21 20 26

Nonlinear processing in the audio driver Include all non-linear processing in the loudspeaker loopback signal. or power amplifier This also applies to processing in the power amplifier which needs to be routed to the OS via I2S bus.

RELATED RESOURCES

94 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Icon Meaning //B Your Windows Store App, Video and Audio //B Capturing Personal Photos, Video and Audio in Windows Store Apps Design Guidelines for Play To Receivers Streaming media to devices using Play to Quickstart: Using PlayTo in applications Quickstart: streaming a slide show using Play To App contracts and extensions Windows Media.PlayTo Namespace Exposing Hardware-Offloaded Audio Processing in Windows KSPROPSETID_AudioEngine IAudioClient2 interface Audio Devices Multichannel Formats for Home-Theater Systems Exploring the Windows Vista Audio Engine Bluetooth Bypass Guidelines for Audio Driver Developers Streaming Media Devices AVStream Overview Hardware Codec Support in AVStream Audio Playback in a Windows Store App Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

IMAGE CAPTURE

Integrated cameras are expected to deliver, but aren't limited to, these scenarios:

 Local preview (viewfinder)

95 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Taking a photo (image capture)  Recording a video (video capture)  Real-time communication (video chat)

HARDWARE AND FIRMWARE

The platform hardware must have these controls:

Feature Controls Capture DSP Exposure Brightness Contrast White balance Location The ACPI stores location and orientation information as documented in the Windows Hardware Certification Requirements. The platform hardware must support at least 720p 30fps video capture.

For firmware guidance, refer to Windows Hardware Certification requirements.

DRIVER

Image and video capture and processing devices must implement an AVStream driver. The Windows Hardware Certification requirements for System.Client.Webcam covers driver implementation and requirements.

CAMERA SUBSYSTEM PART SELECTION AND QUALITY

Camera subsystem (sensors, modules, firmware, and all parts involved) must meet the quality bar set in the System.Client.Webcam.Specification.Camera requirements.

96 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Specifically, camera sensors must meet the following requirements:

Parameter Requirement Notes Busses See Hardware Configurations Image resolution Notebook: 720p front Tablet: 1.2MP front, 5 MP rear Video resolution Front: At least 720p (required to support 30fps @ 80 lux 1280x720, 640x480, and 640x360) Rear: At least 1920x1080 Vertical field of view Front: At least 35° Rear: At least 25° Spatial resolution Between MTF30 and MTF80 The Modulation Transfer Function is the magnitude of the Optical Transfer Function. MTF30 is the cycles/pixel where the MTF=30%, generally considered to be the lowest acceptable MTF for imaging. Luminance range Y=128 +/- 40. The sensor must be able to automatically adjust its exposure and gain for a good quality image. When viewing a neutral gray (reflectance=18%) image, the resultant image should also be neutral gray, that is, have a luminance value near 128. SNR10 Less than 50 lux at native sensor resolution Anti-glare coating Recommended

The USB peripherals and Lync PC test specifications on TechNet describes the test setup and methodology for most of these requirements.

97 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

For rear cameras, if an MIPI connection is used, the camera sensor and module must support and use 4 MIPI CSI lanes.

Front cameras must include a usage indicator. You should choose a neutral indicator color and make sure its placement doesn't cause the camera's veiling glare or dynamic range measurements to fail. The distance between the camera and the indicator depends on the optics used such as lens coating and cover glass.

We recommend that centering the front-facing camera on the top of the device's front bezel.

Camera

Front-facing camera on a laptop

98 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Camera

Front-facing camera on a tablet

Camera

Front-facing camera on an all-in-one

SYSTEM

99 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

All System.Client.Webcam requirements must be met, which includes the System.Client.Webcam.Specification.CameraRequirements, which is marked as discretionary in the Windows certification documentation.

WINDOWS STORE DEVICE APP FOR CAMERA

We strongly recommend that a platform containing one or more embedded cameras include an OEM-provided Windows Store Device App for Camera. This provides users with a separate experience and lets the OEM extend the Windows platform by having custom camera-specific effects (and OEM branding) appear within the "Advanced Settings" context of in-box and third-party Windows Store camera apps and in-box image/video capture workflows. The Windows Store Device App can also include value-added features like photo/video editing, video overlays, special printing effects, integration with on-line photo sharing sites, etc. This also lets the OEM monetize the camera experience through such channels as in-app purchases, app feature upgrades, and third-party business relationships (for example, photo printing), creating a new value chain and potential OEM revenue source.

The components required to deliver a custom camera experience are:

100 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Component Description Owner OEM Windows Store Device App App delivering value-added features and OEM for Camera effects for integrated cameras Device metadata package Binds the OEM Windows Store Camera App OEM to the built-in camera, ensuring that settings are properly mapped to the device in Windows. Media Foundation Transform Media transformations required to IHV or OEM depending on Driver ("Driver MFT") implement custom effects in camera's video degree of differentiation bit stream Camera driver Provides Windows access to camera Use Windows camera class driver, or OEM provides custom driver

The Related resources section below contains links to the necessary white papers and code samples for creating Windows Store Device App for Cameras.

COMMON LYNC AND SKYPE VIDEO ISSUES

The following table lists the most common video issues encountered by Lync and Skype for video calls on Windows notebooks and tablets.

101 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Issue Impact Solution Low frame rate Video is jerky and has severe motion blur Adjust AGC/AEC so >= 15 FPS High image noise CODEC requires >> bitrate Use image sensor with SNR10 < 50 lux Degrades image quality Poor veiling glare Images are washed out with low contrast Use/improve AR coating Don't put camera behind uncoated Gorilla Glass Poor color uniformity Image center is red or blue Improve color uniformity correction Poor image acuity Image is blurry or edges are jaggy Improve lens MTF Improve image scaling

RELATED RESOURCES

Icon Meaning //B Building a great Windows Store device app for your camera //B How to declare your app's capabilities //B Media Fundamentals of a Communications App Developing Windows Store Device Apps for Cameras Media Capture Sample Camera Capture UI Sample Windows.Media.Capture Namespace Application Verifier Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

BUILDING A GREAT DEVICE FOR APPS

102 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

CONSIDERATIONS

Devices should provide an appropriate amount of storage for the user to customize their device with apps. For more information, see the UX Windows Engineering Guide.

RANDOM ACCESS MEMORY (RAM)

For information on RAM configuration guidance, refer to the Hardware Configurations section. Depending on the target usage scenarios and software pre-load, additional RAM may be more appropriate.

Use only low-power memory technology, such as Mobile DDR or LPDDR2, on Connected Standby platforms. Error detection or corrections support is optional.

For traditional platforms, DDR3 is the recommended memory technology.

TOOLS AND TECHNICAL REFERENCE

For more information about selecting and developing apps for your customers, see the Apps and Store Windows Engineering Guide.

Apps can have a significant impact on the performance of your device when they are not developed efficiently for your hardware. For more information about assessing and optimizing the performance of apps on your device, and selecting energy efficient apps, see the Performance Windows Engineering Guide.

BUILDING A DEVICE WITH GREAT HUMAN FACTORS

HUMAN INTERFACE DEVICES

103 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

BUTTONS

On Connected Standby capable platforms, buttons must be connected through GPIO. Button interrupts must be non-shared (Exclusive), edge-triggered (Edge) and capable of signaling an interrupt on both edges (ActiveBoth).

POWER

The power button, whether implemented as an ACPI Control Method Power Button or as part of the Windows- compatible Button Array, must be able to power-up the system and also generate the Power Button Override Event (Section 4.7.2.2.1.3 of the ACPI 4.0a specification) when held down for 4 seconds.

WIRELESS RADIO CONTROL

The Wireless Radio Control button can be implemented over HID. The hardware sends a HID report descriptor to the Radio Management API with information about the state of the switch or button. Three new HID usage IDs will be defined and standardized with the USB-Implementers Forum (IF) for 'All wireless' radios switches and buttons. The usage IDs are for: hardware radio slider switch, hardware radio button, and radio LED. The behavior of the switch is as follows:

 Send a HID message when its state changes.  HID then broadcasts a corresponding Windows Message with a specific usage ID for the wireless radio state.  The radio management API consumes this message and updates the user interface (UI) accordingly.  If the change is made by the user through the UI, the HID will support bi-directional communication and update the current state in the hardware.

For more information, see General-Purpose Input/Output (GPIO) in this document.

104 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

CONSUMER PAGE HID CONTROLS Usage Description Control type 0xB5 Scan Next Track One Shot Control (OSC) 0xB6 Scan Previous Track OSC 0xB7 Stop OSC 0xCD Play/Pause OSC 0xE0 Volume Linear Control (LC) 0xE2 Mute On/Off Control (OOC) 0xE9 Volume Up Re-trigger Control (RTC) 0xEA Volume Down Re-trigger Control (RTC)

105 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

KEYBOARD AND TOUCHPAD DEDICATED KEYS

Windows features defined charms for settings, search, share, etc. OEMs who want to integrate these charms (in the form of dedicated buttons) on their keyboard can do so using the following language (i.e. keyboard layout) agnostic Windows key-combination definitions.

CHARMS AND HOTKEYS

Windows uses a toolbar that incorporates “charms” which display as colorful tiles on a beautiful, yet clean, interface a user can pan, zoom, and swipe with a touch of a finger. The power of charms is not limited to touch devices only; touch and non-touch device users both win with the latest version of Windows. Benefits include easy access to apps, device management and customization, and quick search across apps.

For example, if a user wants to search for a photo, Windows not only searches Windows Photos, but any application that may contain photos such as social media, SkyDrive, etc. Most of these benefits a user sees with a swipe of the finger or click of a mouse, but, like previous versions of Windows, hotkeys offer an even quicker way to take advantage of the Windows interface. Because hotkeys have played a role in building the Windows experience into what it is today, it is only reasonable, if not expected, to continue this practice of building devices with configured hotkeys.

You must program the agnostic configuration as it’s not tied to a specific language and, therefore, is universal.

We recommend that if you implement a limited set of hotkeys on your device keyboard, you choose to implement the app bar (Windows logo key + Ctrl + F23) and bring up Search (Windows logo key + Shift + F21).

We recommend that you do not implement a hotkey for only one of the charms.

Typically, you would implement the following four charms in the following order:

1. Search 2. Share

106 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

3. Devices 4. Settings

If you want to implement additional, popular keys, implement them in the following order:

1. Show list of recently used apps 2. Rearrange/Placesetter 3. Back

We recommend you use keys F5 through F8 if hotkeys are implemented as a secondary function of function keys.

Charm Layout Agnostic Description Combination Search charm Windows logo key + SHIFT Opens the Seach charm and search file + F21 Share charm Windows logo key + ALT + Opens the Share charm F21 Settings charm Windows logo key + F21 Opens the Settings panel Devices charm Windows logo key + CTRL+ Opens the Devices charm F21 Show charms Windows logo key + Alt + Launches the Charms bar F23

In addition to charms, OEMs can optionally support other features, such as display switching and the app bar, on their keyboard or touchpad.

107 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Feature Layout Agnostic Description Combination Display switch Windows logo key + F22 Selects a presentation display mode Display switch Windows logo key + Ctrl + Cycles through display modes (forward order) sticky F22 Display switch Windows logo key + Shift + Cycles through display modes (reverse order) reverse F22 Back Windows logo key + Ctrl + Goes back through the display mode Backspace Show list of Windows logo key + Ctrl + Displays a list of recently-open apps recent apps Tab

Appbar Windows logo key + Ctrl + Shows the commands available in the app F23

FIRMWARE

Systems with an integrated keyboard must implement the ACPI Control Method Power Button (Section 4.7.2.2.1.2 of the ACPI 4.0a specification). Systems without an integrated keyboard must implement the Windows-Compatible Button Array control method device. Features for this device are listed below.

 Must contain the _CID of PNP0C40  Must list its GPIO interrupt resources in the _CRS object in the following order: 1. Interrupt corresponding to the power button. 2. Interrupt corresponding to the Windows button.

108 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

3. Interrupt corresponding to the volume up button. 4. Interrupt corresponding to the volume down button. 5. Interrupt corresponding to the rotation lock button.

For more information, see General-Purpose Input/Output (GPIO) in this document.

RELATED RESOURCES

Icon Meaning Tablet PC Button Driver Sample

KEYBOARD AVAILABILITY INDICATORS

Windows 8 introduced support for GPIO Buttons and Indicators via a HID miniport Class driver. The goal was to provide support for key buttons (Power, Windows, volume and rotation lock) in a standardized way with associated corresponding Windows Engineering Guidance (WEG).

Windows 8.1 is focused on enhancing the quality of the End-To-End user experience and unifying the behavior across various innovative form factors.

As part of Windows 8.1 investments, the msgpio button driver is bringing a number of important enhancements:

1. Augmented logging to speed up investigations 2. Improved synchronization and error handling to enhance the robustness. 3. The new ConvertibleSlateMode Unattended Windows Setup to be used on non-GPIO laptops in order to statically set the mode to laptop as part of the OEM image customization.

109 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

GENERAL CONSIDERATIONS

Architecture considerations

Non-GPIO/traditional. This architecture requires button reporting be done through a human interface device (HID)-compliant firmware that exposes the collections necessary to integrate with Windows OS.

System on a Chip (SOC)-based architecture. This architecture typically Includes GPIO support. We recommend to leverage the in-box GPIO button driver through Advanced Configuration and Power Interface (ACPI) entries that define the GPIO resources for each button.

STATE INDICATORS

BEHAVIOR AND GUIDANCE

The states of the two indicators available (Mode and Docking) play an important role in determining the user experience around

- Touch keyboard experience - Screen auto-rotation.

There are a few key scenarios to take into account when determining the modes to be reported for the indicators. The expected behavior is described in the table below:

110 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Mode Indicator Dock Indicator On screen keyboard Auto-rotation enabled

displayed

1 Laptop Undocked No No

2 Laptop Docked No No

3 Slate Undocked Yes Yes

4 Slate Docked Yes No

111 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

When the system is in Slate mode:

 Touch Screen Keyboard is auto-invoked  Rotation lock is unlocked (unless previously locked by the end user)  Rotation lock can be toggled  Display can freely rotate

When the system is in Laptop mode:

 Touch Screen Keyboard is suppressed  Rotation is set to landscape and locked  Rotation lock cannot be toggled  Display cannot freely rotate

In order to match this behavior, the mode and dock indicators need to be implemented following the guidance described in the table below:

112 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Indicator States Implementation guidance

Mode Laptop Report laptop if a keyboard is attached and the user can type to it. They

must have complete access and be able to use it comfortably. (For

convertibles, the system can be folded as clamshell or equivalent mode

from keyboard access perspective)

Slate Report Slate if the physical keyboard is not available to the user. (This

includes the case where they don’t have complete access or they can’t

type comfortably.)

Dock Docked Report Dock if the system is stationary (attached to a docking system or

113 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

a port replicator, power supply does not apply as long as the system

can be moved freely).

Undocked Report undocked if the system is not stationary. This applies to the case

of having the device connected to general power supply as it can still

be freely moved.

IMPLEMENTATION REQUIREMENTS FOR VARIOUS FORM FACTORS

Form Factor Definition Requirements on GPIO indicator implementation 1 Slate Tablet form factor with no Need to implement the attachable keyboard docking indicator

3 Laptop Permanently attached Required to statically set the keyboard that is always mode to laptop available for typing

114 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

2 Convertible System that can be used as Both docking and either a slate or a tablet as laptop/slate indicator need their keyboard can be de- to be implemented attached/flipped/swiveled

4 All-In-One These are medium size No implementation desktop/semi-portable required, the keyboard is an systems that have a keyboard optional accessory attached as an accessory

CONSIDERATIONS FOR CONVERTIBLES: TIMING AND PERFORMANCE

Convertible systems are a much enjoyed choice for many users as it gives them the option to have both a slate and a laptop within one system. This is an exciting space for innovation but here we’ll try to give examples of a few popular ways of creating the transition just to help distinguish between the laptop and the slate mode.

The main criteria for distinguishing when a convertible is used as a laptop and when is used as a tablet is strictly determined by the presence of a keyboard. The generic rule to follow is to consider a convertible being a laptop when the keyboard becomes fully accessible to the user and she/he may be able to comfortably type in a natural position.

An important aspect to consider when triggering a mode or docking change is to ensure no undesired state changes were sent as a mode or docking change happens. From this perspective one simple approach would be to trigger an indicator change as soon as the system has reached a new stable state but not sooner.

The general rule is to trigger the indicator mode change after the user finished their action and the system is fully transitioned into the new mode.

Mode indicator examples:

115 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

- Attach/detach keyboard - Flip the screen - Swivel the screen - Slide the screen to cover/uncover the keyboard

Dock indicator examples

- Attach to a classic docking system - Attach to a port replicator

Performance guidance: To provide an optimal user experience the state indicator change should be a fast user experience. The state change notification should be sent no later than 200ms after the system reached the new state.

The following two examples for convertibles start with the laptop mode and describe the optimal timing where the indicator state should be toggled:

116 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

1.1.1 KEYBOARD ATTACH AND DEATACH CONVERTIBLE

1.1.2 SCREEN SWIVEL CONVERTIBLE

117 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

PHYSICAL BUTTONS

Hardware buttons enable users to perform many common tasks that do not have a convenient user interface alternative. For the purposes of the scenarios addressed in this paper, the hardware buttons are typically used for

118 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

tasks that occur while the physical keyboard is not available to the user on form factors such as convertibles, slates, etc.

BEHAVIOR

System can expose the following set of buttons to the users:

Required Buttons Optional buttons 4. Rotation Lock Button 1. Power Button

2. Volume +/- Buttons 3. Windows Button

Please see in the following table the expected behavior for each of the buttons.

Button or Combination Press Experience Press and Hold Experience Windows Navigate to Start Screen N/A

Volume Up Increase volume Rapid Volume Increase Volume Down Decrease volume Rapid Volume Decrease Rotation Lock Rotation Lock Toggled N/A Power Power on Connected Standby systems Connected Standby HoldTime<2s : enter CS 2<=HoldTime<=10s : slide to power off UX HoldTime>10s : power off Non – Connected standby systems

119 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Holdtime< 4s :enter sleep [optional] Holdtime>=4s :power off the device

Windows + Volume Up Launch/Exit Narrator N/A Windows + Volume Down Perform a screen capture N/A Windows + Power Secure attention sequence N/A (Display lock screen)

The in-box GPIO button driver reports to the operating system based on the interrupts that are received on the defined GPIO resources of the button array. See the official ACPI 5.0 specification for additional details.

BUTTON REPORTING

GPIO button reporting

The in-box GPIO button driver reports to the operating system based on the interrupts that are received on the defined GPIO resources of the button array.

Button Requires _CRS Requires On-SOC GPIO Edge Reporting (assuming Wakeable ActiveLow) Windows Yes Yes Both Volume Up Yes Yes Both Volume Down Yes Yes Both Rotation Lock No Yes Both Power Yes Yes Both

120 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The in-box GPIO button driver reports the button presses and combinations listed above.

Non-GPIO based button reporting

All non-GPIO based implementations must follow the same reporting scheme.

Order of definition is Power, Windows, Volume Up, Volume Down, and Rotation Lock. For examples of how to create HID descriptors for these please refer to the code samples section below: Error! Reference source not found.

Note: Previous requirements outlined the use of Win + “O” for Rotation Lock. Although this combination is still functional, it is not impervious to keyboard layout changes, whereas Win + F14 is layout-agnostic.

Individual Button Source Usage Requirements Report Trigger Repeated? Reporting Power System Control 0x84 (Power) Physical Button – Up No

Windows Keyboard 0xE3 (Win) Physical Button – Up No

Volume Up Consumer Collection 0xE9 (Volume Up) Physical Button – Down Yes

Volume Down Consumer Collection 0xEA (Volume Down) Physical Button – Down Yes

Rotation Lock Keyboard 0xE3 = 0x69 (Win + F14) Physical Button – Down No

121 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The following keyboard combinations must be reported based on their completion and should not be repeated if the combination is held.

Button Combination Usage Requirements Report Trigger Repeated? Reporting

Windows + Power 0xE0 + 0xE2 + 0x4C Physical Power Button – Down No (Ctrl + Alt + Del)

Windows + Volume Up 0xE3 + 0xE0 + 0x69 Physical Volume Button Down No (Win + Ctrl + F14)

Windows + Volume 0xE3 + 0x6A (Win + F15) Physical Volume Button Down No Down

INTERFACE IMPLEMENTATION GUIDANCE

Available interfaces and related APIs

There are 3 interfaces one for each device and each interface is referenced by a GUID.

1. /* 30ebfbf8-df5f-4d4d-9fc5-a26c7fd1df4a */

DEFINE_GUID(GUID_GPIOBUTTONS_NOTIFY_INTERFACE, 0x30ebfbf8, 0xdf5f, 0x4d4d, 0x9f, 0xc5, 0xa2, 0x6c, 0x7f, 0xd1, 0xdf, 0x4a);

2. /* 317fc439-3f77-41c8-b09e-08ad63272aa3 */

122 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

DEFINE_GUID(GUID_GPIOBUTTONS_LAPTOPSLATE_INTERFACE, 0x317fc439, 0x3f77, 0x41c8, 0xb0, 0x9e, 0x08, 0xad, 0x63, 0x27, 0x2a, 0xa3);

3. /* a84e689b-0dce-493a-a164-acde05478fc3 */

DEFINE_GUID(GUID_GPIOBUTTONS_DOCKMODE_INTERFACE, 0xa84e689b, 0x0dce, 0x493a, 0xa1, 0x64, 0xac, 0xde, 0x05, 0x47, 0x8f, 0xc3);

The interfaces above allow any one of the following buttons or indicators to be toggled in state by calling WriteFile against the respective device interface. Please note that a handle to the device is for exclusive access to prevent potential conflicts between multiple providers.

typedef enum { GPIO_BUTTON_POWER, GPIO_BUTTON_WINDOWS, GPIO_BUTTON_VOLUME_UP, GPIO_BUTTON_VOLUME_DOWN, GPIO_BUTTON_ROTATION_LOCK, } GPIOBUTTONS_BUTTON_TYPE;

INDICATOR IMPLEMENTATION

With sensor placement and related logic being specific to various systems, it is important to update the mode when the system is doing any related power transitions

- Coming out of connected standby - Coming out of sleep or hibernate. - After boot

This is going to enforce the correct state and ensure a refresh to the user interface layer.

123 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Laptop/Slate mode: implementation for convertibles

The following diagram summarizes the implementation options for implementing GPIO indicators on a convertible system.

Laptop/Slate mode: implementation for laptops

The following diagram shows the implementation options for the laptop/slate indicator, being required to be implemented on laptops:

124 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The ConvertibleSlateMode Unattended Windows Setup setting allows the OEMs to flag clamshells to laptop mode statically as an image customization, without the need to implement the injection mechanism.

125 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

This is targeting touchscreen systems that have a permanently attached keyboard (that user can use at any time for typing conformably). Our showcase example here would be the touchscreen clamshells that have no GPIO indicators/ injection available.

This setting needs to be applied as part of the specialized configuration passes and can be applied to all client SKUs. Please refer to the code samples section below for more details: Error! Reference source not found.

Notes

- Loading the GPIO button driver would override the value introduced with the unattend setting. - The injection mechanism can still be used with 8.1 systems if desired. - The ConvertibleSlateMode unattend setting does not affect to Windows 8 to Windows 8.1 upgrade scenarios.

- If this setting is not present and the GPIO indicators are not implemented the system defaults to slate mode. - This setting is not available on server SKUs

BUTTON IMPLEMENTATION

The button implementation guidance is to use a physical GPIO resource for both the buttons and state indicators

On systems which do not have a physical GPIO resource for a required/optional hardware button or for a GPIO indicator (laptop/slate mode indication or docked indication), a user mode or kernel mode driver may inject state changes directly to the inbox driver in lieu of a physical hardware resource attributed to either the button array device (_CID PNP0C40), laptop/slate mode state indicator (_CID PNP0C60) or docking state indicator (_CID PNP0C70).

126 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Please note that to use any of the below interfaces, an entry must exist in the ACPI table defining each of the respective device(s) for which the interface is to be utilized against, however the existence of any GPIO resources for a device is optional (please see example ACPI entries below) Error! Reference source not found..

QUERING THE SYSTEM STATE

The default state for all buttons supported by the inbox driver on load is in the “UP” position. The first indication via the interface mentioned above will toggle the specified button (by index) to a state of “DOWN”.

The default state of the laptop/slate mode indicator is “SLATE”.

The default state of the docked mode indicator is “UNDOCKED”.

The first indication via the interface mentioned above will toggle the indicator to the other state.

In order to query the state the GetSystemMetric API can be leveraged as follows:

int WINAPI GetSystemMetrics( _In_ int nIndex );

Parameters available for indicators

1. SM_SYSTEMDOCKED for the docking state. . The call returns 0 for Undocked Mode and non-zero otherwise. 2. SM_CONVERTIBLESLATEMODE for the slate mode. The call returns 0 for Slate Mode and non-zero otherwise.

127 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

NOTIFICATIONS

When either system metric, SM_CONVERTIBLESLATEMODE or SM_SYSTEMDOCKED changes, a broadcast message is sent by the system via WM_SETTINGCHANGE.

The LPARAM of the WM_SETTINGCHANGE message indicates which system metric has changed, with a string of either “ConvertibleSlateMode” or “SystemDockMode”.

CODE SAMPLES

LAPTOP/SLATE MODE TOGGLING BETWEEN STATES

The following sample code will toggle the laptop/slate mode indicator state.

int __cdecl ToggleConversionIndicator( __in int argc, __in_ecount(argc) char **argv) { LPWSTR DevicePath; HANDLE FileHandle; BOOL b; BYTE buffer; HWND hwnd; MSG msg;

//assuming our GetDevicePath method is creating a device path using use SetupDi API DevicePath = GetDevicePath((LPGUID)&GUID_GPIOBUTTONS_LAPTOPSLATE_INTERFACE);

FileHandle = CreateFile(DevicePath, GENERIC_WRITE, 0, NULL,

128 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

OPEN_EXISTING, 0, NULL);

buffer = 0; WriteFile(FileHandle, &buffer, sizeof(buffer), NULL, NULL);

return 0;

}

WINDOWS BUTTON SAMPLE

The following sample code will toggle the Windows button to be identified as down and then subsequently up.

int __cdecl InjectButtonPress( __in int argc, __in_ecount(argc) char **argv) { LPWSTR DevicePath; HANDLE FileHandle; BOOL b; BYTE buffer; HWND hwnd; MSG msg;

DevicePath = GetDevicePath((LPGUID)&GUID_GPIOBUTTONS_NOTIFY_INTERFACE);

FileHandle = CreateFile(DevicePath, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0,

129 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

NULL);

buffer = GPIO_BUTTON_WINDOWS; //using GPIOBUTTONS_BUTTON_TYPE enum defined Error! Reference source not found. WriteFile(FileHandle, &buffer, sizeof(buffer), NULL, NULL); // send button down buffer = GPIO_BUTTON_WINDOWS; WriteFile(FileHandle, &buffer, sizeof(buffer), NULL, NULL); // send button up

return 0;

}

ACPI DESCRIPTOR SAMPLES

ACPI Description for Button Array

Device(BTT00N) { Method(_HID, 0x0, NotSerialized) { Return("ID9000") } Name(_CID, "PNP0C40") Name(_CRS, ResourceTemplate() { GpioInt(Edge, ActiveLow, SharedAndWake, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , RawDataBuffer() {}) {0xE1}

130 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

GpioInt(Edge, ActiveBoth, SharedAndWake, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , RawDataBuffer() {}) {0xE2} GpioInt(Edge, ActiveBoth, Exclusive, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , RawDataBuffer() {}) {0xE3} GpioInt(Edge, ActiveBoth, Exclusive, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , RawDataBuffer() {}) {0xE4} GpioInt(Edge, ActiveBoth, Exclusive, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , RawDataBuffer() {}) {0xE5} }) }

ACPI Description for Laptop/Slate Mode Indicator

131 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Device(CONV) { Method(_HID, 0x0, NotSerialized) { Return("ID9001") } Name(_CID, "PNP0C60")

}

ACPI Description for Docking Mode Indicator

Device(DOCK) { Method(_HID, 0x0, NotSerialized) { Return("ID9002") } Name(_CID, "PNP0C70") }

Note: Please use only 4 chars length for ACPI descriptors for Device definitions such as “CONV”.

HID BUTTON REPORT DESCRIPTORS

0x05, 0x01, // USAGE_PAGE (Generic Desktop) 0x09, 0x06, // USAGE (Keyboard) 0xa1, 0x01, // COLLECTION (Application) 0x85, REPORTID_KEYBOARD, // REPORT_ID 0x05, 0x07, // USAGE_PAGE (Key Codes) 0x09, 0x4c, // USAGE(Del Key) 0x09, 0x69, // USAGE(F14 Key) 0x09, 0x6a, // USAGE(F15 Key) 0x09, 0xe0, // USAGE(Left Ctrl Key)

132 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

0x09, 0xe2, // USAGE(Left Alt Key) 0x09, 0xe3, // USAGE(Left Windows Key) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0x01, // LOGICAL_MAXIMUM (1) 0x75, 0x01, // REPORT_SIZE (1) 0x95, 0x06, // REPORT_COUNT (5) 0x81, 0x02, // INPUT (Data,Var,Abs) 0x95, 0x1a, // REPORT_COUNT (27) 0x81, 0x03, // INPUT (Cnst,Var,Abs) 0xc0, // END_COLLECTION

0x05, 0x0C, // USAGE_PAGE (Consumer devices) 0x09, 0x01, // USAGE (Consumer Control) 0xa1, 0x01, // COLLECTION (Application) 0x85, REPORTID_VOLUME, // REPORT_ID 0x09, 0xe9, // USAGE(Volume up) 0x09, 0xea, // USAGE(Volume down) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0x01, // LOGICAL_MAXIMUM (1) 0x75, 0x01, // REPORT_SIZE (1) 0x95, 0x02, // REPORT_COUNT (2) 0x81, 0x02, // INPUT (Data,Var,Abs) 0x95, 0x1e, // REPORT_COUNT (30) 0x81, 0x03, // INPUT (Cnst,Var,Abs) 0xc0, // END_COLLECTION

0x05, 0x01, // USAGE_PAGE (Generic Desktop) 0x09, 0x80, // USAGE (System Control) 0xa1, 0x01, // COLLECTION (Application) 0x85, REPORTID_POWER, // REPORT_ID 0x09, 0x81, // USAGE(System power down) 0x09, 0x83, // USAGE(System wake up) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0x01, // LOGICAL_MAXIMUM (1) 0x75, 0x01, // REPORT_SIZE (1) 0x95, 0x02, // REPORT_COUNT (2)

133 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

0x81, 0x02, // INPUT (Data,Var,Abs) 0x95, 0x1e, // REPORT_COUNT (30) 0x81, 0x03, // INPUT (Cnst,Var,Abs) 0xc0, // END_COLLECTION

IMPLEMENTING THE UNATTENDED WINDOWS SETUP SETTING

Please use Windows System Image Manager to edit your unattended file, here is a sample of the output file:

LOGGING AND INVESTIGATIONS

LIVE DEBUG PRINTS FROM KD

!wmitrace.start foo -kd ; !wmitrace.enable foo {5a81715a-84c0-4def-ae38- edde40df5b3a} -level 4 -flag 0xFFFFFFFF !wmitrace.stop foo

134 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

LOGGING AND INVESTIGATIONS IFR log from KD:

!rcdrkd msgpiowin32

LogMan:

logman start -ets FOO -p {5a81715a-84c0-4def-ae38-edde40df5b3a} 0xFFFFFFFF 4 logman stop -ets FOO Validations Either IFR log or logman can be used to validate weather the state is being toggled correctly. For example if a dock indicator change is expected the following entry should be found in the log at the time the notification should be triggered. --- start of log --- 10: Indicator_EvtDevicePrepareHardware - Received 0 resource descriptors, assuming indicator status will be injected via WriteFile 11: Indicator_EvtIoWrite - Indicator state change : DockMode_Indicator : old state : NotDocked 12: Indicator_UpdateRegistryValue - Indicator state update : DockMode_Indicator : new state : Docked

EXECUTING TEST PASSES

Our MITT platform has the capability of testing GPIO buttons offering both test automation and the option to customize the GPIO patterns being sent for targeted investigations. For more information on how to take advantage of our testing tool please contact our [email protected] alias.

135 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

To get started please refer to the GPIO buttons testing with MITT platform reference below.

Instructions: Download the installer, unpack its content and review the ReadMe file for a general overview of the tool.

End to End Indicator testing for convertibles

This is an important area to exercise and validate for convertible systems. The goal of these scenarios is to expose any potential issues around:

1. Various timings when converting the system from a mode to another 2. Mechanical specifics of the convertible.

Laptop to Slate conversion test scenario

Setup: Start with the system in laptop mode (keyboard accessible).

Step 1: Press window button to navigate to start. Step 2: Press a letter using the keyboard to bring “Search” experience up Step 3: Tap into the edit filed. Validation: The on-screen-keyboard should not deploy Step 4: Rotate the system (landscape/portrait/back to landscape, etc) Validation: The system should not rotate Step 5: Convert from laptop to slate (the keyboard becomes inaccessible) Example of such actions: swivel or flip the screen, de-attach the keyboard, etc Step 6: Tap in the “Search” edit field Validation: The on-screen-keyboard should deploy Step 7: Rotate the system (landscape/portrait/back to landscape, etc) Validation: The system should rotate

Important note: Repeat the test above for each of distinct ways that the system can be converted into the tablet mode.

136 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

PRECISION TOUCHPAD

Touchpads on PCs today leave a lot to be desired. From missing drivers, to accidental taps while typing, to poor mechanical design, users often choose to turn their touchpad off. Windows 8.1 Precision Touchpads change that, giving users a best-in-breed touchpad experience on Windows PCs.

While touch provides the best experience for directly manipulating user interfaces and lowers the barrier for content consumption, it is not optimized for all productivity needs. Windows believes in optimizing each input mechanism for its strengths, and as such we take advantage of touchpads’ natural precision and other attributes. Precision Touchpads are designed to be used alone or paired with touch, and they are designed to meet users’ growing expectations of the experience on their PCs.

Consistent and reliable

When users sit down at a new PC, the touchpad should work in a familiar and expected fashion. The goal of PTP is to bring that consistency of experience to Windows devices, yet at the same time allow for the exciting breadth of form factors that exist in our ecosystem. Touchpad settings have been added to the modern control panel, providing centralized control in an easy to locate place. Moreover, devices should just work. Users and enterprises do not want to have to find the right driver to get basic functionality. Reliability should be architected for from the ground up. Precision touchpads require no drivers to update, and the experience works out of the box every time.

Familiar, fast, and responsive

Windows 8.1 PTP leveraged the Win8 touch language where it made sense, providing a familiar set of gestures to users. One of the large investments in Win8 touch was in DirectManipulation, the component that powers the buttery smooth pan and zoom experience for touch. That same component is utilized with PTP to provide an amazing pan and zoom experience for touchpads that apps get for free and that competitors cannot match. The

137 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

strengths of touchpads have been optimized – for example, where touch is required to be “stick to your finger”, because touchpads are indirect input devices, there is more flexibility and it can be equally easy to pan very precisely or very quickly to get to the end of a long document. Additionally, the are ecosystem investments in hardware, raising the bar for touchpads. Precision touchpads are more accurate, higher resolution, and lower latency than other devices, and come paired with excellent industrial design.

An experience you don’t want to turn off

One of the top complaints from users is accidental activation. While typing, suddenly a brush of the touchpad will change focus to another app, or the cursor moves and or the text gets chopped up, or worse. Windows 8.1 PTP invests heavily in addressing this problem and ensures the touchpad never gets in the way of what is trying to be accomplished. Addressing this problem permeates all PTP work and includes efforts in avoiding accidental taps, edge gestures, palms and thumbs resting on the touchpad, and more.

A strong guarantee through hardware certification

Precision Touchpads are backed with a strong certification program that guarantees a high quality experience matched with great hardware. The device certification requirements ensure hardware features superior accuracy, resolution, latency, and report rate characteristics. These attributes make the user experience shine. Additionally, Windows collaborated closely with hardware partners around the design and materials used for the experience. The result is an unparalleled integration between materials, hardware engineering, and software platform.

For these reasons, it is strongly recommended that OEMs implement Precision Touchpad on clamshell and convertible form factors, including slates that ship with docks or sleeves.

The touchpad implementation described in this section is based on x86/x64 architecture.

CONSIDERATIONS

138 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

HID protocols

Windows Precision Touchpads are expected to use the Human Interface Device (HID) protocol in order to communicate with the host. A good understanding of the HID protocol is helpful for implementing precision touchpads. For more information, see the Tools and technical references in this section.

Human interface device (HID) refers to either the protocol or the device itself. In this document, HID refers to the device and HID protocol refers to the protocol in definition.

I²C and USB

I2C (Inter-Integrated Circuit) is a multi-master serial single-ended bus that is used to attach low-speed peripherals to the motherboard, embedded. Windows Precision Touchpad hardware may use either I2C or USB buses.

IMPLEMENTATION

DEVICE BUS CONNECTIVITY

For x86/x64 architecture, a Windows Precision Touchpad may utilize either USB or I2C for host connectivity. The following are examples of device configurations.

I2C DEVICES

A Windows Precision Touchpad module is defined as the combination of a controller IC, sensor and any associated mechanics.

An I2C connected Windows Precision Touchpad module shall expose at a minimum the required 5 pins for host connectivity; I2C data and clock lines (SDA and SCL), an interrupt line, and attachment to power rail and ground.

139 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

When connecting to an I2C controller it is important to understand the bandwidth demands of all components sharing that controller. The minimum I2C clock speed of a Windows Precision Touchpad shall be 400KHz. It is highly recommended that touch screen controllers and Windows Precision Touchpad controllers do not share the same I2C controller as this may result in bandwidth demands that exceed bus capability.

It is recommended that the interrupt line (also referred to as ATTN line) is connected to an On-SoC GPIO controller or an IOAPIC. The GPIO or IOAPIC resource where the interrupt line is connected to must be capable of waking the SoC in order to allow the Windows Precision Touchpad to wake the system in various scenarios.

In order to allow for various wake scenarios, the power rail used to feed to the Windows Precision Touchpad should not be shared with devices which are not wake capable (for example, a touch controller). The power rail used must be energized during connected standby/S3 conditions.

Windows Precision Touchpad Module

2 SDA I C Controller

SCL Windows Precision Touchpad Controller (IC) SDA Sensor Connection

SCL

Windows Precision Touchpad VDD GND ATTN/INT GPIO Controller Sensor

Active Power Rail

I2C Connected Windows Precision Touchpad

ACPI Table Entries

140 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

An I2C connected Windows Precision Touchpad shall need to define an entry in the ACPI table for the device to be recognized. Detailed guidance for entries can be found in the Windows Precision Touchpads Device Implementation Guide available on the Connect Microsoft website.

USB DEVICES

A USB 2.0 connected high-speed/full-speed Windows Precision Touchpad module shall expose the necessary pins for host connectivity.

Connection to the host can take many forms and is at the discretion of the integrator.

It should be noted that when connecting to a USB hub it is important to understand the bandwidth demands of all components sharing that hub. It is highly recommended that high bandwidth devices and Windows Precision Touchpad controllers do not share the same USB hub as this may result in bandwidth demands that exceed bus capability.

USB BRIDGE DEVICES (I2C  USB)

If a USB bridge is elected for connecting an I2C Windows Precision Touchpad to the host, the bridge shall expose the Windows Precision Touchpad as a distinct device node with the device’s unique attributes (wVendorID, wProductID, wVersionID).

POWER MANGEMENT

POWER CONSUMPTION

141 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Power consumption requirements for the Active and Idle modes of a Windows Precision Touchpad (irrespective of bus connectivity) are governed by the following formula:

0.9 x (IDLE Power Consumption in mA) + 0.1 x (Active Power Consumption in mA) <= 25

Power consumption for the Sleep mode of a Windows Precision Touchpad (irrespective of bus connectivity) is required to be <= 1mW.

I2C DEVICES

I2C connected Windows Precision Touchpads shall implement support for 4 distinct power states; Active, Idle, Sleep (Armed for Wake) and Off as shown in the Error! Reference source not found.below.

142 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Device Receives SET_POWER SLEEP (Host Initiated)

SLEEP ACTIVE Device Receives a Contact/Button Event (Device Initiated) ARMED FOR WAKE (Fully Powered) (Host will issue SET_POWER ON after waking) (Internally Gated)

Po we r H as To Be ( Th en Ho e A st De pp In vic lie iti e d Power Has Been Removed Device Has Been Idle P ate ow d) From Device Device Has Contact/Button Event 120 Seconds er Ha (Host Initiated) (Device Initiated) (Device Initiated) s Fr Be ( om en Ho D Re st e m In vic ov iti e ed ate d)

P EE SL ER W OFF IDLE PO T_ d) SE te (Externally Gated) (Internally Gated) es tia eiv Ini ec st e R Ho vic ( De

Power Has Been Removed From Device (Host Initiated)

I2C Device Power States

Active State

The device enters an active state when you turn it on and it finishes booting or when it’s been suspended and then 1 or more contacts are present, the button is down.

You must adhere to the contact down latency and contact move latency requirements for the active state.

143 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The device must boot in less than 100ms.

Idle State

The device enters an idle state when no contacts or button activity happen for 120 seconds.

You can elect to reduce the scan rate in the idle state to meet power consumption requirements and still mmet the contact down latency requirement.

The device will go back to an active state when it detects either contact or button activity.

Sleep (Armed for Wake) State

The device enters a sleep state when it has been issued a HID I2C SET_POWER SLEEP command by the host.

In the sleep state, a device must not consume more than 1mW of power. You can reduce the scan rate significantly in the sleep state to meet power consumption requirements and still assert an interrupt for either contact or button activity to wake the system. A Windows Precision Touchpad must ensure that interrupts are not asserted for spurious contacts which would result in an unintended system wake. There is no contact down latency requirements for this mode; however it is recommended that more than 1 second of continuous contact should result in an interrupt being asserted.

The device must transition to the active state when it receives a HID I2C SET_POWER ON command from the host.

Off State

The device is in an off state when it doesn’t use any power.

USB DEVICES

USB connected Windows Precision Touchpads shall implement support for 4 distinct power states; Active, Idle, Sleep (Armed for Wake) and Off as shown below.

144 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Latency Mode = 1 (Host Initiated) (In addition USB Suspend D2)

ACTIVE SLEEP (Internally Gated) (Fully Powered) Latency Mode = 0 (Host Initiated)

P ow Device Has Been Idle er Ha T s B (Host Initiated – USB Suspend D2) o T e (H he en Or os D Ap t I ev pl Power Has Been Removed nit ice ied Device Has Been Idle 120 Seconds P ia ow ted From Device (Device Initiated) er ) Ha (Host Initiated) s Fr Be ( om en Ho D R Device Has Contact/Button Event st e em In vic ov iti e ed (Device Initiated) ate d)

1 e = od ) OFF IDLE M ed cy iat en it (Externally Gated) at t In (Internally Gated) L os (H

Power Has Been Removed From Device (Host Initiated)

USB Device Power States

145 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Active State

The active state is when the device has power, has finished booting, and is not suspended.

You must adhere to the contact down latency and contact move latency requirements for the active state.

The device must boot in less than 250ms.

Idle State

The device goes into an idle state when there are no contacts or button activity within a host-defined period. This is also called selective suspend or USB selective suspend.

All USB connected Windows Precision Touchpads must support selective suspend and report this capability via a Microsoft OS descriptor. For additional details see Microsoft OS Descriptors.

You can reduce the scan rate in the idle state to meet power consumption requirements and still meet the contact down latency requirement.

When the device detects either contact or button activity, it must signal a remote wake. From that event, the device must buffer at least 100ms worth of contact reports so that input is not lost while the USB host controller is resuming.

Sleep (Armed for Wake) State

The sleep state is when the host is in S3 or Connected Standby. This is indicated to the device via the latency mode feature report with a value of 1 indicating maximum latency is permitted. The device must exit this high latency mode both on activity and on host resume.

In the Sleep state a device must not consume more than 1mW of power. You can reduce the scan rate significantly in the sleep state to meet power consumption requirements and still signal a remote wake for either contact or button activity. A Windows Precision Touchpad must ensure that remote wake is not signaled for spurious contacts

146 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

which would result in an unintended system wake. There is no contact down latency requirements for the sleep state; however it is recommended that continuous contact for more than 1 second should signal a remote wake.

Off State

The device is in an off state when it doesn’t use any power.

PROTOCOL IMPLEMENTATION

Windows includes a HID class driver and corresponding HID I2C and HID USB miniport drivers; therefore there is neither need nor allowance for any 3rd party drivers for Windows Precision Touchpads. There is only the need to report the usages described in this white paper in the firmware for your Windows Precision Touchpad. Windows will use the OEM provided firmware and its own HID drivers to enable mouse and gesture capabilities for your device and furnish Windows applications with access to your device.

REQUIRED HID DESCRIPTORS

Required USB HID Descriptor

The following table shows the required USB HID descriptor. For more information, see section 6.2.1 in Device Class Definition for Human Interface Devices (HID) Version 1.11.

147 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

USB HID Descriptor Members

Member Size in bytes Description bLength 1 Size of the descriptor bDescriptorType 1 Type of descriptor bcdHID 2 HID version number bCountryCode 1 Country code bNumDescriptors 1 Number of descriptors bDescriptorType 1 Descriptor type bDescriptorLength 2 Length of the descriptor

Required I2C HID Descriptor

The following table shows the required I2C HID descriptor.

HID I2C Descriptor Members

Member Size in bytes Description wHIDDescLength 2 The length of the complete HID descriptor (in Bytes) bcdVersion 2 The version number, in binary coded decimal (BCD) format wReportDescLength 2 The length of the Report descriptor (in Bytes) wReportDescRegister 2 The register index containing the Report descriptor wInputRegister 2 The register number to read the input report (in unsigned Bytes) wMaxInputLength 2 The length of the largest input report to be read from the input register wOutputRegister 2 The register number to send the output (in unsigned Bytes) wMaxOutputLength 2 The length of the largest output report to be sent

148 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

wCommandRegister 2 The register number to send command requests (in unsigned Bytes) wDataRegister 2 The register number to exchange data with command requests (in unsigned Bytes) wVendorID 2 USB-IF assigned Vendor ID wDeviceID 2 Device ID wVersionID 2 Firmware version number

REQUIRED DEVICE ATTRIBUTES

The following HID properties must be provided in the device attributes. The reporting of these device attributes is bus specific. Consult the HID specific guidance for your choice of bus.

Required Device Attribute Members

Member Description USB I2C wVendorID Vendor Id idVendor in USB Device wVendorID in I2C HID Descriptor Descriptor (see above) wProduct Product Id idProduct in USB Device wDeviceID in I2C HID Descriptor Descriptor (see above) wVersionID Firmware version number bcdDevice in USB Device wVersionID I2C HID Descriptor Descriptor (see above)

REQUIRED HID TOP-LEVEL COLLECTIONS

149 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

A Windows Precision Touchpad device shall expose 3 mandatory top-level collections; Windows Precision Touchpad, Mouse and Configuration. An optional (recommended) collection for firmware update may also be implemented.

150 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Windows Vendor Specific Mouse Configuration Precision Touchpad Firmware Update Collection Collection Collection Collection

Device Capabilities Mouse Reports Input Mode Firmware Transfer

Device Certification Selective Reporting Status

Latency Mode

Contacts/Button Reports Windows Precision Touchpad HID Collections

Top Level Collection

Top Level Collection (Optional)

Input Report

Output Report (Optional)

Feature Report (GET)

Feature Report (SET)

151 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

MOUSE COLLECTION

Using the HID protocol, a Windows Precision Touchpad shall provide a top-level collection that appears as generic desktop/mouse. The mouse collection of a Windows Precision Touchpad serves the purpose of providing HID compliant mouse reporting to the host. This is especially important for hosts that are not capable of consuming input via the Windows Precision Touchpad collection. The mouse collection shall support an input report such that relative position (x,y), and left and right buttons are reported at a minimum. There are no mandatory feature reports associated with this collection. Please see the Windows Precision Touchpads Device Implementation Guide for the descriptor reference.

By default, Windows Precision Touchpads shall report data via the mouse collection as this is the most compatible reporting mode as mentioned above.

CONFIGURATION COLLECTION

Using the HID protocol in Windows Blue, a Windows Precision Touchpad shall provide a top- level collection that appears as digitizer/configuration.

The configuration collection of a Windows Precision Touchpad serves the purpose of allowing the host to configure two different aspects of the device. The collection shall support two feature reports; one that allows the host to select input mode and the other to allow the host to be selective in what is reported. There are no mandatory input reports associated with this collection.

INPUT MODE FEATURE REPORT

The input mode feature report is communicated by the host to the Windows Precision Touchpad to indicate which top-level collection should be used for input reporting. There are two collections which may be used for input reporting, the mouse collection and the Windows Precision Touchpad collection.

152 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

By default, meaning upon cold-boot/power cycle, Windows Precision Touchpads shall report input via the mouse collection. A Windows Precision Touchpad shall only report data via one given collection at any time and shall only report from a different collection once the corresponding feature report has been received from the host indicating the desired input mode. Please see the Windows Precision Touchpads Device Implementation Guide for the input mode usage values.

The host may issue the input mode feature report to a Windows Precision Touchpad at any time after reading the report descriptor. This includes while data is potentially being reported through the active collection. In the event that a mode switch occurs while data is being reported, all contacts and button state should be reported as up and all reporting should cease via that collection. Reporting via the newly specified collection can occur after all contacts are physically up. The input mode shall not be persisted by a Windows Precision Touchpad across power cycles.

SELECTIVE REPORTING FEATURE REPORT

The input mode feature report is communicated by the host to the Windows Precision Touchpad to indicate which types of input should be reported. There are two types of input which may be reported: surface contacts and button state.

By default, meaning upon cold-boot/power cycle, Windows Precision Touchpads shall report both surface contacts and button state. A Windows Precision Touchpad shall only report input that has been previously selected by the host per the corresponding feature report. Please see the Windows Precision Touchpads Device Implementation Guide for the surface and button switch usage values.

The host may issue the selective reporting feature report to a Windows Precision Touchpad at any time after reading the report descriptor. The selective reporting state shall not be persisted by a Windows Precision Touchpad across power cycles.

When a USB connected Windows Precision Touchpad is suspended, it shall only signal a remote wake based on the input the host has selected via this feature report.

153 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

An I2C connected Windows Precision Touchpad shall only generate interrupts based on the input the host has selected via this feature report.

WINDOWS PRECISION TOUCHPAD COLLECTION

The Windows Precision Touchpad collection serves the purpose of providing rich multi-contact and button reporting to the host as well as device information pertaining to those reports. The collection shall support two feature reports; one that allows the host to obtain device capabilities and the other to obtain the device’s certification status. The mandatory input report is specified in detail below. An optional (highly recommended) feature report may be implemented to obtain latency mode hints from the host in order to achieve required power consumption on USB devices in sleep mode.

DEVICE CAPABILITIES FEATURE REPORT

The device capabilities feature report is requested by the host of the Windows Precision Touchpad to elicit the device’s contact reporting capabilities and device button type.

The device’s contact reporting capability is defined by the maximum number of concurrent surface contacts it may report. A Windows Precision Touchpad shall support a minimum of 3 concurrent contacts and a maximum of 5 concurrent contacts and shall report this value via specification of the contact count maximum in the device capabilities feature report. While reporting data, a device must not report more contacts than the contact count maximum. Any new contact information reported after the contact count maximum has been reached will be ignored by the host.

The device’s button type is defined as either a depressible implementation (also referred to as click-pad type) or a non-depressible implementation (also referred to as pressure-pad). Either implementation is acceptable for a Windows Precision Touchpad. The host may request the device capabilities feature report of a Windows Precision Touchpad at any time after reading the report descriptor. Please see the Windows Precision Touchpads Device Implementation Guide for the button type usage values.

154 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

DEVICE CERTIFICATION STATUS FEATURE REPORT

The device certification status feature report is requested by the host of the Windows Precision Touchpad to elicit the device’s 256-byte blob. The 256-bytes shall be specified via the vendor specific usage in a vendor defined usage page in the device certification status feature report, and the Windows Precision Touchpads Device Implementation Guide provides detailed guidance.

LATENCY MODE FEATURE REPORT

The latency mode feature report is sent by the host to a Windows Precision Touchpad to indicate when high latency is desirable for power savings and conversely when normal latency is desired for operation, and the Windows Precision Touchpads Device Implementation Guide provides detailed guidance. For USB connected Windows Precision Touchpads, this allows the device to disambiguate between being suspended for inactivity (runtime IDLE) and being suspended because the system is entering S3 or Connected Standby.

If a device has been enabled for contact reporting via the selective reporting feature report, the device shall switch to normal latency mode automatically on host resume or contact activity. If the device has not been enabled for contact reporting via the selective reporting feature report, it shall switch to normal latency mode automatically upon receipt of a selective feature report from the host indicating contact reporting is desired.

WINDOWS PRECISION TOUCHPAD INPUT REPORTS

The host makes use of the following usages when extracting contact data from an input report via the Windows Precision Touchpad collection. These are Contact ID, X, Y, Tip, Confidence, Width and Height for contact level usages; and Report ID, Scan Time Contact Count and Button for report level usages. The Windows Precision Touchpads Device Implementation Guide provides details on mandatory and optional usages. It should be noted that any device that does not report all mandatory usages at either the contact or report level will non-functional as a Windows Precision Touchpad. Mandatory usages are strictly enforced by the Windows host. Where a logical maximum value has not been restricted, it may be optimized for to reduce descriptor size.

155 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Contact ID

Uniquely identifies a contact within a report for its lifecycle. The contact ID must remain constant while the contact is detected and reported by the device. Each separate concurrent contact must have a unique identifier. Identifiers can be reused once the previously associated contact is no longer detected or reported. There is no expected numeric range and the values used are only limited by the specified logical maximum in the descriptor.

X/Y

X and Y report the coordinates of a given contact. A Windows Precision Touchpad can report two points for each contact.

The first point (known as T) is considered the point that the user intended to touch and is mandatory.

The optional second point (known as C) is considered the location of the center of mass of the contact. In order to report optional height and width usages, reporting the second point is mandatory (and vice-versa).

Devices that are capable of reporting T and C should have a usage array of two X values and two Y values. The values in the first position in the arrays are interpreted as the coordinates for T and the values in the second position are interpreted as the coordinates for C. For devices opting to report both T and C, the report count for both X and Y usages shall be 2 to indicate the presence of a usage array.

The following global items, remain the same across multiple main items until they are changed, shall be specified for both the X and Y usages:

156 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Logical minimum & Logical maximum (ensuring >= 300DPI input resolution) o Note: The entire logical coordinate range shall be reportable across both the X and Y axis.  Physical minimum & Physical maximum (see Device Integration - Size)  Unit & Unit exponent

Tip

Used to indicate when the contact is on the surface or has left the surface of the digitizer. This is indicated by a main item with a report size of 1 bit. When delivering a contact report, the bit should be set when the contact is on the digitizer surface and cleared when the contact has left the surface.

When a contact is being reported with the tip switch clear, the X/Y location being reported should be the same as the last position reported with the tip switch set.

Confidence

Used to indicate that the contact does not have any dimensions (height or width) > 25mm which implies it is not an unintended contact. Windows Precision Touchpads should not reject any contacts in firmware processing, but should forward all contacts to the host and indicate the confidence. Once a device has deemed a contact to be unintentional, it shall clear the confidence bit for that contact report and all subsequent reports. Until a contact has been deemed unintentional, the device shall set the confidence bit for that contact being reported.

157 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Width/Height (Optional)

The Width and Height usages represent the width and height of the bounding box around the center of mass of a given contact. The reported values should never be 0 except when a contact up event is being reported (Tip bit cleared), in which case they shall both be 0. If Height and Width are reported they shall be accurate within +/-2mm of the actual contact dimensions.

The following global items shall be specified for both the Width and Height usages:

 Logical minimum & Logical maximum (this is relative to the min/max specified for X/Y)

Scan Time

Scan Time reports relative digitizer time in 100µs units. It represents the delta from the first frame that was reported after a device starts reporting data subsequent to a period of inactivity. The first scan time received is treated as a base time for subsequent reported times. The deltas between reported scan times should reflect the scanning frequency of the digitizer. It is important to note that unlike other usages, the host does not allow any flexibility for the unit for the scan time usage. It must be in 100µs units. The value is expected to roll over, as only 2 bytes are allocated to the counter.

158 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The scan time value should be the same for all contacts within a frame.

Contact Count

This is used to indicate the number of contacts being reported in a given frame irrespective of their associated tip switch.

Button

This specifies the up/down state of the Windows Precision Touchpad button. Irrespective of button type implementation, when the button has received the required amount of activation force its down state shall be reported by setting the button bit. When the activation force applied to the button falls below the required threshold, the up state shall be reported by clearing the button bit.

PACKET REPORTING MODES

While Windows Precision Touchpads Device Implementation Guide provides detailed guidance on packet reporting modes, a summary is provided below.

Parallel Mode

159 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

In Parallel mode, devices report all contact information in a single packet. Each physical contact is represented by a logical collection that is embedded in the top-level collection. This logical collection contains all the usages that the device supports for each contact. When taking advantage of Parallel mode, each of the logical collections must be identical. Because the device generally reports fewer contacts than the maximum, the number of contacts that are reported in a parallel packet should be communicated via the Contact Count usage.

Hybrid Mode

In Hybrid mode, the number of contacts that can be reported in one report is less than the maximum number of contacts that the device supports. For example, a device that supports a maximum of 4 concurrent physical contacts can set up its top-level collection to deliver a maximum of 2 contacts in one report. If 4 contact points are present, the device can break these down into 2 serial reports that deliver 2 contacts each.

When a device delivers data in this manner, the Contact Count usage value in the first report should reflect the total number of contacts that are being delivered in the hybrid reports. The other serial reports should have a contact count of 0.

Single Finger Hybrid Reporting Mode

The first input report for a given frame shall indicate the total number of contacts to be reported via the contact count usage and all subsequent input reports for the same frame shall have a value of 0 for the contact count usage to indicate that they are part of the previously reported frame. The scan time for all reports of a given frame shall be identical.

160 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

USB and I2C connected Windows Precision Touchpads may deliver input reports in either single-finger hybrid reporting mode or two-finger hybrid reporting mode.

FIRMWARE UPDATE COLLECTION (OPTIONAL)

Using the HID protocol in Windows Blue, a Windows Precision Touchpad may provide a vendor specific top-level collection for performing device firmware and vendor configuration updates.

The vendor specific firmware update collection could provide an output report for transferring the firmware payload from the host to the device.

This is highly advantageous as it allows for firmware updates to be performed without requiring a driver on the host.

It should be noted that field firmware update capability is a requirement for Windows Precision Touchpads and the above mechanism is recommended for compliance. It is mandatory for the wVersionID to be incremented after a firmware upgrade.

Windows Precision Touchpads shall be able to recover from a failed firmware update, due to power loss or other error, via a power cycle.

It is highly recommended that basic mouse functionality be available even after a failed firmware update.

DEVICE INTEGRATION

Windows Precision Touchpads define an experience and integration of the module has a significant impact on how well that experience is realized.

SIZE

161 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

A Windows Precision Touchpad shall have a sensor with minimum dimensions of 32mm x 64mm as illustrated below. This shall be the minimum permissible size reported via the physical maximum for X and Y in the report descriptor.

>= 32mm

>= 64mm

Windows Precision Touchpad Minimum Size

The best Windows Precision Touchpads shall have recommended dimensions of approximately 65mm x 105mm as illustrated below to allow for more comfortable interactions.

162 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

>= 65mm

>= 105mm

Windows Precision Touchpad Optimal Size

PLACEMENT

Windows Precision Touchpad placement is defined by three measurements; horizontal offset, vertical offset and depth offset.

HORIZONTAL OFFSET

163 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The optimal placement for a Windows Precision Touchpad is to center the device with the line which bisects the F and J keys of the integrated keyboard as shown below.

F J

X mm X mm

Optimal Horizontal Placement (Zero-Offset)

164 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

If a Windows Precision Touchpad cannot be integrated with the optimal zero offset, the integrator shall store the positive or negative offset (in himetric) in the registry to allow the host to compensate.

With reference to the illustration below, if a device has an offset, the value to store is computed by taking the length of the touchpad to the right of the bisecting line and subtracting the length of the touchpad to the left of the bisecting line such that (Y – X) = Offset value. If a device has a right offset, this value will be positive, whereas a device with a left offset will result in a negative value. e n i L

r o t c e s i B

X mm Y mm

R mm

Horizontal Placement (Right-Offset)

VERTICAL OFFSET

165 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Windows Precision Touchpads shall be integrated at different vertical offsets from the keyboard spacebar due as shown below. The integrator shall store the positive offset (in Himetric) in the registry to allow the host to compensate. If a value is not provided, the host shall assume a default offset of 14mm.

SPACE

Vertical Offset

DEPTH OFFSET

166 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Windows Precision Touchpads shall be integrated such that the digitizer surface is flush with the palm deck as shown below. Up to 1.5mm of depth offset is permitted due to manufacturing and integration tolerances; however the highest quality implementations will seek to eliminate this offset.

Depth Offset (0 – 1.5mm) PALM DECK (LEFT) PALM DECK (RIGHT)

WINDOWS PRECISION TOUCHPAD SURFACE

Depth Offset

MODULE DESIGN FOR HCK REQUIREMENTS

The HCK requirements set forth for Windows Precision Touchpads are designed to provide a consistent user experience where precision and reliability are at the forefront. These requirements shall influence all aspects of the module, including the sensor, controller IC and associated mechanics.

SENSOR DESIGN

The design of the sensor in the Windows Precision Touchpad module is essential to ensuring an accurate representation of the user’s finger interactions.

While a specific sensor pitch is not mandated in this implementation guide, it should be understood how a larger sensor pitch can introduce challenges when attempting to meet or exceed specific requirements.

MINIMUM INPUT SEPARATION

Related HCK requirements:

167 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

- Device.Input.PrecisionTouchpad.Performance.MinSeparation - Device.Input.PrecisionTouchpad.Precision.ContactDivergence - Device.Input.PrecisionTouchpad.Precision.HVInputSeparation - Device.Input.PrecisionTouchpad.Precision.DiagonalInputSeparation

Ensuring that each unique finger contact is identified and reported is essential for consistent and reliable gesture recognition.

Windows Precision Touchpads shall not alias contacts aligned vertically or horizontally at a minimum separation of 10mm or aligned diagonally at a minimum separation of 13mm irrespective of whether the contacts are stationary, diverging, converging or being interleaved.

SURFACE & EDGE CONTACT DETECTION

Related HCK requirements:

- Device.Input.PrecisionTouchpad.Precision.EdgeDetection - Device.Input.PrecisionTouchpad.Reliability.ContactsReported

Ensuring that contacts are registered and reported as close to the edge of the sensor is essential for consistent and reliable edge gesture recognition.

Windows Precision Touchpads shall detect and report contacts anywhere on the digitizer surface within a maximum of 2mm of the edge of the digitizer surface irrespective of whether the contacts are within, entering or exiting the sensor area.

CONTROLLER IC DESIGN

The design of the controller IC in the Windows Precision Touchpad module is essential to ensuring an accurate representation of the user’s finger interactions.

168 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

POSITION REPORTING

Related HCK requirements:

- Device.Input.PrecisionTouchpad.Precision.MotionJitter - Device.Input.PrecisionTouchpad.Precision.Position - Device.Input.PrecisionTouchpad.Precision.StationaryJitter

The kinematics of the surface contacts shall be reported as accurately as possible to the host by a Windows Precision Touchpad. If a contact is stationary it shall be reported with stationary coordinates. A moving contact shall have its position accurately reported with respect to the scan time value.

LINEARITY

Related HCK requirements:

- Device.Input.PrecisionTouchpad.Precision.Linearity

The reporting of subtle movements by the user is an essential part of a precise and responsive user experience; however the lack of deviation and ability to follow the vector of a finger precisely is just as critical.

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.

169 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Relaxed Linearity Area 3.5mm

3.5mm Strict Linearity Area

Linearity

LATENCY & REPORT RATE

Related HCK requirements:

- Device.Input.PrecisionTouchpad.Precision.ActiveTouchdownLatency - Device.Input.PrecisionTouchpad.Precision.IdleTouchDownLatency - Device.Input.PrecisionTouchpad.Precision.PanLatency - Device.Input.PrecisionTouchpad.Performance.ReportRate

User perceived latency significantly diminishes the experience of a Windows Precision Touchpad and therefore all aspects of the system from end-to-end shall meet or exceed specified latency goals. Providing a minimal input

170 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

report rate of 125Hz for single contacts and 100Hz for multiple contacts ensures that with the correct scan frequencies, contact down and update latencies of 25ms and 15ms respectively can be achieved.

RELIABILITY

Related HCK requirements:

- Device.Input.PrecisionTouchpad.Reliability.ContactSuppression - Device.Input.PrecisionTouchpad.Reliability.FalseContacts - Device.Input.PrecisionTouchpad.Reliability.PowerStates

The most critical aspect of a digitizer system is ensuring that spurious contacts are not reported. Spurious contacts can occur due to noise interference introduced in to the system from a variety of sources and the Windows Precision Touchpad controller shall ensure that these are never reported to the host.

A user can make contact with a Windows Precision Touchpad at any time (be it intentional or inadvertent) and the controller must ensure that it can boot correctly irrespective of surface contacts or button state and be able to report contacts in accordance with the HCK requirements once all the initial contacts have been removed. Should a Windows Precision Touchpad detect more contacts on the surface than is supported for contact reporting and tracking, it shall report an up for all contacts and buttons, and cease all reporting until all contacts have been removed.

MECHANICAL DESIGN

The design of the mechanics in the Windows Precision Touchpad module is essential to ensuring a consistent user experience.

171 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

BUTTON ACTIVATION FORCE

Related HCK requirements:

- Device.Input.PrecisionTouchpad.Hardware.ClickpadPress - Device.Input.PrecisionTouchpad.Hardware.PressurePadPress

Irrespective of button type implementation, a button down state shall be reported by a Windows Precision Touchpad when a force greater than 150g-180g is applied to the contact area. The best Windows Precision Touchpads shall strive to provide uniform activation across the entire contact area (this is required for pressure- pad implementations), however at a minimum Windows Precision Touchpads shall ensure that activation force applied as illustrated by the Figure below results in button down reporting.

172 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

20%

> (150g-200g) Activation Force 20%

60% > (150Rge-la1x8e0dg L)i nAecatriivtya Atiroena Force

Activation Force

ENABLE/DISABLE TOGGLE BUTTON

Windows Precision Touchpads (or legacy touchpads which have opted in for enable/disable control in Windows 8.1) may have their enable/disable state toggled via a hardware button or keyboard combination.

The state of the touchpad will be toggled when the following keyboard combination is reported to the host: CTRL + WIN + F24.

173 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

PRECISION TOUCHPAD EXPERIENCES

Windows 8.1 provides support new precision touchpads. Any logo certified precision touchpad will have the following interactions available.

Pointing should be driven with a single finger motion on the touchpad.

Single-finger slide

Mouse cursor manipulation

The following methods of mouse clicking are supported. Note that all precision touchpads require a fully clickable surface:

Button Press Bottom Right Button Single Finger tap, Two Finger tap/click Press double tap

Left Click, one or two Right Click, one or two Left click, double left Right Click finger drag supported finger drag supported click

The following additional gestures are supported.

174 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Two-finger slide Two-finger pinch Swipe in from the right Swipe in from the left edge edge

Horizontal or vertical Zoom Toggle the charms bar Toggle the app switch scroll list

Tools and technical reference

Whitepapers

For detailed information about implementing Precision Touchpad, see Windows Precision Touchpads Device Implementation Guide.

For information about touch digitizers for Windows 8, see Windows Pointer Device Data Delivery Protocol.

HID-Related Specifications

For the HID Device Class Definition and the HID usage tables, see the USB HID Information page.

175 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

For information about the HID over I2C protocol, please refer to the HID Over I2C Protocol Specification.

Specifications

For additional information on ACPI 5.0, see Advanced Configuration and Power Interface Specification

The following documents include information about the protocol:  Device Class Definition for Human Interface Devices (HID) Version 1.11  HID Usage Tables Version 1.12  HID Over I2C Protocol Specification Version 1.0

TOUCH

OVERVIEW

Touch interfaces can be found today across myriad devices ranging from mobile phones to slates to kiosks to horizontal/vertical displays of 30’’. Each of these direct touch interfaces has its own requirements, restrictions, and affordances. But to end users, what matters the most is the smooth, responsive, and natural experience of interacting with a device using touch. That touch experience is at the front of the user’s satisfaction with the device.

The next version of Windows continues the emphasis on optimizing for touch. Touch, as an input method, is a first- class citizen on Windows, just as the keyboard and the mouse are today. For all ARM form factors, touch is the primary and preferred input method. Achieving a smooth, responsive, and natural touch experience requires a combination of good hardware and good software. Hardware and software vendors, including producers of touch

176 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

hardware, displays, touch input stacks, applications, and so on, need to continue to work well together. For the success of Windows and the Windows ecosystem, optimal touch user experience needs to be guaranteed. This document focuses on areas dependent on hardware vendors to achieve optimal touch user experience.

TOUCH INTERACTION PRINCIPLES

NATURAL, INTUITIVE, CONFIDENT

Beginning with Windows 8, the touch became based on manipulations, which supports a more natural and intuitive touch user experience with basic gestures supplementing the experience. The manipulations model will continue in the next version of Windows, and no new gestures are defined.

TOUCH INTERACTIONS

In Windows 8, there are seven primary touch interactions which were defined for users to interact across all form factors. Those will remain unchanged for this version of Windows. Users can perform these interactions across all the form factors (slate, convertible notebook, all-in-one (AIO), and so on) in all applications and expect to have consistent touch user experience.

For example, the user should not have to change the way to swipe, such as speed and swipe distance, to select the objects between his slate and his AIO. Both devices should recognize the “swipe” interaction for the same finger movement consistently.

177 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

You can learn more about the touch language and the seven interactions from these BUILD conference sessions:

 8 traits of great Windows Store apps  Designing Windows Store apps that are touch-optimized  Building great touch systems MANIPULATIONS

A manipulation is a real-time, direct handling of an object. A manipulation differs from a gesture in that the manipulation corresponds in a direct and one-to-one manner with how the user expects an object would react in the physical world. For example, using your fingers to pan the contents of a website up or down directly maps to using your fingers to slide a piece of paper up and down on a table.

GESTURES

178 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

A touch gesture is a quick movement of one or more fingers on a screen that the computer interprets as command or shortcut. Gestures often don’t directly map to any real world conventions, which creates an additional cognitive load for the user to learn and execute different gestures. This is why the gesture set defined in Windows 8 is not being expanded in the next version of Windows. Common touch gestures include “tap” to open and press and hold to invoke a contextual menu.

TOUCH PERFORMANCE

Fast and fluid performance that is perceivable and obvious – touch is direct so performance issues are felt more directly and viscerally compare to other input devices like a mouse.

The user can distinguish “responsive” from “non-responsive” touch devices easily. This does not require an expert in the touch hardware domain. For example, when an object is dragged around the screen, the user expects the object to stay under the finger to feel natural, fast, and fluid. The larger the distance between the finger and object, the more the user feels the experience is atypical and has to adjust to the device. This video created by the Microsoft Applied Sciences Group demonstrates the visible touch latency.

APPLICATION PROMISE

Consistent experience across form factors – a user can download any application from the Windows Store and it runs great on the user’s machine. There is no application that runs great on one device but not on another. This means developers can target all Windows 8 and this version of Windows touch devices without worrying about the quality of touch devices depending on the type of form factor.

For example, all Windows 8 touch devices require supporting a minimum of 5 simultaneous touches. All touch points require meeting requirements of 25 ms initial touch-down hardware latency and 15 ms subsequent contacts hardware latency. Game developers can design features based on fast and responsive 5 simultaneous touch points support across all Windows 8 touch devices.

TOUCH USER EXPERIENCE GUIDELINES ON TOUCH TARGETING

179 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

There are two distinctive targets for touch, unambiguous and ambiguous. Users should not have any trouble touching the unambiguous targets.

Slate-like form factors have more of a parallax effect, making it difficult for users to touch targets. When the device is placed on a flat surface, the user’s viewing angle is slanted compared to the normal standing display. You can reduce the parallax effect by reducing the space between the surface of the cover glass and the display.

UNAMBIGUOUS

Unambiguous targets meet these guidelines:

 Elements that meet the minimum touch user experience guidelines for size (9 mm x 9 mm).  Elements that don’t meet the minimum touch user experience guidelines for size, but are separated by at least 9 mm of space measured from center to center of each element. AMBIGUOUS

Ambiguous targets are elements that don’t meet the minimum touch user experience guidelines for size and are not separated by at least 9 mm of space measured from center to center of each element.

FINGER SIZE

The size of the contact touching the screen varies depending on the size of the finger, posture of the finger contacting the screen, and how hard the finger is pressed against the screen. We collected large samples in the lab to measure the “contact area“ size.

 The average size of the contact area using an index finger was 9.4 mm x 8.8 mm (bounding box width x height). One of the smallest observed in the lab was 5 mm x 6 mm, and the largest was 17 mm x 20 mm.  For “normal tap“ gestures, the average size observed in the lab was 10.8 mm x 10.5 mm. Combining this information with various other data, including non-index finger usage such as side of a thumb hitting a space bar in the software keyboard, the sizes to use are:

180 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Average – 9 mm x 9 mm  Smallest – 7.5 mm x 7.5 mm  Largest – 30 mm x 30 mm

GESTURES

The core gestures described in this section differ from manipulations in that they can all be considered static. Static gestures refer to gestures that don’t require drags of the finger(s) across the screen and are detected based on touch input, where the user’s finger is down and not moving (within a threshold of distance called the drag threshold).

TAP

A tap occurs when a finger is placed on the screen, remains within the well-defined drag threshold and radius, and is removed. Two successive taps constitute a “double tap” gesture. Both of these gestures can trigger a command or shortcut if defined by the foreground control or the application.

When a touch up (TU) occurs after x ms (the value is predefined by Windows), this becomes a hold. When a TU location is farther than y mm (the value is predefined by Windows), this becomes a drag.

Parameters Metric Drag threshold Finger down moves <= Y mm radius from initial (x,y) of down (The distance is defined in

181 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

the sub millimeters.)

Time No time limit

Action F1_Down F1_UP U

D Y mm Time(ms) 0 X ∞

Event Down Hold Tap

TARGETING AND CONTACT GEOMETRY

Windows uses contact geometry data for the targeting. When the touch hardware reports accurate and reliable contact geometry data, this improves the user’s targeting experience.

Each digitizer reports the point that it deems to have been intended by the user. When this point does not fall over a valid target, Windows will look at any reported geometry data to identify the most probable target.

USER EXPERIENCE

Accuracy and responsiveness across the screen are two important factors for a good user experience. Users have a specific target they want to tap, and that target can be small, such as a hyperlink in a browser that today is designed for the precision of a mouse. Touch devices that correctly recognize taps make the user feel confident while interacting with the device.

Users can use multiple fingers at the same time in different parts of the UI. The position of the finger during the tap varies for applications as well as for the environment in which the device is used. In some scenarios, like using a software keyboard, the user uses the side of the thumb to touch the space bar and uses tip of fingers for other keys. In a paint application, the user tends to apply a larger contact area. When the PC is placed on the table, users tend to tap more strongly with a larger contact area compared to when the PC is placed on the lap while sitting on a couch.

182 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

USAGE

Common usage scenarios for tap gestures include:

1. Text selection – tapping on a word 2. Active hyperlinks in the browser 3. HTML controls in the browser 4. Navigating the system and launching apps KEY HARDWARE ACCOUNTABILITY

 Contact geometry  Pixel accuracy for all areas  Sampling rate, reporting rate for all fingers  Hardware latency  Noise suppression, no phantom contacts

DOUBLE TAP

A double tap is the equivalent of the left double click of a mouse. A single finger taps the screen twice within a well-defined period of time and with a specific distance between taps.

Double tap is a key interaction on all the desktop scenarios.

Parameters Metric Drag threshold Tap1: Finger down moves <= Y mm radius from initial landing position (x,y) (black circle) Tap2: Finger down within X mm of Tap1 up (red circle) and moves <= Z mm (blue- dotted circle). The distance is defined in the sub millimeters.

183 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Time Tap1: Up1 is <= M ms after Down1 Tap2: Down2 begins within M ms after the end of Tap1 (F1_Up) and Up2 begins within M ms of Down2.

USER EXPERIENCE

Accuracy and responsiveness across the screen are two important factors for a good user experience. The user needs to be able to target an object on the screen originally designed for a mouse. The expected experience is the same as for a tap.

USAGE

Common usage scenarios for tap gestures include the following:

1. Desktop – double tap on a folder icon to open. 2. Desktop – double tap on a shortcut to start the app. 3. Internet Explorer – double tap to zoom in.

184 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

PRESS AND HOLD

A hold gesture is used to learn about the UI or invoke the context menu. This gesture replaces “press and tap” as the “right-click“ gesture from the previous versions of Windows. In Windows 8, this gesture brings up a UI to discover and learn about the object under the finger.

Details:

Hold is fundamentally on the same path of detection as a “long” tap. Because a tap is not bounded by time, but rather by the user’s finger movement, a consistent experience should be afforded for both taps and holds. Hold is considered a “marker“ or “flag“ in the detection path for tap to allow apps and controls to have the ability to gain consistent hold timing throughout the operating system.

For objects that accept taps (such as URLs), the hold event can be used to provide the users a visual cue to aid their decision to perform a tap or to drag away to cancel. For objects that only accept taps (such as buttons), the hold event is no different than a tap (provided the finger is still within the drag threshold), and the button can simply ignore the hold flag.

USER EXPERIENCE

Accuracy and responsiveness across the screen are two important factors for a good user experience. Users have a specific target that they want to hold, and that target can be small, such as a hyperlink in the browser which today is designed for the precision of a mouse. The UI to respond to this gesture needs to appear without delay, because users are already waiting by holding down a finger. The user feels confident with visual confirmation that the

185 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

object or the operating system reacts to this gesture precisely with the timing defined by the Windows gesture recognition engine.

USAGE

Common usage scenarios for press and hold gestures include the following:

4. Picker – press and hold on a file 5. Press and hold on a tile on the Start screen to show a tooltip with the full name of the app 6. Desktop – press and hold on the open space in the desktop 7. Desktop – press and hold on a file in File Explorer

MANIPULATIONS

SWIPE TO SELECT

This is very similar to “slide” except the distance between finger down and up is very short. Users perform this gesture very quickly on tiles such as application tiles in the Start menu, photos in the photo picker, and files in the file picker.

Use a single finger to swipe the object vertically to select.

186 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

USER EXPERIENCE

Accuracy and responsiveness are key factors for a good select experience by swipe.

For example, when a user is selecting the tile, this should not be mistaken for a tap that launches the app. This causes extreme annoyance for the user. In most cases, there isn’t a simple interaction to cancel the tap and go back to the original screen where user was selecting objects.

The user expects the UI to responds as a finger swipes the screen. The UI response indicates to the user that the interaction is recognized successfully. This also helps users to move to the next item to swipe and select with minimum delay between the swipes. Very fast flicking interactions that only touch the screen for a very short distance and time are expected by users to work for selection. A “flick” is a short, quick motion meant to quickly pan or select content. Often, on modern touch stack-ups, this motion will result in a very small amount of meaningful data coming to the operating system and this typically conflicts with jitter. Digitizer must follow the guidance under the Performance Considerations section of this document to provide a clean velocity data to enable fast and fluid flicks.

USAGES

 Start menu – selecting a tile for advanced options such as unpin, uninstall, making the tile smaller  Photo picker

187 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

SWIPE FROM EDGE

Starting with Windows 8 and continuing with this version of Windows, key UIs hide under the edge of the screen. A user can bring up or hide the UI with a simple swipe action. By not always showing the Windows UI on the screen, this maximizes the display area applications can use. Left and right edges are used by Windows, and top and bottom are used by application.

To bring up Windows UI from the edge, user will place one finger on the bezel, and drag toward the center of the screen. User must be able to perform this action comfortably at any position of the edge; the location can vary depending on the posture of a user holding a device. This is like “dragging” an object hiding under the bezel to the display area; directly manipulating an object. The difference between a typical drag is that user does not target an object to start dragging. Instead, user simply places a finger at any part of the edge and drag toward the center of the display. You may perceive this as a single finger swipe starting on the bezel and moved toward the center.

Edge drag From right to center Windows UI called “charms bar” shows up. From left to center This action is called “back and snap“. Short drag: Back: Similar to Windows button + Tab, toggles through the running applications. Long drag and hold: Snap: Turns into arrange mode – user can drag the application and drop to the side bar or main area to snap. From top/bottom to This is assigned to application user experience. center Short drag from top or bottom: Application can show its menu on top, or bottom, or both. Long drag from top and hold: Snap: Turns into arrange mode – user can drag the application and drop to the side bar or main area to snap.

188 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

USER EXPERIENCE

The device’s form factor can impact the user experience around device edges. For example, the physical transition from the bezel to the screen is different when the bezel height is not same as the screen.

When a user drags a finger from a bezel, the user feels as if she is dragging out the menu bar from underneath the bezel. The user is confident to perform this on all four edges at any location. The user does not have to press the finger harder to the screen or try to target the very edge of the screen to drag out the menu bar. When a user places a finger on the bezel, the menu bar is stacked to the user’s finger and as the finger is dragged out to the screen, the menu bar is dragged out.

The observed average finger moving speed is 160 mm/second and goes as fast as 730 mm/second. The 95th percentile (that is, 95% are slower than this) is 400 mm/second. The user can perform edge UI drag interaction at any given speed between (slow) to (fast).

Swiping backward is also very important. The user can toggle through the running applications by swiping back to the edge and swinging in again to bring the next application. The application should not mistakenly drop to snap to the screen.

USAGE

1. Windows UI 2. Application UI

SWIPE FROM EDGE (APPLICATION)

Dragging can start or end at the edge of the screen. It can even start from outside of the screen if the user places a finger on the bezel, and it can also end on the bezel.

USER EXPERIENCE

189 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Everything described in the Drag section applies to this section.

USAGES

1. Full screen application (paint application, game) 2. Desktop – dragging in the tablet input panel

SLIDE (PANNING)

Panning occurs when a user slides the finger – the user’s finger(s) is placed on the screen and moved beyond a distance threshold. The user’s finger may continue to move in any direction for any duration. The panning ends when the user lifts the finger(s).

A single finger pan moves an object. One or more fingers moving in the same direction either directly manipulates an object or pans scrollable content. During panning, the distance between fingers remains constant within a threshold. If a second finger is placed on the screen and the distance between two fingers goes beyond the threshold, the panning stops and zooming begins. If the fingers converge, the manipulation is a zoom out; if they diverge, the manipulation is a zoom in. If distance is changed while dragging, it becomes compound manipulation (see the next section).

The pannable objects in Windows have inertia. Users can drag objects with inertia (velocity). Inertia occurs when the user is manipulating content (for example, panning a webpage) and the finger slides off the display, creating a

190 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

sense of velocity and thus inertia. The object stops moving gradually, calculated from the inertia. The object stops moving when it reaches the wall defined by the application, such as end of the list or when it is out of momentum. The ability to create such a believable slow-down effect is predicated on having accurate tracking information. When the information is inaccurate, we break the illusion and the feeling that users are manipulating physical objects.

Users can repeatedly apply inertia on top of the panning object and have the object keep panning with velocity.

COMPOUND MANIPULATION

Panning can be done as part of other manipulations. For instance, users can pan and zoom at the same time.

Compound Interactions Pan and Converge Rotate and Diverge Pan and Converge and Diverge Rotate and Converge Pan and Converge and Rotate Rotate and Converge and Diverge Pan and Converge and Diverge and Rotate Converge and Diverge Pan and Diverge Pan and Diverge and Rotate

USER EXPERIENCE

Responsiveness is the most important factor for a good panning experience. Other factors, such as pixel accuracy identifying where a finger touched the screen and is lifted, is less important.

When a user places a finger on the screen and moves an object, the object stays under the finger. When the finger stops, the object stops at the same time and location with no visually noticeable lag to a user. When finger is moved with velocity and lifted, the object continues to move in the direction the finger was moved. The user feels as if the object was tossed on a smooth physical surface in the real world and the object’s speed decreases as if due to friction.

191 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 The user does not need to worry about how many fingers are used.  The user typically does not worry about the exact location where finger(s) touches the screen.  The user notices objects start to “slip away” by seeing the object following after the finger movements. Ideally the distance of the object from the contact point should be less than the diameter of the in- contact surface. See General Performance Considerations for details.  The user can start panning at any time.  It feels natural to the user to apply the same manipulation over the same moving object and that the object continues to move with applied velocity. USAGE

3. Webpage browsing/navigation – Internet Explorer 4. Photo manipulation – Windows Live Photo Gallery 5. Used heavily for system browsing and navigation

SLIDE (DRAG)

A drag manipulation occurs when a user’s finger(s) is placed on the screen and moved beyond the initial drag threshold. The user’s finger may continue to move in any direction for any duration. The drag ends when the user lifts the finger(s).

Placing a single finger down and dragging the finger moves an object. When one or more fingers are pressed down and dragged in the same direction to move an object, the distance between the fingers should remain within a defined threshold.

192 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

USER EXPERIENCE

Pixel accuracy for the entire screen area is one of the most important factors of the drag experience. The user targets an exact point (location) on the screen to touch and start dragging the object. The user also targets an exact point on the screen to lift the finger to stop dragging the object.

Contact tracking is another important factor. When the user drags an object from one location to another, the user can pause the movement but the finger stays touching the screen. With poor contact tracking, the object can drop out from the finger and require the user to retarget the object to drag.

 The user can target an object to touch anywhere in the entire screen.  While the user drags an object with various speeds, the object does not jitter. The user sees the object move smoothly.  The user can drag an object from one location to another in any part of the screen with one single drag, as long as the finger remains on the screen. While the user drags the finger, the dragging speed can change and pause. The object under the finger should not jitter at any time.  The user notices objects start to “slip away” by seeing the object follow after the finger movements. Ideally the distance between the object and the contact point should be less than the diameter of the in- contact surface. USAGES

6. Start menu – rearranging tiles 7. Desktop – rearranging icons 8. Desktop – window resizing

PINCH (CONVERGE, DIVERGE)

193 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

A pinch or stretch occurs when two or more fingers are placed on the screen on a foreground application and moved toward or away from each other. The user’s fingers may continue to move in any direction for any duration. The gesture ends when the user lifts the fingers, and one or no fingers remain touching the screen. The intent of these gestures is to change the scale of the object.

Details:

Converge and diverge manipulations require the use at least two fingers to perform. The key component is the delta and vector between each contact. This manipulation does not require both contacts to be moving, just that the delta is either increasing or decreasing along opposing vectors.

The following graphic shows two- and three-finger diverge and converge.

2 3

1 2 2 3 1 2

1 1

194 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

CONVERGE

The converge gesture happens when two or more fingers placed on an object are dragged closer together (that is, toward each other). For example, a user places the thumb and forefinger on the top and bottom edges of a picture and pinches the fingers together.

DIVERGE

The diverge gesture happens when two or more fingers placed on an object are dragged apart.

USER EXPERIENCE

Responsiveness is very important for this experience. The object changes its scale in real time and simultaneously with the finger movement. The user does not notice any visual delay between the fingers and the object.

1. The user doesn't need to worry how many fingers are used or if two hands are used. 2. In direct touch interactions, users notice that objects start to “slip away” by seeing the object following after the finger movements. Ideally, the distance between the object and the contact point is less than the diameter of the in-contact surface. USAGE

1. Photo manipulation – Windows Live Photo Gallery 2. Webpage browsing/navigation – Internet Explorer 3. System browsing and navigation

ROTATE

195 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The rotate gesture happens when two or more fingers on an item are dragged in clockwise or counter-clockwise directions along an arc.

Details:

The rotate manipulation requires at least two fingers to perform. The action is fundamentally two contacts moving in opposite directions along an arc, as shown in figure b. However, it’s not necessary that both fingers are moving. A “pivot“ rotation is when one finger remains stationary and the other finger(s) move along an arc around it, as shown in figure b.

2 2 3

1 1

a. Pivot rotation b. Standard two-finger rotation c. Standard three-finger rotation

USER EXPERIENCE

196 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The object changes its orientation in real time and simultaneously with the finger movement. The user doesn't notice any visual delay between the movement of the fingers and the object.

4. The user can perform rotation with other direct manipulation such as converge and diverge. For example, the user can zoom into the photo and rotate the photo simultaneously. 5. In direct touch interactions, users notice objects start to “slip away” by seeing the object following after the finger movements. Ideally, the distance between the object and the contact point is less than the diameter of the in-contact surface. See General Performance Considerations for details. USAGE

6. Photo Viewer 7. Map application

SELECT AND PAN

In the new Start menu, a user can select a tile (grab for rearrangement) and pan the menu to find a location for the selected tile to drop using a second contact or several contacts. This is a multi-finger gesture.

Another example may be a photo gallery application. The user selects one photo by dragging it out from a list of displayed pictures, and while holding on to the photo, uses another hand (finger) to pan the list to find the location for rearrangement.

USER EXPERIENCE

The object selected stays under the finger without jittering while the whole list (menu) is panned by another hand (finger). The panning performance is not degraded.

197 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

SOFTWARE KEYBOARD

Text entry is an integral part of the Windows experience. Even though the touch experience lends itself more toward content consumption, there are still times when text entry is required. Typing in a URL, posting on Facebook, tweeting, searching for artists, or filling out the credit card number in an online store are all common tasks.

On a physical keyboard, the average typing speed is 39 – 40 words per minute (wpm). Administrators can type up to 70 – 80 wpm. Professionals can type up to 90 to 120 wpm.

USER EXPERIENCE

Tapping on a software keyboard key needs to be very responsive without any delay to ensure a good user experience. Users will tap rapidly. To type upper-case letters, users will hold the shift key with one finger and tap on the alphabet key rapidly then lift the finger off the shift key. The next tap can come while the previous finger is still down or just being lifted. 1. All the keys tapped appear correctly in the order tapped.

198 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

2. The user can hover the finger over the screen (not touching the screen) when moving from one key to another, and keys under the hovering fingers are not tapped.

A common bad experience is a case where two quick taps can be mistaken as a short drag particularly as touch resolution goes down or latency goes up. This means taps are sometimes change to moves and this is a bad typing experience. Rapid taps should not be recognized as drags.

TEXT SELECTION

Today’s Windows users have grown accustomed to editing and manipulating text using keyboard and mouse input. This works well because the keyboard and mouse are highly granular methods of input; keys are discrete data points that are either depressed or not depressed, and mouse clicks can easily be mapped to the most granular screen measurement—a single pixel. Touch, on the other hand, has an area of effect—even with a perfect digitizer, it’s very hard for a touch user to pinpoint a specific (x,y) location on the screen, which is the kind of granularity needed when selecting text and placing the text cursor.

USER EXPERIENCE

199 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Users need to be able to target small elements such as a single word in the webpage very accurately. The target may be ambiguous (elements that don't meet the minimum guidelines for size and aren't separated by at least 9 mm of space measured from center to center of each element) and may require more information from the touch digitizer than simple x,y coordinates to target. For users to reliably target small objects, the touch digitizer must generate accurate contact geometry data (the contact area of the finger touching the screen).

Good contact tracking is also very important. The user can drag the finger in all directions to select and manipulate content. When contact tracking is broken, the user will lose the selection while dragging the finger that is manipulating the selection.

USAGE

 Highlighting a word – look up its definition, change fonts  Selecting a word in an edit field – correcting mistyped text  Highlighting a line – copy to email, blog, tweet  Cursor placement – placing at the middle of a word to correct spelling

WINDOWS NARRATOR

Windows Narrator is a text-to-speech utility that assists users with vision impairments. Narrator reads what is displayed on the screen—the contents in the active window, menu options, or text that has been typed. To assist navigation by touch, Narrator has a unique gesture recognition system, relying on good multi-touch functionality.

USER EXPERIENCE

Gesture recognition rate is critical to the success of this scenario. Visually-impaired users should not have to fall back to mouse or keyboard. They must be able to navigate on a slate confidently using touch.

In performing gestures like a 4-finger swipe, the user doesn't need to worry how close 4 fingers are placed to each other. Some users may put fingers very close to each other, and some may have some space in between. In all cases, users can place their fingers in comfortable positions to perform gestures that are recognized correctly.

200 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

TAPS

# of fingers Single tap Double tap Triple tap 1 Explorer Primary action Secondary action (read what is under the finger) (activate a button) (select an item) 2 Element-specific commands Search and select N/A 3 Pause speaking Bring up a list of the available N/A narrator commands 4 Keyboard (open, close) N/A N/A

SWIPES

Swipe is a gesture users can perform to command the narrator. When this is performed, instead of the direct manipulation of the contents under the finger, the user is commanding Narrator to perform an assigned task.

# of fingers Down Left Right Up 1 N/A N/A N/A N/A 2 Navigation Navigation Navigation Navigation (Into) (Previous) (Next) (Parent) 3 Read from here Shift-Tab Tab N/A 4 Scroll (Up) Scroll (Right) Scroll (Left) Scroll (Down)

USAGE

 Windows 8 Narrator

PERFORMANCE CONSIDERATIONS

Digitizer of high performance must follow the considerations below for fast and fluid touch experience.

201 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

CLEAN VELOCITY DATA

Windows is focusing on making the touch experience cleaner and smoother. To help, partners can ensure that they provide realistic velocity modelling in their touch reports, i.e., digitizer must report the realistic velocity of the user between any two consecutive reports for any given contact.

FINGER CONTACTS SCREEN (DOWN)

As the finger makes contact with the screen, it is important to quickly determine whether the contact is real, as this latency will manifest itself in delayed input to the screen, which will be exacerbated if the user quickly begins to move. defines the allowable amount of latency for a Windows system, but we always encourage the lowest possible value whilst maintaining noise resistance.

FINGER BEGINS TO MOVE (DISAMBIGUATION)

As the contact begins to move, we must make a trade-off between holding steady in the presence of noise or involuntary movement and reacting quickly to an intended movement.

We assume the existence of a “disambiguation zone” within which movement is discarded and the contact is reported as stationary. If this area is too large, the user will perceive a lag, or jump, in following her motion across the screen, and any program that attempts to smooth velocity will be disadvantaged by the sudden change in position of the reported contact.

Our position is that the disambiguation zone should be as large as necessary to meet the requirement and no larger.

FINGER CONTINUES TO MOVE (PAN OR FLICK)

202 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Once the contact is deemed to be in motion, it is very important to maintain a realistic representation of its progress across the screen. If the contact is moving at a constant speed of 200 mm/s, then we expect the digitizer to report a change in position of approximately 200 mm/(seconds/report interval). For example, given constant report interval of 10 ms, we would expect the digitizer to represent a change in position of 2.0 mm per report.

In the case of a flick, motion is often accelerating in one direction, and in this situation we expect that the digitizer will represent this as a uniformly increasing (or decreasing) change in position between consecutive each reports. When this is not the case, the user will see a misrepresentation of her intended speed in an application, as the program will need to overcome what appears to be stoppage or backtracking.

FINGER LEAVES SCREEN (UP)

It is vitally important to report the removal of a contact as quickly as possible and optimally within 15 ms, as this latency will manifest itself to the user in the form of improper speed representation in touch applications. An ideal stream of reports for a moving contact would appear as a sequence of TIP-down reports with position data reflecting the true rate of motion, followed by a single report with the TIP flag removed, and the same position as the final TIP-down report. Please refer to windows-device-pointer-protocol.docx. for state transition details.

PALM DETECTION

The digitizer shall represent a palm as one contact with the confidence bit set to zero from the very first report. Once it’s set, the confidence bit should not be changed during the lifetime of the contact. For the details on confidence bit, refer to windows-device-pointer-protocol.docx.

203 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

There is a known trade-off between low latency (only occasional accidental touch as a downside) and palm/accidental-touch rejection (but with higher latency or sensitivity). Fast reporting of contacts is of higher priority over palm detection.

TECHNICAL DETAILS

This section describes key technical areas on the touch hardware and firmware that can impact Windows touch user experience.

TOUCH REPORT RATE

The Touch Report Rate is defined as the rate of sustained reporting rate of the touch contacts by the firmware/driver to the host. The requirement for this value is based on the consideration of the higher level scenario-specific recognition, in that a high enough report rate enables the host to catch or distinguish the motion details of moving fingers, for the purpose of recognition and differentiation as described in the previous sections.

Failure Cases:

 Manipulation – a low rate can cause tracking to lose motion details of the physical finger moves.  Gesture – a low rate could lead to incorrect interpretation of the gestures.

TOUCH SCANNING RATE (SAMPLING RATE)

The touch scanning rate is defined as the rate of scanning through the entire frame of the sensor grid for the raw sensor signal. The requirement for this value is mainly for correct tracking of the touch IDs when the fingers are moving fast.

 The touch report events are a subset of the touch scanning events, in the sense that multiple scanning samples can map to a single touch report, and as such the touch report rate should never be higher than the touch scanning rate.

Failure Cases:

204 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Software keyboard (SKBD) – a low scanning rate can cause difficulty in distinguishing 2-finger tapping from single finger fast move.  Multi-touch – a low scanning rate can cause contact ID switching/hopping between multiple contacts.

INITIAL TOUCH LATENCY

This is defined as the first touch event reported in relation to the first physical contact in time. Sometimes the firmware delays reporting the first touch contact up to a few frames in order to gain better accuracy by using certain kinds of temporal filtering. This causes fast motion panning to have a delayed start, and the end result is a far smaller range than that of physical finger motion, leading to a “sluggish” panning experience.

Responsiveness is critical to the end user touch experience. Immediately report the first touch registered even when it is less accurate, and indicate so in the report. The subsequent reports can still use the previously buffered samples for filtering to gain accurate reports. This way the buffering delay can be eliminated altogether.

Note: This scheme requires a gestural recognition engine to be aware of the potential inaccuracy of the initial touch.

Failure Cases:

 panning – A large initial touch latency can cause “sluggishness“ in the panning experience, as the range of the panning is much reduced.

SUSTAINED REPORT LATENCY

This is defined as the total time duration from the touch contact on the touch screen (finger down) to the visual response on screen. It can be caused by a number of factors compounded together (hardware, firmware, driver, input stack, apps, graphics subsystem, and so on). This latency manifests itself as a moving lag of touch points on screen when the physical touch moves. For the purpose of this report, the focus should be a minimal latency in milliseconds.

Failure Cases:

205 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Manipulation – Failure to have a small enough sustained latency can cause visual delay of the tracking which causes an unsatisfactory effect in scenarios of manipulation.

CONTACT TRACKING BETWEEN FAST TAPPING AND FLICKER

This issue is caused by two consecutive taps happening next to each other at different locations, and the “contact up“ on the first tap is immediately followed by a “contact down“ at a different location in the next scanning frame.

A higher scanning rate can reduce the chance of this occurring.

Failure Cases:

 Software keyboard – a user typing fast on a soft keyboard with alternating key strokes (“ABABABAB…“) can cause two successive individual key strokes to be interpreted as a touch move event.

CONTACT TRACKING WITH MERGE

The contact tracking model must be robust enough to handle the situation when multiple contacts merge into a single component in the raw sensor image. To this end, a typical connected component analysis fails to work, and a level-based approach may not bring a robust solution, either. The reverse of splitting from a single contact component to multiple contacts should also be taken care of along with the merge case, and a properly treated merge/split pair would avoid the issue of contact ID switching.

Failure Cases:

 Failure to do so may cause contact ID switching when the two fingers physically touch together, which could happen while performing a converge gesture.

CONTACT POSITION STABILITY

Contact position stability requires certain filtering to smooth the noise when touched stationary.

206 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Failure Cases:

 Manipulation such as pinching and rotation – unsmoothed targeting can lead to confusion of certain gesture detection. For example, pinching could be confused with rotation.

BALANCE OF SENSITIVITY AND GHOST REPORTS

 The balance is defined through the ROC curve on the false positives (ghost reports) and the false negatives (missed reports).  The balance point is determined by a combination of a judicious selection of the signal thresholds and an accurate baseline removing process.  There may be multiple levels of thresholds for events such as finger touch down, up, and non-finger detection. Furthermore, the thresholds may be region dependent if such information can be properly fed back to the firmware.  The baseline removing process should promptly update the baseline to minimize the perceived noise level for the purpose of contact detection.

 Partners should follow the state transition guidelines. Failure Cases – when the activation threshold is set too low:

 Ghost points – unwanted triggering of links due to sensitivity being too high.  Software keyboard – unwanted keys tapped. Failure Cases – when the activation threshold is set too high:

 Loss of contacts – dragging of a contact can be lost due to sensitivity being too low at certain areas.  Change of contact ID – dragging of a contact changes the contact ID, causing the app to interpret a different gesture.  Software keyboard – false double taps.

NON-FINGER DETECTION

207 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 A non-finger is defined as a component that is likely not a finger due to its size and shape, as well as the distribution of its sensor pixel values.  A non-finger can be detected through certain approaches. A simple approach is to use a certain set of heuristic tests such as area test, shape test, fractional dimension test, and so on.  Non-finger detection can also be used to report the touch as palm with the palm indicator set. Failure Cases:  Massive interference with all scenarios – causes non-fingers to be interpreted as finger touches.  Baseline removal – failure to identify a non-finger can lose the chance to promptly update the baseline, resulting in suboptimal balance between the sensitivity and ghost reports.

BASELINE REMOVAL

Properly and promptly identify the baseline case within a short time that such updating will not interfere with user attention of baseline change and remove it immediately.

Related Issues

 Suboptimal balance of sensitivity and ghost reports.

SELECTIVE SUSPEND

All USB connected Windows Touch Screen controllers shall support selective suspend and report this capability via a Microsoft OS descriptor. For additional details see Microsoft OS Descriptors.

A device may elect to reduce scan rate in this mode to reduce overall power consumption while still adhering to the contact down latency requirement for this mode.

To ensure no data is lost while the device is resuming from Selective suspend, the touch device manufacturer has two options:

208 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

OPTION 1 (Ideal Solution): Buffering

Once the device has detected contact activity, it shall signal remote wake. From that event, the device shall buffer at least 100 ms worth of contact reports to ensure that little to no input is lost while the USB host controller is resuming. This option works in Windows 8.1 as well as in Windows 8.

OPTION 2 (Backup Solution): Registry Key

This solution should only be used if Option 1 is not feasible (i.e. older touchscreens).

In the case that buffering is not feasible, HID USB touch controllers should not be selectively suspended by the Host after 5 seconds of IDLE time; instead, they should be suspended by the Host only on screen off. To ensure this happens, the following registry values must be set by the OEM for a given device instance:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\\\Device Parameters

refers to the vendor ID (or vendor ID/product ID combination) of the HID USB touch digitizer, and refers to the instance of the device to which these settings should apply.

If the following values do not exist, they must be added:

Value Name Type Value EnhancedPowerManagementUseMonitor DWORD 1 SelectiveSuspendEnabled DWORD 0

In order for the registry keys to be preserved across OS upgrades, they should be set via third party device INF. This device INF should only be setting the registry value and the third party should not install a driver via the INF. Please note that in order to meet the Device.Digitizer.Touch.HIDCompliantFirmware HCK requirement while implementing this INF, the touch digitizer has to report using the inbox Win32k.sys driver and conform to the HID

209 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

specification as defined in windows-device-pointer-protocol.docx. If the INF installs any kind of bridge driver, it will fail HCK tests and Touch Hardware Quality Assurance Certification.

It should also be noted that there is no Sleep state for USB touch controllers as they are not wakeable devices and should therefore be as close to OFF as possible when the system has entered S3 or CS. We recommend USB controllers not be used on CS capable systems.

IDLE STATE

The Idle State is defined as the device operating mode when no contacts have occurred within a host defined period and has therefore been suspended. This is referred to as USB selective suspend.

210 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

If the device is using USB to connect the touch digitizer, the USB hub for the digitizer must not be the same as the USB hub for the storage. Storage devices consume a lot of bandwidth so they are not appropriate for input buses.

If the device is using I2C, the device is required to meet the Device.Digitizer.Touch.ResponseLatency requirement.

POWER ADAPTORS

Different power adapters can generate different noise levels that impact touch performance. Each unique power adaptor configuration should be considered as a unique touch device. Thus if the same touch device is shipped with two different power modules (e.g. 2 pins or 3 pins for different regions), each should be considered as a unique touch device.

BEZEL GUIDANCE

TABLET SYSTEM

Tablet Systems include Slates and Convertible Notebooks. These are required to have flush bezel. Flush bezels are also called “Edge to Edge” glass.

211 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Bezel Area

Display Area

Below is an illustration of a flush bezel which is a cutaway on edge view. If there is a non-active border area between display area and bezel area, the non-active border area is to be considered as part of the bezel area for this illustration and bezel guidance for flush bezels. For details on flush bezel, refer to Device.Digitizer.Touch.Bezel.

Display Area Bezel Area

For a tablet system, the main purpose of the bezel and non-active border area is to allow enough space for users to grip the device to reduce accidental touches. Flush bezel guidance is provided below under the heading Flush Bezel.

NON-TABLET SYSTEM

212 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Non-Tablet Systems include All-In-Ones and Clamshells and these can have non-flush bezels.

Below is the illustration where it is not a flush bezel. In this case, the bezel is higher than the display area.

213 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Non-tablet are not required to have a flush bezel, but if the bezel is not flush and introduces a raised edge, a 20 mm border area must be implemented to allow for uninterrupted edge access. For details on the requirements on non-flush bezel devices, refer to Device.Digitizer.Touch.Bezel and System.Client.Tablet.BezelWidth.

If Non-tablet has a flush bezel, the main purpose of the bezel and non-active border area is to allow enough space for responsive swipe from edge.

FLUSH BEZEL

The bezel size cannot be bigger than 26 mm. The recommended bezel size is 17.5 mm. This is to allow enough space for the users to comfortably hold the tablet in variety of postures without accidentally activating screen UI.

If your form factor is a Small Tablet and it demands your bezel size to be smaller, it can be as small as 7 mm provided that your device meets the accidental touch input requirement as defined in System.Client.Tablet.BezelWidth. Refer to Display section for the full definition of Small Tablet.

If your form factor is an All-In-One or Clamshell and it demands your bezel size to be smaller, it can be as small as 7 mm.

If there is a non-active border, the allowable maximum and minimum applies to the combination of the bezel area and non-active border area.

CONTACT GEOMETRY

Contact geometry data is used throughout the operating system to disambiguate touch targets and improve users’ ability to reliably hit on-screen UI. Applications make use of geometry in painting scenarios and they can use the contact geometry to implement palm rejection or palm detection scenarios in their application layer.

214 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Digitizer must report contact geometry where T (x,y), C (x,y), h’ and w’ are required variables to represent contact geometry.

CONTACT GEOMETRY HID REQUIREMENTS

The table summarizes the HID requirement to report contact geometry. The details are available in windows- device-pointer-protocol.docx.

Variable Definition Tx, Ty Intended target coordinate Cx, Cy Center of the mass X/Y coordinate of the finger contact area. At the same time, this is the center of the rectangle bounding the finger contact area. Can be equal to T. h’ Height of the oriented (pink) rectangle bounding the finger contact area Reported in physical units (mm). This has the accuracy requirement of +/- 1mm. Do not report zero. w’ Width of the oriented (pink) rectangle bounding the finger contact area Reported in physical units (mm) This has the accuracy requirement of +/- 1mm. Do not report zero. Θ Counter clock Angle of the oriented (pink) rectangle against the X axis. Range [0, 360) Optional Variable. If omitted, assumed axis-aligned

This figure shows the parameters to represent a contact.

215 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

h’

Y axis T (x, y)

C (x, y)

w’

X axis

COVER GLASS CONSIDERATIONS

For tablet systems which include Slates and Convertible Notebooks, Microsoft recommends that the cover glass application be one of the following:

 A one glass solution (OGS)  A discrete cover glass application in which the glass serves as a protective display over situated on top of the touch sensing layer, but not as a physical carrier or substrate for the touch sensing layer itself.

The following glass cover design characteristics are highly recommended:

216 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 The cover glass should be chemically strengthened to exhibit non-frangible behavior where the glass does not energetically fragment into a large number of small pieces when impacted with sufficient penetration force.  Particular care should be made to strengthen the edge area of the glass and holes and/or slots should be used in the machined glass cover parts  The cover glass should be scratch and smudge/fingerprint resistant.  The glass bond is sufficient to prevent pooling (ripple effects around the contact) on touch.  Latency of touch reports is reduced to have optimal Windows touch user experience.  It is important to be able to slide a finger smoothly across the glass.

FIRMWARE

To provide better servicing and compatibility with future developments in touch technologies, touch controller firmware must be updatable in the field. Touch controllers should comply with the HID/I2C and/or HID/USB protocol.

Device field firmware update (FFU) capability is an HCK requirement as it is an essential mechanism for allowing devices to receive critical bug fixes and potential feature additions. Touch devices are required to be HID compliant which means that device specific fixes cannot be undertaken via a driver update and hence OEMs will rely on targeted device firmware updates.

The best-in-class Windows systems utilize UEFI to perform device firmware update via a UEFI capsule. There are significant advantages in this mechanism in that system firmware, ACPI, bus controller firmware and device firmware dependencies can all be addressed via a single package which is applied atomically. The role of the input device, be it a touch, pen or precision touchpad is to expose an interface for pushing the update payload to the device. This interface is then leveraged by the UEFI implementation.

217 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

It is highly recommended that the interface be based on a vendor specific top-level HID collection specifically used for host transfers of firmware payloads to the device. This collection would define an output report optimally sized for payload transfers to the device (see below).

Irrespective of interface implementation, it is essential that device firmware/bootloaders are constructed to recover from power loss during firmware update. If a firmware update does not complete successfully, the device should revert to the previous version of firmware on power cycle.

218 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Mouse Vendor Specific Touch Collection Collection Firmware Update (Dummy) Collection

Maximum Supported Firmware Payload Contacts Report

THQA

Contact Reports

Windows Touch Device HID Collections

Top Level Collection

Reporting Collection

Feature Report

219 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

HARDWARE

The following tables summarize the hardware features of a multi-touch solution.

Feature Requirement or Recommendation Power Draw The maximum power draw for a digitizer/controller combination (7” – 15.6”) Active – The state where the touch controller is fully powered and functioning per device requirements. Idle – The state transitioned to from 'Active' when the touch controller has not received input for a specified period of time. Off – The state where the touch controller is powered down. For details, refer to power-handling-windows8-touch-controllers.docx. Communication Bus I2C and USB only. Connected Standby systems must support I2C.

If I2C, must be independent bus for digitizer and required to meet Device.Digitizer.Touch.ResponseLatency requirement.

If USB, Digitizer’s USB Hub must be separate from USB Hub for Storage and must meet selective suspend requirement as described in the documentation earlier.

Contact Geometry Digitizer must report contact geometry as described earlier in this documentation. Palm Detection Digitizer must report Palm as one contact with contact geometry and confidence bit. Velocity Data Digitizer must report velocity data as described in Performance Consideration section of this documentation Others Required to meet all of Device.Digitizer.Base and Device.Digitizer.Touch

220 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

requirements. Refer to WHCR

RELATED CONTENT

The following table provides links to additional content resources for this section.

Icon Meaning

//B Building great touch systems

//B Touch firmware development: Talking HID to Windows

//B Building great Windows 8 systems

//B Make Great Windows Store Apps that are Touch Optimized using

HTML5

//B Build advanced touch apps

//B Designing Windows Store apps that are touch-optimized

//B Make Great Touch Apps using XAML

//B Building and delivering a great Windows Store app for your device

221 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Windows Pointer Device Data Delivery Protocol

Windows Touch Drivers

Windows Hardware Certification

Windows 8 Hardware Certification Requirements and Policies

Touch in Windows 8

PEN

PEN BEHAVIORS

Pen is a unique input in Windows that often takes on the personalities of other inputs, but, in some cases, does something different. Pen supports hovering while showing a small diamond visual on the screen (this is a different visual than the touch and mouse visuals). During most interactions, the Windows mouse, pen, and touch all do the same actions (clicking on buttons, moving objects around, etc.); however, there are a few areas where they differ. In many of these areas, the pen mirrors the interactions of mouse. If it is not doing that, it usually mirrors touch - most notably in the main parts of Windows:

 Scrolling – touch pans, mouse and pen drag the scrollbar  Text selection – touch taps, mouse and pen drag to select  Edge invocation – touch and pen drag in, mouse uses the corners  Secondary tap – touch and pen press and hold, mouse right clicks

222 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

PALM DETECTION

Palm detection is a crucial part of the “inking” experience. Inking allows users to input ink by just starting to write, without having to tap, give a command, or do anything special. Doing so enables the most natural experience with a pen. For users to ink with confidence, they shouldn’t have to worry about whether their palm is leaving behind artifacts (from the pressure of their palm on glass) or activating what is underneath.

Windows uses the presence of a pen to shut-off touch interactions in the operating system so that the two methods will not conflict when a user is attempting to write. This has the most value when the pen is detected well before the user has a chance to make incidental contact with the screen, which usually means the distance between the tip of the pen and the user’s palm. 20 mm is the Pen Range recommendation.

To validate this multi-method input experience is consistent, try using touch while the pen is within the range of 20 mm of the screen and make sure touch does not work.

PEN BUTTON AND ERASER

A Windows tablet may come with a pen. Users hold the pen against the screen’s surface like it’s paper. It’s recommended the pen has a pen button and an Eraser.

223 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

PEN BUTTON

The Pen button is also called a Barrel button. (A barrel button pen is one you click to make the pen tip appear and then click again to make the pen tip go back into the pen’s barrel). When a user presses the Pen button, this sets the Barrel switch in the HID descriptor. The Barrel switch allows right mouse button functionality when using the pen. This implementation allows the user to fast switch the function of the tip from a primary action (tap, drag) to a secondary action (right tap, right drag). Only use the Pen button for the Barrel switch and do not overload it with other functionalities.

ERASER

The eraser is used to delete ink when the Eraser is on the surface of the screen. Eraser HID Descriptor is set when the Eraser button is on the surface of the screen and its points. Only use the Eraser for Eraser HID descriptor and do not overload it with other functionalities. The Eraser button is recommended to be on the opposite end of the pen like an eraser on a pencil.

HARDWARE

Feature Requirement or Recommendation DigitizerAppearAsHID Required. Refer to WHCR Z-Axis detection (Hover Required. Refer to WHCR. Detection) Pen Resolution Required. Refer to WHCR. Pen Range The pen digitizer must report the pen is within range when it is 20 mm away

224 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

from the screen in at least one location on the screen. X and Y coordinates are not required to be reported at 20 mm. Sample Rate This is Reporting rate for the Pen and buttons. Must report 125 Hz. 250 Hz Maximum. Contact Accuracy The physical contact with the device and the contact position the device reports must be within 0.5 mm of each other. This applies whether the input is stationary or in motion. Hover Accuracy While hovering within 5 mm, the pen's position and the position the device reports must be within 0.5 mm of each other. This applies whether the input is stationary or in motion. Type Active Pen Communication Bus I2C and USB Power States (mobile Active, Idle, Off only) Wake Trigger (from Disable (pen should not wake the device.) Selective Suspend and Connected Standby) Digitizer Jitter Digitizer's jitter must be a maximum of 0.5mm over 50 mm of travel

Description

Non-stationary pen inputs must not:

 Exhibit input jitter which exceeds a maximum of 0.5 mm of jitter over 50 mm of travel  Report duplicate packets for inputs  Report jitter in the direction opposite of the direction of travel Stationary touch inputs must produce 0 mm of jitter while they are held. For both non-stationary and stationary inputs there must not be any loss,

225 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

introduction, or swapping of the reported inputs.

Physical Input Position Digitizer reports physical contact with the device and the contact position

Description

The touch digitizer must report all inputs within plus or minus 0.5 mm of the center of the physical input for all touchable areas.

All pixels on the screen must be touchable, including edges and corners.

For additional details on verification and testing of this requirement, go to http://go.microsoft.com/fwlink/?LinkID=234575

Eraser Button Must have this feature. Only use this for setting Eraser HID Descriptor and implement the state transitions as described in the Windows Pointer Device Data Delivery Protocol. Pen Button (or Barrel Must have this feature. Only use Pen button for setting the Barrel switch and Button) implement the state transitions as described in Windows Pointer Device Data Delivery Protocol. Pressure Devices must report using the pressure usage to represent force applied by a pen between 0-255g with precision +/- 5g. NoiseSupression Pen digitizer must adhere to Touch.NoiseSupression. Refer to WHCR. FieldFirmwareUpdate Pen digitizer must adhere to Touch.FieldFirmwareUpdate. Refer to WHCR. HIDCompliantFirmware Pen digitizer must adhere to Touch.HIDCompliantFirmware. Refer to WHCR. PowerStates Pen digitizer must adhere to Touch.PowerStates. Refer to WHCR. ResponseLatency Pen digitizer must adhere to Touch.ResponseLatency. Refer to WHCR.

226 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

VALIDATION SCENARIO

INKING/DRAWING

While not complete, the following list contains examples of validating inking/drawing:

 Inking in Windows Store Applications “DocuSign Ink”, “Note Anytime” and “OneNote MX”.  Highlighting texts in applications such as Windows Application “Reader”.  Writing notes in Windows Journal.  Drawing in Windows Store Applications “didlr” and “Fresh Paint”.  Writing an equation in math input panel.  Writing a text and trying text recognition in Windows Store “Onenote MX” or Text Input Panel which is part of the Soft Keyboard.

MULTI MODAL

Check that the multi modal experience is intact.

1. Open One Note MX. 2. Draw several strokes using the pen, a single finger, mouse, or two or more fingers simultaneously. Expected: Ink displays and flows under your finger/pen with no noticeable lag. 3. Use pen (barrel) button and drag on the paint window Expected: Nothing happens. Pen (barrel) button selects. 4. Select the eraser button and attempt to erase some strokes Expected: Parts of the stroke are erased.

EDGE

227 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Check Basic Edge Interactions: 1. Open any two apps. 2. Return to the Start Screen. 3. Using the pen, at a fast speed, attempt to use each edge: i. Right edge: Charm bar appears. ii. Left edge: Application is switched. iii. Top/Bottom edges: Context menu appears. Check Near-Edge Interactions: 1. Open a text document in Notepad so both vertical and horizontal scrollbars display when maximized. 2. Maximize the window then use the pen to drag each scrollbar. The focus here is the number of interactions more than the length of each interaction, so try many short drags. 3. Make sure the Edge UI never displays.

START SCREEN

Check Start Screen Scenarios: 1. Go to the Start Screen. 2. Verify the pen can select tiles on the Start menu and that you can perform the following gestures: i. Rearrange: Drag the pen down or up on a tile. You should see the tile break free and move with the pen ii. Select: Hold the pen down on a tile until you see a checkmark and context menu appear. This should take no more than one second.

OTHER NAVIGATION

Check the following navigational scenarios:  Scroll a page in IE  Copy / paste text between applications using only the pen with context menus  Hover over an item and look at the tooltip

228 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Navigate folders in Explorer  Click a link or a small button in IE.

USER EXPERIENCE

Palm rejection is a crucial part of the inking experience. For users to ink with confidence, they shouldn’t have to worry about whether their palm is leaving behind artifacts (from accidentally pressing the screen) or activating what is underneath.

The touch digitizer does not reject a palm touch. The operating system touch input stack stops streaming all touches when a pen comes in range. The detection distance for "pen in range" was increased in Windows 8. This allows the operating system to detect the user's intent to use a pen in time to stop streaming touch.

The digitizer keeps reporting and can use the confidence bit if necessary, but it’s not required. There is no requirement on how quickly to detect and report the confidence bit.

KEY HARDWARE ACCOUNTABILITY  Pen in-range detection accuracy and speed

PEN APPENDIX

HARDWARE CONFIGURATIONS

TABLET MODE Component Remarks Pen Type Active Resolution 150 pixels per inch Equal to or greater than the native display Reporting Rate 100Hz

229 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Busses I2C or USB

CLAMSHELL CONFIGURATION Component Remarks Pen Type Active Resolution 150 pixels per inch Equal to or greater than the native display Reporting Rate 100Hz Busses I2C or USB

ALL-IN-ONE CONFIGURATION Component Remarks Multi-Touch Type Projective Capacitive Resolution 150 pixels per inch Equal to or greater than the native display Reporting Rate 100Hz Busses I2C or USB

DETECTION RANGE

Windows uses the presence of a pen to shut off touch interactions in the operating system so that the two methods don't conflict when a user tries to write. This has the most value when the stylus is detected well before the user has a chance to make incidental contact with the screen, which is usually the distance between the tip of the pen and the user's palm—up to 5 cm or so.

HEAT MANAGEMENT

Heat management plays an important role in delivering safe systems with good performance even with a high energy workload. Machines are becoming more mobile and compact, making hardware design for thermal dissipation more challenging. At the same time, users’ expectations for performance and capabilities continue to grow, increasing the heat generation of system components. The impact of good thermal design now is more critical than ever.

230 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Form factors such as tablets and clamshells, generally have the following problematic thermal characteristics:

 Small, compact space with little room for air flow  Fanless or small fans  Large battery and display (relative to overall form factor)  Drive as much performance from the hardware

Because of these characteristics, a centralized unit is generally required on devices to manage thermal constraints throughout the platform. Systems with or without fans may require reducing performance or even functionality of various pieces of the to reduce the temperature in over-heated locations while also preserving the user’s experience (for example, watching a video). Like power management, heat management must be done on a platform-wide basis, orchestrating local device thermal constraints within the scope of global heat conditions.

The main contributors to thermal spikes in the platform are:

 CPU and GPU (for example, the SoC itself).  Battery charging  Display backlight

The goal for Windows is to manage these areas at run time in an efficient and minimally-user-invasive manner.

DEFINING A “GOOD” THERMAL SOLUTION

What does it mean to design a system with a good thermal solution?

This overarching question is vague and ambiguous and needs to be broken down into many more specific questions. What does it mean to “perform at their best?” Is it realistic for all components to deliver 100% at all times? For short periods of time? How short? How hot is too hot? Is “hot” different for each device?

231 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

This section only covers the overview and basics of thermal management. For more information, refer to the Thermal Guide on Connect.

THERMAL MANAGEMENT GUIDELINES  Safety – Regardless of how the customer uses the device, it should never become too hot to handle.  Operating range – The system operates over the normal operating range of ambient temperatures.  Full-performance experiences – Core Windows experiences are not performance-compromised under normal operating conditions.  Quiet while idle – When the machine is in a low power state such as Connected Standby, users should not hear or see the fan turn on.  Diagnosability – Windows prefers any cooling mitigations, active or passive, to be initiated through OS provided mechanisms so that issues can be identified in the field and reported back via telemetry.

Windows suggests a more focused direction to tackling the thermal issue that is driven by user experience.

THERMAL USER EXPERIENCE

From a user’s perspective, thermal management should be invisible. Slates and other SoC-based systems should have the hardware and software energy efficiency necessary to stay cool under normal use. The system should stay on and fully functioning without any thermal mitigations for as long as possible. This goal depends on good hardware design.

Even when the system is undergoing thermal mitigations, users should not experience any disruptions as long as the machine is still usable. Only when the machine can no longer operate should users be notified of the thermal situation.

THERMAL SCENARIOS

You can group thermal challenges in three scenarios:

232 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

1. The system is on, but producing too much heat to be sustainable. The system is fully functioning when it detects it is getting warm. Thermal mitigations, i.e. passive cooling and active cooling, must begin to reduce the heat produced to a sustainable rate. If thermal mitigations are not successful, #3 occurs. 2. The system is on, but unusable due to thermal constraints. The user notices this in the following ways: a. The system display is on but does not respond to the user’s inputs. b. The machine is too hot to continue running and must initiate shutdown or hibernate now. c. The machine is much too hot and firmware cuts the power to the system. 3. The system is off, and cannot boot due to thermal constraints. When a user tries to turn on a machine in an environment that is too hot or too cold, the machine fails to boot.

THERMAL MITIGATIONS EXPERIENCE

While the system is on and in use, the user should notice any thermal mitigations. In other words, the user would never know when their machine is or is not thermally mitigated. The goal of thermal mitigations is to allow the customer to use the machine for as much and as long as possible without disruption.

IHV/OEM partners have a great deal of control in their design of the system to reduce the need for thermal mitigation by designing hardware that is effective at dissipating heat. For more information, refer to the Thermal Guide on Connect.

CRITICAL THERMAL “SHUTDOWN” EXPERIENCE

In extreme conditions, where the ambient temperature is much higher above the targeted temperature range, heavy workloads might cause the system temperature to continue rising even with the throttling mechanisms engaged.

233 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

When the critical shutdown threshold is met, the system immediately starts the critical thermal action. By default, systems will hibernate if enabled and shutdown if hibernate is not available. This thermal shutdown path is the shortest shutdown path available and usually completes within 1 second. No notification is given to apps or services, so apps do not have the chance to autosave or close.

Furthermore, each system must have knowledge of its hardware failsafe temperature, which is determined in ACPI by the IHV. This value is very important because the firmware must be able to detect thermal constraints before the OS is loaded and prevent the system from causing damage to itself and the user. If at any time while the system is on, the system reaches its hardware failsafe trip point, it immediately cuts off the power and turns off. The failsafe trip point is usually slightly higher than the critical shutdown trip point. This way, the system can hibernate or shutdown before the hardware failsafe is reached. It is possible to reach the failsafe trip point before the system completes a critical hibernate or shutdown. However, if you choose a good critical threshold, this should seldom occur.

THERMAL BOOT EXPERIENCE

Systems have thermal constraints during boot as well. In firmware, each system must check the temperature before boot to ensure that boot can complete successfully. Two major concerns:

 Ambient temperature is too hot. Boot is often a resource intensive action and produces a lot of heat. If too much heat is produced during boot, the system may hit the hardware failsafe temperature and kill power to itself.  Ambient temperature is too cold. Battery may not be able supply enough resources to the system.

Systems designers should model and predict the thermal characteristics of boot, in particular temperature increases.

Firmware must check that there is enough headroom for the system to boot without crossing the hardware failsafe trip point.

234 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

For example, if the system temperature consistently rises 5°C during boot and the failsafe temperature is 40°C, the system should be (at the very most) 35°C at boot. This is necessary in firmware since the Windows Thermal framework will not have been loaded at boot to mitigate the issue.

In the case where a machine is too hot or cold to boot, the system should provide user feedback to give the user an opportunity to alleviate the issue and re-attempt boot when appropriate.

Please follow the guidelines in “Boot Experience” paper published on Connect for instructions on how to implement the thermometer logo in firmware: https://connect.microsoft.com/site1094/Downloads/DownloadDetails.aspx?DownloadID=46448.

THERMAL MANAGEMENT REQUIREMENTS CHECKLIST

HARDWARE REQUIREMENTS The following points are required for a good thermal hardware design:

 All systems meet applicable industry standards (for example, IEC 62368) around consumer electronics safety.  Hardware must have failsafe temperature trip point that shuts down the system or prevents boot.  Sensor hardware must be accurate to +/- 2° C.  Sensor hardware must not require software polling to determine if a threshold temperature is exceeded.  While operating, the system display brightness is never thermally limited to less than 100 nits.  Battery charging is not throttled while the system is 1) idle and within the ambient temperature range below 35⁰C, or 2) under any conditions while the ambient temperature is below 25⁰C.

HCK TEST REQUIREMENTS FOR CONNECTED STANDBY SYSTEMS

All Connected Standby systems have requirements regarding thermal regardless of processor architecture and form factor. These requirements are tested in the HCK.

235 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

1. All CS systems must have at least one thermal zone. 2. Each thermal zone must report actual temperature on the sensor. 3. At least one thermal zone must have critical shutdown temperature defined. An exception is made for Intel® Dynamic Platform and Thermal Framework. 4. All CS systems with fans must expose its activity to the OS. The fan needs to notify the OS of its activity at all times, including during idle resiliency in Connected Standby. Currently, this notification causes no action from the OS. The main purposes of this are diagnosability and telemetry. The fan notification can be integrated with existing tracing tools, including Windows Performance Analyzer. System designers can use these tools to tune the platform design. 5. All CS systems with fans must keep the fan off while in “Sleep” or Connected Standby state. The HCK test here runs a realistic CS workload that should not trigger the fan turning on. If the thermal solution had this requirement in mind, it should have no problem passing this test.

For implementation details regarding these requirements, refer to the “Thermal Guide” on Connect.

THERMAL MANAGEMENT SOLUTIONS

The Window Thermal Framework based on ACPI is the recommended thermal management solution for all systems. The major benefits include the ability to easily diagnose thermal related issues with inbox tools and valuable telemetry gathered in the wild. For details on Windows Thermal Framework, refer to the Thermal Guide on Connect.

However, alternative solutions to the Windows Thermal Framework are acceptable if the above requirements are met. In addition, each core silicon or SoC partner may have their own proprietary thermal solutions compatible with and supported by Windows (for example, Intel® Dynamic Platform and Thermal Framework).

BATTERY CLASS

236 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Windows offers battery support through two driver options: a native miniclass driver and an ACPI-based Control method battery driver.

BATTERY MINICLASS DRIVER

Battery miniclass drivers use the Thermal Cooling Interface directly as described.

CONTROL METHOD BATTERY

The Windows Control Method Battery miniclass driver (CMBATT.SYS) uses the Thermal Cooling Interface. This necessitates a new ACPI control method to set the thermal limit for charging. This method is implemented as a Device Specific Method (_DSM), as defined in the ACPI 5.0 specification, Section 9.14.1.

CHARGING THERMAL LIMIT DEVICE SPECIIFC METHOD UUID Revision Function Description 4c2067e3-887d-475c-9720-4af1d3ed602e 0 1 Set Battery Charge Throttle

Arguments Arg0: UUID: 4c2067e3-887d-475c-9720-4af1d3ed602e Arg1: Revision: 0 Arg2: Function: 1 Arg3: Thermal Limt (Integer value from 0 to 100) Return No return value

The firmware is responsible for taking the current thermal limit into account when engaging charging.

DISPLAY CLASS

237 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Windows' built-in display driver (MONITOR.SYS) uses the Thermal Cooling Interface. It maps the thermal limit directly to display brightness, which is limited to the Thermal limit percentage, unless the operating system- requested brightness is already below this level.

PROCESSOR CLASS Windows' Processor Power Management infrastructure supports the Thermal Cooling Interface. Processor drivers are notified via this interface (instead of a direct call) when a thermal limit must be applied. Processor drivers will also report the new thermal limit back to the Kernel so future Performance state requests are based on the new limit.

GRAPHICS CLASS Display miniport drivers use the Thermal Cooling Interface directly as described. If the PEP handles passive cooling for the Graphics stack, it must filter the stack and respond to the Interface Query on behalf of the miniport.

DISPLAY Recommended Feature Tablet Mode Clamshell All-in-One Diagonal Size (in.) >=10.1 >=10.1 >=15 Resolution >=1366x768 >=1366x768 >=1366x768 Aspect Ratio 16:9 16:9 16:9 Viewing Angle Symmetrical 85⁰ N/A N/A Brightness >=400 nits at 0 >=400 nits at 0 >=400 nits at 0 degrees , 150 nits at degrees, 150 nits at 40 degrees, 150 nits at 40 40 degrees degrees degrees Backlight LED or better LED or better LED or better IS0 standard (white -->black--> 6 milliseconds (ms) to 6 ms to 16 ms 6 ms to 16 ms white) response rate as measured 16 ms as the rise time (tR) and fall time

238 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

(tF) of a pixel as it changes from white to black to white Grey to Grey response rate 6 ms 6 ms 6 ms Contrast ratios and color 800:1 800:1 800:1 reproduction Refresh rates 48 Hz, 60 Hz 48 Hz, 60 Hz 48 Hz, 60 Hz

RESOLUTION AND WINDOWS STORE APPS

Windows Store apps have supported resolution guidelines for a good Windows experience. For display resolution recommendations, refer to the Display and Hardware Configurations section.

Resolution User Interface 1024x600 Desktop apps only (no access to Windows Store apps) 1024x768 Windows Store apps and Desktop apps >=1366x768 Windows Store apps with Snap View and Desktop apps

DISPLAY SURFACE

You should follow these guidelines to create a successful touch experience on a tablet mode display:

 Use glass or glass coatings designed to reduce fingerprints.  Consider anti-glare materials and LED-based illumination to ensure screen readability in outdoor and brightly lit indoor environments.  Choose an anti-glare material with the following characteristics:

o Low haze value (<=6%) to minimize reduction of display clarity and contrast while providing minimal friction. o Finer than the sub-pixel pitch to prevent sparkling.

239 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

o Minimal surface friction (surface roughness of 100-500 nm (RMS). High surface friction causes the finger to skip over the surface, breaking touch contact.

REFRESH RATE

Starting in Windows Blue, the OS will (on supported hardware) automatically and seamlessly switch the refresh rate to better match the frame rate of any full-screen videos that are playing. For example, when playing a 24fps video (film), the OS will switch to 24 Hz or 48 Hz. When playing a 30fps video (NTSC TV), the OS will switch to 30 Hz. This functionality provides two key benefits to the user:

1. For film content (24fps), by setting the refresh rate to an integer multiple of the video frame rate, 3:2 pulldown no longer needs to be performed. Each video frame will be displayed for exactly 41.7ms – 3:2 pulldown, which is necessary at 60 Hz (since it is 2.5x the frame rate), results in a pattern of 33.3ms, 50ms, 33.3ms, 50ms, …, causing ‘film judder’. 2. Because the optimal refresh rate can be lower than the standard 60 Hz, running at these refresh rates actually improves video playback battery life for users. Running at 48 Hz for 24 fps video improves system battery life upwards of 5%, while running at 24 Hz provides an additional 10% savings over 48 Hz.

Because the battery life savings when running at 24 Hz are so significant (measured in hours), we recommend that all portable form factors use displays that are qualified for 24 Hz and 30 Hz refresh rates when possible. Generally, this means using display panels built on the Indium-Gallium-Zinc-Oxide (IGZO) process. Amorphous Silicon-based panels (a-Si) are generally only able to support the 48 Hz and 50 Hz refresh rates (which are still valuable).

The OS will switch to the following refresh rates based on the underlying content in order of priority (lower refresh rates are always a higher priority since the power savings are greater there).

240 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

24 fps (NTSC film) 24 Hz, 48 Hz, 60 Hz.

25 fps (PAL film) 25 Hz, 50 Hz, 60 Hz.

29.97 fps (NTSC TV) 30 Hz, 60 Hz.

48 fps (very rare, some films shot at 48 fps) 48 Hz.

50 fps (PAL TV) 50 Hz.

59.94 fps (NTSC TV) 60 Hz.

This feature is designed so that the lower refresh rates are triggered automatically and triggered without any visible artifacts normally associated with a mode switch.

For this feature to be engaged by the OS at a particular refresh rate, the system must report support for the rate through its firmware. By reporting support for a particular refresh rate, the system is guaranteeing that the display panel can run at the corresponding refresh rate without any adverse effects (such as flicker).

DEVICE COVER GLASS

This section defines the functional attributes for device cover glass that provides the user with a high quality touch-screen experience worthy of the Microsoft brand. Attributes include those that preserve and protect the surface, appearance, and device, and improve the touch functional experience.

COVER GLASS FOR DISCRETE APPLICATIONS

241 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Discrete cover glass applications use the glass as a protective display cover on top of the touch sensing layer, but not as a physical carrier or substrate for the touch sensing layer (ITO, etc.) itself. You should conduct all tests and measurements following the conditions outlined in the Cover Glass Test and Measurements.

For optimal damage resistance:

 The cover glass should be chemically-strengthened with a minimum magnitude and depth of layer (DOL) of the compressive stress as follows. In all cases, glasses should exhibit non-frangible behavior. Frangible behavior is when the glass breaks into a large number of small pieces when hit with sufficient force: o 0.55 mm: ≥ 700 MPa CS and > 35 microns DOL o 0.7 mm: ≥ 750 MPa CS and > 40 microns DOL o 1.0 mm: ≥ 750 MPa CS and > 45 microns DOL  4-point bend test performance (edge strength) recommendations: o 0.55 mm: Average peak stress = 600 MPa o 0.7 mm: Average peak stress = 620 MPa o 1.0 mm: Average peak stress = 620 MPa  Abraded ring-on-ring test performance (surface strength) recommendations: o 0.55 mm: Average load-to-failure = 30 kgf o 0.7 mm: Average load-to-failure = 55 kgf o 1.0 mm: Average load-to-failure = 100 kgf  The following general design guidance should apply to machined cover glass parts:

242 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Figure 14 - Machined cover glass part 4

4 Tests conducted using a standard 1mm glass

243 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

# Feature Measure Guidance 1 Outer corner Radius >1.0 mm 2 Slot radius Radius >1.5 mm 3 Slot width Width >1.5 mm 4 Min. hole diameter Diameter >1.5 mm 5 Hole-to-edge distance Distance >4.0 mm 6 Width of protrusion Width Width > Depth 7 Width of the slot Width Width > Depth 8 Inner radius Radius >1.0 mm

 The indentation threshold as measured with a Vickers indenter should be ≥ 5* kgf.  The Knoop scratch load to lateral cracks should be ≥ 4* N.

High-Quality Touch Experience Recommendations:

 Minimum dielectric constant is 7.0.  The Young's Modulus of the glass should be 71.5±5 GPa.  The coefficient of thermal expansion (CTE) should be 80±4 x 10-7 per ºC.  Water absorption should meet Hydrolytic Resistance Class 2 or better.

High-Quality Viewing Experience Recommendations:

 Optical transmission as measured through 1.0 mm thick cover glass is >91% nominal transmission across the 390-760 nm (visible) wavelength spectrum, with variation not to exceed ±1%.

COVER GLASS FOR INTEGRATED TOUCH APPLICATIONS

Integrated touch cover glass applications are glass covers that serve as a protective display cover and as a physical carrier or substrate for the touch sensing layer (ITO, etc.) itself. Integrated touch cover glass applications are also

244 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

known as one-glass solutions (OGS). You should conduct all tests and measurements following the conditions outlined in the Cover Glass Test and Measurements section.

Optimal Damage Resistance Guidelines:

 The cover glass should be chemically-strengthened with a minimum magnitude and depth of layer (DOL) of the compressive stress (CS) as follows. In all cases, glasses should exhibit non-frangible behavior. Frangible behavior is when the glass breaks into a large number of small pieces when hit with sufficient force: o 0.55 mm: ≥ 500 MPa CS and > 25 microns DOL o 0.7 mm: ≥ 550 MPa CS and > 37microns DOL o 1.0 mm: ≥ 550 MPa CS and > 55 microns DOL  4-point bend test performance (edge strength) recommendations: o 0.55 mm: Average peak stress = 600 MPa, B10 > 450MPa o 0.7 mm: Average peak stress = 620 MPa, B10 > 500MPa o 1.0 mm: Average peak stress = 620 MPa B10 > 500MPa  Abraded ring-on-ring test performance (surface strength) recommendations: o 0.55 mm: Average load-to-failure = 13 kgf o 0.7 mm: Average load-to-failure = 20 kgf o 1.0 mm: Average load-to-failure = 29 kgf  Refer to Figure 14 - Machined cover glass part for general design guidance on machined cover glass parts. Holes and/or slots are not recommended on cover glass used for integrated touch applications due to compromises in edge strength.  The indentation threshold as measured with a Vickers indenter should be ≥ 5 kgf.  The Knoop scratch load to lateral cracks should be ≥ 4 N.

High-Quality Touch Experience Guidelines:

245 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

HIgh-Quality Viewing Experience Guidelines:

 The recommended optical transmission as measured through 1.0 mm thick cover glass is >91% nominal transmission across the 390-760 nm (visible) wavelength spectrum, with variation not to exceed ±1%.

COVER GLASS TESTS AND MEASUREMENTS  Make all measurements on bare glass with no coatings, films, or other types of surface treatments applied.  Conduct all tests in a controlled environment (23±2º C, 50±5% RH)  4-Point Bend. Perform horizontal bending testing using 18mm loading spans, and 36mm support spans applying a nominal crosshead rate of 5mm/min. The preferred sample geometry is 44mmx60mm. Breaking stress is reported based on ASTM C158. Sample geometries beyond the preferred geometry may require consultation by Corning on span selection.  Abraded Ring-on-Ring (AROR). Abrasion with 90 grit Silicon Carbide @ 5psi, 5 seconds, ¼" mask; retained strength measured through Ring on Ring, ½" load ring, 1" support ring. Nominal crosshead rate of 1.2mm/min. Center the abrasion on the glass sample and place it in the center of the loading ring for testing. Breaking load is reported. The preferred sample geometry is 50mmx50mm. You can use ASTM C1499 as a reference for some aspects of the ring on ring procedure.  Indention. A Vickers indenter makes a series of indents in a glass samples, stepping through a range of repeated loads and held at the maximum load for 10 seconds, samples are inspected to assess the load where >50% of the indents exhibit evidence of radial cracks after a fixed period of time once the indents have been created. Loading/unloading rates = 0.2mm/min.  Scratch Threshold. A Knoop indenter places a series of 10mm scratches in a sample. Repeated scratches are performed over a range of loads, samples are inspected to assess the load where >50% of the scratches exhibit evidence of lateral cracks after a fixed period once the scratches have been created.

TOOLS AND TECHNICAL REFERENCE

246 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Resource Title Human Input Devices Design Guide Windows Touch Drivers Power button behavior GetSystemMetrics Keyboard Hotkeys and Windows 8 Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies HID over I2C Unattend settings Windows ACPI Implementation Guide GPIO buttons testing with MITT platform Windows Driver Kit (WDK) 8

BUILDING A GREAT DEVICE FOR NETWORKING AND DEVICES

STORAGE AND BOOT SOURCES

Windows provides in-box support for most of the prominent storage host controllers (HCs). Windows supports the following storage technologies: Serial-ATA, SD/eMMC, and USB Mass Storage (USB-MS). Windows does not support raw NAND flash. Additionally, boot support is limited to Serial-ATA, eMMC, and USB 3.0 storage devices. You must include at least 32 gigabytes (GB) of storage for the boot device, with at least 10 GB of space available to the user.

Feature Remarks

247 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Power Max Idle Power 5 mW Random Performance 4KB write IOPs (measured over a 1 GB area) >= 200 4KB write IOPs (measured over a 10 GB area) >= 50 64KB write IOPs (measured over a 1 GB area) >= 25 4KB Read IOPs (measured over a 10 GB area) >= 2000 4KB 2:1 read/write mix IOPs (measured over a 1 GB area) >=500 4KB 2:1 read/write mix IOPs (measured over a 10 GB area) >=140 Sequential Performance Write speed (64 KB I/Os) (measured over a 10 GB area) >= 40 MB/s Write speed (1 MB I/Os) (measured over a 10 GB area) >= 40 MB/s Read speed (64 KB I/Os) (measured over a 10 GB area) >= 60 MB/s Device I/O Latency Maximum I/O latency < 500 milliseconds (ms) Additional I/O latency Maximum of 20 seconds sum-total of user- perceivable I/O latencies over any 1 hour period of a user-representative workload, where a user-perceivable I/O is defined as having a latency of at least 100 ms

SD/EMMC HOST CONTROLLERS

Windows supports SD and eMMC based storage. An eMMC device may be used as either a system (boot) disk or as a data disk, while an SD device can only be used as a data disk.

The following table describes SD/eMMC storage devices and supported modes.

248 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Flash type Boot Data disk eMMC Yes Yes SD No Yes

eMMC storage is only recommended for Connected Standby platforms.

HARDWARE

Host Controllers for flash storage must comply with the following standards.

Host Controller Interface Revision eMMC 4.41 or later SD SD 2.0, 3.0

Windows supports the following eMMC storage types:

 eMMC

FIRMWARE

ACPI-enumerated SDIO controllers must contain the register base address for each slot on the controller within its _CRS object, ordered according to the slot number. If the SDIO controller does not support the standard Card Detect bit due to power constraints, then the platform must provide a GPIO interrupt to signal the card insertion event. This GPIO interrupt resource must be non-shared (Exclusive), edge-triggered (Edge), and wake-capable (Wake), and it must appear as the last interrupt resource in the _CRS.

Devices and Slots connected to the SDIO controller must appear in the ACPI namespace with the _ADR object. For SDIO, the _ADR provides an ordinal denoting the slot number on the controller to which the device is connected. Internal devices (non-removable) must include the _RMV object indicating that the device cannot be removed.

249 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

When using eMMC as the primary boot device, the eMMC memory must be hardware partitioned so the boot- critical portion of the EFI Firmware resides in an area of the device Windows can’t access. The Connected Standby platform SoC vendor or firmware provider must furnish the software tools needed to maintain and update the firmware.

DRIVERS

Windows provides in-box drivers for SD/eMMC host controllers that comply with the SD Host Controller specification. If the SD/eMMC host controller is non-standard, then the hardware vendor must provide a device driver to support their hardware. Windows locates the best driver by using the ACPI namespace, PID/VID, or custom INF.

In-box driver functionality includes support for Boot, Paging, Crash Dump, Hibernation, and File System I/O.

SECURITY

The storage device should support the following security features:

 Trusted commands  TCG OPAL v2.x  IEEE 1667 TCG Storage Silo

PARTITIONING

PARTITIONING SCHEME

eMMC is the default storage device for Connected Standby enabled platforms.

250 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

For cost reasons, an OEM may prefer to put the device's firmware on the same physical eMMC device as the rest of the system. However, with this design, a customer could inadvertently disable the device if they damage the area where the device firmware is installed through malware, accidental reformat, or reinstallation of Windows.

To reduce these problems, the JEDEC eMMC 4.41 specification (JESD84-A441) lets you create multiple physical partitions on a single storage device.

The physical partitions are not normally visible to the host operating system which should help reduce these problems.

This section provides an overview of the partitioning mechanism described in JESD84-A441/7.2 and describes the recommended partition layout that an OEM should consider following.

BOOT AREA AND RPMB PARTITIONS

An eMMC device is initially manufactured with the following default layout.

251 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Offset 0 Offset 0 Boot Area Partition 1 Offset N x 128KB Offset 0 Boot Area Partition 2 Offset N x 128KB Offset 0 RPMB User Data Area Offset M x 128KB

Card size - 1

The default layout of an eMMC device includes:

User Data Area  This is the default area visible when the card is powered on.

Boot Area Partition 1 and Partition 2  The device can this area for loading device firmware and there is a special mechanism that a device may use to access the boot area partition during system bootstrap. (JESD84-A441/7.3)  JESD84-A441 requires the minimum size of the RPMB partition to be 128 KB. However, the manufacturer of the eMMC device is free to provision larger RPMB partitions in 128 KB increments and Windows requires a minimum RPMB size of 256KB.

252 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 The size of these partitions is fixed when the eMMC device is manufactured and cannot be altered.

RPMB  This area is protected against unauthorized read and write. Replay attacks are reduced with a monotonically increasing write counter maintained by the eMMC hardware. An HMAC (hash-based message authentication code) with a pre-shared key authenticates commands. (JESD84-A441/7.6.16)  JESD84-A441 requires the minimum size of the RPMB partition to be 128 KB. However, the manufacturer of the eMMC device is free to provision larger RPMB partitions in 128 KB increments.  The size of this partition is fixed when the eMMC device is manufactured and cannot be altered.

GENERAL PURPOSE AREA PARTITIONS

JESD84-A441/7.2 also defines the ability to create up to four General Purpose Area Partitions.

253 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Offset 0 Offset 0 Boot Area Partition 1 Offset N x 128KB Offset 0 Boot Area Partition 2 Offset N x 128KB Offset 0 User Data Area RPMB Offset M x 128KB

Offset 0 Remaining Space -1

General Purpose Partition 1

General Purpose Partition 2

General Purpose Partition 3

General Purpose Partition 4

You may create these General Purpose Area partitions by sending the SWITCH command (JESD84-A441/7.2.3) to write the new partition layout to the eMMC device's Extended CSD register (JESD84-A441/8.4, GP_SIZE_MULT field). The General Purpose Area partition sizes must be a multiple of the High Capacity Write Protect Group Size. (JESD84-A441/8.4, ERASE_GROUP_ DEF field)

254 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The new layout is then committed by writing to the PARTITIONING_SETTING_COMPLETED bit in the Extended CSD, followed by a power cycle.

When the new partitions are created, the system removes storage space from the end of the User Data Area and assigns it to the new General Purpose Area partitions.

Note: You can only configure the General Purpose Area partitions once. Once set, you can never alter these partitions.

ACCESSING THE EMMC GENERAL PURPOSE AREA PARTITIONS

An eMMC device powers up with the User Data Area being the active partition.

To access a General Purpose Area Partition, the card must be sent a SWITCH command, writing the active partition ID into the eMMC device's Extended CSD register (JESD84-A441/7.2.4).

The Microsoft SD/eMMC driver will have API support to allow vendor kernel mode drivers access to the RPMB and GPP partitions. For guidance, refer to the "MMC RPMB and GPP IOCTL Design.docx".

RECOMMENDED PARTITION LAYOUT

We recommend you store the device firmware in the General Purpose Area Partition 1, unless it fits entirely in the Boot Area Partition 1.

CASE 1 – DEVICE FIRMWARE FITS ENTIRELY INTO A BOOT AREA PARTITION

255 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Offset 0 Offset 0 EFI System Partition Boot Area Partition 1 Device Firmware Offset N x 128KB Offset 0 Boot Area Partition 2 Unused Offset N x 128KB User Data Offset 0 Area RPMB Windows Offset M x 128KB

Card size - 1

If the device firmware fits entirely into a Boot Area Partition, then the simplest solution is to just use Boot Area Partition 1.

The platform’s boot block will load the device firmware from the eMMC Boot Area Partition.

Once the firmware is initialized, the card must be reset to the User Data Area to allow Windows to load.

CASE 2 – DEVICE FIRMWARE DOES NOT FIT INTO THE BOOT AREA PARTITION

256 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Offset 0 Offset 0 EFI System Partition Boot Area Partition 1 Device Firmware Boot StraOpffset N x 128KB Offset 0 Boot Area Partition 2 Unused Offset N x 128KB User Data Offset 0 Windows Area RPMB Offset M x 128KB

Remaining Size - 1 Offset 0

General Purpose Partition 1 Device Firmware

Figure 15 - Device Firmware Does Not Fit Into the Boot Area Partition

If the device firmware can’t fit into the Boot Area Partition, put a bootstrap firmware into the Boot Area Partition and allocate the General Purpose Area Partition 1 to store the rest of the firmware.

The bootstrap firmware must be able to initialize the SD/MMC host controller, and issue the appropriate SWITCH command to set the active partition and load the device firmware.

Once the firmware is initialized, the card must be reset to the User Data Area so Windows can load.

257 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

258 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

CASE 3 – PLATFORM BOOT BLOCK IS SMART ENOUGH TO DO THE WHOLE THING

Offset 0 Offset 0 EFI System Partition Boot Area Partition 1 Unused Offset N x 128KB Offset 0 Boot Area Partition 2 Unused Offset N x 128KB User Data Offset 0 Windows Area RPMB Offset M x 128KB

Remaining Size - 1 Offset 0

General Purpose Partition 1 Device Firmware

Figure 16- SoC Boot Block is Smart Enough to do the whole thing

If the boot block in the SoC is smart enough to fully initialize the SD/eMMC controller, then the Boot Area Partitions may be ignored entirely, and the boot block can send the appropriate SWITCH command to load the device firmware from the General Purpose Partition 1.

259 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Once the firmware is initialized, the card must be reset to the User Data Area so Windows can load.

RELATED RESOURCES

Icon Meaning Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

SERIAL-ATA STORAGE

Windows supports serial-ATA storage connected to an AHCI host controller. The storage device may be defined as a system (boot device) or data disk.

HARDWARE

AHCI Host Controllers using Windows for boot support must comply with the AHCI specification. The boot device must be connected to an internal SATA port. Booting Windows from an eSATA storage is not supported.

The following table summarizes the host controller interfaces supported in Windows.

Host Controller Interface Revision AHCI 1.1, 1.2

If you use SATA as the storage interface for a Connected Standby platform, low-power SATA is preferred if the power consumption of the SATA device meets the power targets listed in the table. SATA devices that use low- power schemes, such as PHYSLP, may provide a good solution for higher performance storage.

Feature Remarks

260 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Power Max Idle Power <=5 mW5

Traditional platforms support the following SATA storage types:

 Solid-state drive (SSD)  Hard disk drive (HDD)  Hybrid hard disk drive (HHDD)  Optical disk drive (ODD)

FIRMWARE

The UEFI firmware must be able to interface with the AHCI controller and load the boot binaries from a Serial-ATA device. The UEFI firmware must comply with spec version 2.3.1 (http://www.uefi.org/specs/).

When SATA is used as the primary boot device, to ensure reliability and prevent inadvertent removal of the firmware, the boot critical portion of the UEFI firmware must reside on a separate storage device. The host operating system should not access this location. The firmware provider must furnish the software tools needed to maintain and update the firmware.

DRIVER

The Microsoft SATA AHCI in-box driver provides full support for Serial-ATA storage devices. In-box driver functionality includes support for boot, paging, crash dump, hibernation, and file system I/O.

5 If the SATA storage exceeds 5 mW on idle, then the overall platform should not consume more than 5 percent of its battery when in Connected Standby over a 16 hour period.

261 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

SECURITY

SATA based storage devices may support the following security features:

 Trusted commands  TCG OPAL v2.x  IEEE 1667 TCG Storage Silo

NON-VOLATILE MEMORY EXPRESS (NVME)

NVMe is a relatively new storage protocol designed to fully use the latency and throughput potential of flash- based storage devices by connecting them directly to the PCIe interface. Protocol overhead is minimal and allows interrupts to be spread across multiple processors (logical or physical).

INDUSTRY SPECIFICATION & WINDOWS HARDWARE CERTIFICATION KIT (WHCK) Item URL NVMexpress 1.0e http://www.nvmexpress.org/index.php/download_file/view/100/1/ Windows Hardware Device.Storage.ControllerDrive Certification Kit

The WHCK section representing NVMe devices is: Device.Storage.ControllerDrive

NVME DRIVERS FOR WINDOWS

Windows 8.1 contains a native NVMe driver structured as a complete Storport Miniport. Microsoft will write and maintain this driver called StorNVMe.sys. The driver will provide a stable base driver that any logo-compliant NVMe device can use.

No other inbox NVMe drivers are accepted.

262 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Third-party NVMe drivers can be written and certified as compatible with Windows 8.1 as defined under the following logo program item: Device.Storage.Controller.Driver

STORNVME FUNCTIONALITY Functionality Comment Namespace Management Each namespace presented by the device to Windows is exposed as an individual disk object to the file system. For example, if the device exposes four namespaces, diskmgmt.msc will show four NVMe disks as storage devices. DSM – Deallocate Deallocate provides the host with the ability to mark regions of the flash as ready for garbage collection services. This helps Windows maintain flash endurance and life and is required of NVMe devices to pass Windows certification. Flush Flush support is needed on NVMe devices that implement volatile write caches. The host must clear these caches and make sure data is successfully placed on a non-volatile medium. The Windows NVMe driver will propagate flushes to the device. I/O Coalescing For more efficiency in I/O completion, StorNVMe.sys supports I/O coalescing on server systems. This feature is exposed through a registry key and controls the interval time for the coalescing. NVMe Pass-Through Windows does NOT support any pass-through mechanisms in StorNVMe.sys except for SCIS pass-through, i.e. SCSI commands that have a direct NVMe translation. NVMe pass-through, as well as pass-through of vendor specific commands is currently not supported by the Windows inbox NVMe driver.

NVME IMPLEMENTATION CONSIDERATIONS

 Device support via in-box or third-party drivers.  NVMe solutions work best for high-performance data store.  Boot scenarios are not supported at this time.

263 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Connected Standby scenarios are not supported at this time.

For more information, read to the NVMe specification on nvmexpress.org.

NETWORKING

WINDOWS NETWORKING INFRASTRUCTURE

We highly recommend that at a minimum, the platform is equipped with Wi-Fi connectivity. Mobile Broadband support may provide you the opportunity to differentiate from competitors. Wired Ethernet is form factor and target scenario dependent and is optional. Support for booting from an Ethernet is dependent on the platform and Ethernet solution.

The Windows networking infrastructure includes several new power management features to ensure optimal power efficiency for networking devices. In addition to PCI, secure Digital Input Output (SDIO) and USB are supported buses.

Power-friendly features, such as protocol offloads, TCP checksum offload, USB selective suspend, and interrupt moderation greatly reduce the power impact of networking on the overall system power budget. Support for these power saving features is available in The NDIS 6.30 driver platform provides support for these power-saving features.

RELATED RESOURCES

Icon Meaning //B Networking for connected standby //B Building great Windows 8 systems //B Building Great Networked Media Devices for Play To Apps

264 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Windows Vista and Later Networking Reference Network Design Guide Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

BLUETOOTH

HARDWARE

If implemented, Bluetooth controllers must support the Bluetooth 4.0+LE specification, complying with both Basic Rate (BR) and Low Energy (LE).

The following table summarizes the supported peripheral buses and driver support.

Bus (HCI) Driver support SCO support

Non-USB WDK sample6 Sideband I2S/PCM connection only (HCI bypass)7

6 The WDK sample will be based on the UART (H4) standard as defined in the Bluetooth SIG specification. A vendor will be required to adopt and enhance the sample for any vendor-specific device requirements around device initialization and/or power management. If desired, the vendor can adopt the sample and develop for a non-UART interface as well – i.e. non-UART controllers will also be supported by the Bluetooth stack (given a proper vendor-supplied driver).

Note: A vendor supplied serial controller driver is necessary for UART-based controllers. For UART-specific features, see the Simple Peripheral Buses section of this document.

7 A non-USB connected Bluetooth controller must use a sideband channel for SCO applications – i.e. SCO over I2S/PCM interface. Furthermore, SCO over HCI (in-band) will not be supported for non-USB controllers.

265 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

USB In-box In-band (SCO over HCI)

INITIALIZATION AND POWER HANDLING

For non-USB based Bluetooth controllers that require initialization, a vendor-supplied driver must configure the radio to a known state prior to the loading of the Bluetooth stack. This allows the stack to initiate communication with the controller. For more information, see Transport Bus Driver for Bluetooth Power Handling Guidelines and Bluetooth Power Management for Connected-Standby Platforms.

TRANSPORT BUS DRIVER

A Windows Driver Kit (WDK) sample is available for the UART (H4) transport. A vendor can enhance it for any vendor-specific feature, including for any non-UART transports as well. There will be no limitations around the stack’s ability to support a particular transport.

There will be no changes to the existing in-box Bluetooth USB driver.

We recommend using UART (H4) as the connectivity interface, since the WDK sample will be UART-based and due to UART’s lower power consumption. Voice (SCO) support must go through a “sideband” audio channel for non- USB controllers, such as an I2S/PCM interface.

RADIO MANAGEMENT

The 3rd-party Bluetooth radio management plugin is no longer supported as Bluetooth Radio Management support is now provided inbox. Transport drivers must respond to being D3 by turning off power to the radio. For more

266 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

information, see the System.Client.BluetoothController.Base.OnOffStateControllableViaSoftware requirement in the Windows HCK System and Device Requirements.

267 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

MECHANICAL

We do not recommend an external switch for controlling the on/off state of the Bluetooth radio. However, if this is still desired, please refer to the Wireless Radio Control button in the Button Implementation section for information.

3RD PARTY BLUETOOTH SOFTWARE

3rd party software can be added to x86/x64 Windows PCs to provide additional Bluetooth profile functionality not natively shipped in Windows. To avoid impacting the Windows user experience, causing incompatibilities with other Windows PCs, and creating serviceability issues on upgrade, Windows recommends the following:

3. Do not replace inbox profiles, icons, or user interfaces 4. When adding profiles and/or other software, use the native Windows APIs 5. Use Wi-Fi Direct for high bandwidth peer-to-peer scenarios instead of Bluetooth High Speed (HS)

3RD PARTY BLUETOOTH SOFTWARE – WINDOWS RT VERSION

3rd party software should not need to be added to Windows RT PCs to provide additional Bluetooth profile functionality not natively shipped in Windows. Under some circumstances, it may be allowed but requires explicit permission from Microsoft. In these cases, to avoid impacting the Windows user experience, causing incompatibilities with other Windows PCs, and creating serviceability issues on upgrade, Windows recommends the following:

6. Do not replace inbox profiles, icons, or user interfaces 7. When adding profiles and/or other software, use the native Windows APIs 8. Use Wi-Fi Direct for high bandwidth peer-to-peer scenarios instead of Bluetooth High Speed (HS)

268 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

RELATED CONTENT

The following table provides links to additional content resources for this section.

Icon Meaning

Windows HCK System and Device Requirements

Bluetooth Radio Management – Partner Spec

Bluetooth WinRT API – Partner Spec

Windows Bluetooth Partner Testing Guidance

Bluetooth Devices References

Bluetooth Extensible Transport Enumerations

Bluetooth Extensible Transport Structures

Bluetooth Extensible Transport IOCTLs

How to Implement a Bluetooth Low Energy Proximity Profile Device and Application

Windows Hardware Certification

Windows 8 Desktop App Certification Program

From p. 236:

269 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

TABLET MODE

Component Connected Standby Traditional Remarks

Bluetooth Version 4.0+LE Busses UART (H4) UART (H4) or USB USB is not supported on Connected Standby. Non-USB/Non-UART (H4) is also supported with vendor-supplied driver on Connected Standby and Traditional.

p. 238:

CLAMSHELL CONFIGURATION

Component Connected Standby Traditional Remarks

p. 240:

270 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

ALL-IN-ONE

Component Connected Standby Traditional Remarks

Bluetooth Version 4.0+LE Busses UART (H4) UART (H4) or USB USB is supported on Connected Standby but not recommended. Non-USB/Non-UART (H4) is also supported with vendor-supplied driver on Connected Standby and Traditional.

ETHERNET

ETHERNET HARDWARE

Due to potential mechanical design limitations, An Ethernet is optional on a tablet form factor. However, if implemented, the platform must provide a power gating option to reduce the power consumption of the integrated Ethernet chip. For more information, refer to Hardware Configurations.

ETHERNET FIRMWARE

The following features require firmware changes.

Feature Remarks Wakeup on LAN Support D0 and D3 Protocol Offloads Support

271 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

TCP Checksum Support Interrupt Moderation Support Operating system-programmable packet filtering Support

ETHERNET DRIVER

The platform requires the use of an NDIS 6.30 Ethernet driver.

The Ethernet driver must pass the Windows HCK tests. Features for testing include modifications to the Ethernet platform that are required for power management handling. No additional connection management software is required or recommended.

WAKE-ON-LAN (WOL)

The default shutdown behavior puts the system into Hybrid Shutdown (S4)8 and all devices into the lowest power state (D3). In Hybrid Shutdown, user sessions are shut down while the contents of the kernel sessions are written to the disk enabling faster startup.

WOL wakes the PC from a low power state when a network adapter detects a WOL event (typically, a specially constructed Ethernet packet). Remote wake from Hybrid Shutdown (S4) or Classic Shutdown (S5) is unsupported because Network Interface Cards (NICs) are explicitly not armed for wake in both the Classic (S5) and Hybrid Shutdown (S4) cases. Users expect zero power consumption and battery drain in both Shutdown states. This behavior removes the possibility of spurious wakes when explicit shutdown was requested.

8 See http://msdn.microsoft.com/en-us/library/windows/hardware/ff564553(v=vs.85).aspx for more information about power states.

272 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

In summary:

 Wake-On-LAN is only supported from Sleep (S3) or Hibernate (S4) states.  Wake-On-LAN is not supported from Classic Shutdown (S5) or Hybrid Shutdown (S4) states.

RELATED RESOURCES

Icon Meaning USB Remote NDIS Devices and Windows

MOBILE BROADBAND (MB)

MB HARDWARE

Windows supports combinations of the GSM- and CDMA-based mobile broadband technologies including LTE. The minimum connectivity capability for a Mobile Broadband device is 3G connectivity. 2G connectivity is optional. Devices for the various broadband technologies must follow the specifications of standards bodies and certified by the preferred mobile operator.

 GSM/LTE – http://www.3GPP.org  CDMA – http://www.3GPP2.org

The following table summarizes the recommended mobile broadband hardware features.

273 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Feature Remarks Bus USB-HSIC for surface mounted solutions

USB for connector mounted solutions (the device must continue to work while in USB selective suspend mode and capable of waking up the device) Idle Power <10 mW (Connected Standby platform) SIM Connector User Accessible9

Embedded module solutions must always have mobile broadband functionality available without any USB hub design inside the chipset.

Idle mode power for 3GPP devices covers:

 PDP context activated but no network traffic state  PDP context de-activated state

Idle mode power for 3GPP2 devices covers:

 Connected state with no network traffic state  Disconnected state

MB FIRMWARE

USB based devices for GSM and CDMA technologies (3GPP/3GPP2 standards based) must be firmware compliant with the Mobile Broadband Interface Model specification. The USB Forum must certify these drives for compliance (when that certification becomes available for mobile broadband devices).

9 Also dependent on Telco requirements.

274 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The following table summarizes the additional features, as specified by NDIS, that we recommend the firmware support.

Feature Remarks No Pause on Suspend Support Wake Reason Reporting Support USB SS Support if USB based Radio Management Support Fast Dormancy Support

MB DRIVERS AND SOFTWARE Non-USB devices for GSM and CDMA use IHV developed Mobile broadband drivers. The drivers must comply with the Mobile Broadband Driver Model. IHV developed MB drivers must pass the tests for validating mobile broadband functionality, such as the Windows HCK tests.

 Devices based on the SPI peripheral bus need SPI driver support from the platform vendor. The SPI driver must comply with the features listed in the Simple Peripheral Bus section of this document.  USB devices must be compliant with the Microsoft USB driver stack and not require any IHV or third-party drivers for the mobile broadband functionality.

MULTI-DEVICE 1. In case of MB+GNSS multi-function device, the GNSS driver can be an IHV driver as compliant with GNSS and power requirements. Please see GNSS requirements for more information. 2. No serial port devices enumerated for the purposes of diagnostics, device management or firmware upgrade etc. in the final production image 3. Serial/AT command port, for the purposes of Mobile Network Operator (MNO) certification or OEM factory diagnostics/configuration should be supported through an IHV driver stack solution only. This IHV software stack / port drivers must be removed in the shipping image.

275 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

4. No IHV software based function SKUs to enumerate (or not enumerate) other functions in case of multi- function MB device solutions. 5. All functions, including any virtual functions (where needed) that are enumerated by the MB device need to be power-aware and respect Connected Standby and power states and cannot use legacy, non-power aware or non-PnP friendly solutions.

CONNECTION MANAGER There is no additional Connection Manager software necessary for the operation of mobile broadband devices. Value-add Mobile Broadband Connection Managers, if implemented, must implement the Mobile Broadband API (http://msdn.microsoft.com/en-us/library/dd323271(VS.85).aspx).

The mobile broadband driver or device must implement the power management optimizations as required by NDIS.

BEHAVIOR IN ACPI S3 1. If the platform supports ACPI S3 operating system power states, wireless devices shall not be removed from the bus upon entering S3.

MECHANICAL

SIM CARD

If the device features a SIM card, we recommend the SIM card socket is accessible to the user to ease the activation process. If the device has a removable battery pack, the recommended location is inside the battery compartment.

WIRELESS RADIO CONTROL BUTTON

For guidance, refer to the Wireless Radio Control button in the Button Implementation section.

276 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

ANTENNA  In any direction, the gain of at least one antenna attached to the device should be better than -15dBi  The directive gain in any direction should not be higher than 6dB  The antenna efficiency should be better than 50%. Antenna efficiency includes losses due to impedance mismatch and the radiation efficiency

RELATED RESOURCES

Icon Meaning //B Understanding mobile broadband and connection management in Windows 8 //B Connecting Windows 8 to mobile broadband and Wi-Fi networks //B Testing mobile broadband devices //B Building great Windows Store apps for mobile broadband devices Mobile Broadband Interface Model (MBIM) specification Device Apps for Mobile Network Operators Windows.Devices.Sms namespace Windows.Networking.NetworkOperators namespace Mobile Broadband (MB) Design Guide Mobile Broadband (MB) Reference Engineering Windows 8 for Mobile Networks Overview of Mobile Broadband Windows Runtime API Mobile Broadband SMS Device App Lifecycle Submitting a Mobile Operator App Windows 8 Hardware Certification Requirements and Policies

277 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

NEAR FIELD PROXIMITY

The Windows near field proximity services and APIs provide a standard way for devices and PCs to connect and communicate with each other through Windows. While other near field proximity technologies are supported, we recommend Near Field Communication (NFC), working in conjunction with Bluetooth, Wi-Fi, and Wi-Fi Direct as out-of-band transports.

Near field proximity enables new "Tap and Do" experiences for PC to PC, mobile phone to PC, and PC to tag interaction. The design supports scenarios that are interpersonal in nature, between two people holding different devices; it also works when one user is holding two devices.

 Tap and Use, Tap and Launch, Tap and Acquire o Tap the PC to another PC or a mobile phone to connect two apps if both apps are already running. o If the app isn't running on the other computer, the user is invited to launch the app. o If the app isn't installed on the other computer, the user is invited to install it from the Windows Store. o Tap a PC to a tag to launch the app specified in the tag. If the app isn't installed, the user is invited to install it from the Store.  Tap and Share, Tap and Receive o Tap a PC to another PC or mobile phone to share content such as a URL, photos, or documents to the other user. o Tap a PC to another PC, mobile phone, or a tag to receive content from the other user or the tag.  Tap and Setup, Tap and Reconnect o Tap a Bluetooth device that supports out-of-band unidirectional pairing to the PC to pair it and set it up. o Tap the Bluetooth device again to the PC to re-pair it if it had previously been paired with another device, and lost its pairing relationship with the PC.

The following table lists additional optional, recommended or required near field proximity features.

Feature Remarks Near field proximity Near Field Communication defined by NFC Forum with Wave One, SNEP, and LLCP NFC

278 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

technology Forum certification (required). Secure Element (optional). Bus Refer to Hardware Configurations. SPB API support using I2C, SPI or UART (required). Antenna Antenna dimensions can vary, as long as the effective actuation successfully connects at a range of 0 cm to 2 cm, is allowed but not required to connect at a range of 2 cm to 10 cm, and is prohibited to connect at a range greater than 10 cm (required). An antenna dimension of 40 mm x 60 mm is known to best achieve these results, but other configurations are acceptable as long as they meet the range of actuation requirements that enable the Windows scenarios (recommended). Antenna placed according to form factor along with the use of the Tap and Do visual mark (required). Connection Time A NFP provider must support the creation of sessions within 0.5 seconds from the point of being detected within the effective operating volume (required). Implementation Compliant with the Windows 8 Near Field Proximity Implementation Specification at http://go.microsoft.com/fwlink/?LinkId=237135 (required). Session Reliability 95% success rate without errors based on 100 consecutive session attempts with 5 second intervals (required). NFC Certification All NFC-enabled NFP implementations must be certified by the NFC Forum for Wave One and SNEP and LLCP certification (required).

Hardware must comply with the Windows HCK requirements for near field proximity, including but not limited to accuracy, resolution, antenna placement, use of the Tap and Do visual mark, and range of values.

FIRMWARE

Enumerate the device through ACPI.

279 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

DRIVERS

Near field proximity devices use IHV developed drivers. The drivers must comply with the Windows 8 Near Field Proximity Implementation Specification. IHV developed drivers must pass the tests for validating near field proximity functionality such as the Windows HCK tests.

MECHANICAL

Antenna placement is critical for providing the best user experience and providing a consistent tap interaction between devices. Adding a Tap and Do visual mark (refer to the Windows 8 Near Field Proximity Implementation Specification) on the device so the user knows where to tap devices together helps users discover and align the antenna, helping them complete the scenarios in the intended way. Additionally, Windows provides sound feedback during the Tap and Do experience.

The table below describes the location for the antenna by form factor, including the degree of flexibility from the requirements.

Form Factor Antenna Location and Considerations Tablet Place the NFC loop antenna on the back side of the device, not in the middle, with proper shielding to ensure sufficient actuation volume (required). Place in the upper right-hand quadrant seen from the user holding the device to support the most natural interaction (recommended). Convertible Place the NFC loop antenna on the underside of the device towards the rear with proper (slider style) shielding to ensure sufficient actuation volume (required with some flexibility). Convertible Place the NFC loop antenna on the underside of the device towards the rear with proper (rotating hinge) shielding to ensure sufficient actuation volume (recommended with some flexibility if primarily used in clamshell mode). Clamshell Place the NFC loop antenna to the right of the touch pad, under the touch pad or under the right palm rest with proper shielding to ensure sufficient actuation volume (recommended

280 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Form Factor Antenna Location and Considerations with some flexibility). All-in-One Place the NFC loop antenna on the front of device (for example, bezel area) (recommended). Desktop Place the NFC loop antenna on the top of the chassis near the edge or provide a USB dongle (recommended).

RELATED RESOURCES

Icon Meaning //B Simplifying wireless and network device discovery and pairing //B Designing Systems and Developing Drivers for NFC //B Connecting and Sharing with Near Field Communication Proximity Devices Supporting proximity and tapping (JavaScript) Proximity and tapping (C#) Windows 8 Near Field Proximity Implementation Specification Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

WIRELESS LAN

HARDWARE

281 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

We recommend you include a wireless Local Area Network (LAN) solution in all mobile and all-in-one form factors. Wireless LAN is optional in a desktop form factor. The following table summarizes our guidance on wireless LAN features.

Feature Remarks Bus Refer to Hardware Configurations Protocol 802.11a/b/g/n/ac Idle Power Refer to Hardware Configurations

FIRMWARE

We recommend the device firmware support all of the following offloads:

Firmware feature Remarks Wake-on-WLAN Support Network List offload Support D0 offload Support USB Selective Suspend Support if USB based

DRIVER

Support for an NDIS 6.30 Wi-Fi driver is recommended. Wi-Fi drivers must pass the tests for validating Wi-Fi functionality such as the tests in the Windows HCK. The test includes testing of modifications to the Wi-Fi platform that is required for power management handling. Certification of these drivers through the Wi-Fi Forum Alliance (WFA) (http://www.wi-fi.org/) is required. No additional connection management software is recommended.

282 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Driver feature Remarks No Pause on Suspend Support USB Selective Suspend Support if USB based Wi-Fi PSM Support Wi-Fi Direct Support Radio Management Support IEEE 802.11w Support

LOCATION-BASED SERVICE THROUGH WIRELESS LAN

The next version of Windows has a default Wireless LAN-based location provider. To enable the location-based service, the ACPI must identify the device. No additional driver or software is required to enable location-based services.

MECHANICAL

ANTENNA

The device should have an antenna system that meets the following recommendations:

 Use the CTIA/Wi-Fi Alliance Test Plan for RF Performance Evaluation of Wi-Fi Mobile Converged Devices to obtain the TRP and TIS values. The TRP and TIS values should meet the below requirements: o The Total Radiated Power (TRP) value on IEEE 802.11g MUST be better than 10dBm for 6Mbps data rate. o The Total Isotropic Sensitivity (TIS) value on IEEE 802.11g MUST be better than -67dBm for 54Mbps data rate. The sensitivity degradation due to activity in the platform MUST be below 5dB. o Human hands holding the device in one of the common grip areas, should not significantly affect the antenna performance.

283 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

o The TIS and TRP values should not be affected by more than 3 to 5dB in any of the common handgrips.

RELATED RESOURCES

Icon Meaning //B Testing Wi-Fi Networking Devices //B Simplifying wireless and network device discovery and pairing //B Reimagining the experience for connecting with devices //B Understanding Wi-Fi Direct in Windows 8 //B Understanding Wi-Fi networking in Windows 8 Installing Wi-Fi Devices Using Rally Vertical Pairing Wi-Fi Direct (WFD) Reference Mobile Broadband (MB) Design Guide Engineering Windows 8 for Mobile Networks Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies

RADIO MANAGEMENT

We don't recommend including any type of radio switch on the PC. However, if you prefer to include a switch, refer to the guidance below. To deliver a consistent and predictable Windows experience for controlling all wireless capabilities, implement the wireless radio control button. The purpose of this button is to turn on or off all radio capabilities in the device (it has the same function as the global software switch – also known as airplane mode switch). Wireless radios include Bluetooth, Mobile Broadband, Wireless LAN, and GNSS. Only one button should control all wireless capabilities. Individual radio buttons are not allowed. The button type should be a single action push-button toggle. A-B slider switches are also allowed. This button must not change the state of the radio hardware directly. Instead,

284 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

it should only communicate the change of state to the Radio Management API using HID. You must create an HID- compliant driver for the button, and it must use the correct HID descriptors that have been defined for radio management. For more information, see the HID section. If the button is a function key (Fn+Fx), the HID driver doesn't need to be created. Nevertheless, the button must still send the correct HID descriptors and work properly with the Windows radio management feature.

PERFORMANCE The values provided below are based on the CTIA/Wi-Fi Alliance Test Plan for RF Performance Evaluation of Wi-Fi Mobile Converged Devices. Feature Remarks Total Radiated Power (TRP) value on IEEE 802.11g >15dBm @ 6Mbps data rate Total Isotropic Sensitivity (TIS) value on IEEE 802.11g -73dBm @ 54Mbps data rate Sensitivity degradation due to activity in the <5dB platform Impact to TIS and TRP while device is held <5dB (landscape and portrait orientation) Transmit data Dynamically adjusted according to radio conditions providing the best possible link quality and speed

SENSORS

The Windows sensor platform provides a standard way to integrate sensor and location devices into Windows, and a standard programming interface for applications to take advantage of these devices. Windows supports certain sensors (such as ambient light sensors and accelerometers) to provide features such as adaptive brightness and automatic screen rotation.

The table below summarizes some of the sensor requirements as documented in the Windows Hardware Certification Kit and sensors support in Windows Next. For desktops and all-in-one units, we recommend only

285 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

implementing Ambient Light Sensors, which improves the user experience by increasing power savings and maximizing the display’s viewability.

Form Factor ALS 3D 3D Gyro 3D Sensor Fusion10 Accelerometer Magnetometer Tablet Required Required Required Required Required Convertible Required Required Required Required Required Clamshell Optional Optional11 Optional11 Optional11 Optional11 All-In-One Optional Optional Not Supported Not Supported Not Supported Desktop/Other Not Supported Optional11 Optional11 Optional11 Optional11

For specific form-factors, specific scenarios are supported in Windows and for Windows applications:

Adaptive Brightness Screen Rotation Sensor Apps and Games

10 Includes 3D Compass (tilt compensated heading), 3D Inclinometer (yaw, pitch, roll relative to device chassis) and device orientation (quaternion, rotation matrix).

11 Windows does not have any scenarios for accelerometer and other sensors on form factors other than Tablets and convertibles and hence does not recommend the inclusion of these additional sensors in non-tablet and non- convertible form factors.

286 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Tablet Supported Supported All sensors supported Convertible Supported Supported All sensors supported Clamshell Supported Not Supported ALS Supported All-In-One Supported Supported ALS + ACC Supported Desktop/Other Not Supported Not Supported Not Supported

As OEMs innovate, different device classes begin to slowly merge and differentiating between the two becomes more difficult. This is especially true for Adaptive-All-In-Ones (A-AIOs), an AIO that is capable of running on battery power for some appreciable amount of time and has a degree of mobility. These devices essentially act as large tablets that remain docked most of the time, but due to their bulk they do not support the same range of scenarios.

For all tablet, convertible, and A-AIO, we highly recommend including an ALS even when not explicitly required. For any mobile device, the ALS will improve the user experience by enabling Adaptive Brightness that will adjust the backlight to the environment (also improving the power management and battery life). Similar, any device that supports the device being in different orientations should include an accelerometer in order to enable Autorotation.

Outside of those two sensors, nine-axis fusion (Accelerometer, Gyrometer, and Magnetometer) is dependent upon size and weight and their mobility. This table demonstrates where nine-axis fusion should be implemented:

Device Size < 12 inches 13-15 inches 16-17 inches 18+ inches

Nine-Axis Fusion Required Optional, Optional, Not Not Supported Recommended Recommended

OEMs should have designs reviewed by their sensor manufacturer during each milestone of the project. All designs should follow the guidelines published by IHVs and in Microsoft whitepapers. You should review the following items:

287 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

o Device selection o Device placement o Manufacturing process o Calibration

FIRMWARE AND DRIVER UPDATE CAPABILITIES

Sensor solutions with devices that persist their firmware and drivers should use a Unified-Extensible Firmware Interface (UEFI) capsule update to update their FW. Solutions that don’t persist their firmware should handle this as a standard driver update.

RELATED CONTENT

The following tables provides links to additional content resources for this section

High priority references:

Icon Meaning

Integrating Motion and Orientation Sensors

Sensor Devices Programming Guide

Sensors HID Annotation

Filtering data

Windows Hardware Certification

Windows 8 Hardware Certification Requirements and Policies

//B Architecting and integrating sensor drivers

288 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Useful references:

Icon Meaning

Sensors driver sample for Geolocation devices

The Sensor Diagnostic Tool

Overview of motion and device orientation for Windows Developer Preview

//B Supporting sensors in Windows 8

//B How to declare your app's capabilities

//B Chalk Talk for Sensor and Location Support in Windows

//B Using Location and Sensors in your App

//B Building great Windows 8 systems

ACCELEROMETER

 Auto-screen rotation: Ensure auto-rotation is responsive and behaves as a user expects. Expose sensors through the sensor platform as documented in the Sensor Devices Design Guide.  Auto-screen orientation: Ensure that game play motion is responsive and accurately represented on the screen when the device is tilted or rotated.

HARDWARE

The following table summarizes the recommended accelerometer characteristics. These are not requirements (which are captured in WHARDWARE CERTIFICATION KIT requirements and tests).

289 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Characteristics Remarks Bus Refer to Hardware Configurations Axes 3 Sensitivity -4G to 4G Data rates >=50 Hz

The hardware must comply with Windows HARDWARE CERTIFICATION KIT requirements for accelerometers, including but not limited to: accuracy, resolution, axis orientation (including three-axis support), acceleration, and range.

Recommendations:

You must place the sensor in a stable position away from vibrational components, such as audio speakers or system fans, as they can cause the sensor to report incorrect data from system movements rather than user interaction. Place the device in a location and on materials that will not amplify internal vibrations. Related Content

The following table provides links to additional content resources for this section.

Icon Meaning

Accelerometer Sensor Sample

Quickstart: Responding to user movement with the accelerometer (C#)

Quickstart: Responding to user movement with the accelerometer (JavaScript)

AMBIENT LIGHT SENSOR

You should include one or more ambient light sensors (ALS) to enable the Windows Adaptive Brightness feature for better readability across varying lighting conditions. The benefit of including at least one allows Windows to

290 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

automatically adjust the brightness of the screen to match conditions in the environment. OEMs should only use a 3-step ALR curve and avoid more complex curves.

INTEGRATION CONCERNS

Hardware must comply with Windows HARDWARE CERTIFICATION KIT requirements for ALS, including but not limited to accuracy, resolution, and range of values. This includes verifying that the aperture size for the ALS device is wide enough to detect light without too much attenuation when the light source is at an angle to the device. A hole too small or too deep can cause shadows to fall across the ALS sensor, known as the “shadow effect”, which significantly reduces the usability of the ALS sensor. OEMs should work with their sensor manufacturer to determine an appropriate aperture size. Additionally, you should consult sensor manufacturers on any light pipe used in the system as well as glass coating over the aperture, as these can greatly affect the reliability and performance of the ALS sensor.

The following table summarizes the ALS characteristics.

291 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Characteristics Specification Remarks Bus Refer to Hardware Configurations Protocol For MCU-based sensor implementations, integrate through the HID sensor specification. Refer to HID Annotation Document for more details.

On any system with simple peripheral bus connectivity available, integrate through I2C. For more information refer to SPB Sensor Integration.

Via ACPI on x86/x64 systems is not recommended since this is considered a legacy approach due to power and performance considerations. Illuminance range 5-100k lux As output through sensor platform, calibrated, and including all optics, surfaces, and components. Not relative to bare sensor. Accuracy +/- 10% As output through sensor platform, calibrated, and including all optics, surfaces, and components. Not relative to bare sensor. Type Digital ALS IR/UV rejection Supported Important for consistent measurements WDDM Brightness/ Required Graphics driver should implement smooth Dimming support transitions between brightness levels

292 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

FIRMWARE

If an MCU exists in the sensor driver solution, route the ALS through the MCU.

RELATED CONTENT

The following table provides links to additional content resources for this section.

Icon Meaning

Light Sensor Sample

Quickstart: Responding to changes in lighting (C#)

Quickstart: Responding to changes in lighting (JavaScript)

MAGNETOMETER

HARDWARE

The following table summarizes the magnetometer features.

Characteristics Remarks Bus Refer to Hardware Configurations Axes 3

293 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The magnetometer must comply with the Windows HARDWARE CERTIFICATION KIT requirements, including but not limited to accuracy, resolution, reporting range, and frequency. A 3D accelerometer that features tilt compensation is also recommended.

INTEGRATION DETAILS

Specifications:

 Place sensors at least two millimeters from high current sources with greater distances for higher currents. For example, 15 mm away for 100 mA and 2 mm for 35 mA. Sources of high current include but are not limited to inductors, RF PA, and related devices.  Place sensors >=2 mm from the surrounding resistors and capacitors since nickel plating is usually present on solder end caps of surface mount components.  Place sensors >=1 mm from an RF transceiver and receiver if not shielded.  Place sensors >=1 mm from Bluetooth, Wireless LAN, and GNSS if not shielded.

Recommendations:

 Be careful when implanting digitizer screens, as they can greatly affect the reading from the magnetometer.  Place sensors as far away as possible from magnetic components, such as a speaker, receiver, vibration motor, microphone, and ferrite bead.  Place sensors away from the battery connector, since the connector may contain ferromagnetic materials.  Place sensors away from an inductor, since the inductor may contain magnetic material and also high current.  Place sensors away from power discrete components (such as transistors and diodes).  Avoid high current trace near or across the sensor.  Check the material used for the antenna and RF feeder as it may impact the sensor – avoid ferromagnetic materials if possible.

294 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Ensure that the back shell of the display panel does not contain ferromagnetic material (such as iron, cobalt, or nickel).  Ensure that the shielding material used for RF, Bluetooth, and other components does not contain ferromagnetic material.  Ensure mechanical parts (such as keys, screws, or connectors) do not contain ferromagnetic material.

GYROSCOPE

This sensor augments the magnetometer and accelerometer sensors by providing enhanced control in apps and games with rotational velocity data.

HARDWARE

The following table summarizes the recommended gyro characteristics.

Characteristics Remarks Bus Refer to Hardware Configurations Axes 3

The hardware must comply with Windows HARDWARE CERTIFICATION KIT requirements for accelerometers, including accuracy, resolution, axis orientation (including three-axis support), motion, acceleration, and range.

Recommendations:

 Gyro power states should be independent from Accelerometer power states so that one can be powered on while the other is powered off, as when no apps are subscribed to sensors but the rotation manager is checking data.

295 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Place the sensor must be placed in a stable position away from vibrational components, such as audio speakers or system fans, as these can cause the sensor to report erroneous data from system movements rather than user interaction.  Place the device in a location and on materials that will not amplify internal vibrations as these can cause the sensor to report erroneous data from system movements rather than user interaction..

RELATED CONTENT

The following table provides links to additional content resources for this section.

Icon Meaning

Gyrometer Sensor Sample

Quickstart: Determining angular velocity with the gyrometer (C#)

Quickstart: Determining angular velocity with the gyrometer (JavaScript)

FUSION SENSORS

By combining the data from a 3D accelerometer, 3D gyroscope, and 3D magnetometer we can achieve 9-axis Fusion and derive certain “virtual” sensors. While it is possible to have 6-axis Fusion, 9-axis provides the greatest granularity and strongest feature set of data; therefore, if any type of fusion is implemented for Windows, it must be 9-axis Fusion.

We support three different virtual sensors – Inclinometer, Orientation, and Compass.

INCLINOMETER

An inclinometer is a sensor that indicates the inclination of the device related to the horizontal of an axis. These are formulized as Yaw, Pitch, and Roll.

296 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

INCLINOMETER RELATED CONTENT

The following table provides links to additional content resources for this section.

Icon Meaning

Inclinometer Sensor Sample

Quickstart: Determining pitch, roll, and yaw with the inclinometer (C#)

Quickstart: Determining pitch, roll, and yaw with the inclinometer (JavaScript)

ORIENTATION

Orientation is a sensor that defines how the device is situated in space. Typically, this value is given through rotation data, but it can also support a rotation matrix.

ORIENTATION RELATED CONTENT

The following table provides links to additional content resources for this section.

Icon Meaning

Orientation Sensor Sample

Quickstart: Retrieving the Quaternion and rotation matrix with the orientation sensor (C#)

Quickstart: Retrieving the Quaternion and rotation matrix with the orientation sensor (JavaScript)

COMPASS

Compass is a tilt-compensated heading with respect to True North and, dependent upon the sensor capabilities, Magnetic North.

COMPASS RELATED CONTENT

297 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The following table provides links to additional content resources for this section.

Icon Meaning

Compass Sensor Sample

Quickstart: Determining current heading with the compass (JavaScript)

Quickstart: Determining current heading with the compass (C#)

FINGERPRINT READER

For guidance, refer to the Security section.

INCLINOMETER

An inclinometer is a sensor that indicates the inclination of the device related to the horizontal of an axis.

RELATED RESOURCES

Icon Meaning

Sensors HID driver sample

Responding to Motion and Orientation Sensors

Integrating Motion and Orientation Sensors

Inclinometer Sensor Sample

Quickstart: Determining pitch, roll, and yaw with the inclinometer (C#)

Quickstart: Determining pitch, roll, and yaw with the inclinometer (JavaScript)

ORIENTATION SENSOR

298 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

RELATED RESOURCES

Icon Meaning

Responding to Motion and Orientation Sensors

Integrating Motion and Orientation Sensors

Orientation Sensor Sample

Quickstart: Retrieving the Quaternion and rotation matrix with the orientation sensor (C#)

Quickstart: Retrieving the Quaternion and rotation matrix with the orientation sensor (JavaScript)

SIMPLEORIENTATION SENSOR

RELATED RESOURCES

Icon Meaning

Responding to Motion and Orientation Sensors

Integrating Motion and Orientation Sensors

SimpleOrientation Sensor Sample

Quickstart: Determining device orientation with the SimpleOrientation sensor (C#)

Quickstart: Determining device orientation with the SimpleOrientation sensor (JavaScript)

EXPANSION PORTS

299 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

UNIVERSAL SERIAL BUS (USB)

HARDWARE

For improved power efficiency and performance, it is recommended USB Host Controllers are least USB 3.0 compatible with an XHCI controller integrated into the SoC or chipset. The operating system supports standard EHCI and XHCI 1.0 controllers, including debug registers. If the host controller is not fully compatible with the published standard specifications, the deviations must be documented and support for the host controller is determined on a case-by-case basis. In addition, the debug capability is important for XHCI host controllers.

USB Host Controller Interface Remarks XHCI 1.0+Errata or higher (including debug capability) Required per the Windows HCK starting from June 2012 EHCI Supported UHCI/OHCI Companion Controllers Not-supported

Windows supports several dual-role (OTG) USB controllers with an EHCI compliant host controller implementation. These dual-role controllers can be used primarily in host mode with the in-box Windows USB controller drivers. When properly configured, several of these supported dual-role controllers can be used as a kernel debug transport in function mode. Windows should control the operation of the dual role controller with no additional software or drivers.

The USB physical layer (phy) and controller must support a low power state when all USB ports are selectively suspended or disconnected. While in the low power state, the USB phy must maintain the ability to detect wake events for device connect, disconnect, or device resume signaling. If the in-band interrupt is expected to be acknowledged by the Windows USB driver, the firmware or PEP must verify the USB controller registers are accessible and not power-gated or clock-gated prior to the assertion of the interrupt. This allows the Windows USB driver's interrupt service routine to query the appropriate registers to determine the necessary actions.

300 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

If USB devices are connected and selectively suspended prior to the controller or phy entering a low power state, the devices must not require a reset to function again upon resuming from the low power state. The USB controller's PORTSC registers are expected to report the correct status after exiting a low power state, indicating if a new device has been connected or if a device was removed. If the PORTSC registers do not report the correct status, the USB device may be reset, even if a reset was not necessary. All USB xHCI host controllers must support runtime power management, as defined by the xHCI Specification version 1.0. This includes runtime wake if it's implemented. Runtime is defined as the system working state (S0), including the Connected Standby sub-state of S0 if the controller is tested on a system that supports Connected Standby.

XHCI controllers support all speeds of devices. There is no need to dynamically route traffic to one type of controller or another based on a device's speed. In fact, Windows Certification requires that a USB 3.0 port is only routed to a single controller at one time. Microsoft strongly recommends against using a MUX or switch between the controller and the port, using the BIOS to switch the port between the two controllers (ensuring only one controller is connected to the port at one time). If you must implement such a design, ensure XHCI is always enabled when Windows is running. Verify that devices are always enumerated by the XHCI host after a system power state transition and after reboot.

EXTERNAL USB PORTS

For the best Windows experience, all devices are recommended to have an externally accessible standard USB type A port. This allows users to connect their existing USB devices, without an adapter. Standard USB A ports can also be used as a kernel debug port, to expose standard USB EHCI Host debug, USB XHCI host debug or USB function debugging.

A simple Standard USB A male to Micro USB B female adapter can be used to expose USB function or XHCI host debug transport from a Standard USB-A port. This adapter must prevent shorts on the VBus line by removing the VBus line completely or by having a 1k ohm resistor in line with the VBus line. It is strongly recommended that the standard USB A port provide built-in protection against a short on the VBus line. This can occur if the USB port is connected to another host when it is not properly configured in debug mode.

301 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

All user-accessible USB ports must fully comply with the USB 3.0 or USB 2.0 specification. Ports with labels ensure differentiation, with USB 3.0 ports being blue or designated with an "SS". USB 3.0 ports must properly support 900 mA USB 3.0 devices and 500 mA USB 2.0 and 1.1 devices. USB 2.0 ports must properly support 500 mA USB 2.0 and 1.1 devices.

Speed EHCI Port (USB 2.0) XHCI Port (USB 3.0) Low-Speed Yes Yes Full-Speed Yes Yes Hi-Speed Yes Yes Super-Speed No Yes

All exposed ports must support all speeds slower than the maximum speed of the host controller to allow support of legacy devices including keyboards and mice. USB 3.0 ports connected to a standard XHCI controller satisfy this requirement.

Transaction translators (TTs), integrated with the EHCI host controller, are not standardized, but the Windows USB 2.0 driver supports several implementations of an integrated TT. The supported integrated TT implementation must be identified using the _HRV hardware revision for the USB controller. Legacy companion controllers (UHCI/OHCI) are also not supported.

If the USB EHCI controller does not feature an integrated TT, any externally exposed ports must be routed through an embedded rate-matching hub. If a micro-A/B USB port is exposed, an embedded rate-matching hub can be switched into or out-of the port path based on the ID-pin or upon detecting external V-BUS power. This configuration allows the micro-A/B port to support all device speeds in host mode while still being available as a function port. Note that internal devices that are not Hi-Speed or Super-Speed must go through a rate matching hub.

If the device is too thin to expose a standard USB A port, it is acceptable to expose a micro-A/B port. However, the system should ship with a micro-USB A/B male to standard USB A port (female) receptacle adapter. This adapter

302 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

enables a user to connect a standard USB device to the micro-USB A port and must ground the ID pin of the micro- USB port. If shipping a receptacle adapter then the following criteria should be met:

 Receptacle adapter is USB-IF certified. More information on certification can be found at www.usb.org.  HCK testing is performed with the receptacle adapter that will be shipping with the system.  The receptacle adapter matches the speed of the port, ie, xHCI (USB3) ports must ship with a SuperSpeed (USB3) receptacle adapter.

External USB Connector Remarks Form factor 1 or more Standard USB A Port Preferred All Micro-USB A/B (Host + Function debug) Port Preferred Thin Tablet Micro-USB B Port (Function Debug) + 1 or more Supported Tablet or Non-Tablet Standard USB A Ports Mini-USB A/B or B Port Not Recommended Not Recommended Micro-USB A/B Port + 1 or more Standard USB A Port Not Supported Not Supported Proprietary Docking Port with USB Host and/or debug Supported Tablet Functionality

A USB function controller is recommended to be externally accessible to the user for debugging. If there is a standard USB A (host) port in addition to a micro-USB B (function) port, the USB ports must be connected to separate USB controllers. If the micro-USB port provides no additional functionality beyond debugging, it must be hidden in the battery compartment or behind a cover. In order to comply with USB-IF requirements, VBUS must not be asserted on the micro-USB A/B port until the resistance to ground of the ID pin of the micro-USB port is less than 10 ohms. This will prevent a short circuit when a user connects a micro-USB B cable to another USB host, such as a desktop.

Windows does not natively support charging the internal battery from a connected USB A/B port with the controller in USB Host mode. Platform support for charging the internal battery from a USB B/function port

303 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

controller must be provided by a third party if implemented. Caching of transaction descriptors that is not implemented in a software transparent manner is also not supported.

MECHANICAL AND ELECTRICAL

In USB 3.0 eXtensible Host Controllers (XHCI), connecting a SuperSpeed USB 3.0 device such as a flash drive or storage drive will generate noise in the 2.4 GHz band. This noise impacts the adjacent wireless devices' ability to transmit and receive signals. This issue does not apply to USB 2.0, Enhanced Host Controllers (EHCI).

Better shielding and grounding on both the device and XHCI controller reduces the amount of noise. Details to implement proper shielding and ground is documented in the white paper titled "USB 3.0 Radio Frequency Interference Impact on 2.4 GHz Wireless Devices" available from http://www.usb.org/developers/whitepapers/. We strongly recommend reviewing this white paper and following its guidance for any USB 3.0 XHCI controller integrated into your design. This guidance applies to all XHCI controllers from all hardware vendors.

To validate this issue, connect a USB 3.0 device to your USB 3.0 host controller. If two or more USB 3.0 ports are adjacent to one another, verify wireless mice or keyboards connected to the adjacent port continue to work. Regardless of the number of ports, verify Bluetooth devices, mobile broadband, and Wi-Fi still work. If these radio antennae are within a few centimeters of the USB 3.0 port used for the USB 3.0 device, they are at risk.

In designing systems, we recommend placing USB 3.0 ports at least 5 cm away from other USB type ports and any internal radios (e.g. Bluetooth, Wi-Fi) to prevent interference at the system level. All user-accessible USB ports must be easily accessible; they should not be recessed. This is especially important for USB 3.0 ports to ensure that USB 3.0 devices get enumerated at Super-Speed instead of Hi-Speed.

FIRMWARE

If an XHCI controller is available, the UEFI firmware must be capable of interfacing with the XHCI controller. The firmware must also be capable of booting from an internally connected USB 3.0 UASP device, including the

304 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

standard USB BIOS handoff mechanism defined in the UEFI spec. In addition, UEFI must support all USB device speeds including low and full speed devices on the EHCI and/or XHCI controller for all exposed USB ports.

The USB host controller must be initialized to start in host mode by default and whenever a reset is performed. Windows does not support the OTG standard including the dynamic host negotiation protocol. OTG controllers must be configured to start in host mode by default except when a separate USB host controller is accessible from an externally exposed USB A or micro-A/B port. ACPI must implement a _DSM method to initialize the USB OTG controller to host mode.

If there is a separate full-size USB A port, the OTG controller's micro-B port must be configured to start in device mode by default to comply with USB OTG standards, except when it is hidden and only used for debugging. The USB host controllers are enumerated using ACPI. In addition to the vendor and product ID of the USB host controller, the firmware must contain the ACPI specified USB Port Capabilities (_UPC) and Physical Device Location (_PDL) descriptors that correctly indicate the location of the internal and external USB ports such as "package type", "user visible", the "connectable" property, and the type of the USB Port. The package type parameter as defined in the ACPI 4.0a specification, section 9.13 allows Windows to determine when a micro-A/B port is exposed, and ID pin detection is necessary.

DRIVER

Windows provides a full PC experience on all platforms. The primary USB scenario on Windows platforms is as a USB host, which allows users to connect many of their existing USB devices. Windows does not provide in-box support of scenarios where one Windows system is connected to another Windows system as a USB device, either to charge, or to perform tasks like synchronizing. If a third party implements USB device functionality, Microsoft strongly recommends the Windows system enumerate as a MTP 2.0 device when connected to another system.

Selective suspend is an important power saving feature of USB devices. Selective suspension of USB devices is especially useful in mobile computers, since it helps conserve power utilized by the devices themselves as well as the USB host controller. If a USB device is internally connected, the device driver must enable selective suspend by default. Every USB device driver must place the device into selective suspend within 60 seconds of no user activity.

305 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

This timeout should be as short as possible while maintaining a good user experience. You can verify the selective suspend support by reviewing the report generated by the powercfg –energy command.

Some devices can lose the ability to detect a wake event when limited to the selective suspend current, 500 microamps per unit load, 2.5 mA max. These devices, such as a USB Bluetooth module, must be self-powered and not rely solely on the USB bus for power. By drawing power from another source, the device can detect wake events.

For more information on implementing selective suspend in a driver, see this white paper:

http://www.microsoft.com/whdc/driver/wdf/USB_select-susp.mspx.

To specify a port that is internal (not user visible) and can be connected to an integrated device, the ACPI properties _UPC.PortIsConnectable byte must be set to 0xFF and the _PLD. UserVisible bit must be set to 0. More details are available on the MSDN website.

RELATED RESOURCES

306 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Icon Meaning Building great USB 3.0 devices USB 3.0 in Windows 8 //B Debugging Innovations in Windows 8 //B Integrating with the Windows Device Experience //B Running Windows from an External USB drive with Windows To Go //B Windows Certification: improvements to the logo program Universal Serial Bus (USB) Drivers Setting Up a USB 3.0 Connection in Visual Studio Setting Up a USB 3.0 Connection Manually Universal Serial Bus (USB) Drivers USB Reference Windows 8 Battery Charging Experience Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies Visual Studio 11 Professional Beta

PERIPHERAL COMPONENT INTERFACE EXPRESS (PCIE)

PCIe is a supported interface for form factors with devices requiring higher interconnect bandwidth. PCIe is most likely to be less energy efficient for battery-powered form factors compared to other mobile interconnect solutions. Chipset vendors and OEMs are advised to consider the overall power budget for the target device before selecting PCIe to connect a given peripheral chip.

307 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

SIMPLE PERIPHERAL BUS (SPB)

Windows introduces support for low-power, simple buses, such as I2C and SPI, using framework extensions of the Kernel Mode Driver Framework (KMDF) architecture. Controller drivers are not provided in-box. Chipset vendors, OEMs, or IHVs must develop a controller driver implemented in KMDF. The architecture provides flexible device configuration topologies supporting simultaneous use of buses for control and data transactions, as well as GPIO for signaling and interrupts. The complete device definition is defined through ACPI.

The following two tables summarize the support for the Simple Peripheral Bus.

Bus In-box Framework Third party Additional support details support extension allowed provided I2C No Yes Yes, using SPB Master only Framework "General Call" not supported extension DMA Supported SPI No Yes Yes, using SPB Master only Framework Support full duplex extension DMA Supported MIPI-HSI No No Yes, using WDF MIPI- No No Yes, using WDF SLIMbus MIPI-CSI No No Yes, using WDF UART No Yes Yes, using Serial DMA Supported Framework Custom transfer modes extension supported with SerCx2 (SerCx2)

308 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

In Windows, buses are supported through KMDF controller drivers. With the aid of the KMDF platform, the controller driver is used predominantly to define the hardware-specific interfaces necessary to enable controller function.

The Windows infrastructure supports devices that share buses, buses that are multiplexed on the same line, and device configuration through ACPI. Windows uses ACPI as the primary means for device identification, configuration, and control.

DESIGN CONSIDERATIONS FOR SPB

The following are some generic considerations for SPB:

 SPB is not a Plug and Play bus. Peripheral devices typically have fixed connections to an SPB and cannot be removed. System manufacturers must ensure accurate information in ACPI to enumerate the SPB-connected peripheral devices for the Plug and Play manager, and specifies the hardware resources that are dedicated to each device.  There is no in-band interrupt support for SPB. Most peripherals support device signaling through a separate interrupt (often GPIO based) mechanism, and accurately mapped in ACPI.  Windows provides support for the SPB Class Extension (spbcx.sys) in Windows 8 and beyond. SoC partners are responsible for developing and redistributing their appropriate SPB Controller driver.  Peripheral drivers for SPB devices are generally provided by SPB Device partners. Microsoft provides one class driver for SPB devices for HID over I2C (hidi2c.sys).  Device classes may provide HCK requirements or WEG guidance around the following topics related to I2C:  Sharing I2C controller with other devices  Preferred I2C signaling speed  Power management and wake scenarios over I2C and GPIO.  Inter Integrated Circuit (I2C): I2C is the primary bus that is validated as part of SPB and is highly recommended on SoC systems. Microsoft introduces WHCK device requirements and tests for I2C, starting in Windows 8.1.

309 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Simple Peripheral Interface (SPI): Support for SPI is optional and up to the SoC partner. Windows 8.1 HCK does not contain any requirements specific to SPI bus.

SUPPORT FOR SPB ACROSS SYSTEMS

On Windows 8, Microsoft supports SPB on ARM systems and x86/x64 platforms (running in S3 configurations). On Windows 8.1, Microsoft supports SPB on platforms running in both CS and S3 configurations.

Please contact your platform provider for drivers and support.

CONECTIVITY SCENARIOS INVOLVING I2C

There are a number of device scenarios that leverage SPB for connectivity. The following table identifies the key scenarios for SPB in 2013 timeframe:

Device Class Preferred Bus on Preferred Bus on Connected traditional power Standby System (CS) model System (S3/S4) Touch Controller I2C, USB(1) I2C Sensor / Hub I2C, USB(1) I2C Precision Touchpad I2C, USB(1) I2C Keyboard EC(LPC), I2C, USB(1) EC(LPC), I2C NFC (proximity) I2C, USB(1) I2C Pen Digitizer I2C, USB(1) I2C

(1) Use this bus to build an S3/S4 system that is boot-compatible with Windows 7.

310 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

This table is not comprehensive. OEM partners could potentially attach other devices / device classes over I2C, if those device class needs/requirements are met by I2C. Devices on removable docks/ports should also follow the guidance around docking scenarios, also included in the WEG. Some of those devices may make more sense over buses like USB rather than I2C.

SPB FRAMEWORK EXTENSION

The SPB framework extension library extends the Windows Driver Framework to support SPB drivers. The SPB framework simplifies development of an SPB controller driver and improves the compatibility between peripheral drivers and the controller driver by providing common implementation of the "top-half" of the driver that processes I/O requests (as compared to the "bottom-half", which is driven by the top-half and controls the hardware). The SPB Framework Extension is a KMDF extension library. It handles the up-front processing of SPB request and the sequence in which they are handed to the controller driver. The SPB framework extension is designed to support I2C and SPI buses, and may be appropriate for other buses with similar semantics.

SERIAL FRAMEWORK EXTENSION

The serial framework extension library extends the Windows driver framework to support serial controller drivers. Similarly to the SPB framework, the serial framework simplifies development of a serial controller driver and improves the compatibility between peripheral drivers and the controller driver by providing common implementation of the "top-half" of the driver that processes I/O requests. The serial framework extension is a KMDF extension library. It handles the up-front processing of the calls to the serial APIs and the sequence in which they are handed to the controller driver. 8.1 is bringing our new SerCx2 serial framework extension designed to support the modern UART controllers and simplify controller driver implementation and diagnosability.

311 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

I2C AND UART HCK REQUIREMENTS Windows 8.1 introduces new HCK requirements for I2C and UART controllers. HCK requirements for SPI are being considered for the future as well. The logo requirements are primarily intended for SoC silicon vendors for the bus interface hardware and the associated controller drivers. OEMs and ODMs are not required to revalidate the hardware or controller driver but are welcomed to run the tests if desired. Special set-up steps are required to validate these requirements. The setup includes the following:

 An open system with accessible I2C /UART pins/ports  Modifications in ACPI to expose the I2C/ UART test device to software  A specific test device (WITT) attached to the system under validation

For additional set-up information, please refer to the HCK documentation.

PERIPHERAL DRIVERS

Peripherals are enumerated by ACPI and are generally static. Peripheral function drivers determine their appropriate bus resources by interacting with the framework extensions. Peripherals and controllers are not hierarchical, and peripherals may use several SPB, GPIO, Serial, and other high speed buses. Peripheral drivers that access embedded devices, such as sensors, input devices, modems, and radios, may be written in kernel mode or user mode. These drivers may be portable across different ODM or OEM board configurations as long as ACPI is updated appropriately.

FIRMWARE

Controller ACPI settings and bus parameters are vendor-specific and dependent on the particular controller. The following table summarizes the ACPI settings for the controller and the peripheral bus.

312 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

Bus Controller ACPI settings Peripheral ACPI settings I2C Controller addresses Bus-Address Pin configuration Clock Rate Slave Mode Addressing Mode SPI Controller addresses Chip-Select line Pin configuration Clock rate Clock Polarity Clock Phase Wire Mode Device Selection Device Selection Polarity Slave Mode UART Controller address / pin Initial baud rate Configure Initial baud rate Parity Start Bit and Stop-Bit Length Flow Control method (Software/Hardware/None) Lines in Use Receive Buffer Size Transmit Buffer Size Endian-ness

TOOLS AND TECHNICAL REFERENCE

Resource title Content type Description Link Using the Windows Driver Video Discusses how the WDF can Channel 9 Framework to build better drivers improve driver reliability, what’s new

313 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

in the WDF, and how to better realize power-savings and deploy drivers on multiple versions of Windows. Understanding Low-Power Buses Video Demonstrates how to integrate a Channel 9 device on the new buses and create a driver. You will learn how to write ACPI to enumerate your peripheral and get started writing and testing a peripheral driver. Kernel-Mode Driver Framework Article Introduces Kernel-Mode Driver MSDN Design Guide Framework (KMDF). UMDF 1.x Design Guide Article Introduces User-Mode Driver MSDN Framework (UMDF). Windows Hardware Certification Article Provides information on the Windows MSDN Certification Program. Certification requirements for Article Contains the technical requirements MSDN Windows desktop apps and eligibility qualifications that a desktop app must meet in order to participate in the Windows 8.1 Desktop App Certification Program.

GENERAL-PURPOSE INPUT/OUTPUT (GPIO)

WINDOWS GPIO SUPPORT

Windows supports the use of GPIO pins as resources by function (peripheral) drivers. Similar to Serial Peripheral Buses, described in Section 10, function drivers are abstracted from the underlying GPIO controller hardware by

314 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

the Resource Hub. To support the controller hardware itself, a GPIO-specific KMDF class extension is provided. This interface supports the creation of GPIO controller drivers. Windows supports the use of GPIO as input, output, and interrupts.

GPIO HARDWARE

A GPIO controller must comply with the following hardware model:

 Contains logic for controlling configurable input and output pins.  Has a dedicated (non-shared) register interface to the logic.  Has status and enable bits for any pin that can interrupt the processor.  Memory-mapped (on-SoC) controllers are strongly recommended. If a GPIO expander (off-SoC GPIO controller) is required, its system interrupt must be edge-triggered and connected to a memory-mapped GPIO controller.  "Bit-banging" (implementing low-level, timing-based serial protocols) is discouraged because results cannot be guaranteed.

FIRMWARE

A GPIO controller is modeled as a device in the ACPI namespace, with the following features:

 _HID or _ADR and _CRS objects, at a minimum.  The device's _CRS resources must maintain mapping between system resources and the pins to which they relate. This is achieved by modeling the GPIO controller as a collection of banks, each representing 64 or fewer GPIO pins and the system resources for that set of pins. Resources claimed in the _CRS must be listed in bank order (for example, first set of resources map to bank 0, next set maps to bank 1, and so on)

The GPIO controller namespace may optionally include:

315 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 GPIO IO OpRegion declarations for access to the controller's pins by ASL methods.  GPIO-signaled ACPI Event Information (_AEI object) for use of the standard ACPI System Event mechanism. In this case, the GPIO interrupts used for this purpose must be non-shared (Exclusive), and the corresponding event method (_Lxx/_Exx) must appear under the target GPIO controller's namespace (not in the _GPE namespace).

Peripherals that connect to GPIO pins must:

 Include GPIO IO descriptors in their _CRS for any GPIO I/O pins consumed.  Include GPIO Interrupt descriptors in their _CRS object for any GPIO interrupt pins consumed.  Designate wakeup-capable GPIO interrupts as such using the WAKE flag in the descriptor.

GPIO DRIVER

For each unique GPIO controller (_HID) that appears in the namespace, SoC manufacturers must provide a GPIO controller driver based on the KMDF GPIO class extension.

DEVICE DRIVERS BEST PRACTICES

Delivering a great Windows experience is not limited to firmware and hardware components. The quality of drivers is a key component to deliver a great Windows experience. This section lists our recommendations and considerations on driver development.

DRIVER AVAILABILITY ON WINDOWS UPDATE

For some device classes such as sensors, and location and input devices, hardware vendors (OEM or IHV) make must make available all necessary software online. Acceptable solutions include the following:

1. The software package is available on Windows Update or 2. [Non-optimal] The software package is identified through a DNF (Driver Not Found) solution.

316 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The software package must contain all driver binaries and services to make the product fully functional and operable on Windows.

Easy access to drivers ensures an optimal user experience. The table lists device driver scenarios.

Issue Summary Problematic Scenario Solution Newer Driver Hardware vendor addresses bugs in their Newer drivers that address critical bugs device or software but the fixed driver is not pushed to customers through Windows easily discoverable by customer. update. Clean Install An end user clean installs their system with If the hardware vendor publishes their a copy of Windows and is unable to discover drivers on Windows Update, the end the missing drivers to obtain full customer gets these drivers silently installed functionality. and has full system functionality. Upgrade to An end user upgrades their system from If the hardware vendor publishes their Windows8 Windows 8 to the next version of Windows drivers on Windows Update or through DNF and is unable to discover the missing drivers solution, the end customer gets these to obtain full functionality. drivers (potentially silently installed) and has full system functionality.

RELATED RESOURCES – GENERAL DRIVERS Icon Meaning //B Developing drivers in Visual Studio //B Designing great devices and drivers //B Best practices for packaging and distributing device drivers //B Inside the Windows 8 driver developer workflow //B Moving driver quality upstream with WDK driver verification and test tools //B Using the Windows Driver Framework to build better drivers //B Advanced app and driver debugging

317 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

//B Introducing low-power buses for Windows 8 //B Windows 8 kernel debugging: New protocols and certification requirements //B NDIS Driver Testing and Certification (part I, II, and III) //B Reducing the memory footprint of drivers and apps //B Delivering great device installation experiences //B Advanced driver code analysis techniques //B Improving code quality with Windows Error Reporting Driver Development Tools Developing, Testing, and Deploying Drivers Tools for Signing Drivers Tools for Testing Drivers How WER Collects and Classifies Error Reports Windows Hardware Certification Video: Get ready for Windows 8 certification Windows 8 Hardware Certification Requirements and Policies Windows 8 Hardware Certification Resources and Support Windows Hardware Certification Step-by-Step Guide Windows Hardware Certification Kit Visual Studio 11 Professional Beta Windows Driver Kit (WDK) 8 PS/2 Hardware IDs

RELATED RESOURCES – PRINT DRIVERS

Icon Meaning //B Building a great Windows Store apps for your printers

318 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

//B Connecting print devices to Windows using V4 Printer Drivers //B Retrieving Configuration and Status Information from USB Printers Print Devices Design Guide Developing v4 Print Drivers Building Print-To-File Solutions for Windows 8 OpenXPS Support in Windows Building a WSD Secure Print Device for Windows Windows Hardware Certification Windows 8 Hardware Certification Requirements and Policies Windows Driver Kit (WDK) 8

BUILDING AN ENERGY EFFICIENT DEVICE

Regardless of the form factor you are building, both enterprise and home users are looking for devices with lower power consumption. If you are building a portable device such as a laptop or a table, battery life may be a crucial competitive differentiator. Recent studies indicate that 76% of consumers rate battery life as "extremely important" when choosing a tablet and mobile PC.

You can use the Hardware Windows Engineering Guide to help you choose and configure components to provide the right balance of features and energy consumption for your target market. You should also review the Manufacturing and Performance Windows Engineering Guides for this scenario because a holistic approach is needed to optimize energy efficiency.

HOW TO BUILD A GREAT CONNECTED STANDBY PC

A connected standby platform is a set of firmware, hardware and software components that deliver very low idle power, an always connected experience resulting in up-to-date Windows Store apps, and very quick transitions between an on and off state. Tight integration between the firmware, chipset, low power components, and drivers

319 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

achieves very low idle power. If you are building a connected standby-capable device, you probably want to invest in optimizing your battery life to make your device strongly competitive to your market.

In addition to certification tests to ensure that Connected Standby platforms deliver great battery life and user experience, Windows validates the following items:

• Non-rotational boot volume • Wi-Fi device that supports NDIS 6.3 features (D0 offload, Wake on Push, etc.) • ACPI 5.0 flag indicating low-power S0 over S3

A Connected Standby platform is form-factor agnostic. This means you can build a tablet, convertible, clamshell or all-in-one Connected Standby platform, although this platform may focus solely on mobile form factors.

CONSIDERATIONS

OEMs must design Connected Standby PCs from the ground up, with special attention to the power usage and performance measures needed to deliver key Windows user experiences. Again, the focus for these investments is defined sets of components with specific connectivity.

For Windows 8.1, we continue to invest in x86 and x64 ISA (Industry Standard Architecture) platforms to enable Connected Standby systems. As with Windows 8 and Windows RT, Windows 8.1 is designed to support connected standby on platforms with a specific components and connectivity requirements. To achieve the all-day battery life and stability users want and expect, operating system subsystems, component drivers, and firmware must be highly integrated. User expectations were different for past x86 / x64 PCs, and those traditional design principles don't fulfill the promise of Connected Standby PCs.

The Connected Standby hardware platform provider needs to work with the Windows team to ensure that component selection, connectivity, and engineering align for the platform. The following table lists our requirements on the connectivity of key components for x86 / x64 platforms capable of Connected Standby:

320 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

RECOMMENDED GOALS Component Type Comments Graphics/display Various sizes and Meet graphics performance bar: 8 hours of 1080p @ resolutions 200 nits video playback Recommend panels that support 60Hz and under (for example,48Hz) No Hybrid GPU Memory 32-bit: 2 GB only Low power (for example, LPDDR, DDRL, DDRL-RS) 64-bit: 4 GB minimum Storage 32-bit: eMMC No Hybrid HDD + SSD 64-bit: SSD SATA No Optical Drive Wi-Fi/Bluetooth SDIO/UART No PCIe No USB Mobile broadband USB/HSIC MBIM compliant hardware No PCIe Touch I2C

Ethernet USB NDIS 6.3-compliant 32 wake patterns No PCIe Touchpad I2C Precision Touchpad (see the touchpad section in this document) No USB Sensors I2C Class driver GPS/location UART When GPS is on a combined solution with MBB: composite endpoint Proximity/NFC UART Webcam MIPI/USB MIPI is preferred over USB to save power

321 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

RELATED RESOURCES Source Title //B Understanding Low-Power Buses Power Metering and Budgeting Introduction to Connected Standby //B Understanding Connected Standby

FORM FACTOR CONSIDERATIONS

ACCESSORIES

DOCKING ACCESSORY UNIT

This section provides recommendations are primarily intended for a Connected Standby platform, allowing you to design a low power dock. Certification requirements apply to both undocked and docked mode.

322 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The table below lists the Mobile Dock12 A/C Powered Stationary Dock13 supported bus/protocol connections between the platform and devices housed in the dock. We strongly do not recommend using raw I2C over a dock connector.Function Keyboard, touchpad HID_I2C14  Preferred HID_USB15 Rotational secondary storage Not permitted

SSD secondary storage Not permitted SD card reader Not permitted Supported Audio Pass-through USB Audio 1.0. With built-in speakers only

12 A mobile dock is defined as a dock powered by an internal battery or the main PC (e.g., tablet) and remains functional without AC power. If equipped with a battery, use an ACPI-Compliant Control Method Battery component to expose the battery.

13 An A/C power stationary dock is defined as a dock that exclusively uses A/C power meaning it does not have an integrated battery.

14 If the devices in the dock are connected to the device using a non-enumerable bus like I2C, refer to the additional recommendations listed below.

 Pre-enumerate dock devices in main form factor firmware. In other words if the dock has a keyboard controller and keyboard connected to the SoC through I2C, then the devices would be enumerated through the ACPI DSDT (or SSDT) table entries at boot time.  Use _STA to signal presence of the various devices in the dock when connected/disconnected.  Use a side band GPIO to signal a DEVICE_CHECK or BUS_CHECK event (depending on the number of devices in the dock).

15 Selective suspend is enabled through an INF or Microsoft operating system descriptor for a keyboard or pointing device connected using USB_HID. Refer to Enabling USB Selective Suspend for HID Devices on MSDN for more details.

323 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

The table below lists the Mobile Dock12 A/C Powered Stationary Dock13 supported bus/protocol connections between the platform and devices housed in the dock. We strongly do not recommend using raw I2C over a dock connector.Function USB Audio 2.0. With built-in speakers and/or audio jacks16 Video Pass-through or passive Pass-through or video adapter video adapter Ethernet17 Not permitted USB USB battery charging v1.1 Not permitted Supported capable USB ports

KEYBOARD AND MOUSE ON DOCKING STATIONS

This section provides our recommendations for building keyboards and mice/touchpads on Connected Standby platforms with docking stations. This section also discusses challenges and principles along with potential solutions. Both potential solutions apply to mobile and A/C powered stationary docks.

DESIGN PRINCIPLES FOR DOCKING STATIONS AND INPUT DEVICES

This section talks about the design principles to consider for input devices as they relate to docking stations:

16 The third party driver for the USB Audio 2.0 device supports Selective Suspend.

17 The Ethernet device supports a sideband wake of the core system through GPIO to ensure proper connectivity in Connected Standby mode.

324 Microsoft Confidential for: Connect User Hardware – Windows Engineering Guide for x86-based Platforms

 Accurately identify keyboard/mouse presence to software (for example, dock attached/detached)  Accurately identify keyboard/mouse availability to software (for example, keyboard/mouse is user accessible)  Low protocol error introduced by the docking connector (removed in firmware where possible)  Optimize the user experience experiences o Correctly influence virtual keyboard display o Disable the screen rotation feature when in clamshell mode  Optimize for power when in slate mode (for example, undocked) o Power down the slate embedded controller(if present) when undocked o Power down any I2C controllers and hubs with no devices connected when undocked