Mobile System Displays and Windows

Version 1.2c

Updated: December 4, 2001

On This Page

  Introduction and Requirements
  Dataflow on Display Switching
  Miniport Implementation
  Implementing _DSS
  Implementing _DDC
  Simulating DDC Detection of the LCD Display Panel, Monitor, and TV

Introduction and Requirements

This article is for developers of system BIOS and video miniport drivers for displays on mobile PCs designed to run with the Microsoft Windows 2000 and Windows XP operating systems. This article describes Windows ACPI support for display switching using a "hotkey" and simulating Plug and Play detection of the installed LCD display and attached TV. Appendix A contains descriptions of the new support provided by Videoprt.sys to implement this functionality.

This article assumes that the reader is familiar with implementing video miniport drivers as described in the Windows DDK. This article also assumes the reader is familiar with Appendix A, "ACPI Extensions for Display Adapters," in Advanced Configuration and Power Interface Specification, Revision 1.0b, available at http://www.acpi.info/ , and is familiar with the VESA Extended Display Identification Data Standard, Version 3, available at http://www.vesa.org/ .

 Top of page

Dataflow on Display Switching

Windows supports display switching using the ACPI methods documented in Appendix A of the ACPI 1.0b specification. If this support is implemented solely by the ACPI BIOS, the BIOS must simulate the actions carried out by _DSS, _DCS, and _DDC methods through SMI mode. However, for Windows, SMI mode should always be avoided. In SMI mode, the CPU is dedicated to the BIOS only and system interrupts cannot be handled. This may have extremely adverse effects on system robustness.

Shaded blocks in Figure 1 are components implemented in Windows. White blocks indicate vendor implementations. The steps in Figure 1 are as follows:

1. When the end user presses the Display Switching button on the machine, the system BIOS generates the ACPI event Notify(VGA, 80). The video port driver picks up this event and starts to handle it.

2. Video port driver asks the BIOS about the next desired state for each display output device, using the ACPI method _DGS.

3. Video port driver sends the notification IOCTL_VIDEO_VALIDATE_CHILD_STATE_CONFIGURATION to the miniport driver to determine whether the miniport allows the state change of devices.

4. Video port driver sends the notification IOCTL_VIDEO_SET_CHILD_STATE_CONFIGURATION to the miniport driver to make state change of the devices.

5. If the miniport allows state change of device and IOCTL_VIDEO_SET_CHILD_STATE_CONFIGURATION succeeds, the video port driver calls the ACPI BIOS _DSS method with Bit30=0. Otherwise, the video port driver calls the ACPI _DSS method with Bit30=1 to let the BIOS make the actual switch. The usage of Bit30 is described in "Implementing _DSS" later in this article.

6. Video port driver sends a notification to Windows 2000, which may change display settings if necessary.

Figure 1. Flow Chart of Display Switch Event Handling

 Top of page

Miniport Implementation

As mentioned earlier, there are potentially serious ramifications to system stability when the ACPI BIOS performs the display switching function. The same is true with enumeration of child devices such as a CRT monitor, LCD panel, or TV. For these devices, it is highly recommended that the miniport driver return the ACPI Extended Display Identification Data (EDID) buffer from HwVidGetVideoChildDescriptor.

To accomplish this, it is also recommended that the miniport driver handle these messages: IOCTL_VIDEO_SET_CHILD_STATE_CONFIGURATION
IOCTL_VIDEO_VALIDATE_CHILD_STATE_CONFIGURATION
IOCTL_VIDEO_GET_CHILD_STATE.

For information about these messages, see the Windows DDK.

IMPORTANT: It has been observed that disabling mode pruning may affect the switch actions, especially for those miniport drivers that delay physical switching until DrvAssertMode. Be careful to avoid this in your implementation.

 Top of page

Implementing _DSS

The ACPI _DSS method has to return synchronously. Any subsequent _DCS method must reflect the real state of the display output devices.

The purpose of Bit 30 is to allow the video port driver to indicate that the _DGS should be toggled to the next desired state when the miniport is doing the actual update, rather than the BIOS. Consider a scenario where the end user presses a hotkey to switch the display, but the miniport rejects the request. Without Bit 30, the _DGS method never changes; any subsequent hotkey requests will be rejected as well.

Therefore, _DSS with Bit30=0 will cause subsequent _DCS and _DGS value changes; _DSS with Bit30=1 will only cause subsequent _DGS value changes.

 Top of page

Implementing _DDC

Some systems don't connect the video chip I2C lines. For such systems, it is impossible for the miniport driver to retrieve EDID information from the CRT through I2C functions. Therefore, the BIOS has to implement the _DDC method for the CRT.

For systems that do connect the video chip I2C lines, it is recommended that the BIOS not implement the _DDC method for the CRT, because the miniport driver can do the job. Otherwise, the operating system tries one more time to use the _DDC method to retrieve the EDID, which only reduces performance.

 Top of page

Simulating DDC Detection of the LCD Display Panel, Monitor, and TV

Generally, mobile PCs do not support Plug and Play detection of the attached display panel, monitor, or TV. By supporting the Windows messages described in the previous section, the system can simulate this capability, which greatly improves the end-user experience. For example, Windows supports using the EDID preferred mode bit, which can be used to automatically set the display resolution to the native display mode for the attached panel.

To accomplish this, the ACPI BIOS must construct an EDID in the ACPI EDID buffer. This EDID will be returned to the system by the miniport using HwVidGetVideoChildDescriptor. This will cause the system to use the EDID information to properly configure the system without user intervention.

To the display adapter, any TV outputs are the same device, so a single ID is specified to avoid confusion. PNP09FE was assigned in a previous release of Windows and is used in the INF provided with Windows as the Plug and Play compatible ID for TV. Use this as the manufacturer ID.

Windows 2000 supports monitor-preferred mode. Windows 2000 Setup will try to set the default display resolution to "Monitor preferred resolution." This feature is important for most laptop systems.

To do this when defining the EDID, set Byte18H/Bit1 to 1. The first detailed timing block (36-47H) represents the preferred mode. OEMs must fill in the following EDID fields.

1. In order to minimize the amount of work necessary, all the normally required data in an EDID is not required. Refer to the VESA EDID standard for information about correctly populating the above data in the EDID.

2. Many OEMs also produce monitors that support DDC and contain an EDID. If the PC manufacturer chooses not to use the predefined IDs listed in this table, care must be taken to coordinate the Manufacturer ID such that a mobile PC does not use the same ID as a monitor or that future monitors do not use the same ID as the mobile PC.

For Windows 2000 and Windows XP, OEMs can make their LCDs generic so that the operating system determines the information from INF files. To do so, OEMs can choose the following EDID manufacturer IDs.

 Top of page