TWAR05007_WinHEC05.pdf

Session OutlineWhere this session appliesBooted OS and an active device driverNo coverage for pre-boot environmentThe intricate art of component communicationWhere Video BIOS, System Firmware, driver and OSneed to work together for display hotkey and customfunctionality supportProblems with current approach for Windowscodenamed “Longhorn”What can be done?The new interface to ACPI in LDDMACPI Mechanisms available for use

Driver-Firmware CommunicationKernel ModeACPI.SYSVIDEOPRT.SYSMiniport driverProvided by:MicrosoftIHVOEMACPI FirmwareSystem BIOSVGA/Video BIOSKeyboard/InputGraphics hardware

General Issues and ChallengesSMM is not OS/developer friendlyEverything else is stopped while executing SMM codeSome Video BIOS functions (e.g. display detection)may potentially take some time to finishMay cause problems for time-sensitive OS functionsRequires x86 assembly language for developmentMay not be available on some platforms

General Issues and ChallengesVideo BIOS is x86 “real mode” codeLimited to 64KByte size due to legacy PC architectureHard to customize/extend/debug (16bit x86 assembly)Almost all of the available space is used for required functions64bit: no “virtual x86” mode, OS SW emulation layerRequires use of VGA legacy resources (0xA0000aperture, 0x3D4/0x3D5 I/O range, etc.) toprogram hardwareRequires fixed video memory range for any buffersVideo BIOS buffers are not available to OS/driver managementHardware alignment requirements may cause video memorypartitioning to allow fixed range that BIOS can use/reference

Longhorn LDDM ChallengesVideoPortInt10 is deprecated in LDDMGraphics driver doesn’t “own” video memorymanagement anymoreVideo memory usage is virtualized by OS VidMMDriver specifies video memory range(s) available to VidMMLonghorn has a “richer”, more responsive UIAverage video memory utilization may be higher than on XP dueto desktop composition process and more graphical contentbeing processedAny video memory reserved for BIOS functionality can’t be usedfor other purposesLonghorn has explicit support for display hotplugArrival/departure of displays will be much more common and OS,driver, ACPI firmware and Video BIOS need to stay in sync

The New Interface to ACPI in LDDMLDDM allows the driver to directly interface to ACPImethods in VGA namespace via it’s DDIDxgkCbEvalAcpiMethod()Hotkey/Lid/Dock notification events can be forwarded by OS to thegraphics driver viaDriverInitializationData.DxgkDdiNotifyAcpiEvent()Due to the new DMM (Display Mode Management) architecture ofthe LDDM, the graphics driver and OS are much better in syncregarding output device state, capabilities and displaydevice topology_DGS/_DSS methods will be handled by graphics driver_DSS will update the ACPI FW with the _DGS state request asmatched with the current display status detected by the driverWorkarounds done in ACPI FW for older OS to handle corner caseswith output device detection and display topology are not necessaryanymore

More Flexible Use of Available Methods_ROM method (VGA namespace)Provide display devices’ ROM image if stored inproprietary format (e.g. PCI “ROM BAR” not available)Allows configuration data transfer from ACPI FW tographics driver, up to 4KB in sizeOffset, Size parameter can be specified to request data(e.g. Offset = 0x10000: additional ACPI status andconfiguration data)Limited use even on WindowsXP and earlier OSthrough VideoPortGetRomImage() in the driver (onlylength from beginning of “ROM” can be passed to theOS function)

Custom Methods in the ACPI VGA NamespaceAllows handling custom display features thatcan’t be supported by standard ACPI methodswithout resorting to Int10h/SMI mechanismsFaster and simpler code developmentSafer interface from LDDM driver

RestrictionsACPI FW needs to explicitly check _OS/OSIFor any Windows OS before Longhorn, the new ACPI LDDM DDImechanisms are not availableIf _ROM method is sufficient as available on XP, that mechanismmay be usableACPI FW needs to be aware when LDDM device driverstarts up and shuts down_DOS method is used by LDDM driver to notify ACPI FW when ittakes over device hotkey switching after DmStartDevice() andwhen it passes control back before DmStopDevice()Better: have defined handover mechanism on DmStartDevice()and DmStopDevice() of the LDDM driver via ACPI method callsWhen LDDM driver is not active, ACPI FW either disablesfunctionality or has to handle it in a “pre-boot” fashion

RestrictionsACPI Thermal events currently don’t getforwarded to the graphics deviceACPI Thermal zones are currently not associated withdevices in the OSFor critical notification (e.g. overheating) fallbackmechanisms still need to be in place

ResourcesProvides Windows related Information for ACPIand Power management support:http://www.microsoft.com/whdc/system/pnppwr/powermgmt/default.mspxACPI overview, tools and specificationshttp://www.acpi.infoLDDM specification

Community ResourcesWindows Hardware & Driver Central (WHDC)www.microsoft.com/whdc/default.mspxwhdc/default.mspxTechnical Communitieswww.microsoft.com/communities/products/default.mspxNon-Microsoft Community Siteswww.microsoft.com/communities/related/default.mspxMicrosoft Public Newsgroupswww.microsoft.com/communities/newsgroupsTechnical Chats and Webcastswww.microsoft.com/communities/chats/default.mspxwww.microsoft.com/webcastsMicrosoft Blogswww.microsoft.com/communities/blogs

© 2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.