Connected standby wake sources

A PC that supports the connected standby power model must be capable of waking from connected standby in response to certain events, even if the platform has entered a very low-power idle state.

This topic describes the scenarios in which the devices in this PC must be able to wake the processor. It also explains which wake events should turn the screen on and which wake events should allow the screen to stay turned off. System integrators should use this information to ensure that their hardware platforms, firmware, and software can configure wake sources to achieve the required behavior.

Overview of connected standby user experience for wake

The connected standby user experience is designed to model that of a cellular phone. When users finish using their phones, they press the system power button and the cell phone turns off. The phone remains off until the user presses the power button again, or a phone call, email, or instant message is received.

Similarly, when a PC is in connected standby, it looks and feels off—the screen is blanked, the system has no visible LED indicators, and there is no acoustic noise. However, a PC in connected standby remains on and connected to the Internet, just as the cell phone remains connected to the cellular network. (The connected standby PC uses any available network connection—Wi-Fi, mobile broadband (MBB)/cellular, or wired Ethernet.) The connected standby PC also has very long battery life in its off state, just like a cell phone.

Enabling the connected standby user experience requires all of the devices and software in the connected standby PC to actively and correctly participate in system power management. Achieving long connected standby battery life is primarily a function of allowing all devices, plus the core silicon or System on a Chip (SoC), to enter a very low-power idle state. During connected standby, the networking subsystem stays connected so that the system can wake and instantly respond to incoming emails or Skype calls. Enabling the real-time nature of connected standby is primarily a function of platform devices waking the SoC for the correct events at the correct times.

Nearly all devices in the connected standby PC are expected to be capable of waking the SoC from its deepest idle power state. However, few devices should be capable of generating a wake signal for an event that would cause the system display to turn on. The difference between waking the SoC and turning on the display is at the center of delivering the connected standby user experience.

The following rules govern platform wake behavior:

  • Generally, all devices must be capable of waking the SoC from its lowest power state when the device state changes.
  • Only wake events that are user-initiated cause the system to turn on the display.
  • Wake source operation and scenarios are the same for all connected standby PCs, regardless of whether they are based on the x86 or ARM processor architecture.
  • Wake source operation and scenarios are the same across all form factors, including slate, convertible tablet, clamshell, and docked slate.
  • Wake source operation and scenarios do not change between AC and battery-powered states. To deliver a consistent user experience, the guidelines in this section apply equally to when the system is on AC power and on battery power.

The remainder of this topic describes, for each device type, whether a device should be capable of waking the SoC from a deep idle state. Also described are the wake mechanisms for these devices, and whether the driver and system software will turn on the display in response to the wake event.

Real-time clock (RTC) or always-on timer

The core silicon or SoC chip in a connected standby platform has one or more timers that are always powered on that so that Windows can schedule future work and place the SoC into a deep idle state. During connected standby, the RTC/always-on timer reliably wakes the SoC after each 30-second idle interval so that the platform can spend most its sleep time in a very low power state. After the SoC wakes, and before it again enters idle, Windows configures the always-on timer to expire 30 seconds in the future.

DeviceWake the SoC from deep idle?Wake mechanism or pathTurns on the display?Remarks
Real-time clock or always-on timerYesSoC-specific, internal to the SoCNoEach SoC has a different mechanism for programming the RTC/always-on timer.

 

Buttons

The system power button is the most common user-initiated wake source in a connected standby platform. All connected standby PCs must be designed so that the power button is always enabled to send a wake interrupt to the SoC. To deliver an instant-on experience, the power button must cause the SoC to wake from the deepest idle state without delay.

Connected standby PCs might feature other system buttons, including rotation-lock and volume up/down buttons.

DeviceWake the SoC from deep idle?Wake mechanism or pathTurns on the display?Remarks
Power buttonYesGPIO interruptYes

The Windows power manager will turn on the display when the power-button interrupt occurs.

Windows buttonOptionalGPIO interrupt

Yes

(if wake-enabled)

The Windows power manager will be notified that the Windows button was pressed and will turn on the screen. The Windows button is considered to be user input.

Volume buttonsNoN/AN/A

Volume buttons are expected to function while the system is playing audio, including when the screen is off. However, when the screen is off and no audio is being played, the volume buttons must not wake the system.

Rotation-lock buttonNoN/AN/A
Lid switch (mechanical or sensor-based)YesGPIO interrupt Yes

There might be multiple types of lid switches, all of which are exposed to Windows in the same way. The lid switch can be a mechanical-contact switch or sensor-based switch. The platform can expose a lid switch for turning off the display when a tablet is attached to a keyboard dock that is closed. If the tablet has a cover, the sensor for detecting cover closing is also treated as a lid switch.

Opening the lid, opening the cover, or adjusting the display to make it visible must cause the display to automatically turn on. The Windows power manager automatically turns on the display in response to the lid switch interrupt.

 

Communications devices

The Wi-Fi and mobile broadband (MBB) devices are responsible for delivering the real-time and constant connectivity features of connected standby.

DeviceWake the SoC from deep idle?Wake mechanism or pathTurns on the display?Remarks
Wi-Fi radioYesGPIO interrupt

No

(See Note following this table.)

Mobile broadband (MBB) radioYesUSB in-band resume signaling

No

(See Note following this table.)

Bluetooth radioYesGPIO interruptNoWindows and its drivers are responsible for detecting the type of associated Bluetooth device. If a keyboard, mouse, or other user-input device is responsible for causing the Bluetooth radio to wake the SoC, the display will turn on. Other Bluetooth devices such as portable audio headphones will not cause the display to turn on.
Wired LAN (USB-attached, connected standby-capable)YesUSB in-band resume signaling

No

(See Note following this table.)

Wired LAN devices in connected standby platforms or their supported docks must support pattern-match offloads in order to be connected standby-capable.

 

Note  Windows can turn on the display when an incoming critical alert or activity is detected over the Wi-Fi network. Examples include notifications from lock-screen applications and Skype calls.

Input devices

We recommend using HIDI2C for input peripherals whenever possible, but this is not a requirement. If necessary, USB can be used to connect to an input device such as a touchpad, touch digitizer, or pen digitizer. A precision touchpad must be capable of waking the system from deep idle, regardless of whether this device is connected to USB or I2C. As an option, a non-precision touchpad can wake the system from deep idle. Touch digitizers and pen digitizers must not wake the system from deep idle.

In addition to buttons on the chassis, a connected standby PC might have other input devices physically integrated into the system or attached to the system directly or indirectly through a dock. When the user generates input through an input device, it must always wake the SoC from the deepest idle state and cause the display to turn on.

DeviceWake the SoC from deep idle?Wake mechanism or pathTurns on the display?Remarks
Keyboard (integrated HIDI2C)

Yes

(See Note in Remarks.)

GPIO interruptYes

The Windows power manager will turn on the display when keyboard input is detected.

All keys on the keyboard must generate a GPIO wake interrupt and cause the display to turn on (with the exception of volume buttons, which should not turn on the screen).

If the keyboard exposes consumer control keys—such as volume up/down and brightness—these keys must also generate a GPIO wake interrupt.

Note  If the keyboard is not visible to a user who is interacting with the display (as in a convertible tablet), we recommend that the keyboard not wake the SoC in that mode.

Keyboard (external USB)YesIn-band USB resume signalingYes
Keyboard (external Bluetooth)YesBluetooth radio followed by GPIO interruptYes
Touchpad (integrated HIDI2C)

Yes

(See Notes in Remarks.)

GPIO interruptYes

Moving a finger on the touchpad or exerting button activation force on the digitizer surface should cause a wake event.

Notes
  • A precision touchpad must be able to wake the SoC, but it's optional whether a non-precision touchpad should wake the SoC.
  • If the touchpad is not visible to a user who is interacting with the display (as in a convertible tablet), the touchpad is not required to wake the SoC in that mode.
Touchpad (external USB)

Yes

(See Notes in Remarks.)

In-band USB resume signalingYes

Moving a finger on the touchpad or exerting button activation force on the digitizer surface should cause a wake event.

Notes
  • A precision touchpad must be able to wake the SoC, but it's optional whether a non-precision touchpad should wake the SoC.
  • If the touchpad is not visible to a user who is interacting with the display (as in a convertible tablet), the touchpad is not required to wake the SoC in that mode.
Mouse (external USB)YesIn-band USB resume signalingYes

At a minimum, pressing any button on the mouse should generate a resume event and cause the screen to turn on. It is an optional capability for the mouse to support generating a resume event and waking the system for any movement of the mouse other than pressing a button.

Mouse (external Bluetooth)YesBluetooth radio followed by GPIO interruptYes

At a minimum, pressing any button on the mouse should generate a resume event and cause the screen to turn on. It is an optional capability for the mouse to support generating a resume event and waking the system for any movement of the mouse other than pressing a button.

Touch digitizer (integrated HIDI2C)NoGPIO interruptNo
Touch digitizer (external USB)NoIn-band USB resume signalingNo
Pen digitizer (integrated HIDI2C)NoGPIO interruptNo
Pen digitizer (external USB)NoIn-band USB resume signalingNo
Sensors (ALS, gyro, compass, GPS, etc.)NoN/AN/A
USB HID devices other than keyboards or miceNoN/AN/A

 

Insertion or removal of a connector or device

In addition to buttons on the chassis, a connected standby PC may have other input devices that are physically integrated into the system, or are attached to the system directly or indirectly through a dock. When the user generates input through an input device, this event must always wake the SoC from the deepest idle state and cause the display to turn on.

DeviceWake the SoC from deep idle?Wake mechanism or pathTurns on the display?Remarks
USB device insertionYesUSB host controller wake signalingNo
USB device removalYesUSB host controller wake signalingNo
SD card insertion (SDIO controller-attached)YesCard-detect GPIO interruptNo
SD card removal (SDIO controller-attached)YesCard-detect GPIO interruptNo
SD card insertion (USB-attached)YesIn-band USB resume signalingNo

The SD controller selected must be capable of detecting card insertion and removal while in the USB suspend state drawing less than 1 milliwatt average.

SD card removal (USB-attached)YesIn-band USB resume signalingNo

The SD controller selected must be capable of detecting card insertion and removal while in the USB suspend state drawing less than 1 milliwatt average.

Attaching a dockYes

Varies independently per device in the dock.

Varies

Depends on the devices in the dock and their current state.

Attaching a dock should be treated the same as individually attaching each of the devices included in the dock.

For example, attaching a dock alone should not cause the SoC to wake. Instead, detection of new devices (USB device, I2C device, battery, AC power source, and so on) contained in the dock should cause the SoC to wake.

Removing a dockYes

Varies independently per device in the dock.

Varies

Depends on the devices in the dock and their previous state.

Removing a dock should be treated the same as individually removing each of the devices included in the dock.

Removal of a dock alone should not cause the SoC to wake. Instead, removal of the individual devices (USB device, I2C device, battery, AC power source, and so on) contained in the dock should cause the SoC to wake.

Headphone or microphone insertionYesGPIO interruptNo

Attaching a headphone or microphone to the system provides an interrupt to enable the audio stack to correctly route audio.

Headphone or microphone removalYesGPIO interruptNo

Removing a headphone or microphone from the system generates an interrupt to enable the audio stack to correctly route audio.

 

Environmental context changes

The connected standby PC must also respond in real-time to changes in environmental conditions. The common cases are thermal events and power source change events.

DeviceWake the SoC from deep idle?Wake mechanism or pathTurns on the display?Remarks
Power source change (AC to battery, or battery to AC)YesGPIO interrupt from battery subsystem or power-management IC (PMIC)Yes

The Windows power manager will turn on the display when the battery subsystem has indicated a power source change. The GPIO interrupt for power source changes must cause the ACPI _PSR method under the power supply device to be executed.

The power subsystem must wake the SoC any time the power source changes, including when the system is attached or removed from a dock that has a battery or AC power source.

Thermal eventYesGPIO interruptNo

All temperature sensors must wake the SoC from the deepest power state to indicate temperature change.

ACPI firmware should monitor thermal zone temperature changes continuously during connected standby and when the SoC is in the deepest idle state. The ACPI firmware should report to the Windows thermal manager when the temperature rises above the trip points.

Battery charge completionYesGPIO interrupt from battery subsystem or PMICNo
Battery threshold changeYesGPIO interrupt

No

(See Note following this table.)

The battery subsystem must wake the SoC from its deepest idle state anytime the remaining capacity goes below the value specified by Windows in the _BTP control method.

The battery subsystem must wake the SoC from its deepest idle state anytime the remaining capacity goes below the value specified by DesignCapacityOfLow in the _BIX control method. Windows will hibernate (x86) or shut down (ARM) the system when the remaining capacity falls below DesignCapacityOfLow.

 

Note  When the battery charge level crosses either the low or critical level, Windows briefly turns on the display to present a visual notification of the charge status to the user. This behavior is implemented in Windows and does not require additional firmware support.

 

 

Send comments about this topic to Microsoft

Show:
© 2014 Microsoft