Enabling Wake-on-Touch With a Custom HID Mini Driver

This topic discusses how to implement Wake-on-Touch with a custom HID mini driver.

Background: HIDClass Power Policy for Wake-On-Touch

The following state diagram illustrates the logical states the input device will be placed into when it supports the Wake-on-Touch power policy.

Notes:

1. Dx = DEVICE_CAPABILITIES.DeviceWake
2. The idle timer interval is 1 second

How to Enable Wake-on-Touch

1. Decide the D-State for Wake-on-Touch and implement the custom HID mini driver with the guidance in “CHoose D-State for Wake-on-Touch” section below for some guidance.
2. Build an INF to opt-in the Wake-on-Touch policy as per the “INF Requirements” section.
3. Validate that the device wakes up on the appropriate touch gesture(s), based on the OEM requirements and/or form-factor of the device. Also validate that it does not cause spurious wake events and the power consumption from enabling the feature is acceptable. See Wake-on-Touch Validation Guide.

Choose D-State for Wake-on-Touch

For custom HID mini driver, the following diagram has the guidance about how to choose between D2 and D3. Assuming the touch controller needs the main device power source in its Wake-on-Touch mode, when D3Cold is supported, D2 is recommended for Wake-on-Touch, as D3Hot may be followed by D3Cold where Wake-on-Touch is not possible.

INF Requirements

The HIDClass Wake-on-Touch power policy is not opted-in by default.

For the touch controllers that use custom HID mini drivers and INFs, OEMs/IHVs should create an INF, and add the following to its DDInstall.HW section to opt-in the Wake-on-Touch policy.

Include = input.inf

Needs = WakeScreenOnTouch.HW

If the device has opted in any other HID policy that conflicts with the Wake-on-Touch policy, either of the policies will be ignored.

If the device has multiple HID collections including touch screen collections (UsagePage:0xD, Usage:0x4) and non-touch-screen collections, the touch firmware should only support wake from the touch screen collections. If a non-touch-screen collection may signal wake too, the device will be still brought back to D0 to drain the power.

Understanding When to Enable or Disable Wake-on-Touch

In Wake-on-Touch scenarios, HIDClass requests IRP_MN_WAIT_WAKE to arm the device for wake before requesting D-IRP to power down the touch device. In the Device-Not-In-Use scenario, HIDClass requests D-IRP directly to power down the touch device without requesting IRP_MN_WAIT_WAKE first.

• If the custom solution uses D2 for Wake-on-Touch and uses D3 for Device-Not-In-Use, it may simply rely on D-state in the D-IRP to differentiate between two scenarios, and only enable Wake-on-Touch on D2.
• If the custom solution uses D3 in both scenarios, it must rely on the presence of IRP_MN_WAIT_WAKE to differentiate between two scenarios and enable Wake-on-Touch when getting D3 request after IRP_MN_WAIT_WAKE.

It’s recommended that the custom HID mini driver not rely on any other system notifications such as GUID_MONITOR_POWER_ON, since that may potentially cause timing issues with the HIDClass-requested IRP_MN_WAIT_WAKE and D2/D3.

Device Reset Notification

This is not a requirement specific to Wake-on-Touch, but a general requirement for HID mini drivers. The custom HID mini driver is responsible for completing IOCTL_HID_DEVICERESET_NOTIFICATION whenever it realizes the device state loss and the need of device reinitialization. This may be implemented in the device-initiated reset handler, or in driver’s D0Entry routine for example after it detects the resume from D3Cold.