Wake-on-Touch Implementation Guide
Introduction
Wake-on-Touch is a new, optional capability coming to Windows 11 devices. This feature allows users to touch a device’s screen with their finger to wake it from sleep. Using a pen to wake the screen is not supported. Wake-on-Touch is only available on devices that explicitly opt in per the guidance below.
If a device has opted in to Wake-on-Touch, the OEM may specify the default state (enabled/disabled—additional information is in the OEM Considerations section below). Users also have a "Touch the screen to wake" option to toggle it on or off based on their preference in the new Bluetooth & devices -> Touch settings page per the figure below.
Note
If this functionality is not supported on a device, the setting will not appear on this page.
This document describes how HID based touch devices compatible with Windows can support Wake-On-Touch and what OEMs/ODMs and touch IHVs need to do depending on whether they are using an inbox HID mini-port driver available for USB, I2C or SPI or a 3P HID mini-port specifically for a bus which lacks an inbox driver (i.e. Intel THC SPI).
OEM Considerations
It is imperative that OEMs consider whether to implement Wake-on-Touch for each design and SKU as there are noticeable power consumption trade-offs for the feature. Pressing a key on the keyboard, interacting with the touchpad, or clicking the Bluetooth button on a paired pen, are all methods to wake the device with lower power consumption.
Wake Gesture
When enabling Wake-on-Touch, OEMs can specify the wake gesture to be either a single-tap or a double-tap working with their touch IHV. Whichever gesture is chosen shall be usable anywhere on the active area of the display to wake the device. Once the touch controller has detected a wake based on either the single tap or double tap gesture:
- Touch controller is required to send 2 frames representative of a single finger down and up (X, Y, TIP SET, followed by X, Y, TIP CLEAR) regardless of what gesture was used to cause the wake
- The host will only use these 2 frames as indication of user presence to turn on displays, etc. and will not deliver that input to shell or applications
- The up and down frames can both be sent immediately, however if scantime usage is present it should be incremented between frames
Note
If the touch controller has detected a wake gesture and asserts an interrupt to indicate to the host that input report(s) are ready, but the host does not in fact issue the read, the touch controller should revert back to low power state after some vendor defined timeout. This is considered an abnormal case, but may be desirable for touch IHV to account for in order to minimize unnecessary power consumption in standby.
Device Posture
Different postures, device types, and power states should all be taken into consideration for maximum optimization of battery life and reliable UX if the feature is to be utilized. As an example, a convertible device may only want to enable Wake-on-Touch when it is in its “tablet” state and disable it when it is in its “laptop” state in order to conserve battery.
Availability of Wake-on-Touch, be it whenever the device is in standby or just in specific postures requires different approaches in implementation.
For systems with a lid (e.g. a laptop form factor device), the HID stack will automatically disable Wake-on-Touch when the lid is closed. If your device matches this form factor or if it is desired for Wake-on-Touch to be enabled regardless of device posture, skip the rest of the content in this section and follow the guidance in the rest of this document.
If it is desired for Wake-on-Touch to only be enabled in certain postures, the recommendation is to implement a filter driver that controls whether the touch controller is armed for wake based on the device posture. In this type of implementation, the filter driver would decide whether to let the IRP flow to ACPI to put the device to D2 (armed for wake) or whether to have the device be put to D3 Cold (off).
If the device design does not permit ACPI to pull power (D3 Cold) from the touch controller when Wake-on-Touch is not desired based on posture then a vendor-specific mechanism should be implemented to allow the touch controller to remain powered (D3 Hot) while informing it to go to its lowest power state, internally gating, and not scanning for any touches. This vendor specific mechanism allows the touch controller to disambiguate whether to be scanning for user input or not in the SLEEP/Armed for wake state per the figure below.
Note
This diagram is for HIDI2C. For more information about power transitions, including for HIDUSB and HIDSPI, please see Touchscreen Power Management.
Lastly, if it is desired for a device to have different Wake-on-Touch behaviors based on posture, it is recommended to wake the device when a posture change happens. Posture changes are a clear indication of user input and this also ensures the proper arming/disarming of the touch controller when the device enters a new posture.
Default State for Wake-On-Touch User Setting
The default for the Wake-On-Touch setting is ON for capable systems, but an OEM can add a registry value specifying the default should instead be OFF. The change should be applied to the default user and it will get picked up by each new user on the device. Once the user changes the setting, their preference always takes precedence regardless of what the initial OEM default was.
To do so, create the below registry key and store it in the Default User NTUSER.DAT:
Registry Location: \HKEY_CURRENT_USER\Software\Microsoft\Input\WakeableInputTypes
Registry Key:
| Name | Type | Value |
|---|---|---|
| Touch | REG_DWORD | 0 = Disabled, 1 = Enabled |
Requirements for Enabling Wake-on-Touch
General Requirements
It is generally recommended that the device indicates support for wake from D2 state, so that when the operating system (OS) needs to arm the device for wake on touch, it can place it into D2. If the OS does not need to arm the device for wake on touch, it will place the device into D3. This will then allow the device to transition into D3Cold for greater power savings. This can be done by following the _S0W related guidance provided in the ACPI section below. Device-initiated power optimizations (that are not initiated by the host or operating system) should be done in a manner transparent to the operating system.
Please note when the operating system (or host) places the device into a state that enables “Wake-On-Touch” as described in this documentation, it is up to the touch controller to configure itself to wake on an appropriate touch gesture, based on the OEM requirements and/or form-factor of the device. For example, a device with a touch screen that is not occluded by a lid may need to ensure it does not cause spurious wakes.
If a HID touch device has any other top-level HID collections, such as vendor-defined collections, to which OEM software may open file handles to perform device I/Os, closing the file handles as soon as the OEM software completes these device I/Os can reduce power consumption of the HID device. Please note that Windows 11 22H2 has been updated to manage the power state of a Wake-on-Touch device more efficiently by powering it off without allowing wake from modern standby as long as Wake-on-Touch is not needed, for example, when the “Touch the screen to wake” setting is Off or when the laptop lid is closed. For such OEM software, the side effect is that inputs from such top-level HID collections will be suppressed too during modern standby.
ACPI Firmware Requirements
If the touch controller device is defined in ACPI, it must implement the following to report its wake capabilities and resources.
- _S0W method, which returns the lowest device power state under which the device may signal wake.
- _CRS method, which defines the wake-capable interrupt.
- _PRx methods, which define the power resources that are associated with each D-state supported.
For more information, please refer to the Wake-capable interrupts (_CRS) documentation.
Driver Requirements for Enabling Wake-on-Touch
For details on how to implement Wake-on-Touch for either inbox drivers (HIDI2C, HIDSPI, and HIDUSB) or custom drivers, please see the respective documentation below:
| Topic | Description |
|---|---|
This topic discusses how to implement Wake-on-Touch with the inbox HIDI2C, HIDSPI, or HIDUSB drivers. |
|
This topic discusses how to implement Wake-on-Touch with custom HID mini drivers. |
Glossary
| Term/Abbreviation | Definition |
|---|---|
| HID | Human Interface Devices. |
| HIDClass | The Windows inbox class driver for HID. |
| HID Mini Driver | A Windows HID transport driver that binds to and works with HIDClass. For more information, please refer to the Minidrivers and the HID class driver documentation. |
| D-State, D0, D2, D3hot, D3Cold | The device power states that are defined by ACPI specification. |
| Dx | One of the D-states. The actual “x” number is unspecified by this document. |
| DeviceNotInUse | A condition that occurs when the operating system moves to a state under which it is not consuming (touch) input. An example is laptop lid closure. |
| DeviceInUse | Opposite to DeviceNotInUse, it is a condition that occurs when the operating system moves to a state under which it may consume (touch) input. An example is that the laptop lid open. |
| Monitor, Screen, and Display | They are sometimes used interchangeably. |
| MonitorOn | A condition that occurs when the operating system turns on the primary monitor. |
| MonitorOff | Opposite to MonitorOn. It is a condition that occurs when the operating system turns off the primary monitor. |
| IRP | I/O Request Packet. For more information, please refer to the I/O request packets documentation. |
| D-IRP | An IRP that requests to set the device power state. |
| HIDI2C | The Windows inbox HID mini driver HIDI2C.SYS, which implements I2C transport layer for HID devices according to the HIDI2C specification. |
| HIDSPI | The Windows inbox HID mini driver HIDSPI.SYS, which implements SPI transport layer for HID devices according to the HIDSPI specification. |
| HIDUSB | The Windows inbox HID mini driver HIDUSB.SYS, which implements USB transport layer for HID devices according to the HID and USB specifications. |
| ACPI Firmware | The ACPI codes that are implemented in the system firmware (BIOS). |
| Extension INF | A new type of Windows INF files in Windows 10. For more information, please refer to the Using an Extension INF File documentation. |