Windows Hardware Certification Requirements for Client and Server Systems

Description

Desktop Windows Manager (DWM) is the desktop graphical user interface system that enables the Windows Aero user interface and visual theme. This feature is required to be enabled for all Windows 7 systems, but the memory bandwidth requirement applies to certain form factors.

Related Requirements

• System.Client.Aero.SystemsStartAeroTheme
  
  

Target Feature: System.Client.Aero

Title: Systems are capable of starting the Aero theme

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  

Description

All Windows systems must be capable of starting the Aero theme, by meeting the following requirements. All Windows systems must enable the Aero theme by default when running with a version of Windows that includes Aero.

Requirements

• All video hardware in all system form factors must support a minimum 32 bpp.
  
  
• All systems must meet the following DirectX requirements:
  
  
  • All Windows 7 systems are required to either support the D3De9X interface and be Direct3D 9.x compliant, OR support Direct3D 10 or greater.
    
    
  • All Windows 7 systems except ultra-mobile form factor PCs are required to include graphics hardware that supports Direct3D 10 or greater.
    
    
  • All Windows 7 ultra-mobile form factor PCs are required to either support the D3De9X interface and be Direct3D 9.x compliant, or support Direct3D 10 or greater.
    
    
• All systems must meet the following minimum video memory size requirements.
  
  
  • For desktop that ship with a monitor and have one video port connector, all-in-one systems that do not have a video port for a second monitor, and for all mobile and ultra mobile systems, the following amount of total graphics memory (either discrete and/or total non-local) is required for specified monitor resolutions. Monitor resolutions are expressed as total pixels (X dimension multiplied by Y dimension):
    
    
    • Resolution less than 1,310,720 (1280x1024) pixels include 64MB.
      
      
    • Resolutions equal to or greater than 1,310,720 (1280x1024) pixels and equal to or less than 2,304,000 (1920x1200) pixels include 128MB.
      
      
    • Resolutions greater than 2,304,000 (1920x1200) pixels include 256MB.
      
      
  • For desktop systems that do not ship with a monitor, a minimum of 128MB of total graphics memory (either discrete and/or total non-local) memory is required.
    
    
  • For all dual monitor capable desktop systems that ship with a monitor (systems with two physical and operational monitor connections)
    
    
    • Resolution less than 2,621,440 (1280x1024 by 2) pixels includes 128MB.
      
      
    • Resolutions equal to or greater than 2,621,440 (1280x1024 by 2) pixels includes 256MB.
      
      
  • For dual monitor capable desktop systems that do not ship with a monitor, 256MB of total graphics memory (either discrete and/or total non-local) memory is required.
    
    
  • Mobile and ultra mobile systems with dual monitor capabilities are excluded from the dual monitor desktop requirements and are treated as single monitor systems. This is due to the different usage models and that external monitor ports are often used in mirroring or "duplicate" mode.
    
    
• Systems must meet the following minimum video memory performance requirements, as measured by WinSAT:
  
  
  • Desktop systems must have a measured memory bandwidth of 1,600 megabytes per second (MB/s) at a monitor resolution of 1,310,720 (equivalent to 1280x1024).
    
    
  • Mobile systems and all-in-one designs must achieve a measured bandwidth of 1,600 megabytes per second (MB/s) measured at the native resolution of the shipping panel.
    
    
  • Ultra mobile systems have no minimum video memory performance requirement.
    
    

Design Notes

Memory requirements described here are for usable or active connectors. Microsoft does not recommend supporting fewer active connections than available connectors on a given system as this causes failed expectations and poor user experience. If a system supports m connectors, but limits the number of active connections to n (where n < m), then memory requirements are applicable for n connectors as long as there is no way for a user to activate greater than n connections at any time.

Description

These requirements apply to systems that have generic Bluetooth controllers.

Related Requirements:

• System.Client.BluetoothController.Base.4LeSpecification
  
  
• System.Client.BluetoothController.Base.SC
  
  
• System.Client.BluetoothController.Base.SystemsWithBluetoothImplementDeviceID
  
  

Target Feature: System.Client.BluetoothController.Base

Title: If a system includes a Bluetooth controller it must support the Bluetooth 4.0 specification requirements.

Applicable OS Versions

• Windows 8 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows RT
  
  

Description

The Bluetooth controller must comply with the Basic Rate (BR) and Low Energy (LE) Combined Core Configuration Controller Parts and Host/Controller Interface (HCI) Core Configuration requirements outlined in the Compliance Bluetooth Version 4.0 specifications.

Target Feature: System.Client.BluetoothController.Base

Title: Systems that support Connected Standby with Bluetooth controllers must ship with The Microsoft inbox Bluetooth stack.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Systems that support Connected Standby that ship with Bluetooth controllers must ship with The Microsoft inbox Bluetooth stack.

Target Feature: System.Client.BluetoothController.Base

Title: Systems which support Bluetooth must implement the DeviceID profile, version 1.43

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Systems which support Bluetooth must include the Device ID record as specified in the DeviceID profile, version 1.43. This record shall contain the device's VID/PID.

Description

These requirements apply to systems that have non-USB Bluetooth controllers.

Related Requirements:

• System.Client.BluetoothController.NonUSB.NonUsbUsesMicrosoftsStack
  
  
• System.Client.BluetoothController.NonUSB.ScoSupport
  
  

Target Feature: System.Client.BluetoothController.NonUSB

Title: Any platform using a non-USB connected Bluetooth controller must ship with The Microsoft inbox Bluetooth stack.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Any platform using a non-USB connected Bluetooth controller must ship with The Microsoft inbox Bluetooth stack.

Target Feature: System.Client.BluetoothController.NonUSB

Title: Any platform with a non-USB connected Bluetooth controller must use a sideband channel for SCO.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Any platform using a Non-USB connected Bluetooth controller must use sideband channel for SCO (for example, SCO over an I2S/PCM interface).

Description

This section describes requirements systems with brightness controls.

Related Requirements:

• System.Client.BrightnessControls.BacklightOptimization
  
  
• System.Client.BrightnessControls.BrightnessControlButtons
  
  
• System.Client.BrightnessControls.SmoothBrightness
  
  

Target Feature: System.Client.BrightnessControls

Title: WDDM 1.2 drivers must enable scenario based backlight power optimization to reduce backlight level used by integrated panel.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

1. If WDDM driver supports scenario based backlight power optimization, it must indicate the support by implementing the DXGK_BRIGHTNESS_INTERFACE2 interface.
   
   
2. When Windows sets the current scenario by using the DxgkDdiSetBacklightOptimization function, the WDDM driver is required to honor the intent of the scenario as follows:
   
   
   1. DxgkBacklightOptimizationDisable: Driver is required to completely disable all backlight optimization.
      
      
   2. DxgkBacklightOptimizationDesktop: Driver is required to enable backlight optimization at a lower aggressiveness level. Driver must optimize for scenarios like photo viewing, browser, and Office documents.
      
      
   3. DxgkBacklightOptimizationDynamic: Driver is required to enable backlight optimization at a higher aggressiveness level. Driver must optimize for scenarios like video playback and gaming.
      
      
   4. DxgkBacklightOptimizationDimmed: Driver is required to enable backlight optimization at a higher aggressiveness level. Driver must make sure that the content on the screen is visible but it need not be easily readable.
      
      
3. Driver is allowed to dynamically change the aggressiveness level based on the content on the screen.
   
   
4. Driver is required to handle Windows requests for change to brightness level (based on user input or ambient light sensor) while keeping backlight optimization enabled.
   
   
5. Driver is required to gradually transition between aggressiveness levels.
   
   
   1. This is important in the case when user briefly invokes playback controls. At that time, Windows resets the scenario from DxgkBacklightOptimizationDynamic to DxgkBacklightOptimizationDesktop. The transition must not be a step but must be gradual.
      
      
6. WDDM driver is required to provide accurate information when Windows queries DxgkDdiGetBacklightReduction
   
   
7. Connecting additional display devices to the system must not impact the ability to perform backlight optimization on the integrated panel of the system.
   
   

Target Feature: System.Client.BrightnessControls

Title: Mobile systems that have brightness control function keys use standard Advanced Configuration and Power Interface (ACPI) events and support control of LCD backlight brightness using ACPI methods in the system firmware.

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

The Windows Mobility Center provides users with an LCD brightness control user interface. If the system implements keys that are invisible to the operating system, these keys must use Advanced Configuration and Power Interface (ACPI) methods. These keys must not directly control the brightness after Bit 2 of the _DOS method has been set. This requires the implementation of ACPI brightness methods in the system firmware.

The following methods are required:

• _BCL
  
  
• _BCM
  
  

Bit 2 of the _DOS method must be disabled so that the system firmware cannot change the brightness levels automatically.

The following methods are optional:

Support for the _BQC method is highly recommended but not required. Systems must map keys to the following ACPI notification values:

• ACPI_NOTIFY_CYCLE_BRIGHTNESS_HOTKEY 0x85
  
  
• ACPI_NOTIFY_INC_BRIGHTNESS_HOTKEY 0x86
  
  
• ACPI_NOTIFY_DEC_BRIGHTNESS_HOTKEY 0x87
  
  
• ACPI_NOTIFY_ZERO_BRIGHTNESS_HOTKEY 0x88
  
  

Design Notes

The _BCL and _BCM methods in the firmware enable the operating system to query the brightness range and values and to set new values. Refer to the ACPI 3.0 specification for more details.

Target Feature: System.Client.BrightnessControls

Title: Driver must support a smooth transition in response to all brightness change requests from Windows

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

1. All Windows 8 systems that support brightness control are required to support smooth brightness control.
   
   
2. All Windows 8 systems are required to report 101 brightness levels to Windows. Brightness is reported as a percentage, so this means 0 to 100 levels, including 0 and 100. Internally the driver might support more precise brightness control.
   
   
   1. This is to ensure that Windows has the ability to make fine grained changes to the screen brightness. However, the brightness slider UI might expose fewer levels through the slider because it might be cumbersome for the user to adjust so many levels.
      
      
3. WDDM driver is required to implement smooth brightness control in the driver without depending on the embedded controller (EC) for the smoothness.
   
   
4. WDDM driver is required to indicate support for smooth brightness control using the capability bit defined in the DXGK_BRIGHTNESS_INTERFACE2 interface.
   
   
5. WDDM driver must enable/disable smooth brightness control based on state set using DxgkDdiSetBrightnessState.
   
   
6. When Windows requests a change to brightness, driver is required to gradually change the brightness level over time so that the change is not a step.
   
   
7. WDDM driver is allowed to select an appropriate slope for transition. However, the transition must complete in less than 500 ms.
   
   
8. WDDM driver is allowed to alter the slope based on panel characteristics to ensure smoothness of brightness control.
   
   
9. WDDM driver is required to start responding immediately to new brightness level requests. This must be honored even if the system is already in the process of an existing transition. At such a time, the system must stop the existing transition at the current level and start the new transition from the current position. This ensures that when a user is using the slider to manually adjust the brightness, the brightness control is still responsive and not sluggish.
   
   
10. WDDM driver is required to continue supporting smooth brightness control, even if content based adaptive brightness optimization is currently in effect.
    
    
11. When WDDM driver is pnp started, it must detect the brightness level applied by the firmware and smoothly transition from that level to the level set by Windows.
    
    
12. Connecting additional display devices to the system must not impact the ability to do smooth brightness control on the integrated panel of the system.
    
    
13. Brightness levels are represented as a % in Windows. Therefore there is no absolute mapping between brightness % level and physical brightness level. For Windows 8, the following is the guidance.
    
    

Description

Base feature for digitizer

Related Requirements:

• System.Client.Digitizer.Base.DigitizersAppearAsHID
  
  
• System.Client.Digitizer.Base.HighQualityDigitizerInput
  
  

Target Feature: System.Client.Digitizer.Base

Title: Please refer to Device.Digitizer.DigitizersAppearAsHID

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Base.DigitizersAppearAsHID

Target Feature: System.Client.Digitizer.Base

Title: Please refer to Device.Digitizer.Base.HighQualityDigitizerInput

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  

Description

Please refer to Device.Digitizer.Base.HighQualityDigitizerInput.

Description

Pen feature for digitizer.

Related Requirements:

• System.Client.Digitizer.Pen.100HzSampleRate
  
  
• System.Client.Digitizer.Pen.ContactAccuracy
  
  
• System.Client.Digitizer.Pen.HoverAccuracy
  
  
• System.Client.Digitizer.Pen.PenRange
  
  
• System.Client.Digitizer.Pen.PenResolution
  
  

Target Feature: System.Client.Digitizer.Pen

Title: Please refer to Device.Digitizer.Pen.100HzSampleRate

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Pen.100HzSampleRate.

Target Feature: System.Client.Digitizer.Pen

Title: Please refer to Device.Digitizer.Pen.ContactAccuracy

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Pen.ContactAccuracy.

Target Feature: System.Client.Digitizer.Pen

Title: Please refer to Device.Digitizer.Pen.HoverAccuracy

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Pen.HoverAccuracy.

Target Feature: System.Client.Digitizer.Pen

Title: Please refer to Device.Digitizer.Pen.PenRange

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Pen.PenRange.

Target Feature: System.Client.Digitizer.Pen

Title: Please refer to Device.Digitizer.Pen.PenResolution

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Pen.PenResolution.

Description

Windows Touch interface for digitizer devices.

Related Requirements:

• System.Client.Digitizer.Touch.5TouchPointMinimum
  
  
• System.Client.Digitizer.Touch.Bezel
  
  
• System.Client.Digitizer.Touch.DigitizerConnectsOverUSBOrI2C
  
  
• System.Client.Digitizer.Touch.DigitizerJitter
  
  
• System.Client.Digitizer.Touch.ExtraInputBehavior
  
  
• System.Client.Digitizer.Touch.FieldFirmwareUpdatable
  
  
• System.Client.Digitizer.Touch.HIDCompliantFirmware
  
  
• System.Client.Digitizer.Touch.HighQualityTouchDigitizerInput
  
  
• System.Client.Digitizer.Touch.HighResolutionTimeStamp
  
  
• System.Client.Digitizer.Touch.InputSeparation
  
  
• System.Client.Digitizer.Touch.NoiseSuppression
  
  
• System.Client.Digitizer.Touch.PhysicalDimension
  
  
• System.Client.Digitizer.Touch.PhysicalInputPosition
  
  
• System.Client.Digitizer.Touch.PowerStates
  
  
• System.Client.Digitizer.Touch.ReportingRate
  
  
• System.Client.Digitizer.Touch.ResponseLatency
  
  
• System.Client.Digitizer.Touch.TouchResolution
  
  
• System.Client.Digitizer.Touch.ZAxisAllowance
  
  

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.5TouchPointMinimum

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.5TouchPointMinimum.

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.Bezel

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.Bezel.

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.DigitizerConnectsOverUSBOrI2C.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.DigitizerConnectsOverUSBOrI2C.

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.DigitizerJitter.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.DigitizerJitter.

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.ExtraInputBehavior.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.ExtraInputBehavior.

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.FieldFirmwareUpdatable

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.FieldFirmwareUpdatable

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.HIDCompliantFirmware

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.HIDCompliantFirmware

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.HighQualityTouchDigitizerInput

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  

Description

Please refer to Device.Digitizer.Touch.HighQualityTouchDigitizerInput

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.HighResolutionTimeStamp

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.HighResolutionTimeStamp

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.InputSeparation

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.InputSeparation

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.NoiseSuppression

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.NoiseSuppression

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.PhysicalDimension

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.PhysicalDimension

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.PhysicalInputPosition

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.PhysicalInputPosition

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.PowerStates

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.PowerStates

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.ReportingRate

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.ReportingRate

Target Feature: System.Client.Digitizer.Touc

Title: Please refer to Device.Digitizer.Touch.ResponseLatency

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.ResponseLatency

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.TouchResolution

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.TouchResolution

Target Feature: System.Client.Digitizer.Touch

Title: Please refer to Device.Digitizer.Touch.ZAxisAllowance

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Please refer to Device.Digitizer.Touch.ZAxisAllowance

Description: The requirements in this section describe what is required.

Related Requirements:

• System.Client.Firewall.FirewallEnabled
  
  

Target Feature: System.Client.Firewall

Title: Systems enable a firewall solution by default

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

All systems must test and ship with firewall software solution enabled by default.

Design Notes

The firewall can either be the inbox solution found under Security Center or a third party equivalent.

Description: This section describes requirements for systems implementing UEFI firmware.

Related Requirements:

• System.Client.Firmware.UEFI.GOP.Display
  
  

Target Feature: System.Client.Firmware.UEFI.GOP

Title: System firmware must support GOP and Windows display requirements

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Every firmware on a Windows 8 system must support the Graphics Output Protocol (GOP) as defined in UEFI 2.3.1.

The display is controlled by the system UEFI before the WDDM graphics driver takes over. GOP must be available when the Windows EFI boot manager loads. VBIOS is not supported. It is also required for prior UI, such as OEM logo, firmware setup, or password prompt screens to enable GOP. During this time when the firmware is in control, the following are the requirements:

Topology Selection

1. UEFI must reliably detect all the displays that are connected to the POST adapter. The Pre-OS screen can only be displayed on a display connected to the POST adapter.
   
   
2. In case multiple displays are detected, UEFI must display the Pre-OS screen based on the following logic:
   
   
   1. System with an Integrated display(Laptop, All In One, Tablet): UEFI must display the Pre-OS screen only on the integrated display.
      
      
   2. System without an integrated display (integrated display is shut or desktop system): UEFI must display the Pre-OS screen on one display. UEFI must select the display by prioritizing the displays based on connector type. The prioritization is as follows: DisplayPort, HDMI, DVI, HD15, Component, S-Video. If there are multiple monitors connected using the same connector type, the firmware can select which one to use.
      
      

Mode Selection

1. Once UEFI has determined which display to enabled to display the Pre-OS screen, it must select the mode to apply based on the following logic:
   
   
   1. System with an Integrated display (laptop, all-in-one, tablet): The display must always be set to its native resolution and native timing.
      
      
   2. System without an Integrated display (desktop):
      
      
      1. UEFI must attempt to set the native resolution and timing of the display by obtaining it from the EDID.
         
         
      2. If that is not supported, UEFI must select an alternate mode that matches the same aspect ratio as the native resolution of the display.
         
         
      3. At the minimum, UEFI must set a mode of 1024 x 768
         
         
      4. If the display device does not provide an EDID, UEFI must set a mode of 1024 x 768
         
         
   3. The firmware must always use a 32-bit linear frame buffer to display the Pre-OS screen
      
      
   4. PixelsPerScanLine must be equal to the HorizontalResolution.
      
      
   5. PixelFormat must be PixelBlueGreenRedReserved8BitPerColor. Note that a physical frame buffer is required; PixelBltOnly is not supported.
      
      

Mode Pruning

1. UEFI must prune the list of available modes in accordance with the requirements called out in EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() (as specified in the UEFI specification version 2.1).
   
   

Providing the EDID

1. Once the UEFI has set a mode on the appropriate display (based on Topology Selection), UEFI must obtain the EDID of the display and pass it to Windows when Windows uses the EFI_EDID_DISCOVERED_PROTOCOL (as specified in the UEFI specification version 2.1 ) to query for the EDID.
   
   
   1. It is possible that some integrated panels might not have an EDID in the display panel itself. In this case, UEFI must manufacture the EDID. The EDID must accurately specify the native timing and the physical dimensions of the integrated panel.
      
      
   2. If the display is not integrated and does not have an EDID, then the UEFI does not need to manufacture an EDID.
      
      

Description: This section describes requirements for graphics devices in client PC systems.

Related Requirements:

• System.Client.Graphics.FullGPU
  
  
• System.Client.Graphics.NoMoreThanOneInternalMonitor
  
  
• System.Client.Graphics.WDDM
  
  
• System.Client.Graphics.WDDMSupportRotatedModes
  
  
• System.Client.Graphics.Windows7.MinimumDirectXLevel
  
  

Target Feature: System.Client.Graphics

Title: A Windows client system must have a "Full" graphics device and that device must be the post device.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

WDDM 1.2 introduces multiple driver/device types: Full, Render only, and Display only. For a detailed description of each, refer to the WDDM 1.2 specification or the Windows 8 WDDM 1.2 requirement Device.Graphics.WDDM12.Base.

Each of these driver/device types are designed for specific scenarios and usage case. All client scenarios expect a "full" graphics device. Also many applications assume that the post device is the "best" graphics devices and use that device exclusively. For this reason, a Windows client system must have a "full" graphics driver/device that is capable of display, rendering, and video.

Target Feature: System.Client.Graphics

Title: Graphics driver must not enumerate more than one monitor as internal

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

The graphics driver must not enumerate more than one display target of the D3DKMDT_VOT_INTERNAL type on any adapter.

Design Notes

For more information, see the Graphics Guide for Windows 7 (http://msdn.microsoft.com/library/windows/hardware/gg487344).

Target Feature: System.Client.Graphics

Title: All Windows graphics drivers must be WDDM

Applicable OS Versions

• Windows 8 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows Server 2012
  
  
• Windows RT
  
  

Description

The Windows Display Driver Model (WDDM) was introduced with Windows Vista as a replacement to the Windows XP Display Driver Model (XDDM). The WDDM architecture offers functionality to enable features such as desktop composition, enhanced fault Tolerance, video memory manager, scheduler, cross process sharing of D3D surfaces and so on. WDDM was specifically designed for modern graphics devices that are a minimum of Direct3D 10 Feature Level 9_3 with pixel shader 2.0 or better and have all the necessary hardware features to support the WDDM functionality of memory management, scheduling, and fault tolerance. WDDM for Windows Vista was referred to as "WDDM v1.0". WDDM 1.0 is required for Windows Vista.

Windows 7 made incremental changes to the driver model for supporting Windows 7 features and capabilities and is referred to as "WDDM v1.1" and is a strict superset of WDDM 1.0. WDDM v1.1 introduces support for D3D11, GDI hardware acceleration, Connecting and Configuring Displays, DXVA HD, and other features. WDDM 1.1 is required for Windows 7.

Windows 8 also introduces features and capabilities that require graphics driver changes. These incremental changes range from small changes such as smooth rotation, to large changes such as 3D stereo, and D3D11 video support. The WDDM driver model that provides these Windows 8 features is referred to as "WDDM v1.2". WDDM v1.2 is a superset of WDDM 1.1, and WDDM 1.0.

WDDM v1.2 is required by all systems shipped with Windows 8. WDDM 1.0 and WDDM 1.1 are only supported with legacy devices on legacy systems. The best experience and Windows 8 specific features are only enabled by a WDDM 1.2 driver. A WDDM driver that implements some WDDM 1.2 required features, but not all required features will fail to load on Windows 8.

For Windows 8, XDDM is officially retired and XDDM drivers no longer load on Windows 8 or Windows Server 2012.

Below is a summary these WDDM versions:

WDDM v1.2 also introduces new types of graphics drivers, targeting specific scenarios and is described below:

1. WDDM Full Graphics Driver: This is the full version of the WDDM graphics driver that supports hardware accelerated 2D & 3D operations. This driver is fully capable of handling all the render, display and video functions. WDDM 1.0 and WDDM 1.1 are full graphics drivers. All Windows 8 client systems must have a full graphics WDDM 1.2 device as the primary boot device.
   
   
2. WDDM Display Only Driver: This driver is only supported as a WDDM 1.2 driver and enables IHVs to write a WDDM based kernel mode driver that is capable of driving display only devices. The OS handles the 2D or 3D rendering using a software simulated GPU. Display only devices are only allowed on client systems within a virtual machine session.
   
   
3. WDDM Render Only Driver: This driver is only supported as a WDDM 1.2 driver and enables IHVs to write a WDDM driver that supports only rendering functionality. Render only devices are not allowed as the primary graphics device on client systems.
   
   

Table below explains the scenario usage for the new driver types:

Target Feature: System.Client.Graphics

Title: If accelerometer is present, WDDM driver must support all rotated modes

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

On a system with an accelerometer, the WDDM driver is required to support all rotated modes for every resolution enumerated for the integrated panel.

• A WDDM driver is required to enumerate source modes for the integrated display. The WDDM driver must support rotated modes (0, 90,180 and 270) for every mode that it enumerates for the integrated panel.
  
  
• The rotation is required to be supported even if the integrated panel is in a duplicate or extended topology with another display device. For duplicate mode, it is acceptable to rotate all targets connected to the rotated source. Per path rotation is allowed but not required.
  
  

Both the above mentioned requirements are optional for Stereo 3D capable resolutions.

Target Feature: System.Client.Graphics

Title: All system display adapters or chipset complies with Direct3D 10 and DXGI feature sets or greater.

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  

Description

For all systems, except ultra-mobile PC form-factor, all graphics hardware in the system must be at least Direct3D 10 or greater.

The graphics memory performance target for Direct3D 10 hardware is 1,600 MB/sec and is measured by using the AeroAT tool.

All features required by this specification must also be exposed including those features defined for the DXGI DLL. The following list includes some of the required features called out in the Direct3D 10 specification:

• Geometry shader
  
  
• Stream output
  
  
• Integer instruction set
  
  
• New compressed formats
  
  
• Render to vertex buffer
  
  
• Render to cube map
  
  
• Render to volume
  
  

Description

Requirements describe the capabilities that are required for media transcode.

Related Requirements

• System.Client.MediaTranscode.SystemTranscodeFasterThanRealTime
  
  

Target Feature: System.Client.MediaTranscode

Title: System is capable of transcoding faster than real time for multimedia scenarios, both on AC and DC power

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Required

Successfully transcode a Standard Definition (SD) video to another SD video from and to the following formats:

• MPEG2-PS SD to H264 SD 2 mbps
  
  
• VC1 SD to MPEG2 (TS&PS) SD 2 mbps
  
  

Successfully transcode a High Definition (HD) video to a Standard Definition video from and to the following formats:

• H264 720p to MPEG2 (TS&PS) SD 2 mbps
  
  
• H264 720p to VC1 SD 2 mbps
  
  

Successfully transcode a High Definition (HD) video to another HD video from and to the following formats:

• VC1 720p to H264 720p 7 mbps
  
  

Optional

Successfully transcode a High Definition (HD) video to another HD video from and to the following formats:

• H264 1080p to H264 720p 7 mbps
  
  
• VC1 1080p to H264 720p 7 mbps
  
  
• H264 720p to MPEG2 (TS&PS) 720p 7 mbps
  
  
• H264 720p to VC1 720p 7 mbps
  
  

Successfully transcode a High Definition (HD) video to another HD video from and to the following formats:

• H264 1080p to MPEG2 (TS&PS) 720p 7 mbps
  
  

Design Notes

• MPEG-2 support is required on x86 and x64 architectures and operating systems only.
  
  
• See the Windows Driver Kit, Streaming Devices (Video and Audio), Hardware MFT Device Class and Stream Class Minidrivers.
  
  

Description

These are requirements for Mobile Broadband devices integrated in the systems.

Related Requirements

• System.Client.MobileBroadBand.ClassDriver
  
  
• System.Client.MobileBroadBand.MobileBroadBand
  
  

Target Feature: System.Client.MobileBroadBand

Title: USB interface based GSM and CDMA class of Mobile Broadband device firmware must comply with USB-IF's Mobile Broadband Interface Model Specification.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

USB interface based GSM and CDMA class of Mobile Broadband device firmware implementation must comply with the USB-IF's Mobile Broadband Interface Model (MBIM) Specification. No additional IHV drivers are needed for the functionality of the device and the device must work with The Microsoft Mobile Broadband(MB) class driver implementation. Note that Microsoft generic class driver doesn't support non–USB interface devices. Non-USB based devices require device manufacturer's device driver compliant with MB driver model specification.

Additional Details:

Mobile Broadband Interface Model Specification:

http://www.usb.org/developers/devclass_docs/MBIM10.zip

Mobile Broadband (MB) Design Guide:

http://msdn.microsoft.com/library/windows/hardware/ff560543

Target Feature: System.Client.MobileBroadBand

Title: Systems that include Broadband support meet Windows requirements

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Firmware Requirements

USB based devices for GSM and CDMA technologies (3GPP/3GPP2 standards based) must be firmware compliant with the Mobile Broadband Interface Model specification. These devices must be certified by the USB Forum for compliance (when it becomes available for mobile broadband devices).

In addition to the above, firmware needs to support the features listed below as specified by NDIS.

Non-USB devices for GSM and CDMA require IHV developed Mobile broadband drivers. The drivers must be compliant with the Mobile Broadband Driver Model. IHV-developed mobile broadband drivers must pass the tests for validating mobile broadband functionality, such as the Windows Hardware Certification Kit (HCK) tests.

• Devices based on the SPI peripheral bus require SPI driver support from the platform vendor.
  
  
• USB devices for GSM and CDMA must be compliant with the Microsoft USB driver stack and do not require IHV specific bus driver stack.
  
  

No additional Connection Manager software is required 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/library/windows/desktop/dd323271).

Microsoft strongly recommends USB-based bus interfaces such as analog USB, HSIC (where applicable) and SSIC (when available). The mobile broadband stack in Windows 8 is designed to support only USB protocol based bus interfaces. IHVs can still certify their devices with non-USB bus interfaces. However, Microsoft does not provide any engineering support for non-USB bus interfaces. Device manufacturers must ensure that any non-USB based mobile broadband solution meets all of the mobile broadband certification requirements. Microsoft is unable to provide any waivers or contingencies for any non-USB bus interfaces towards the certification of non-USB mobile broadband solutions.

The following table summarizes the required mobile broadband features.

Systems must also comply with Mobile Broadband requirements, with:

• Devices MUST support 16 bitmap wake patterns of 128 bytes each.
  
  
• Devices MUST wake the system on register state change.
  
  
• Devices MUST wake the system on media connect.
  
  
• Devices MUST wake the system on media disconnect.
  
  
• GSM and CDMA class of Devices MUST wake the system on receiving an incoming SMS message.
  
  
• Devices that support USSD MUST wake the system on receiving USSD message.
  
  
• Devices MUST support wake packet indication. NIC should cache the packet causing the wake on hardware and pass it up when the OS is ready for receives.
  
  

Mobile Broadband class of devices must support Wake on Mobile Broadband. It should wake the system on above mentioned events. Note that wake on USSD is mandatory only if the device reports that it supports USSD. Else it is optional. See the following MSDN documentation for more information on the SMS and register state wake events.

• NDIS_STATUS_WWAN_REGISTER_STATE
  
  
• NDIS_STATUS_WWAN_SMS_RECEIVE
  
  

Description

Related Requirements

• System.Client.NearFieldProximity.ImplementingProximity
  
  
• System.Client.NearFieldProximity.NFCPlacement
  
  
• System.Client.NearFieldProximity.RangeOfActuation
  
  
• System.Client.NearFieldProximity.TouchMark
  
  
•  

Target Feature: System.Client.NearFieldProximity

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Any system that incorporates NFC technology (namely any technology that utilizes one or more of the air interface specifications incorporated by the NFC Forum by reference as approved specifications, and whose intended use therewith is to support higher-layer NFC Forum specifications and related scenarios) must provide an NFP provider for that NFC implementation that meets the Device.BusController.NearFieldProximity.ProviderImplementation and Device.BusController.NearFieldProximity.NFCCertification requirements.

Any system that does not incorporate NFC technology and does not incorporate NFP technology that implements the device driver interface specified by the Device.BusController.NearFieldProximity.ProviderImplementation requirement need not meet NFP certification requirements.

Target Feature: System.Client.NearFieldProximity

Title: Placement of NFC on all form factors

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

To help users locate and use the proximity technology, the use of a visual mark is required by, and is only permitted for, NFC NFP providers (those NFP providers that implement air interface specifications incorporated by the NFC Forum by reference as approved specifications). Refer to the Windows 8 Near Field Proximity Implementation Specification for placement guidance and mark usage requirements. The spec can be found at:

http://go.microsoft.com/fwlink/p/?LinkId=237135

Target Feature: System.Client.NearFieldProximity

Title: For devices using active radios, proximity technology meets range of actuation.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

An NFP provider must support an effective operating volume to enable users to successfully use NFP technology with Windows in 95 times out of 100 attempts for all tap and do scenarios. Refer to the Windows 8 Near Field Proximity Implementation Specification document for detailed placement guidance, as well as acceptable, minimum, and maximum values for the required effective operating volume. The specification can be found at:

http://go.microsoft.com/fwlink/?LinkId=237135

Target Feature: System.Client.NearFieldProximity

Title: If the system has a proximity technology then there must be a touch mark to indicate where to tap devices together.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

To help users locate and use the proximity technology, the use of a visual mark is required by, and is only permitted for, NFC NFP providers (those NFP providers that implement air interface specifications incorporated by the NFC Forum by reference as approved specifications). Refer to the Windows 8 Near Field Proximity Implementation Specification for placement guidance and mark usage requirements. The specification can be found at:

http://go.microsoft.com/fwlink/p/?LinkId=237135

Description

Starting with Windows 7, Windows is moving towards a device centric presentation of computers and devices. Elements of the Windows user interface (UI), such as the Devices and Printers folder, show the computer and all devices that are connected to the computer. The requirements in this section detail what is required to have the PC appear as a single object in the Windows UI.

Related Requirements:

• System.Client.PCContainer.PCAppearsAsSingleObject
  
  

Target Feature: System.Client.PCContainer

Title: Computers must appear as a single object in the Devices and Printers folder.

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  
• Windows Server 2008 R2 (x64)
  
  

Description

Computers must appear as a single object in the Windows user interface (UI), such as the Devices and Printers folder. Windows 7 and newer has a platform layer which groups all functionality exposed by the computer into a single object. This object is referred to as the computer device container. The computer device container must contain all of the device functions that are located physically inside the computer chassis. This includes, but is not limited to, keyboards, touch-pads; media control/media transport keys, wireless radios, storage devices, and audio devices. The computer device container is used throughout the Windows platform and is visibly exposed to the user in the Devices and Printers UI. This requirement ensures a consistent and high quality user experience by enforcing the "one object per physical device" rule in the Devices and Printers folder and other UI elements.

The computer must appear as a single device container in all Windows UI elements for the following reason:

• The Windows UI is otherwise unable to provide a logical and understandable representation of the computer to the user. Accurate information about which devices are physically integrated with the computer must be supplied to support this and dependent Windows features.
  
  

Design Notes

Windows provides a device-centric presentation of computers and devices. Users interact with the computer and connected devices using this device-centric user interface. For example, the Devices and Printers folder shows the computer and all devices that are connected to the computer. In Devices and Printers the computer is represented by a single icon. All of the functionality exposed by the computer is available through this single icon object, providing one location for users to discover devices integrated with the computer and perform specific actions on those integrated devices. To enable this experience, the computer must be able to detect and group all computer-integrated devices (for example: all devices physically inside the PC). This requires that computer-integrated devices properly identify themselves as integrated components. This can be achieved by indicating that the device is not removable from computer, properly configuring ACPI for the port to which the device is attached, or creating a registry DeviceOverride entry for the device. (Note: Each bus type has different mechanisms for identifying the removable relationship for devices attached to that bus. For more information, see Multifunction Device Support and Device Container Groupings in Windows 7.)

To group the functionality exposed by the computer into a single device container, Windows uses information available in the device hardware, bus driver, system firmware, and Windows registry. The bus type to which a given device is attached determines the heuristic Windows applies to group that device. For more information, the white paper Multifunction Device Support and Device Container Groupings in Windows 7 (http://msdn.microsoft.com/library/windows/hardware/gg463141) explains the heuristic for many bus types, including:

• Universal Serial Bus (USB)
  
  
• Bluetooth
  
  
• IP connected devices using Plug and Play Extensions (PnP-X)
  
  
• 1394
  
  
• eSATA
  
  
• PCI Express (PCIe)
  
  

The Single Computer Display Object test (ComputerSingleDDOTest.exe) must run on the system to check if this requirement has been met. The tool is available in the Windows Hardware Certification Kit (HCK). The computer configuration for this test is different for laptops and desktop computers:

• Laptops: No external devices (other than a monitor) can be attached to the laptop when the ComputerSingleDDOTest.exe is run. If external devices of any type are attached the test fails automatically.
  
  
• Desktops (computers which require an external keyboard, mouse and monitor to be attached): Only a keyboard, mouse and monitor can be attached to the desktop when the ComputerSingleDDOTest.exe is run. If any devices other than these are attached the test fails automatically.
  
  

The ComputerSingleDDOTest.exe identifies those devices which Windows was unable to group with the computer device container. Determine the bus to which the indicated device is attached and follow the details in the white paper to determine why the device was not correctly grouped with the computer.

The design changes required to group an internal device with the computer device container vary depending on the bus to which the device is attached. Refer to the "Multifunction Device Support and Device Container Groupings in Windows 7" white paper for details.

Testing Notes

This requirement can be tested by using the Single Computer Display Object Test (ComputerSingleDDOTest.exe) in the Windows HCK. The computer configuration for this test is different for laptops and desktop computers:

• Laptops: No external devices can be attached to the laptop when the ComputerSingleDDOTest.exe is run. If external devices of any type are attached the test fails automatically.
  
  
• Desktops (computers which require an external keyboard, mouse and monitor to be attached): Only a keyboard, mouse and monitor can be attached to the desktop when the ComputerSingleDDOTest.exe is run. If any devices other than these are attached the test fails automatically.
  
  

The following are examples of the output from the Single Computer Display Object Test, showing both an unsuccessful and successful test pass. Both were run on the same laptop computer. There were not any devices attached to the laptop at the time the test was run.

Unsuccessful test result:

In the failure case, the laptop has two USB devices which are detected as separate device containers from the computer device container. These two devices are actually internal to the computer and connected to an internal USB hub.

D:\Tools\ComputerSingleDDOTest>ComputerSingleDDOTest.exe -laptop

Start: SystemFund-0200: Computers must be represented by one icon in Device Center., TUID=0E7AEA02-2712-422F-A9CD-FFBE470FD391

Found Device "USB Input Device". - This device should be part of the computer.

Found Device "USB Composite Device". - This device should be part of the computer.

Error: 0x0, Error 0x00000000

FAIL: Devices were found that are part of the computer but were reported as removable from the computer.

File=__FILE__ Line=468

End: Fail, SystemFund-0200: Computers must be represented by one icon in Device

Center., TUID=0E7AEA02-2712-422F-A9CD-FFBE470FD391, Repro= D:\Tools\ComputerSingleDDOTest \ComputerSingleDDOTest.exe

Summary: Total=1, Passed=0, Failed=1, Blocked=0, Warned=0, Skipped=0

Successful test result:

This is the same laptop as the unsuccessful test result above. The two USB devices are now grouped into the computer device container. This was done by creating a DeviceOverride registry entry for each device. Various options are available to achieve the correct grouping, depending on the bus type to which the device is attached. See Multifunction Device Support and Device Container Groupings in Windows 7 for details.

D:\Tools\ComputerSingleDDOTest>ComputerSingleDDOTest.exe -laptop

Start: SystemFund-0200: Computers must be represented by one icon in Device Center., TUID=0E7AEA02-2712-422F-A9CD-FFBE470FD391

PASS: Devices were correctly reported as part of the computer.

End: Pass, SystemFund-0200: Computers must be represented by one icon in Device Center., TUID=0E7AEA02-2712-422F-A9CD-FFBE470FD391, Repro=D:\Tools\ComputerSingleDDOTest\ComputerSingleDDOTest.exe

Description

This feature contains requirements for buttons that control the management of any radios in a laptop or Tablet/convertible PC. It also contains requirements for GPS radios, Near Field Proximity radios, and Bluetooth radios that do not use the Windows native Bluetooth stack.

Related Requirements

• System.Client.RadioManagement.HardwareButton
  
  
• System.Client.RadioManagement.RadioMaintainsState
  
  
• System.Client.RadioManagement.RadioManagementAPIHID
  
  
• System.Client.RadioManagement.RadioManagerCOMObject
  
  

Target Feature: System.Client.RadioManagement

Title: If a PC has a physical (hardware) button switch on a PC that turns wireless radios on and off, it must be software controllable and interact appropriately with the Radio Management UI.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

There does not need to be a hardware button for wireless radios on Windows 8 laptops or tablet/convertible PCs.

A wireless hardware button is one of the following:

1. Toggle Button (Laptops and Tablets)
   
   
2. Toggle Button with LED (Non-Connected standby supported laptops and tablets)
   
   
3. A-B slider switch (Laptops and Tablets)
   
   
4. A-B slider switch with LED (Non-Connected standby supported laptops and tablets)
   
   

When there is a hardware button for wireless radios there must not be more than one, and it must control all the radios present in the computer.

An LED to indicate the state of the switch is optional. Please note that an LED indicating wireless status is not allowed on systems that support connected standby. If an LED is present along with the button, it must behave as defined below.

• There must only be one LED to indicate wireless status. In other words, there must be not one LED for Bluetooth, one for Wi-Fi, and so on.
  
  
• If the global wireless state is ON, the LED must be lit.
  
  
• When the global wireless state is OFF, the LED must not be lit.
  
  
• When the button is pressed or switch is flipped, it must send a HID message that can be consumed by the Radio Management API.
  
  
• When the Radio Management API sends a HID message, the button or switch must receive the message and change the state of the LED accordingly.
  
  

Target Feature: System.Client.RadioManagement

Title: Radio maintains on/off state across sleep and reboot power cycles

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

The state of the wireless radio must persist across sleep, reboot, user log off, user switching and hibernate.

Target Feature: System.Client.RadioManagement

Title: Wireless hardware button must communicate the change of state to the Radio Management API using HID.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

When the state of wireless radio switch changes, whether it is a slider A-B switch (with or without LED) or toggle button (with or without LED), this HID-compliant hardware switch/button must expose the HID collections to be consumed by the radio management API.

Toggle button must not change the state of the device radio directly.

A-B switch can be wired directly to the radios and change their state as long as it communicates the change of state to the Radio Management API using the HID driver and it changes the state in all radios present in the PC.

The HID usage IDs are:

The collections are:

Button without LED (stateless button) for laptops, tablets and convertibles

USAGE_PAGE (Generic Desktop) 05 01

USAGE (Wireless Radio Controls) 09 0C

COLLECTION (Application) A1 01

LOGICAL_MINIMUM (0) 15 00

LOGICAL_MAXIMUM (1) 25 01

USAGE (Wireless Radio Button) 09 C6

REPORT_COUNT (1) 95 01

REPORT_SIZE (1) 75 01

INPUT (Data,Var,Rel) 81 06

REPORT_SIZE (7) 75 07

INPUT (Cnst,Var,Abs) 81 03

END_COLLECTION C0

Button with LED For laptops, tablets and convertibles that do NOT support connected standby

USAGE_PAGE (Generic Desktop) 05 01

USAGE (Wireless Radio Controls) 09 0C

COLLECTION (Application) A1 01

LOGICAL_MINIMUM (0) 15 00

LOGICAL_MAXIMUM (1) 25 01

USAGE (Wireless Radio Button) 09 C6

REPORT_COUNT (1) 95 01

REPORT_SIZE (1) 75 01

INPUT (Data,Var,Rel) 81 06

REPORT_SIZE (7) 75 07

INPUT (Cnst,Var,Rel) 81 03

USAGE (Wireless Radio LED) 09 C7

REPORT_SIZE (1) 75 01

OUTPUT (Data,Var,Rel) 91 02

REPORT_SIZE (7) 75 07

OUTPUT (Cnst,Var,Abs) 91 03

END_COLLECTION C0

Slider Switch (without LED) - For laptops, tablets and convertibles

USAGE_PAGE (Generic Desktop) 05 01

USAGE (Wireless Radio Controls) 09 0C

COLLECTION (Application) A1 01

LOGICAL_MINIMUM (0) 15 00

LOGICAL_MAXIMUM (1) 25 01

USAGE (Wireless Radio Slider Switch) 09 C8

REPORT_COUNT (1) 95 01

REPORT_SIZE (1) 75 01

INPUT (Data,Var,Abs) 81 02

REPORT_SIZE (7) 75 07

INPUT (Cnst,Var,Abs) 81 03

END_COLLECTION C0

Slider Switch (with LED) - Laptops, tablets and convertibles that do NOT support connected standby

USAGE_PAGE (Generic Desktop) 05 01

USAGE (Wireless Radio Controls) 09 0C

COLLECTION (Application) A1 01

LOGICAL_MINIMUM (0) 15 00

LOGICAL_MAXIMUM (1) 25 01

USAGE (Wireless Radio Slider Switch) 09 C8

REPORT_COUNT (1) 95 01

REPORT_SIZE (1) 75 01

INPUT (Data,Var,Abs) 81 02

REPORT_SIZE (7) 75 07

INPUT (Cnst,Var,Abs) 81 03

USAGE (Wireless Radio LED) 09 C7

REPORT_SIZE (1) 75 01

OUTPUT (Data,Var,Rel) 91 02

REPORT_SIZE (7) 75 07

OUTPUT (Cnst,Var,Abs) 91 03

END_COLLECTION C0

LED only (No button or slider) - Laptops, tablets and convertibles that do NOT support connected standby

USAGE_PAGE (Generic Desktop) 05 01

USAGE (Wireless Radio Controls) 09 0A

COLLECTION (Application) A1 01

PHYSICAL_MINIMUM (0) 35 00

PHYSICAL_MAXIMUM (1) 45 01

LOGICAL_MINIMUM (0) 15 00

LOGICAL_MAXIMUM (1) 25 01

USAGE (Wireless Radio LED) 09 C1

REPORT_COUNT (1) 95 01

REPORT_SIZE (1) 75 01

OUTPUT (Data,Var,Rel) 91 02

REPORT_SIZE (7) 75 07

OUTPUT (Cnst,Var,Abs) 91 03

END_COLLECTION C0

Wireless radio LED must use HID to reflect the state of the flight mode switch located in the user interface. Wireless radio LED only uses HID for output (no input since there is no button).

When the Radio Management API sends a HID message because the global wireless state has changed, the switch must consume this message and toggle the state.

Target Feature: System.Client.RadioManagement

Title: There must be a radio manager COM object which registers and interacts with the Radio Management API.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Systems that include any of the following radio must create a radio manager COM Object for that radio:

• GPS
  
  
• Proximity-type radios such as NFC and TransferJet
  
  
• Bluetooth radio that doesn't use the Windows Native Bluetooth stack
  
  

Each radio that does not have an inbox radio manager must have its own IRadioInstance object and be enumerable from IMediaRadioManager::IEnumRadioInstance. There is inbox support for WLAN, mobile broadband and Bluetooth.

Verify IRadioInstance::GetRadioManagerSignature returns the media radio manager GUID.

RadioInstance::GetInstanceSignature must return device instance path.

The radio COM object manager must send and consume On and Off calls from the Radio Management API.

When the Airplane Mode switch is turned ON by the user, the Radio Management API calls the method OnSystemRadioStateChange(), with the sysRadioState parameter equal to SRS_RADIO_DISABLED, in which case the Media Radio Manager must record the current device radio state for later use and must set the radio state to DEVICE_SW_RADIO_OFF.

When the Airplane Mode switch is turned OFF by the user, the Radio Management API calls the method OnSystemRadioStateChange(), with the sysRadioState parameter equal to SRS_RADIO_ENABLED, in which case the device radio associated with the radio instance managed by this Media Radio Manager must transition to a previous device radio state (the last recorded state).

Radio COM object manager must report radio instance within 100 milliseconds. Please note that this does not mean that radio COM object manager has to be fully functional (ready to turning radio on/off); it just means that radio COM object manager needs to report the presence of a radio within 100 milliseconds.

Users do NOT need administrator privileges to change the radio state. Any standard user must be able to change the radio state.

Radio COM object manager must be able to change the state of the radio (on to off, or off to on) within 5 seconds.

Description

This feature contains requirements for buttons that control the management of any radios in a laptop or Tablet/convertible PC. The radios that this requirement applies to are GPS, Near Field Proximity, and Bluetooth radios that do not use the Windows native Bluetooth stack. Requirements in this section specifically apply to systems that are identified as supporting the Connected Standby feature.

Related Requirements

• System.Client.RadioManagement.ConnectedStandby.NoRadioStatusIndicatorLights
  
  

Target Feature: System.Client.RadioManagement.ConnectedStandby

Title: Systems that support Connected Standby must not include a light indicating the status of the radios in the system

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

In order to conserve energy, systems that support connected standby cannot include a status indicator indicating whether the radios are on.

Description

Screen rotation is the act of a user rotating a system from landscape to portrait and vice versa. The requirements in this section describe the behavior for the end user experience.

Related Requirements

• System.Client.ScreenRotation.SmoothRotation
  
  

Target Feature: System.Client.ScreenRotation

Title: Systems with accelerometers perform screen rotation in 300 milliseconds and without any video glitches.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

All Windows 8 systems with an accelerometer must have sufficient graphics performance to meet performance requirements for screen rotation.

The following performance metrics must be met:

Description: Not Specified

Related Requirements

• System.Client.Sensor.HumanProximitySensor
  
  
• System.Client.Sensor.Integrated
  
  
• System.Client.Sensor.MBBRequiresGPS
  
  

Target Feature: System.Client.Sensor

Title: System with human proximity sensor meets Windows requirements

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Sensor Category: SENSOR_CATEGORY_BIOMETRIC

Sensor Type: SENSOR_TYPE_HUMAN_PROXIMITY

All human proximity class sensors must ensure that they accurately report the following Data Types to be seamlessly integrated with Windows (through the sensors platform).

Note: Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED for hardware that is built-in to the PC enclosure. Note that proximity sensors with connection type = SENSOR_CONNECTION_TYPE_PC_ATTACHED can also be used for power management features (if integrated into connected peripheral).

For detailed information regarding sensor driver development, see Sensor Driver Design Guide in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Target Feature: System.Client.Sensor

Title: If the system contains an internal sensor that is integrated with the Windows Sensor Platform, it must report itself to the sensors platform as an integrated and correctly oriented sensor.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

If a system contains the following sensors that are integrated with the Windows Sensor Platform, then each of these sensors should report itself to the operating system as an internally integrated sensor.

Sensor Connection Type = SENSOR_CONNECTION_TYPE_PC_INTEGRATED

Required sensor objects exposed via sensor platform (Applies only to Tablet and Convertible-Tablet form-factors):

• 3D Accelerometer (SENSOR_TYPE_ACCELEROMETER_3D)
  
  
• 3D Inclinometer (SENSOR_TYPE_INCLINOMETER_3D)
  
  
• 3D Compass (SENSOR_TYPE_COMPASS_3D)
  
  
• 3D Gyrometer (SENSOR_TYPE_GYROMETER_3D)
  
  
• Device Orientation (SENSOR_TYPE_AGGREGATED_DEVICE_ORIENTATION)
  
  
• Ambient Light Sensor (SENSOR_TYPE_AMBIENT_LIGHT)
  
  

Required Sensor fusion** for PC-Integrated sensors (Applies only to Tablet and Convertible-Tablet form-factors):

• 3D Compass
  
  
  • 3D accelerometer used for tilt compensation (required)
    
    
  • 3D Gyrometer used to enhance data rate and data integrity (required)
    
    
• 3D Inclinometer
  
  
  • 3D accelerometer and 3D Compass used to determine yaw, pitch, roll (required)
    
    
  • 3D Gyrometer used to enhance data rate and data integrity (required)
    
    
• Device Orientation
  
  
  • 3D accelerometer and 3D Compass used to formulate Rotation Matrix, Quaternion (required)
    
    
  • 3D Gyrometer used to enhance data rate and data integrity (required)
    
    

**Sensor fusion is the process of using data from multiple sensors to enhance existing sensor data, or to synthesize new sensor data types from raw sensor data

In addition, each of these sensors should be correctly configured and calibrated with proper orientation (for example: mounted in proper direction) as per the guidance specified for the specific sensor category as outlined in related white papers and documents.

Sensors should not raise events when the system is stationary and the environment is not changing.

For detailed information regarding sensor driver development, see Sensor Driver Design Guide in the Device and Driver Technologies section of the Windows Driver Kit (WDK).

Target Feature: System.Client.Sensor

Title: If a mobile broadband device is integrated into a tablet or convertible system, then an assisted GPS radio is required.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Assisted GPS is only required if a tablet or convertible includes a mobile broadband device.

Description

This feature and requirement defines the computers and devices that compose the system.

Related Requirements

• System.Client.SystemConfiguration.SysInfo
  
  
• System.Client.SystemConfiguration.Windows7NeccessaryDevices
  
  
• System.Client.SystemConfiguration.Windows8RequiredComponents
  
  

Target Feature: System.Client.SystemConfiguration

Title: System information

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

A certification test collects information about the configuration of the machine, including:

• CPU Speed
  
  
• RAM
  
  
• Storage
  
  
• Hardware Resources
  
  
• Devices components
  
  
• Drivers
  
  
• Software
  
  

Target Feature: System.Client.SystemConfiguration

Title: Windows 7 systems includes necessary devices

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  

Description

All buses, devices, and other components in a system must meet their respective Windows 7 logo program requirements and only use drivers that either are included with the Windows operating system installation media or are digitally signed by Microsoft for Windows 7. Driver files that are not signed for Windows 7 may not be included in the system image. Drivers submitted for the Windows 7 logo must be able to be digitally signed and must meet the Microsoft guidelines as defined in the Windows Driver Kit, "WHQL Digital Signature".

For a system to receive a Windows 7 logo it must comply with the Windows 7 logo requirements defined for a system and must include Windows 7 logo devices specified in Table B. These devices must comply with the Windows logo requirements (unless an exception is explicitly noted).

TABLE B: System requirements

Systems must include the devices designated as R (required).

1. If audio is included in the system, it must meet all logo requirements.
   
   
2. Display on all-in-One and mobile systems must comply with requirements for Displays & Monitors.
   
   
3. Graphics solution in desktop, all-in-One and mobile systems must comply with requirements for graphics. For Windows 7, desktop, mobile and all-in one systems must include a display adapter/chipset that complies with Direct3D version 10 and WDDM 1.1 beginning December 1, 2009. Prior to December 1, 2009, WDDM v1.1 is Optional for a display adapter or chipset based on the Direct3D v9 hardware architecture and shipping in a Windows 7 system (desktop, mobile or all-in-one). Ultra Mobile PCs are required to ship with at least Direct3D version 9 and WDDM 1.0.
   
   
4. System must ship with a storage solution.
   
   
5. If system includes Audio it must be supported as a UAA compliant audio solution and be logo qualified.
   
   
6. Either WLAN or LAN device must be included in the system.
   
   
7. If any other devices are included in the system, they must be logo qualified for Windows 7.
   
   
8. A storage drive is required for the OS. An optical disc drive is optional. Read only optical disc drives are still allowed to be included in logo'd systems after June 1, 2010.
   
   

Target Feature: System.Client.SystemConfiguration

Title: Windows 8 systems must include certain devices

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Component requirements for Windows 8 tablets and convertibles can be found in requirements under System.Client.Tablet. For all other Windows 8 systems, the table below lists the minimum required components to be present in a system in order for it to be certified for Windows 8. All components must meet certification requirements and pass device certification testing for Windows 8.

Any buttons that are implemented on the system cannot launch any customized user interface elements.

Buttons refers to buttons or keys.

Customized user interface elements include overlays, pop-up dialogs, toasts, or other transitory user interface elements that appears over the Start screen, Windows Store apps, or desktop. They don't include Windows Store apps or desktop apps.

Examples:

The following user interface elements may not be displayed in response to a button press:

• Showing a customized overlay or a toast in response to the changed state of a keyboard key (for example: Caps Lock, Num Lock).
  
  
• Showing a customized overlay or a toast in response to the changed state of a touchpad
  
  

The following user interactions are permitted:

• Using a designated button or hotkey to launch a default mail client
  
  
• Using a designated button or hotkey to launch a default browser
  
  
• Using a designated button or hotkey to directly launch a desktop application
  
  
• Using a designated button to launch a Windows Store app associated with a file or protocol handler
  
  
• Showing a notification in response to a hardware error (for example: a problem docking or undocking the system
  
  

Onscreen displays for the monitor are allowed. They can only appear after the user has taken action such as pressing a button. The inbox onscreen display cannot be duplicated.

Description: The requirements in this section describe the level 2 quality of HW + SW + OEM image

Related Requirements

• System.Client.SystemImage.PushButtonReset
  
  
• System.Client.SystemImage.SystemRecoveryEnvironment
  
  

Target Feature: System.Client.SystemImage

Title: ARM System includes push button reset to initial factory state

Applicable OS Versions

• Windows RT
  
  

Description

An ARM system shall include a recovery image file that is compatible with the Push Button Reset feature in Windows 8. This recovery image file shall reside on a local recovery partition or on a separate bootable USB flash drive which is packaged with the system, or both.

If the recovery image file resides on a local recovery partition, the GPT partition shall be of type PARTITION_BASIC_DATA_GUID, and shall include the GPT_ATTRIBUTE_PLATFORM_REQUIRED and GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER attributes.

If the recovery image file resides on a separate bootable USB flash drive, the drive shall be configured to load the Windows Recovery Environment when used as the boot device, and the recovery image file shall be stored in the \Sources folder under the root of the drive.

The recovery image file shall meet the following requirements:

1. The recovery image file shall be in the Windows image file format (.wim).
   
   
2. The recovery image file shall be named "install.wim" (or in the case of a split image, "install.swm", "install2.swm", "install3.swm", and so on…).
   
   
3. The recovery image file shall contain the Windows image and applications preloaded on the system.
   
   
4. The Windows image in the recovery image file shall be configured to start Windows Welcome (instead of Audit mode) when it boots for the first time.
   
   
5. The recovery image file shall be captured after the Windows image has completed the Specialize configuration pass.
   
   
6. The Windows System Assessment Tests (WinSAT) results for the DWM test shall be prepopulated in the Windows image in the recovery image file.
   
   

Target Feature: System.Client.SystemImage

Title: ARM System includes Windows Recovery Environment on a separate partition

Applicable OS Versions

• Windows RT
  
  

Description

An ARM system shall include a separate partition with a bootable Windows Recovery Environment image file (winre.wim). The GPT partition should be of type PARTITION_MSFT_RECOVERY_GUID, includes the GPT_ATTRIBUTE_PLATFORM_REQUIRED and GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER attributes, and contains at least 50 megabytes (MB) of free space after the Windows Recovery Environment image file has been copied to it.

Description: The requirements in this section describe the PC system partition configuration requirements.

Related Requirements

• System.Client.SystemPartition.DiskPartitioning
  
  
• System.Client.SystemPartition.OEMPartition
  
  

Target Feature: System.Client.SystemPartition

Title: Systems that ship with a Windows operating system must meet partitioning requirements

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  

Description

A Windows 7 or Windows 8 system shipped in legacy BIOS mode and Master Boot Record (MBR) configured must ship with a type 0x7 or type 0x27, active system partition in addition to the operating system partition (configured as Boot, Page File, Crash Dump, and so on). This active system partition must be at least 100MB in size for Windows 7 systems. For Windows 8 systems, this active system partition must have at least 250 MB of free space, above and beyond any space used by required files. For Windows 7 systems, we similarly recommend that the active partition have at least 25 MB of free space for future upgrade to a new version of Windows. This additional system partition can be used to host Windows Recovery Environment (RE) and OEM tools (provided by the OEM), so long as the partition still meets the 250 MB free space requirement.

Implementation of this partition allows support of current and future Windows features such as BitLocker, and simplifies configuration and deployments.

Tools and documentation to implement split-loader configuration can be found in Windows OEM Preinstallation Kit/Automated Installation Kit (OPK/AIK).

Target Feature: System.Client.SystemPartition

Title: Windows systems with recovery & OEM partitions must meet partitioning requirements.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

If a system includes a separate partition for recovery purposes or an OEM partition for any other purpose, this separate partition must be identified with the GPT_ATTRIBUTE_PLATFORM_REQUIRED attribute. This attribute is defined as part of the PARTITION_INFORMATION_GPT structure (http://msdn.microsoft.com/library/windows/desktop/aa365449) structure.

For example:

• If this separate partition includes a bootable Windows Recovery Environment image file, the GPT partition must be of type PARTITION_MSFT_RECOVERY_GUID and include the GPT_ATTRIBUTE_PLATFORM_REQUIRED attribute.
  
  
• If this separate partition includes a recovery image used by Push Button Reset, the GPT partition must be of type PARTITION_BASIC_DATA_GUID and include the GPT_ATTRIBUTE_PLATFORM_REQUIRED attribute.
  
  

Partitions which are identified with the GPT_ATTRIBUTE_PLATFORM_REQUIRED attribute must not be used for storing user data (such as through data backup, for example).

Description: The requirements apply to systems that are a tablet or tablet/convertible system.

Related Requirements

• System.Client.Tablet.BezelWidth
  
  
• System.Client.Tablet.ColdBootLatency
  
  
• System.Client.Tablet.RequiredHardwareButtons
  
  
• System.Client.Tablet.TabletPCRequiredComponents
  
  

Target Feature: System.Client.Tablet

Title: Tablet systems must provide sufficient bezel and or border space to allow it to be held without resulting in accidental touch input

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Tablet systems must provide sufficient bezel and or non-active border space on the face of the device to allow it to be held in the following postures without resulting in accidental touch input on the edges of the digitizer:

• Device held with one or two hands gripping the device in landscape or portrait orientation, with thumbs/palms on the bezel.
  
  
• Device cradled in either landscape or portrait orientation, with fingers wrapping around the device on to the bezel.
  
  
• Device held from the bottom, with a thumb on the bezel.
  
  

The bezel and or non-active border must not exceed 26 millimeters, to allow for users with smaller hands to access the edges of the digitizer while holding the device with two hands. If a design includes both a bezel and a non-active border, the combined width of both must not exceed 26 millimeters.

On tablet convertibles, where there is a mechanical hinge, it is acceptable to allow for the bezel and or non-active border to exceed the 26 millimeter maximum up to 45 millimeters along the bottom edge closest to the hinge.

Example implementation: include a bezel of 20 millimeters on the face of the device, on all four sides of the digitizer/display, for a tablet device.

Target Feature: System.Client.Tablet

Title: Time for I2C touch controller to respond

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

The time from when power is applied to an I2C touch controller to when the I2C controller is responding to Human Interface Device (HID) commands and providing touch reports must not exceed 100 milliseconds.

Target Feature: System.Client.Tablet

Title: Tablet and convertible PC must have five hardware buttons.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Hardware buttons must generate an event when a button is pressed. Hardware buttons cannot launch any customized user interface elements.

Buttons refers to buttons or keys.

Customized user interface elements include overlays, pop-up dialogs, toasts, or other transitory user interface elements that appears over the Start screen, Windows Store apps, or desktop. They don't include Windows Store apps or desktop apps.

Examples:

The following user interface elements may not be displayed in response to a button press:

• Showing a customized overlay or a toast in response to the changed state of a keyboard key (for example: Caps Lock, Num Lock).
  
  
• Showing a customized overlay or a toast in response to the changed state of a touchpad
  
  

The following user interactions are permitted:

• Using a designated button or hotkey to launch a default mail client
  
  
• Using a designated button or hotkey to launch a default browser
  
  
• Using a designated button or hotkey to directly launch a desktop application
  
  
• Using a designated button to launch a Windows Store app associated with a file or protocol handler
  
  
• Showing a notification in response to a hardware error (for example: a problem docking or undocking the system
  
  

The following buttons must be implemented on a tablet or convertible PC.

The default orientation is in landscape mode and the Windows Key button must be on the front of the device facing the end user in the center along the bottom bezel. If the system is a convertible, the buttons must be accessible in all configurations. For convertible systems, it is acceptable to have the button off center along the bottom bezel when the convertible is in its tablet mode.

The volume control buttons must be a soft press button type. Volume may be implemented as a single physical button, but must present two distinct interrupts via two distinct GPIO resources for SOCs, one for volume up and one for volume down.

A screen rotation lock button can be implemented. The rotation lock button can either be a press button or a slider that is stateless as long as there is no mechanical position.

The power button (and, if applicable, sleep button and lid switch devices) must be implemented using the ACPI control method button definition described in sections 4.7.2.2.1.2, 4.7.2.2.2, and 4.7.4.2.1 of Advanced Configuration and Power Interface Specification (http://www.acpi.info/spec.htm).

It is acceptable that the Power button be a slider switch as long as the switch automatically slides back to the normal state.

For Windows 8, the SAS signal is sent when the combination of the Windows Key button and the Power Button is pressed.

The Windows button size must be large enough for the Windows Logo artwork as well as the required white space as defined in the Logo License Agreement. The button can be any shape (for example: circular, square, or rectangular).

The Windows button selects an item and resumes the device from the Connected Standby state.

The Windows button must be a soft press button type unless the front of the system is entirely glass. If the front of the system is entirely glass, then the buttons on the front of the bezel may be capacitive as long as they meet the following requirements:

1. The user can always feel the button. Some implementation examples are (but not limited to) haptic feedback, etching, or raised bumps.
   
   
2. The button always provides dynamic feedback. Some examples are (but not limited to) force feedback, haptic, button depresses and making clicking sound.
   
   
3. Button sends signal on button down and button up. To be compatible with the inbox button driver, the capacitive button must signal up and down using GPIO for SOC systems.
   
   
4. The button must be able to recognize the difference between the Windows button press and edge swipe. If the end user happens to swipe in from the edge of the screen and happens to go over the button to invoke functionality of the application or the Windows 8 user experience (charms, snap or settings) from the edge, then the swipe gesture must work. The button must also be able to handle palm rejection in the scenarios where the end user is holding the system so their hand covers the button.
   
   
5. Touch controllers are powered off when the screen is powered off so the capacitive button cannot utilize the same controller as the touch screen itself
   
   
6. The capacitive button controller must remain powered in Connected standby. If the Windows button is pressed while the system is in connected standby, it must wake the system. The system is subject to the same power draw requirement as documented in System.Fundamentals.PowerManagement.CS.ConnectedStandbyDuration.
   
   

Target Feature: System.Client.Tablet

Title: Windows 8 Tablet and convertible PC must include certain devices

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

This version update includes the addition of Gyro, USB and device proximity to the list.

A tablet form factor is defined as a standalone device that combines the PC, display and rechargeable power source in a single chassis. A tablet does not include a permanently attached keyboard and pointing device but can be connected to a port replicator, keyboard and/or clamshell dock.

A convertible form factor is defined as a standalone device that combines the PC, display and rechargeable power source with a mechanically attached keyboard and pointing device in a single chassis. A convertible can be transformed into a tablet where the attached input devices are hidden or removed leaving the display as the only input mechanism.

The battery is capable of charging without running Windows.

All components and devices used in these form factors must meet certification requirements and pass device certification testing for Windows 8 if the product type exists.

The minimum components that make up a tablet and tablet convertible are:

Description: These requirements describe the graphics requirements for Tablet PCs.

Related Requirements

• System.Client.Tablet.Graphics.MinimumResolution
  
  
• System.Client.Tablet.Graphics.SupportAllModeOrientations
  
  

Target Feature: System.Client.Tablet.Graphics

Title: Tablet PCs support minimum resolution and color

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

The minimum native resolution/color depth is 1366x768 at a depth of 32bits. The physical dimensions of the display panel must match the aspect ratio the native resolution. The native resolution of the panel can be greater than 1366 (horizontally) and 768 (vertically).

Target Feature: System.Client.Tablet.Graphics

Title: Graphics drivers on Tablet systems are required to support all mode orientations

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Graphics drivers on tablet systems are required to support all mode orientations for every resolution enumerated for the integrated panel.

• A graphics driver is required to enumerate source modes for the integrated display. For each source mode enumerated the graphics driver is required to support each orientation (0, 90, 180 and 270).
  
  
• Each orientation is required even if the integrated panel is in a duplicate or extended topology with another display device. For duplicate mode, it is acceptable to rotate all targets connected to the rotated source. Per path rotation is allowed but not required.
  
  

Both the above mentioned requirements are optional for Stereo 3D capable resolutions.

Description: This section describes requirements for graphics devices within ultra mobile PC client systems.

Related Requirements

• System.Client.UMPC.Graphics.WDDM
  
  

Target Feature: System.Client.UMPC.Graphics

Title: Display subsystem meets minimum GPU, memory, and resolution requirements for a Basic Windows experience on Ultra Mobile PCs

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  

Description

For Windows 7, Ultra Mobile PCs are required to ship with at least Direct3D10 Feature Level 9_3and WDDM v1.1.

• Minimum display resolution for ultra-mobile implementations is 800x600. 32 MB of memory available for graphics, when native display resolution is configured to 1024x768 or less.
  
  
• A minimum color-depth of 32 bpp.
  
  

A DirectX9.L-class GPU that supports Pixel Shader 2.0.

Description: The requirements in this section detail the abilities of the graphics subsystem and its ability to playback high definition video content.

Related Requirements

• System.Client.VideoPlayback.GlitchfreeHDVideoPlayback
  
  
• System.Client.VideoPlayback.GlitchfreePlayback
  
  

Target Feature:System.Client.VideoPlayback

Title:System is capable of playing protected and unprotected High-Definition content with no perceivable glitch during playback on both AC and DC power modes

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

Required

System is capable of playing back protected and unprotected high-definition video of the following profiles with no perceivable glitch and user experience elements:

• 720p WMV - Traditional Content
  
  
  • 720p WMV Video (7mbps at 16x9 aspect ratio), WMA Audio 192 kbps, 48khz, 2-chanel 16-bit
    
    
  • 1280x720 (720p) ~ 7Mbps at Aspect Ratio 16x9,Video: Windows Media Video 9 Advanced Profile, Audio: Windows Media Audio 9 Professional at 384 kbps, 44.1 kHz, 2-channel 24-bit (A/V) 2-pass CBR
    
    
• 720p H.264 - Local and Internet Streaming
  
  
  • 720p H.264 high profile, 5mbps, AAC Audio 192 kbps, 48khz, 2-chanel 24-bit
    
    
• 1080p H.264 - Local and Internet Streaming
  
  
  • 1080p H.264 high profile, 5mbps, AAC Audio 192 kbps, 48 kHz, 2-channel 24 bit
    
    
• For DXVA Video drivers, we expect 720p (H.264 and VC-1) core device creation + decoder creation time < 50ms.
  
  

Optional

System is capable of playing back high-definition video of the following profiles with no perceivable glitch:

• Premium TV Content
  
  
  • TV 1080i 12mbps
    
    
• Complex Camera Content
  
  
  • AVCHD 1080i 20-35 mbps, high frame rate
    
    
  • AAC Audio 192 kbps, 48 kHz, 2-channel 24 bit
    
    

Design Notes

If the system has any of the following configurations:

• Multiple GPUs
  
  
• Multiple output connections
  
  
• It is powered via an AC adapter and used away from an outlet using a rechargeable battery for continuous operation when not plugged in
  
  

Then validation of this requirement must be done against each configuration that applies to the system.

Target Feature: System.Client.VideoPlayback

Title: System is capable of playing High-Definition content with no perceivable glitch during playback

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  

Description

System is capable of playing back high-definition video of the following profile with no perceivable glitch:

• 1280x720 (720p) ~ 7Mbps at Aspect Ratio 16x9
  
  
• Audio: Windows Media Audio 9 Professional at 384 kbps, 44 kHz, 2-channel 24-bit (A/V) 2-pass CBR
  
  
• Video: Windows Media Video 9 Advanced Profile
  
  

Description: These requirements apply to cameras integrated into the system.

Related Requirements

• System.Client.Webcam.PhysicalLocation
  
  
• System.Client.Webcam.VideoCaptureAndCamera
  
  

Target Feature: System.Client.Webcam

Title: Systems with a camera must report the physical location of the camera

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

For any camera device that is built into the chassis of the system and has mechanically fixed direction, the firmware must provide the _PLD method and set the panel field (bits[69:67]) to the appropriate value for the panel on which the camera is mounted. For example, Front indicates the camera view the user (webcam), while Back indicates that the camera views away from the end user (still or video camera).

In addition, bit 143:128 (Vertical Offset), and bits 159:144 (Horizontal Offset) must provide the relative location of the camera with respect to the display. This origin is relative to the native pixel addressing in the display component and should match the present display orientation of landscape or portrait. The origin is the lower left hand corner of the display, where positive Horizontal and Vertical Offset values are to the right and up, respectively.

All other fields in the _PLD are optional.

Target Feature: System.Client.Webcam

Title: Video capture and cameras meet requirements and can support Windows Capture Infrastructure

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Scenarios

• Previewing through the camera locally (viewfinder)
  
  
• Taking a photo
  
  
• Recording a video
  
  
• Real-time Communication
  
  

This requirement applies to systems with non-USB built-in cameras.

Driver Model

A camera driver must be provided. AVStream is the required driver model.

AVStream driver is recommended to be a child driver of the WDDM driver. (IHV graphics driver must report the child slot as a child of the graphics device in DxgkDdiQueryChildRelations with correct AcpiUid. Later IHV driver should report the correct connect status in DxgkDdiQueryChildStatus.

AVStream Camera Driver shall be installed through device driver which meets the Windows security requirement. The driver shall not crash or hang the OS, and shall disallow memory violations.

Pins

The driver is required to expose the following pins types:

• Capture: Supporting PINNAME_VIDEO_CAPTURE pin category with NV12 format
  
  
• Image: Supporting PINNAME_IMAGE pin category with JPEG format (can be supported by IHV Plug-in Model) and an uncompressed format ( at least one of the following uncompressed formats: RGB32 or NV12). In addition image pin must support software trigger, VideoControlFlag_Trigger.
  
  

Optionally, the driver may expose:

• Preview: Supporting PINNAME_VIDEO_PREVIEW pin category with NV12 format. (This is the video streaming pin with lower priority and potentially lower resolution)
  
  

All of the pins must be able to operate both independently and in combination without interfering with each other.

All streaming pins must support progressive format. The driver should set the interlace flag on the media type and the sample correctly.

Resolution & Performance

At least 720p 30 fps must be supported by the capture pin.

Controls

Following controls are recommended:

• Brightness
  
  
• Contrast
  
  
• Hue
  
  
• White Balance
  
  
• Backlight Compensation
  
  
• Zoom
  
  
• Exposure
  
  
• Focus
  
  

Image Stabilization

If there is image stabilization on the device, device must use the Microsoft defined GUID ("1A651206-EB69-4E83-B38F-7DC4CB21442C") for turning on/off this functionality.

If available, latency due to Image Stabilization shall not be more than one frame buffering.

Mirroring

The default state for mirroring must be "not mirrored".

Description

Video capture devices are cameras and audio/video input devices that bring streaming data into a PC.  Cameras that are included in this section are those that take live streaming audio/video and individual still images and either save the stream to the systems storage or to another computer. 

Related Requirements

• System.Client.Webcam.Specification.CameraRequirements
  
  

Target Feature: System.Client.Webcam.Specification

Title: Video capture and cameras must support resolution, anti-flicker, and audio-video sync

Applicable OS Versions

• Windows 8 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows RT
  
  

Description

If a front or rear facing webcam is integrated in the system, then the following requirements apply

Description

The ability to debug a system is crucial to supporting customers in the field and root-causing behavior in the kernel.  Requirements in this area support the ability to kernel debug a Windows system.

Related Requirements

• System.Fundamentals.DebugPort.SystemExposesDebugInterface
  
  

Target Feature: System.Fundamentals.DebugPort

Title: System exposes debug interface that complies with Debug Port Specification

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  

Description

Windows 8 supports several different debug transports. They are listed below in the preferred order of implementation.

Hardware Debugging Transports:

• Ethernet Network Interface Card from the following list: http://go.microsoft.com/fwlink/p/?LinkId=237141
  
  
• USB 3.0 - xHCI controller compliant to xHCI debug specification.
  
  
• 1394 OHCI compliant FireWire controllers.
  
  
• USB2 OTG (on supported hardware, recommend XHCI debug instead). See the supported hardware list at http://go.microsoft.com/fwlink/p/?LinkId=237141
  
  
• USB 2.0 EHCI debug (the debug enabled port must be exposed).
  
  
• Legacy Serial (16550 compatible programming interface).
  
  

ADDITIONAL REQUIREMENTS

All hardware debugging transports must meet the following requirements:

1. There must be at least one user accessible debug port on the machine.
   
   
2. On retail PC platforms, Microsoft strongly recommends that systems include two user accessible debug ports from the above list. The secondary debug port is required to debug scenarios where the first debug port is in use as part of the scenario. Microsoft is not responsible for debugging or servicing issues that cannot be debugged on the retail platform or reproduced on development platforms.
   
   
3. SOC development or prototype platforms provided to Microsoft for evaluation must have a dedicated debug port available for debugging. If the debug port is used for any scenarios that are expected to also be used on retail shipping devices, then there must be a secondary debug port available for debugging. This ensures that SOC development platforms can be used to test and debug all scenarios for all available transports, including USB host and function.
   
   
4. All debug device registers must be memory or I/O mapped. For example, the debug device must not be connected behind a shared bus such as SPI or I2C, because this prevents other devices on the same bus from being debugged.
   
   
5. When enabled, the debug device must be powered and clocked by the UEFI firmware during preboot, before transferring control to the boot block.
   
   

For additional information, see Intel Universal Serial Bus (USB) Specifications

Description

The ability to debug a USB 3 system is crucial to supporting customers in the field and root-causing behavior in the kernel. Requirements in this area support the debugging capability for the xHCI controller based systems via a debug registers. Every system that has xHCI controller and USB3 external port should support via this sport. 

Related Requirements

• System.Fundamentals.DebugPort.USB.SystemExposesDebugInterfaceUsb
  
  

Target Feature:System.Fundamentals.DebugPort.USB

Title:USB 3 system exposes debug interface that complies with Debug Port Specification

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  

Description

Systems that support USB 3 are required to have xHCI controller(s) compliant to the xHCI debug specification. The xHCI controller(s) shall be memory mapped.

• There must be at least one user accessible USB 3.0 debug port on the machine.
  
  
• All USB 3.0 ports must protect against a short on the VBus pin such that if another USB host is connected, the USB circuitry is not damaged.
  
  
• USB 3.0 hubs must not be integrated into the SOC or PCH/Southbridge.
  
  

For additional information, see http://go.microsoft.com/fwlink/p/?LinkId=58376

Description

This feature includes requirements specific to system firmware.

Related Requirements

• System.Fundamentals.Firmware.ACPI
  
  
• System.Fundamentals.Firmware.ACPIRequired
  
  
• System.Fundamentals.Firmware.FirmwareSupportsBootingFromDVDDevice
  
  
• System.Fundamentals.Firmware.FirmwareSupportsUSBDevices
  
  
• System.Fundamentals.Firmware.InternalPointingDeviceWorksWithExternalPointingDevice
  
  
• System.Fundamentals.Firmware.UEFIBitLocker
  
  
• System.Fundamentals.Firmware.UEFIBootEntries
  
  
• System.Fundamentals.Firmware.UEFICompatibility
  
  
• System.Fundamentals.Firmware.UEFIDefaultBoot
  
  
• System.Fundamentals.Firmware.UEFIEncryptedHDD
  
  
• System.Fundamentals.Firmware.UEFILegacyFallback
  
  
• System.Fundamentals.Firmware.UEFIPostTime
  
  
• System.Fundamentals.Firmware.UEFISecureBoot
  
  
• System.Fundamentals.Firmware.UEFITimingClass
  
  

Target Feature: System.Fundamentals.Firmware

Title: ACPI System Requirements

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

ACPI 5.0 is the relevant revision of the Spec for these requirements.

All systems must meet the following ACPI table requirements.

ACPI Table Requirements

DSDT Requirements

As per ACPI 5.0, all devices in the ACPI namespace must include:

• A vendor-assigned, ACPI-compliant Hardware ID (_HID object).
  
  
• A set of resources consumed (_CRS object).
  
  

In addition, the following conditional requirements apply:

• If any devices in the namespace share the same Hardware ID, then each is required to have a distinct Unique Identifier (_UID object).
  
  
• If any device in the namespace is enumerated by its parent bus (Plug and Play buses), the address of the device on its parent bus (_ADR object) is required.
  
  
• If any device in the namespace is compatible with a Microsoft-provided driver, the Compatible ID (_CID object) defined for that device type is required.
  
  

General-Purpose Input/Output (GPIO) on an System that Supports Connected Standby

GPIO Controllers for pins used by Windows drivers or ASL control methods must appear as devices in the ACPI namespace.

Devices in the namespace that are connected to GPIO pins on an enumerated controller device must:

• Include GPIO IO Connection resource descriptors in their _CRS for any GPIO I/O pins connected. Include GPIO Interrupt Connection resource descriptors in their _CRS object for any GPIO interrupt pins connected.
  
  

Simple Peripheral Bus (SPB) on a System that supports Connected Standby

SPB Controllers for connections used by Windows drivers or ASL control methods must appear as devices in the ACPI namespace.

Devices in the namespace that are connected to an enumerated SPB controller device (UART, I2C, SPI) must include SPB Connection resource descriptors in their _CRS for the SPB Connection(s) used.

Power Button

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 cause the system to power-up when required.
  
  
• Generate the Power Button Override Event when held down for 4 seconds.
  
  

Control Method Power Button

Systems dependent on built-in (or connected) keyboards/mice for input must conform to the ACPI Control Method Power Button. In addition, systems that support connected standby must:

• Implement the ACPI Control Method Power Button using a dedicated GPIO interrupt pin to signal button press events.
  
  
• Configure the power buttons GPIO interrupt pin as a non-shared, wake-capable (ExclusiveAndWake) GPIO interrupt connection resource.
  
  
• List the Power Buttons GPIO interrupt connection resource in the ACPI Event Information (_AEI object) of the GPIO controller device to which it is connected.
  
  
• Provide the event method (_Lxx or _Exx object) for the power button event under the GPIO controller device in the ACPI namespace.
  
  

NOTE: For systems that require a separate driver to handle power button presses, it is acceptable to have that driver evaluate a control method that performs a Notify() on the Control Method Power Button device instead of using the GPIO-based solution above.

Button Array-based Power Button

Touch-first (keyboard-less) systems must:

• Implement the Windows-compatible Button Array device.
  
  
• Connect the power button to a dedicated GPIO interrupt pin.
  
  
• Configure the power buttons GPIO interrupt pin as a non-shared, wake-capable (ExclusiveAndWake), Edge-triggered (Edge) GPIO interrupt connection resource, capable of interrupting on both edges (ActiveBoth).
  
  
• List the power buttons GPIO Interrupt connection resource first in the Button Array devices _CRS object.
  
  

NOTE: For systems that require a separate driver to handle power button presses, it is acceptable to have that driver call the 5-Button array driver power button event interface instead of using the GPIO-based solution above.

Time and Alarm Device

All battery-powered systems which are not capable of supporting Connected Standby are required to implement the Alarm capabilities of the ACPI Time and Alarm control method device.

Any system that supports Connected Standby that sets the "CMOS RTC Not Present" bit in the IAPC_BOOT_ARCH flags field of the FADT must implement the devices Time capabilities.

Target Feature: System.Fundamentals.Firmware

Title: System that support connected standby must contain required ACPI elements

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

ACPI 5.0 is the relevant revision of the Spec for these requirements.

Systems that support connected standby contain a hardware abstraction layer (HAL) which is distinct from typical PCs. Connected standby systems also routinely include busses and devices which are not Plug and Play compatible. In these cases, systems that support Connected Standby must include ACPI tables which conform to the Microsoft Windows 8 ACPI Specification for the following devices:

• USB
  
  
• GPIO
  
  
• Simple peripheral busses
  
  
• Human proximity sensor
  
  
• Ambient light sensor
  
  
• Storage and boot
  
  
• Core system resources
  
  
• Power firmware
  
  
• Boot firmware
  
  
• Runtime firmware
  
  

Target Feature: System.Fundamentals.Firmware

Title: System firmware supports booting from DVD device as defined by the El Torito specification

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows Server 2012
  
  
• Windows Server 2008 R2 (x64)
  
  

Description

The system firmware must support booting the system DVD. The system firmware or option ROM must support the No-Emulation mode in the "El Torito" Bootable CD-ROM Format Specification, Version 1.0, for installing Windows from optical media, such as bootable DVD media. The primary optical device must be bootable. This requirement applies to the primary optical storage and the primary bus to which the device is attached.

Target Feature: System.Fundamentals.Firmware

Title: System firmware provides USB boot support for USB keyboards, mouse, and hubs

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows Server 2008 R2 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  

Description

The system firmware must: Support USB keyboards and pointing devices during system boot, resume from hibernate, and operating system setup and installation. Support USB input devices at least two levels of physical hubs below the host controller. Support composite input devices by the boot protocol as defined in HID. For Windows 8 systems, it is acceptable to enumerate, but not initialize all devices. If the device is accessed, it must be fully initialize before proceeding.

The USB controller and USB devices must be fully enumerated when:

• Anything other than the Windows Boot Manager is at the top of the system boot order.
  
  
• A boot next variable has been set to boot to something other than the Windows Boot Manager.
  
  
• On a system where the Windows Boot Manager is at the top of the list, an error case has been hit, such that the firmware fails over from the Windows Boot Manager to the next item in the list.
  
  
• Resuming from hibernate, if the system was hibernated when booted from USB.
  
  
• Firmware Setup is accessed.
  
  

Target Feature: System.Fundamentals.Firmware

Title: System that has an integrated or internal pointing device either disables the device or enables dual operation if external pointing device is attached

Applicable OS Versions

• Windows 7 (x86)
  
  
• Windows 7 (x64)
  
  
• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

If dual operation is not possible, the system firmware must disable the internal pointing device by default when any external pointing device is detected. When the internal pointing device is disabled in system firmware, no input from the embedded pointing device must be sent to the operating system.

Target Feature: System.Fundamentals.Firmware

Title: A system with TPM that supports wired LAN in pre-OS must support the UEFI 2.3.1 EFI_DHCP4_PROTOCOL protocol and the UEFI 2.3.1 EFI_DHCP6_PROTOCOL (and the corresponding service binding protocols)

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  
• Windows Server 2008 R2 (x64)
  
  

Description

Systems which support TPM and wired LAN networking must support EFI_DHCP4_protocol, EFI_DHCP4_SERVICE_BINDING_PROTOCOL, EFI_DHCP6_protocol, and EFI_DHCP6_SERVICE_BINDING_PROTOCOL for wired LAN as defined in UEFI 2.3.1.

At pre-boot, BitLocker must be able to discover its Network Unlock provider on a Windows Deployment Server (WDS) via DHCP, and unlock the OS volume after retrieving a secret from WDS.

Details

All UEFI systems with TPM present and a wired LAN port must support BitLocker Network Unlock. This requires full DHCP support for wired LAN during preboot through a UEFI DHCP driver. Specifically, there must be UEFI driver implementations for EFI_DHCP4_protocol, EFI_DHCP4_SERVICE_BINDING_PROTOCOL, EFI_DHCP6_protocol, and EFI_DHCP6_SERVICE_BINDING_PROTOCOL for wired LAN, as defined in UEFI 2.3.1.

This requirement is "If Implemented" for Server systems and applies only if a Server system is UEFI capable

Target Feature: System.Fundamentals.Firmware

Title: UEFI firmware honors software control over load option variables

Applicable OS Versions

Windows 8 (x86)

Windows 8 (x64)

Windows RT

Windows Server 2012

Windows Server 2008 R2 (x64)

Description

UEFI systems must allow the Operating System to create both generic and device specific boot entries with Messaging Device path, specifically USB Class Device Path (UEFI version 2.3 main specification section 9.3.5.9). The firmware must respect these settings and not modify them once the OS has changed them. Furthermore, the firmware must accurately report the boot entries to the OS.

Functional Notes

If the device corresponding to a boot entry is not found, it is preferable for the system to proceed to the next boot entry silently, without presenting an error message or requiring user intervention.

If the system is booted from an internal USB device and there is a USB class entry at the top of the boot order, the system should first attempt to boot from external USB devices before attempting internal USB boot devices.

Design Notes

The UEFI specification requires that the software boot manager be allowed to do the boot order programming (UEFI v. 2.3 Section 3.1.1 "Boot Manager Programming").

The firmware should interpret load options and device paths as specified in Section 9 "Protocols Device Path Protocol".

The UEFI specification describes the variables that must be modifiable at runtime in Section 3.2, table 10.

The UEFI specification is available at http://www.UEFI.org.

This requirement is "If Implemented" for Server systems and applies only if a Server system is UEFI capable

Target Feature: System.Fundamentals.Firmware

Title: System firmware must meet Windows Compatibility requirements

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  
• Windows Server 2008 R2 (x64)
  
  

Description

All systems which ship with a UEFI-compatible OS must be compatible with the following sections of the UEFI 2.3.1 specification:

2.3, 3.1, 4.3, 6.1 ~ 6.5, 7.1~7.5, 8.1, 8.2, 9.1, 9.5, 11.2 ~ 11.4, 11.8, 11.9, 12.4, 12.7, 12.8, 12.9, 18.5, 21.1, 21.3, 21.5, 27.1~27.8

For more information, see UEFI Support and Requirements: Microsoft Windows Server 2008 (http://msdn.microsoft.com/library/windows/hardware/gg463144).

All Windows 8 systems must boot in UEFI mode by default. Other requirements may add additional sections of compatibility to this list, but this is the baseline.

All systems, except servers, must be certified in UEFI mode without activating CSM. If a system is available with 32bit and/or 64bit UEFI, both configurations must be tested for certification. For server, certification in UEFI mode is only required if UEFI is implemented.

OEMs may ship with CSM mode activated and the enterprise or government customer's licensed OS selection when requested.

Target Feature: System.Fundamentals.Firmware

Title: All client systems must be able to boot into UEFI boot mode and attempt to boot into this mode by default

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  

Description

The System firmware must be able to achieve UEFI mode boot by default. Such a system may also support fallback to legacy BIOS mode boot for deploying OS images which do not support UEFI, if the user explicitly selects that option in the pre-boot UEFI BIOS menu.

This requirement is "If Implemented" for Server systems.

Target Feature: System.Fundamentals.Firmware

Title: Systems which ship with a self-encrypting hard drive as a storage device must support the UEFI 2.3.1 EFI_STORAGE_SECURITY_COMMAND_PROTOCOL protocols and shall contain a non-OS partition that can be used to store Windows Recovery Environment.

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  

Description

If self-encrypted drive support is implemented it must have a UEFI-compatible OS and contain system firmware both conforming to system firmware certification requirements as defined in System.Fundamentals.Firmware and also contain a separate Windows RE partition.

BitLocker shall support self-encrypting drivers that conform to the Encrypted Drive Device Guidelines available at http://msdn.microsoft.com/library/windows/hardware/br259095

• UEFI Trusted Command Support in UEFI 2.3 + UEFI Mantis change number 616 or UEFI 2.3.1
  
  
  • Standard v2.3 + errata Bv2 www.uefi.org
    
    
  • Mantis Change Number 616 www.uefi.org (This is not part of v2.3)
    
    

All necessary partitions have to be created, managed individually pre/post encryption. The Windows RE partition must always be separate and outside of the OS/encryption partition.

If Windows RE is on the system partition, the size is 350 MB. If it's not the system partition, then it's 300 MB. This is assuming MBR layout. (For GPT, Windows RE is always separate from the ESP, hence 300 MB.)

This requirement is "If Implemented" for Server systems and applies only if a Server system is UEFI capable

Target Feature: System.Fundamentals.Firmware

Title: System firmware must not fall back to legacy BIOS mode without explicit user action

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  

Description

If the system ships with a UEFI-compatible OS, system firmware must be implemented as UEFI and it must be able to achieve UEFI boot mode by default. Such a system may also support fallback to legacy BIOS boot on systems with OS which do not support UEFI, but only if the user selects that option in a pre-boot firmware user interface. Legacy option ROMs also may not be loaded by default.

"Explicit User Action" means that end user (or in case of enterprise customer, the IT pro) must manually access the pre-boot firmware configuration screen and change the setting. It may not ship in the BIOS mode by default and programmatic methods which can be attacked by malware are not acceptable.

All systems with Class 2 UEFI must not fall back to legacy BIOS mode nor load legacy Option ROMs without explicit user action within the pre-boot UEFI configuration UI.

An OEM may not ship a 64-bit system which defaults to legacy BIOS or loads legacy option ROMs if that system ships with a UEFI-compatible OS.

When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded. Compatibility Support Modules are always prohibited on systems that support connected standby.

This requirement is "If Implemented" for Server systems.

Target Feature: System.Fundamentals.Firmware

Title: System must meet POST time requirements

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  

Description

All systems meet the following POST time requirements as reported through the Firmware Performance Data Table (FPDT) ACPI table. POST begins with system firmware initialization and ends with hand off to the OS Loader. POST is measured from the default boot path for the system. On x86 and x64 platforms, the default boot path is "hybrid boot", which is the S4 system state as defined in ACPI. The default boot path on the ARM platform is the S5 system state as defined in ACPI.

• Systems with SSD or hybrid SSD must POST in 2 seconds or less. A hybrid SSD has both SSD storage and spinning disks.
  
  
• Systems with spinning disks must POST in 4 seconds or less.
  
  
• If a system has a TPM and initializes it, an additional 300ms can be added to minimum POST time requirements (for example, 2.3 seconds for SSD based systems).
  
  
• All systems that ship with an integrated display (for example: tablets, clamshells, all in ones) are required to meet the POST time requirement.
  
  

Target Feature: System.Fundamentals.Firmware

Title: All client systems must support UEFI Secure boot

Applicable OS Versions

• Windows 8 (x86)
  
  
• Windows 8 (x64)
  
  
• Windows RT
  
  
• Windows Server 2012
  
  

Description

Note: These requirements are "If Implemented" for Server systems and apply only if a Server system supports UEFI Secure Boot.

1. Mandatory. For the purposes of UEFI Secure Boot, the platform shall expose an interface to Secure Boot, whereby the system firmware is compliant with the following sections and sub-sections of UEFI version 2.3.1 Errata B:
   
   
   1. 7.1
      
      
   2. 7.2
      
      
   3. 7.2.1
      
      
   4. 27.2
      
      
   5. 27.5 - 27.8 (as further profiled below).
      
      
2. Mandatory. Secure Boot must ship enabled Configure UEFI Version 2.3.1 Errata B variables SecureBoot=1 and SetupMode=0 with a signature database (EFI_IMAGE_SECURITY_DATABASE) necessary to boot the machine securely pre-provisioned, and include a PK that is set and a valid KEK database. The system uses this database to verify that only trusted code (for example: trusted signed boot loader) is initialized, and that any unsigned image or an image that is signed by an unauthorized publisher does not execute. The contents of the signature database is determined by the OEM, based on the required native and third-party UEFI drivers, respective recovery needs, and the OS Boot Loader installed on the machine. The following Microsoft-provided EFI_CERT_X509 signature shall be included in the signature database: "CN=Microsoft Windows Production PCA 2011" and "Cert Hash(sha1): 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d" which shall use the following SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}, must also be included in the form of either an EFI_CERT_X509_GUID or EFI_CERT_RSA2048_GUID type.
   
   
   • Note: Must NOT contain the following certificate: "CN=Microsoft Windows PCA 2010" and "Cert Hash(sha1): c0 13 86 a9 07 49 64 04 f2 76 c3 c1 85 3a bf 4a 52 74 af 88"
     
     
   • Note II: Windows Server systems may ship with Secure Boot disabled, but all other provisions of this sub-requirement must be met
     
     
3. Mandatory. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded. Compatibility Support Modules are always prohibited on Connected Standby systems.
   
   
4. Mandatory. The initial UEFI signature databases (db) shall be created with the EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute stored in firmware flash and may be updated only with an OEM-signed firmware update or through UEFI authenticated variable write.
   
   
5. Mandatory. Support for the UEFI "forbidden" signature database (EFI_IMAGE_SECURITY_DATABASE1) must be implemented.
   
   
6. Mandatory. The platform shall ship with an initial, possibly empty, "forbidden" signature database (EFI_IMAGE_SECURITY_DATABASE1) created with the EFI_VARIABLE_TIME_BASED_AUTHENTICATED_ACCESS attribute. When a signature is added to the forbidden signature database, upon reboot, any image certified with that signature must not be allowed to initialize/execute.
   
   
7. Mandatory. Secure Boot must be rooted in a protected or ROM-based Public Key. Secure Boot must be rooted in an RSA public key with a modulus size of at least 2048 bits, and either be based in unalterable ROM or otherwise protected from alteration by a secure firmware update process, as defined below.
   
   
8. Mandatory. Secure firmware update process. If the platform firmware is to be serviced, it must follow a secure update process. To ensure the lowest level code layer is not compromised, the platform must support a secure firmware update process that ensures only signed firmware components that can be verified using the signature database (and are not invalidated by the forbidden signature database) can be installed. UEFI Boot Services variables must be hardware-protected and preserved across flash updates. The Flash ROM that stores the UEFI BIOS code must be protected. Flash that is typically open at reset (to allow for authenticated firmware updates) must subsequently be locked before running any unauthorized code. The firmware update process must also protect against rolling back to insecure versions, or non-production versions that may disable secure boot or include non-production keys. A physically present user may however override the rollback protection manually. Further, it is recommended that manufacturers writing BIOS code adhere to the NIST guidelines set out in NIST SP 800-147 (http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf), BIOS Protection Guidelines, which provides guidelines for building features into the BIOS that help protect it from being modified or corrupted by attackers. For example, by using cryptographic digital signatures to authenticate BIOS updates.
   
   
9. Mandatory. Signed Firmware Code Integrity Check. Firmware that is installed by the OEM and is either read-only or protected by a secure firmware update process, as defined above, may be considered protected. Systems shall verify that all unprotected firmware components, UEFI drivers, and UEFI applications are signed using minimum RSA-2048 with SHA-256 (MD5 and SHA-1 are prohibited), and verify that UEFI applications and drivers that are not signed as per these requirements will fail to run (this is the default policy for acceptable signature algorithms). If an images signature is not found in the authorized database, or is found in the forbidden database, the image must not be started, and instead, information about it shall be placed in the Image Execution Information Table.
   
   
10. Mandatory. UEFI firmware and driver implementations must be resistant to malicious input from untrusted sources. Incomplete input validation may result in buffer overflows, integer and pointer corruption, memory overwrites, and other vulnerabilities, compromising the runtime integrity of authenticated UEFI components.
    
    
11. Mandatory. Verify Signature of all Boot Apps and Boot Loaders. Upon power-on, the platform shall start executing boot firmware and use 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.
    
    
12. Mandatory. Microsoft Key Encryption Key (KEK) is provisioned A valid Microsoft-provided KEK is included in the KEK database. Microsoft provides the KEK in the form of either an EFI_CERT_X509_GUID or EFI_CERT_RSA2048_GUID type signature. The Microsoft KEK signature uses the following SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    
    
13. Mandatory. PKpub verification. The PKpub key is owned by the OEM and stored in firmware flash. The private-key counterpart to PKpub is PKpriv, which controls Secure Boot policy on all OEM-manufactured devices, and its protection and use must be secured against un-authorized use or disclosure. PKpub must exist and the operating system must be able to read the value and verify that it exists with proper key length.
    
    
14. Mandatory. No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system.
    
    
15. Mandatory. UEFI Shells and related applications. UEFI Modules that are not required to boot the platform must not be signed by any production certificate stored in "db", as UEFI applications can weaken the security of Secure Boot. For example, this includes and is not limited to UEFI Shells as well as manufacturing, test, debug, RMA, & decommissioning tools. Running these tools and shells must require that a platform administrator disables Secure Boot.
    
    
16. Mandatory. Secure Boot Variable. The firmware shall implement the SecureBoot variable as documented in Section 3.2 "Globally Defined Variables' of UEFI Specification Version 2.3.1 Errata B"
    
    
17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
    
    
    1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
       
       
    2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
       
       
    3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults. On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.
       
       
18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.
    
    
19. Mandatory. If the firmware is reset to factory, then any customized Secure Boot variables are also factory reset. If the firmware settings are reset to factory defaults, all custom-set variables shall be erased and the OEM PKpub shall be re-established along with the original, manufacturer-provisioned signature databases.
    
    
20. Mandatory. OEM mechanism exists to remediate failed EFI boot components up to and including the Windows OS loader (bootmgr.efi). Images in the EFI boot path that fail Secure Boot signature verification MUST not be executed, and the EFI_IMAGE_EXECUTION_INFO_TABLE entry for that component shall be updated with the reason for the failure. The UEFI boot manager shall initiate recovery according to an OEM-specific strategy for all components up to and including Windows bootmgr.efi.
    
    
21. Mandatory. A working Windows RE image must be present on all Windows 8 client systems The Windows Recovery image must be present in the factory image on every Secure Boot capable system. To support automated recovery and provide a positive user experience on Secure Boot systems, the Windows RE image must be present and enabled by default. As part of the Windows 8 Trusted Boot work enhancements have been made to Windows RE to allow optimized recovery from signature verification failures in Secure Boot. OEMs must include Windows RE as part of their factory image on all Windows 8 client systems.
    
    
22. Mandatory. Firmware-based backup and restore. If the OEM provides a mechanism to backup boot critical files (for example: EFI drivers and boot applications), it must be in a secure location only accessible and serviceable by firmware. The OEM may provide the capacity via firmware or other backup store to store backup copies of boot critical files and recovery tools. If such a store is implemented, the solution must also have the capability to restore the target files onto the system without the need for external media or user intervention. This is a differentiator for the OEM in failover protection, used if the Windows OS loader (bootmgr.efi) or other boot critical components fail, preventing Windows native recovery solutions to execute.
    
    
23. Mandatory. Firmware-based backup synchronization. Backup copies of boot critical components (for example: EFI drivers and boot applications) stored in firmware must be serviced in sync with updates to same files on the system If the system has the capability to store a backup copy of the Windows OS loader (bootmgr.efi), and potentially other critical boot components, the files must be serviced on the same schedule as their counterparts in use on the live system. If the Windows OS loader is updated by Windows Update, then the backup copy of bootmgr.efi stored in firmware must be updated on the next boot.
    
    
24. Mandatory. All Windows 8 client systems must support a secondary boot path. For all Windows 8 systems configured for Secure Boot, there must be an alternate boot path option that is followed by the firmware in the event that the primary Windows OS loader fails. The second boot path may point either to the default shadow copy installed by Windows to the system backup store (<EFI System Volume>\EFI\Boot\boot<platform>.efi ), or to a copy stored by the OEM firmware-based mechanism. This alternate path could be a file in executable memory, or point to a firmware-based remediation process that rolls a copy out of the OEM predetermined backup store.
    
    
25. Mandatory. All Windows 8 client systems must support a USB boot path for recovery purposes. For all Windows 8 systems configured for Secure Boot, there is a last resort of booting from USB.
    
    
26. Mandatory. Supporting GetVariable() for the EFI_IMAGE_SECURITY_DATABASE (both authorized and forbidden signature database) and the SecureBoot variable.
    
    
27. Mandatory. Supporting SetVariable() for the EFI_IMAGE_SECURITY_DATABASE (both authorized and forbidden signature database), using an authorized KEK for authentication.
    
    
28. Mandatory. Reserved Memory for Windows Secure Boot UEFI Variables. A total of at least 64 KB of non-volatile NVRAM storage memory must be reserved for NV UEFI variables (authenticated and unauthenticated, BS and RT) used by UEFI Secure Boot and Windows, and the maximum supported variable size must be at least 32kB. There is no maximum NVRAM storage limit.
    
    
29. Mandatory. During normal firmware updates the following must be preserved:
    
    
    • The Secure Boot state & configuration (PK, KEK, db, dbx, SetupMode, SecureBoot)
      
      
    • All UEFI variables with VendorGuid {77fa9abd-0359-4d32-bd60-28f4e78f784b}
      
      
    • A physically-present user who authenticates to the firmware may change, reset, or delete these values
      
      
30. Mandatory. The platform shall support EFI variables that are:
    
    
    • accessible only during the boot services or also accessible in the runtime phase;
      
      
    • non-volatile; and
      
      
    • possible to update only after proper authorization, for example, being properly signed.
      
      

The platform must support EFI variables with any valid combination of the following UEFI 2.3.1 variable attributes set: