Andere ACPI-Namespaceobjekte

Für einige bestimmte Geräteklassen gibt es Anforderungen für zusätzliche ADVANCED Configuration and Power Interface (ACPI)-Namespaceobjekte, die unter diesen Geräten im Namespace angezeigt werden. In diesem Abschnitt werden die zusätzlichen Objekte aufgeführt, die für SoC-basierte Plattformen erforderlich sind.

Prozessoridentifikationsobjekte

Prozessoren müssen im ACPI-Namespace aufgezählt werden. Prozessoren werden unter \_SB unter Verwendung der Anweisung "Device" deklariert, wie bei anderen Geräten auf der Plattform. Prozessorgeräte müssen die folgenden Objekte enthalten:

• _HID: ACPI0007
• _UID: Eine eindeutige Nummer, die dem Eintrag des Prozessors im MADT entspricht.

Anzeigespezifische Objekte

Weitere Informationen zu anzeigespezifischen Objekten finden Sie in Anhang B, "Videoerweiterungen", der ACPI 5.0-Spezifikation.

Display-Specific-Objektanforderungen

USB-Hostcontroller und -Geräte

USB-Hostcontroller werden auf SoC-Plattformen zum Verbinden interner und externer Geräte verwendet. Windows enthält Posteingangstreiber für Standard-USB-Hostcontroller, die den EHCI- oder XHCI-Spezifikationen entsprechen.

Auf SoC-basierten Plattformen kann der USB-Hostcontroller von ACPI aufgezählt werden. Windows verwendet die folgenden ACPI-Namespaceobjekte beim Aufzählen und Konfigurieren kompatibler USB-Hardware:

• Eine vom Anbieter zugewiesene ACPI-kompatible Hardware-ID (_HID).

• Ein Objekt mit eindeutiger ID (_UID), wenn mehrere Instanzen des USB-Controllers im Namespace vorhanden sind (d. a. zwei oder mehr Knoten mit identischen Geräteidentifikationsobjekten).

• Eine kompatible ID (_CID) für den EHCI- oder XHCI Standard-kompatiblen USB-Hostcontroller (EHCI: PNP0D20), (XHCI: PNP0D10).

• Die aktuellen Ressourceneinstellungen (_CRS), die dem USB-Controller zugewiesen sind. Die Ressourcen des Controllers werden in der entsprechenden Hardwareschnittstellenspezifikation (EHCI oder XHCI) beschrieben.

USB-Device-Specific-Methode (_DSM)

Windows definiert eine Device-Specific-Methode (_DSM), um die gerätespezifische Konfiguration des USB-Subsystems zu unterstützen. Weitere Informationen finden Sie unter USB-Device-Specific-Methode.

Unterstützung für integrierte USB-Transaktionsübersetzer (TT) (_HRV)

Standard-EHCI-Hostcontroller unterstützen nur Hochgeschwindigkeits-USB-Geräte. Auf SoC-Plattformen unterstützt Windows zwei gängige Designs von EHCI-kompatiblen Hostcontrollern, die einen integrierten Transaktionsübersetzer für Low-Speed- und Full-Speed-USB-Geräte implementieren. Das Hardware Revision -Objekt (_HRV) gibt den Typ der integrierten TT-Unterstützung an den USB-Hostcontrollertreiber an.

Die _HRV wird gemäß den folgenden Kriterien festgelegt:

• NoIntegratedTT - _HRV = 0

  Standard-EHCI-Hostcontroller implementieren keine integrierten Transaktionsübersetzer, und ein _HRV Wert von 0 ist nur für diese Controller gültig. Es ist nicht erforderlich, das _HRV-Objekt für diese Controller einzuschließen.

• IntegratedTTSpeedInPortSc - _HRV = 1

  Aktivieren Sie die integrierte TT-Unterstützung. Diese Variante der Schnittstelle enthält die LowSpeed- und HiSpeed-Bits im PORTSC-Register selbst. Diese Bits befinden sich bei Bitversatz 26 bzw. 27. Beim Bestimmen der Geschwindigkeit liest der EHCI-Treiber die PORTSC und extrahiert die Geschwindigkeitsinformationen aus diesen Bits.

• IntegratedTTSpeedInHostPc - _HRV = 2

  Aktivieren Sie die integrierte TT-Unterstützung. Diese Variante der Schnittstelle umfasst die LowSpeed- und HiSpeed-Bits in einem separaten HOSTPC-Register. Wenn der EHCI-Treiber die Portgeschwindigkeit bestimmen muss, liest er das HOSTPC-Register, das dem Port von Interesse entspricht, und extrahiert die Geschwindigkeitsinformationen.

USB XHCI D3cold-Unterstützung

Zusätzlich zum selektiven Aussetzen können interne USB-Geräte, die mit XHCI-Controllern verbunden sind, in einen D3cold-Zustand versetzt und ausgeschaltet werden, wenn sie nicht verwendet werden. Weitere Informationen finden Sie unter Device Power Management. Alle USB-Gerätefunktionstreiber müssen sich für D3cold anmelden.

USB-portspezifische Objekte

Windows muss die Sichtbarkeit und Die Verbindungsfähigkeit von USB-Anschlüssen auf dem System kennen. Dies ist erforderlich, um dem Benutzer genaue Informationen über Ports und Geräte bereitzustellen. Zu diesem Zweck werden zwei Objekte, Standort des physischen Geräts (_PLD) und USB-Portfunktionen (_UPC) verwendet. Weitere Informationen finden Sie in den folgenden Themen:

• Abschnitte 6.1.6, "Geräteidentifikationsobjekte" und 9.13.1, "USB 2.0 HostController und _UPC und _PLD", in der ACPI 5.0-Spezifikation.

• Verwenden von ACPI zum Konfigurieren von USB-Anschlüssen auf einem Computer.

SD-Hostcontroller und -Geräte

SD-Hostcontroller werden auf SoC-Plattformen für den Zugriff auf Speicher sowie E/A-Geräte verwendet. Windows enthält einen Posteingangstreiber für SDA-Standard-Hostcontrollerhardware. Aus Gründen der Kompatibilität mit diesem Treiber muss ein SD Host Controller-Gerät die SD-Hostcontrollerspezifikation der SD Association erfüllen.

Auf SoC-Plattformen kann der SD-Hostcontroller von ACPI aufgezählt werden. Windows verwendet die folgenden ACPI-Namespaceobjekte beim Aufzählen und Konfigurieren kompatibler SD-Hardware:

• Eine vom Anbieter zugewiesene ACPI-kompatible Hardware-ID (_HID).

• Ein Objekt mit eindeutiger ID (_UID), wenn mehrere Instanzen des SD-Controllers im Namespace vorhanden sind (d. a. zwei oder mehr Knoten mit identischen Geräteidentifikationsobjekten).

• Eine kompatible ID (_CID) für den SDA-standardkonformen SD-Hostcontroller (PNP0D40).

• Die dem Controller zugewiesenen aktuellen Ressourceneinstellungen (_CRS). Die Ressourcen des Controllers werden wie folgt beschrieben:

  • Hardwareressourcen für alle implementierten Slots sind enthalten. Ein Steckplatz ist ein Verbindungspunkt auf dem SDIO-Bus für ein Speicher- oder E/A-Gerät. Jeder Steckplatz ist einem Standardsatz von Registern und einem Interrupt im SD-Hostcontroller zugeordnet, der für die Kommunikation mit dem verbundenen Gerät verwendet wird. SD-Hostcontroller können eine beliebige Anzahl von Steckplätzen implementieren, aber auf SoC-Plattformen gibt es in der Regel nur eine.

  • Slot-Ressourcen werden in der Reihenfolge der Slotnummer aufgelistet (die Ressourcen von Slot 0 sind zuerst, die Ressourcen von Slot 1 sind zweitens, und so weiter).

  • Für jeden Steckplatz werden Ressourcen in der folgenden Reihenfolge aufgeführt:

    • Die Basisadresse des SD-Standardregisters, das für den Steckplatz festgelegt ist.

    • Der SD-Standard-Interrupt für den Slot.

    • Eine GPIO-Interruptressource für den Steckplatz, für Signalkarteneinfügungen und -entfernungen (wenn die standardmäßige SD-Kartenerkennungsschnittstelle während aller Leistungszustände nicht unterstützt wird).

    • Eine GPIO-Eingaberessource für den Steckplatz zum Lesen, ob sich eine Karte derzeit im Steckplatz befindet (wenn die standardmäßige SD-Kartenerkennungsschnittstelle während aller Leistungszustände nicht unterstützt wird). Verwendet denselben Pin wie der Einfüge-/Entfernungsinterrupt.

    • Eine zweite GPIO-Eingaberessource zum Lesen, ob die Karte im Steckplatz schreibgeschützt ist (wenn die standardmäßige SD-Schreibschutzschnittstelle während aller Leistungszustände nicht unterstützt wird).

Die Unterbrechungen müssen weckfähig sein (beschrieben als "SharedAndWake" oder "ExclusiveAndWake").

Eingebettete SD-Geräte

SD-angeschlossene Geräte werden vom SD-Bus-Treiber aufgezählt. SD-Geräte, die in die Plattform integriert sind, müssen auch im ACPI-Namespace als untergeordnete Elemente des SD-Hostcontrollers aufgeführt werden. Diese Anforderung ermöglicht es dem Betriebssystem, das busenumerierte Gerät den plattformspezifischen Attributen zuzuordnen, die für das Gerät durch ACPI-Objekte bereitgestellt werden (z. B. Nicht-Entfernbarkeit, Gerätestromzustände, GPIO- oder SPB-Ressourcen verbraucht usw.). Um diese Zuordnung zu erstellen, erfordert der Gerätenamespace das Address -Objekt (_ADR), das die Adresse des Geräts auf dem SDIO-Bus kommuniziert. Das _ADR-Objekt gibt eine ganze Zahl zurück.

Für den SDIO-Bus wird der Wert dieser ganzen Zahl wie folgt definiert:

• Hochwort – Slotnummer (0 – erster Steckplatz)

• Niedriges Wort – Funktionsnummer (Siehe SD-Spezifikation für Definitionen.)

Ein eingebetteter SD-Gerätenamespace muss auch Folgendes enthalten:

• Ein Remove-Methode -Objekt (_RMV), das 0 zurückgibt (um anzugeben, dass das Gerät nicht entfernt werden kann).

• Ein _CRS Objekt für die Randbandressourcen, die das Gerät benötigt (z. B. GPIO-Pins oder SPB-Verbindungen), falls erforderlich.

Bildverarbeitungsklassengeräte (Kameras)

Kamerageräte können vom Grafiktreiber oder USB aufgezählt werden. In beiden Fällen muss Windows die physische Position der Kamera kennen, damit die entsprechende Benutzeroberfläche angezeigt werden kann. Dazu sind Kamerageräte, die in das Gehäuse des Systems integriert sind und eine mechanisch feststehende Richtung haben, in den ACPI-Namespace aufgenommen und stellen das Physical Device Location (_PLD)-Objekt bereit. Dies erfordert Folgendes:

• Das Kameragerät, das als untergeordnetes Gerät eines Erkennungsgeräts (entweder das GPU-Gerät oder das USB-Gerät) erscheint.

• Das Kameragerät, das das Adressobjekt (_ADR) bereitstellt, welches die Adresse der Kamera auf dem Bus des Parent-Geräts enthält.

  • Informationen zu USB finden Sie unter ACPI-Namespacehierarchie und _ADR für eingebettete USB-Geräte im nächsten Abschnitt unten.

  • Bei Grafiken ist dies der Bezeichner, der in der unter dem GPU-Gerät bereitgestellten _DOD-Methode angegeben ist. Weitere Informationen finden Sie in Anhang B, "Videoerweiterungen", der ACPI 5.0-Spezifikation.

• Das Kameragerät, das das _PLD-Objekt bereitstellt.

• Wenn für den Kameratreiber Seitenbandressourcen (z. B. GPIO-Interrupt- oder E/A-Verbindungen oder eine SPB-Verbindung) erforderlich sind, wird das _CRS-Objekt für diese Ressourcen bereitgestellt.

Im _PLD-Objekt werden das Panel-Feld (Bits 67-69), das Lidfeld (Bit 66) und das Dockfeld (Bit 65) auf die korrekten Werte für die Oberfläche festgelegt, auf der die Kamera montiert ist. Alle anderen Felder sind optional. Bei mobilen Handheld-Geräten, einschließlich Tablets, ist die Vorderseite die, die den Bildschirm hält, und der Ursprung befindet sich in der unteren linken Ecke, wenn das Display in der Hochformatausrichtung angezeigt wird. Bei Verwendung dieses Verweises gibt "Front" an, dass die Kamera den Benutzer ansieht (Webcam), während "Hinten" angibt, dass die Kamera vom Benutzer weggerichtet ist (Foto- oder Videokamera). Weitere Informationen finden Sie unter Abschnitt 6.1.8, "_PLD (Physischer Standort des Geräts)", in der ACPI 5.0-Spezifikation.

ACPI-Namespacehierarchie und _ADR für eingebettete USB-Geräte

Beim Hinzufügen eingebetteter USB-Geräte zum ACPI-Namespace muss die Hierarchie der Geräteknoten genau mit dem der Geräte übereinstimmen, die vom Windows-USB-Treiber aufgezählt werden. Dies kann durch Untersuchen des Windows-Geräte-Managers im Modus "Ansicht nach Verbindung" bestimmt werden. Die gesamte Hierarchie, beginnend mit dem USB-Hostcontroller und der Erweiterung auf das eingebettete Gerät, muss einbezogen werden. Die "Address"-Eigenschaft, die im Geräte-Manager für jedes Gerät bereitgestellt wird, ist die Adresse, die die Firmware im _ADR des Geräts melden muss.

Die ACPI 5.0-Spezifikation definiert die Adressen für USB-Geräte wie folgt:

USB-Root-Hub: Einziges untergeordnetes Element des Host-Controllers. Sie muss eine _ADR von 0 haben. Es sind keine anderen untergeordneten Elemente oder Werte von _ADR zulässig.

USB-Anschlüsse: Anschlussnummer (1-n)

USB-Geräte, die mit einem bestimmten Port verbunden sind, teilen die Adresse dieses Anschlusses.

Wenn es sich bei dem an einen Anschluss angeschlossenen Gerät um ein zusammengesetztes USB-Gerät handelt, müssen Funktionen innerhalb des zusammengesetzten Geräts die folgende Adresse verwenden:

USB-Funktion innerhalb eines Verbund-USB-Geräts: Anschlussnummer des Anschlusses, an den das Verbundgerät angeschlossen ist, PLUS die erste Schnittstellennummer der Funktion. (Arithmetische Addition).

Weitere Informationen finden Sie unter Identifizieren der Position interner Kameras.

ASL-Codebeispiele

Im folgenden ASL-Codebeispiel wird eine USB-Webcam beschrieben, die direkt an USB-Anschluss 3 angeschlossen ist.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {         // the Root HUB
     Name (_ADR, ZERO)      // Address is always 0.
     Device (CAM0) {          // Camera connected directly to USB
                       //   port number 3 under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
    } // End of Root Hub Device
}  // End of EHCI device

Im folgenden ASL-Codebeispiel wird ein USB-Verbundgerät beschrieben, das eine Webcam als Funktion 2 implementiert.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {
     Name (_ADR, ZERO)
     Device (CUSB) {        // Composite USB device
                    //   connected to USB port number 3
                    //   under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Device (CAM0) { // Camera function within the
                    //   Composite USB device.
                Name (_ADR, 5)  // Camera function has a first
                    //   Interface number of 2, so
                    //   Address is 3 + 2  = 5.
                Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
        } // End of Composite USB Device
    } // End of Root Hub Device
}  // End of EHCI device

Im folgenden ASL-Codebeispiel wird eine Webcam beschrieben, die über I2C verbunden ist.

Device (GPU0) {
    ... // Other objects required for graphics devices
    Name (_DOD, Package ()  // Identifies the children of this graphics device.
                // Each integer must be unique within the GPU0 namespace.
                {
                    0x00024321,  // The ID for CAM0. It is a non-VGA
                    //   device, cannot be detected by
                    //   the VGA BIOS, and uses a vendor-
                    //   specific ID format in bits 15:0
                    //   (see the _DOD specification).
                    ...     // Other child device IDs (for
                    //   example, display output ports)
                })
    Device (CAM0) {
        Name (_ADR, 0x00024321) // The identifier for this device
                    //   (Same as in _DOD above)
        Name (_CRS, ResourceTemplate()
            {
            // I2C Resource
            // GPIO interrupt resource(s), if required by
            //   driver
            // GPIO I/O resource(s), if required by driver
                ...
            })
        Method (_PLD, 0, Serialized) {...}
    } // End of CAM0 device
} // End of GPU0 device

HID-over-I2C-Geräte

Windows enthält einen Klassentreiber für Human Interface Devices (HID). Dieser Treiber ermöglicht generische Unterstützung für eine breite Palette von Eingabegeräten (z. B. Touchpanels, Tastaturen, Mäuse und Sensoren). Auf SoC-Plattformen können HID-Geräte über I2C mit der Plattform verbunden werden und von ACPI aufgezählt werden. Aus Gründen der Kompatibilität mit der HID-Klassenunterstützung in Windows werden die folgenden Namespaceobjekte verwendet:

• Ein anbieterspezifischer _HID

• Eine _CID von PNP0C50

• Eine _CRS mit:

  • Eine I2CSerialBusConnection-Ressource für den Zugriff auf das Gerät

  • Eine GpioInt-Ressource für Interrupts

• Die HIDI2C-_DSM Methode zum Zurückgeben der HID-Deskriptorregisteradresse auf dem Gerät. Weitere Informationen finden Sie unter HIDI2C-Device-Specific-Methode (_DSM).

Schaltflächengeräte

Für SoC-Plattformen unterstützt Windows sowohl den ACPI-definierten Steuerungsmethode-Netzschalter als auch ein Windows-kompatibles Fünf-Tasten-Array. Der Netzschalter, unabhängig davon, ob er als ACPI-Steuermethoden-Netzschalter oder als Teil der Windows-kompatiblen Schaltflächenanordnung implementiert wird, führt die folgenden Aktionen aus:

• Bewirkt, dass die Plattform eingeschaltet wird, wenn sie ausgeschaltet ist.

• Generiert ein Power-Button-Override-Ereignis, wenn die Taste gedrückt gehalten wird. Weitere Informationen finden Sie unter Abschnitt 4.8.2.2.1.3, "Power Button Override", der ACPI 5.0-Spezifikation.

Steuerungsmethode-Netzschalter

Clamshell-Designs und andere Systeme mit integrierten oder verbundenen Tastaturen implementieren den ACPI-definierten Steuermethoden-Netzschalter (Abschnitt 4.8.2.2.1.2 der ACPI 5.0-Spezifikation) mithilfe GPIO-Signaled ACPI-Ereignisse (Abschnitt 5.6.5 der ACPI 5.0-Spezifikation). Um das Netzschaltergerät zu unterstützen, lautet der Namespace:

• Beschreibt den GPIO-Interrupt-Pin des Netzschalters als nicht freigegebene (exklusive) GPIO-Interruptressource.

• Listet die GPIO-Interruptressource des Netzschalters im _AEI-Objekt des GPIO-Controllers auf, mit dem er verbunden ist.

• Stellt die zugeordnete Ereignismethode (Lxx/Exx/EVT) unter dem GPIO-Controllergerät bereit. Diese Ereignismethode benachrichtigt den Control Method Button-Treiber im Betriebssystem, dass das Schaltflächenereignis aufgetreten ist.

Weitere Informationen finden Sie unter Hardware-Tasten für Windows 8-Tablets und konvertierbare Geräte.

Windows-kompatibles Schaltflächenarray

Für Touch-First-Plattformen, wie tastaturlose Plattformen wie Slates, stellt Windows einen generischen Treiber für ein Array von fünf Tasten bereit. Jede Schaltfläche im Array verfügt über ihre definierte Funktion (siehe die nummerierten Elemente in der liste unten), und bestimmte Tastenkombinationen "Halten und Drücken" haben zusätzliche Bedeutung in der Benutzeroberfläche. Es sind keine Tastenkombinationen definiert, für die der Netzschalter gedrückt gehalten werden muss. Aus Gründen der Kompatibilität mit dem Windows-Schaltflächentreiber für den Posteingang wird das Windows-kompatible Button Array ACPI-Gerät implementiert. Das Gerät ist wie folgt definiert:

• Jeder der fünf Tasten ist mit einem eigenen dedizierten Interrupt-Pin auf der Plattform verbunden.

• Jeder Interrupt-Pin ist als nicht geteilte (exklusive), flankengesteuerte (Edge)-Interruptressource konfiguriert, die an beiden Flanken (ActiveBoth) unterbricht.

• Der Gerätenamespace enthält eine vom Anbieter definierte _HID sowie einen _CID von PNP0C40.

• Die GPIO-Interruptressourcen im _CRS-Objekt werden in der folgenden Reihenfolge aufgeführt:

  1. Interrupt, der der Schaltfläche "Ein/Aus" entspricht

     Die "Ein/Aus"-Taste muss weckfähig sein (ExclusiveAndWake).

  2. Unterbrechung, die der Schaltfläche "Windows" entspricht

     Die Windows-Schaltfläche muss weckfähig sein (ExclusiveAndWake).

  3. Interrupt-Signal entsprechend der Taste "Lauter"

     Die "Lauter"-Taste darf nicht zum Aufwecken genutzt werden (muss exklusiv verwendet werden).

  4. Interrupt, der der Schaltfläche "Leiser" entspricht

     Die Taste "Leiser" darf nicht aufweckbar sein (muss ausschließlich verwendet werden).

  5. Interrupt für die Schaltfläche "Drehungssperre", wenn unterstützt

     Die Schaltfläche "Drehungssperre" darf nicht fähig sein, das Gerät zu aktivieren (muss im exklusiven Modus verwendet werden).

Weitere Informationen finden Sie unter Hardware-Tasten für Windows 8-Tablets und Convertibles.

Um die Entwicklung der Windows-Schaltflächen-UI zu unterstützen, definiert Windows eine Device-Specific-Methode (_DSM) für das Windows Button Array-Gerät. Weitere Informationen finden Sie unter Windows Button Array Device-Specific Method (_DSM).

Dock- und konvertierbare PC-Sensorgeräte

Windows unterstützt Docks und konvertible Geräte (Clamshell-/Tablet-Kombinationen) mithilfe von zwei Sensorgeräten im ACPI-Namensraum. Diese Geräte werden vom Windows-Schaltflächentreiber für den Posteingang unterstützt. Beachten Sie, dass die gleichen Anforderungen, die für das Button Array-Gerät gelten, auch für diese Geräte gelten:

• GPIO "ActiveBoth"-Unterbrechungen müssen an einen on-SoC GPIO-Controller angeschlossen werden (nicht an einen SPB-verbundenen GPIO-Controller).

• Der GPIO-Controller muss Level-Mode-Unterbrechungen und dynamische Polaritäts-Neuprogrammierung unterstützen.

• Der GPIO-Controllertreiber muss die ActiveBoth-Emulation verwenden, die von der GPIO-Frameworkerweiterung (GpioClx) bereitgestellt wird.

• Wenn der behauptete Zustand ("Docked" oder "Converted") nicht auf Logikniveau niedrig ist, ist die _DSM-Methode des GPIO-Controllers erforderlich, um das Standardverhalten des GPIO-Treiberstapels zu überschreiben. Weitere Informationen finden Sie im Abschnitt " GPIO-Controllergeräte " im Thema " Allgemeine I/O(GPIO) ".

Weitere Informationen finden Sie unter Hardwaretasten für Windows 8 Tablets und Convertibles.

Dock-Sensorgerät

Ein Dock-Sensorgerät unterbricht das System, wenn ein Dock angeschlossen oder vom System getrennt wird. Diese Modusänderungsinformationen werden verwendet, um die Benutzereingabe- und Ausgabeerfahrung nach Bedarf zu aktualisieren. Der Namespace des Geräts erfordert Folgendes:

• Ein anbieterspezifischer _HID

• Eine _CID von PNP0C70

• Eine _CRS mit einem ActiveBoth-Interrupt

  Interrupt kann nicht aufweckfähig sein.

Konvertierbares PC-Sensorgerät

Ein Convertible-PC-Erkennungsvorrichtung unterbricht das System, wenn ein konvertierbarer PC von der Tablet- zur Clamshell-Form wechselt. Diese Modusänderungsinformationen werden verwendet, um die Benutzereingabe- und Ausgabeerfahrung nach Bedarf zu aktualisieren. Der Namespace des Geräts erfordert Folgendes:

• Ein anbieterspezifischer _HID

• Eine _CID von PNP0C60

• Ein _CRS mit einem ActiveBoth-Interrupt

  Interrupt kann nicht aufweckfähig sein.