Condividi tramite

Interruttore di visualizzazione automatico

  • Articolo

Importante

Alcune informazioni riguardano un prodotto in versione preliminare che potrebbe essere modificato in modo sostanziale prima che venga rilasciato commercialmente. Microsoft non fornisce alcuna garanzia, espressa o implicita, in relazione alle informazioni fornite qui.

Questo articolo descrive la funzionalità del commutatore di visualizzazione automatico (ADS) che fornisce il supporto per il pannello interno di un portatile per passare senza problemi tra una GPU integrata (iGPU) e una GPU discreta (dGPU). ADS è una funzionalità WDDM facoltativa, supportata a partire da Windows 11, versione 24H2 update 2025.01D (WDDM 3.2).

In questo articolo:

  • GPU0 fa riferimento alla GPU a cui è attualmente connesso il pannello integrato.
  • GPU1 fa riferimento alla GPU a cui deve essere passato il pannello.

Panoramica

Alcuni portatili rilasciati hanno un dispositivo multiplexer (mux) che consente di passare il pannello interno tra la GPU integrata (iGPU) e la GPU discreta (dGPU). Il driver grafico attualmente attiva ed esegue il commutatore in questi portatili senza alcuna conoscenza del sistema operativo, che porta ad alcune esperienze utente indesiderate.

ADS consente al sistema operativo di controllare l'uso di un dispositivo mux nel sistema per passare tra le schede grafiche iGPU e dGPU durante la trasmissione allo schermo interno. Di conseguenza, il sistema operativo può offrire un'esperienza utente migliore.

Nella versione iniziale di ADS, è supportato solo il passaggio del pannello interno tra iGPU e dGPU. In futuro, questa funzionalità potrebbe essere espansa per supportare anche il multiplexing di connettori esterni nei portatili.

Progettazione ad alto livello

In generale, il sistema deve garantire che il contenuto del pannello interno venga visualizzato senza alcun sfarfallio o glitch mentre è in corso la commutazione. Il sistema operativo non limita questa funzionalità a un particolare protocollo di visualizzazione. Questo articolo è incentrato su come implementare ADS con eDP, ma esistono più standard di settore che possono essere usati (ad esempio, MIPI o DSI). La progettazione di una piattaforma è libera di utilizzare un altro protocollo di connessione dello schermo se può ottenere la stessa esperienza senza altre modifiche al sistema operativo.

Le sottosezioni all'interno di questa sezione identificano gli aspetti di progettazione della funzionalità e illustrano in dettaglio l'approccio di alto livello per ogni aspetto.

Controllo del dispositivo mux

Per ridurre le dipendenze tra i driver grafici iGPU e dGPU, il mux viene esposto come dispositivo separato che il sistema operativo può controllare indipendentemente dai driver di grafica. I vantaggi di questo approccio sono:

  1. Riduce la complessità del driver grafico perché il driver non deve sapere come controllare ogni mux diverso che un OEM potrebbe usare.
  2. Riduce o elimina le dipendenze tra i driver grafici, riducendo gli aggiornamenti dei driver e semplificando la selezione di GPU e mux da parte degli OEM.
  3. Il sistema operativo può cambiare il mux quando un driver di grafica non è disponibile.

Esposizione del dispositivo mux

Poiché questa soluzione è per il muxing tra iGPU interne e dGPU, è sensato esporre il mux tramite ACPI.

Funzionalità del driver mux

Il driver mux deve soddisfare i requisiti funzionali di alto livello seguenti:

  1. Deve fornire lo stato del mux, la destinazione che attualmente controlla il pannello interno e qualsiasi limite di funzionalità.
  2. Deve fornire un modo per attivare un'opzione e segnalare lo stato dell'opzione.

Per ulteriori informazioni sul dispositivo mux ACPI e sui relativi metodi, vedere ACPI.

Per eseguire una commutazione senza interruzioni, il dispositivo mux richiede le condizioni seguenti in ogni momento durante la commutazione GPU.

  1. Alimentazione del pannello. In qualsiasi momento, il mux richiede che l'alimentazione del pannello venga fornita da una delle GPU. È possibile che entrambe le GPU forniscano la potenza del pannello contemporaneamente.
  2. I segnali di controllo della luminosità sono abilitati da tutte e due le GPU quando si effettua lo switching.
  3. Livello di luminosità (modulato in ampiezza di impulso) da entrambe le GPU durante la commutazione.

Il mux sposta le informazioni seguenti tra le due GPU e il pannello:

  1. Segnale di controllo abilitato alla gestione della luminosità
  2. Livello di luminosità (modulazione a larghezza di impulso)
  3. Linea Aux DisplayPort (DP)
  4. Linea HPD (Hot Plug Detection)
  5. Linea dati DP

Il mux deve essere in grado di commutare quando il pannello non è attivo. Almeno durante la commutazione del pannello interno, il mux non dovrebbe attivare alcun segnale HPD alla GPU.

Il driver GPU non deve mai chiamare i metodi ACPI mux.

Commutatore di visualizzazione automatico DDI

Vengono aggiunte diverse DDI per soddisfare i requisiti del multiplexer. Esistono cinque diversi punti in cui il sistema operativo richiama le DDI di un driver durante una commutazione mux, utilizzando le funzioni seguenti. Le varie chiamate dipendono dalla fase del commutatore e dal fatto che il driver controlli la GPU che attualmente ha il controllo dello schermo.

DDI Descrizione
DxgkDdiDisplayMuxPreSwitchAway Chiamata al driver attualmente connesso allo schermo. Questa chiamata informa il driver che il sistema sta pianificando di trasferire la visualizzazione a un'altra GPU (da GPU0 a GPU1).
DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData Chiamare per raccogliere tutti i dati del commutatore privato dal driver attualmente connesso al pannello (da GPU0).
DxgkDdiDisplayMuxPreSwitchTo Chiamare il driver attualmente non connesso allo schermo. Questa chiamata informa il driver che il sistema operativo sta pianificando di passare la visualizzazione a questa GPU (a GPU1).
DxgkDdiDisplayMuxSwitchAnnullato Chiamare l'autista per indicare che la sequenza di commutazione è stata annullata prima che fosse completata.
DxgkDdiDisplayMuxPostSwitchAway L'opzione mux è completa e il driver della GPU0 non è più connesso allo schermo.
dxgkDdiDisplayMuxPostSwitchToPhase1 Il commutatore mux è stato completato e il driver di GPU1 è ora connesso allo schermo. Questo driver dovrebbe ora eseguire le attività della fase 1.
DxgkDdiDisplayMuxPostSwitchToPhase2 L'interruttore mux è adesso completo, e il driver del GPU1 è ora connesso allo schermo. Questo driver dovrebbe ora eseguire attività della fase 2.
DxgkDdiDisplayMuxUpdateState Chiamato all'avvio dell'adattatore per tornare allo stato di alimentazione D0 e informare il driver dello stato corrente del mux.

Ci sono azioni esplicite che il conducente deve completare in ogni fase. Queste azioni sono descritte più avanti in questo articolo.

Per un elenco completo degli aggiornamenti DDI correlati ad ADS, vedere modifiche DDI WDDM per il cambio di visualizzazione automatica.

Condivisione dei dati tra GPU0 e GPU1

In alcuni casi è possibile creare un'esperienza utente migliore quando:

  • GPU0 e GPU1 provengono dallo stesso IHV.
  • GPU0 può passare informazioni a GPU1 relative alla configurazione dello schermo opaca al sistema operativo.

Un BLOB di dati viene descritto da un GUID che il driver di GPU1 può identificare rapidamente se riconosce il BLOB di dati. A livello generale, il sistema operativo chiama GPU0 per ottenere il GUID del BLOB e i dati prima dello switch e li passa a GPU1 prima che venga richiesto l'HPD nel display.

Il driver di GPU1 è responsabile di:

  • Verificando che sia compreso il GUID del BLOB.
  • Convalidare ogni elemento di dati nel BLOB per evitare effetti dannosi di dati malformati nel BLOB.

Interoperabilità dei driver

Se un driver WDDM supporta ADS, deve supportare ADS indipendentemente dal sistema OEM su cui è in esecuzione o sull'altra GPU nel sistema.

Sequenza di commutazione

Anche se potrebbe essere tecnicamente possibile passare da una GPU quando viene arrestato il driver della GPU, questo scenario non è attualmente supportato. Di conseguenza, la commutazione viene effettuata solo quando entrambe le GPU hanno i driver caricati che supportano il DDI di commutazione.

La sequenza seguente è una visualizzazione generale dell'intera sequenza di switch quando il pannello è attivo, dove GPU0 e GPU1 rappresentano rispettivamente iGPU e dGPU. GPU0 è attualmente connesso al pannello interno tramite il mux e si vuole passare alla scansione GPU1 al pannello.

  1. Viene eseguita una chiamata switch a livello di API.
  2. Il sistema operativo raccoglie gli attributi dello stato del pannello interno corrente (HDR, modalità, frequenza di aggiornamento e così via) e verifica la modalità di visualizzazione temporanea.
  3. Il sistema operativo disabilita qualsiasi modifica alla topologia di visualizzazione a causa degli HPD provenienti da qualsiasi GPU nel sistema.
  4. Il sistema operativo chiama il driver GPU1 DxgkDdiDisplayMuxPreSwitchTo, passando il livello di luminosità corrente. Il conducente deve eseguire le operazioni seguenti solo se il coperchio è aperto:
    • Accendere l'alimentazione al pannello.
    • Impostare il segnale di attivazione della luminosità.
    • Impostare il livello di luminosità fornito dal sistema operativo.
  5. Il sistema operativo disabilita la chiamata DxgkDdiQueryConnectionChange su GPU0 per garantire che il segnale HPD del coperchio non possa essere elaborato fino a dopo il completamento del commutatore mux.
  6. Il sistema operativo chiama il driver GPU0 DxgkDdiDisplayMuxPreSwitchAway DDI. L'autista deve:
    • Se il coperchio è attivo, abilitare PSR1 (pannello auto refresh 1) nel pannello e assicurarsi che non sia disabilitato fino a quando il sistema operativo non ne richiede la disabilitazione più avanti nella sequenza.
    • Aggiungere un pacchetto all'elenco delle modifiche di connessione con DXGK_CONNECTION_CHANGEConnectionStatus impostato su MonitorStatusDisconnected e MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange impostato su 1.
    • GPU0 non può aggiungere pacchetti di modifica della connessione per l'obiettivo del coperchio nella sua coda. Il bug del sistema operativo controlla se funziona correttamente.
    • Restituire la dimensione di qualsiasi BLOB di dati ADS privato (GUID e dati) al sistema operativo. Se il driver GPU0 fallisce in questa chiamata, deve assicurarsi che tutti i pacchetti di stato della connessione ADS inseriti nella coda siano rimossi prima di tornare indietro.
  7. Se il driver di GPU0 ha restituito una dimensione di dati privata diversa da zero, il sistema operativo alloca tale dimensione e la passa al DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData callback per ottenere i dati del commutatore privato.
  8. Il sistema operativo chiama il metodo ACPI del mux per passare da GPU0 a GPU1.
  9. Il sistema operativo consente di richiamare nuovamente la funzione DxgkDdiQueryConnectionChange di GPU0.
  10. Il sistema operativo chiama DxgkDdiQueryConnectionChanges di GPU0 per elaborare il pacchetto di connessione MonitorStatusDisconnected con DisplayMuxConnectionChange impostato su 1.
  11. Il sistema operativo chiama dxgkddiSettimingsfromvidpn per disattivare il percorso dello schermo dal quale si sta passando. Il driver di GPU0 deve:
    • Spegnere l'alimentazione del pannello.
    • Disabilitare il segnale di luminosità.
    • Interrompere l'invio del livello di luminosità al mux.
  12. Il sistema operativo elabora lo spegnimento del display. Non attiva una modifica della topologia per evitare modifiche non necessarie alla topologia.
  13. Il sistema operativo chiama il callback DxgkDdiDisplayMuxPostSwitchToPhase1 di GPU1, passando qualsiasi blob privato ADS ottenuto da GPU0. L'autista deve:
    • Determinare se il coperchio è aperto o chiuso.
    • Aggiungere il pacchetto all'elenco delle modifiche di connessione con DXGK_CONNECTION_CHANGE:Add the packet to its connection change list with DXGK_CONNECTION_CHANGE's:
      • MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange bit impostato.
      • ConnectionStatus impostato su MonitorStatusConnected se il coperchio è aperto o MonitorStatusDisconnected se il coperchio è chiuso.
    • Se il coperchio è chiuso, spegni l'alimentazione e disattiva il segnale di luminosità abilitato per il pannello.
  14. Se il sistema operativo non ha ancora chiamato DxgkDdiQueryAdapterInfo con DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 per la destinazione interna di GPU1, lo fa. In seguito a questa chiamata, il sistema operativo chiama anche DxgkDdiQueryDeviceDescriptor.
  15. L'OS chiama DxgkDdiQueryConnectionChange di GPU1 per elaborare l'evento nell'elenco delle modifiche di connessione. Questa chiamata comporta che DxgkDdiQueryDeviceDescriptor venga chiamato per il nuovo monitor appena rilevato tramite HPD.
  16. Il sistema operativo consente modifiche della topologia del display in seguito agli HPDs.
  17. Il sistema operativo elabora in modo asincrono i pacchetti di connessione da GPU0 e GPU1 con DisplayMuxConnectionChange impostato su 1.
  18. Se GPU1 ha accodato MonitorStatusConnected:
    • Il sistema operativo chiama le funzioni DWM di GPU1 per enumerare le modalità.
    • DxgkddiSettimingsfromvidpn viene chiamato su GPU1 per attivare il percorso di visualizzazione.
    • DWM esegue il rendering e presenta il frame al percorso di visualizzazione in GPU1.
    • Il sistema operativo attende che il primo fotogramma venga reso visibile.
  19. Il sistema operativo chiama il callback DxgkDdiDisplayMuxPostSwitchToPhase2 di GPU1, dove il driver deve disattivare PSR1 per lo schermo se MonitorStatusConnected è stato accodato da GPU1; in caso contrario, non deve fare nulla.
  20. Il sistema operativo chiama il DxgkDdiDisplayMuxPreSwitchAway di GPU0. Anche se non ci sono azioni attese dal driver, questa chiamata è utile per qualsiasi pulizia o contabilità del driver correlata alla commutazione.
  21. Il sistema operativo raccoglie gli attributi dello stato del pannello interno corrente. Se lo stato del pannello è diverso da quello salvato in precedenza, il sistema operativo attiva i dati di telemetria.

Questa sequenza di commutatori è la stessa per iGPU->dGPU e dGPU->iGPU. Potrebbero esserci casi in cui cambiare il mux quando il pannello è inattivo. In tal caso, questa sequenza non è necessaria e il sistema operativo può semplicemente chiamare i metodi ACPI sul mux per commutare.

La maggior parte del sistema operativo non sa che il driver è in modalità PSR. Di conseguenza, il driver deve comunque generare sincronizzazioni Vsync, segnalare i flip come completati e così via, anche se l'utente non vede questi eventi.

Processo di ripristino

Se si verifica un errore durante qualsiasi fase della sequenza di commutazione, viene eseguita la pulizia seguente:

  1. Il sistema operativo chiama DxgkDdiDisplayMuxSwitchCanceled se è stata correttamente chiamata la funzione DxgkDdiDisplayMuxPreSwitchAway della GPU0, ma non è stata chiamata la funzioneDxgkDdiDisplayMuxPostSwitchAway.
  2. Il sistema operativo chiama la funzione DxgkDdiDisplayMuxSwitchCanceled di GPU1 se la funzione DxgkDdiDisplayMuxPreSwitchTo è stata chiamata correttamente, ma la funzione DxgkDdiDisplayMuxPostSwitchToPhase2 di GPU1 non è stata chiamata.
  3. Il sistema operativo riattiva le modifiche alla topologia dello schermo se sono disabilitate.
  4. Il sistema operativo riabilita la chiamata DxgkDdiQueryConnectionChange su GPU0 se disabilitata.
  5. Il sistema operativo esegue il polling della connettività del coperchio sulla GPU a cui il coperchio è connesso.
  6. Il sistema operativo attiva una reimpostazione della configurazione di visualizzazione (SDC) impostata. Il driver che ha il pannello collegato tramite il mux (ottenuto da DxgkDdiDisplayMuxSwitchCanceled) deve assicurarsi che PSR sia disabilitato.

Eventi insoliti che possono verificarsi durante il cambio

  • L'utente collega cavi esterni o scollega un monitor.

    Come parte della sequenza di switch, disabilitiamo l'elaborazione degli eventi HPD del sistema operativo. In questo modo, qualsiasi HPD è accodato ed elaborato insieme al coperchio in un'unica operazione atomica.

  • Un'altra app chiama SDC durante il passaggio

    Mentre l'opzione è in corso, le chiamate a SDC vengono bloccate e verranno eseguite dopo l'elaborazione dell'opzione.

  • Il driver viene disabilitato durante la commutazione

    Quando un driver viene arrestato, le chiamate nella sequenza switch hanno esito negativo e la sequenza di ripristino viene attivata. La sezione PnPStop spiega anche come garantisce che lo schermo sia sempre visibile.

Scenari di chiusura del coperchio

Il driver in genere potrebbe usare uno degli approcci seguenti per rilevare gli eventi di apertura/chiusura del coperchio:

Tuttavia, per WDDM in generale, i driver devono usare l'approccio dxgkDdiNotifyAcpiEvent perché consente di sincronizzare Dxgkrnl stato e stato del driver. Dato che sia iGPU che dGPU possono essere GPU1 in una sequenza di commutazione, ha senso per tutti i driver ADS tenere traccia dello stato del coperchio anche quando il coperchio è spento da esso.

Dopo che il sistema operativo elabora l'evento DisplayMuxConnectionChange da GPU0, considera che GPU0 non possiede più lo stato del coperchio e quindi GPU0 non può segnalare altri pacchetti di stato di connessione per tale destinazione fino a quando il coperchio non viene riportato allo stato precedente. Se gpu0 lo fa, il sistema operativo verificherà bug. Quando il sistema operativo elabora il DisplayMuxConnectionChange da GPU1, considera GPU1 come proprietario dello stato del coperchio. Qualsiasi evento di apertura o chiusura del coperchio può essere ignorato tra questi due eventi perché GPU1 dovrebbe conoscere lo stato del coperchio e segnalare il DisplayMuxConnectionChange pacchetto corretto.

Quando il sistema operativo considera che il driver è proprietario del pannello

La tabella seguente descrive le fasi della sequenza in cui il sistema operativo considera una GPU proprietaria del pannello. La GPU proprietaria può segnalare modifiche connettive usando la sequenza di commutatori. I numeri di passaggio provengono dalla sequenza di commutazione descritta in precedenza.

Tirocinio da fase a Quale GPU controlla il pannello
Prima del cambiamento Passaggio 5 GPU0
Passaggio 6 Passaggio 12 Nessuna GPU
Passaggio 13 Dopo il passaggio GPU1

Il bug del sistema operativo controlla se c'è un pacchetto di modifica della connessione nella coda del driver per un obiettivo multiplexer quando la GPU non controlla il pannello.

Controllo dell'auto-aggiornamento del pannello (PSR)

La funzionalità ADS usa PSR per evitare gli errori durante la transizione. In particolare, PSR1 (modalità di aggiornamento a schermo intero) viene usato in modo che GPU0 e GPU1 non debbano negoziare la modalità PSR da usare.

Anche all'interno di PSR1, sono disponibili funzionalità facoltative che il pannello deve supportare:

funzionalità sink dettagli lavandino esposto tramite
DPCD & versione eDP Abilitare eDP v1.3 o versione successiva. DPCD
Funzionalità e versione PSR Il sink supporta la versione 1. DPCD 00070h bit 7:0
Supporto VSC SDP per comunicare lo stato PSR Solo per PSR; sink supporta almeno la revisione 2 con un massimo di 8 byte validi per trasmettere lo stato PSR e il valore CRC. DPCD 170
Il sink segnala correttamente lo stato correlato a PSR Il sink deve esporre lo stato; ad esempio, errore CRC di collegamento, errore di memorizzazione RFB, stato di autorefresh del dispositivo sink, numero massimo di fotogrammi di risincronizzazione, ultima latenza effettiva di sincronizzazione nel sink e ultimo SDP PSR ricevuto. DPCD 2008h, 2009h, 200Ah rifletteranno lo stato corretto del sink.

Quando GPU1 esegue il training del collegamento come parte di una chiamata DxgkddiSettimingsfromvidpn dal sistema operativo, il driver non conosce la corsia DP e l'impostazione della larghezza di banda usata da GPU0. Pertanto, deve eseguire una sequenza completa di training del collegamento invece di un training rapido. Il sistema operativo non negozierà alcuna politica PSR tra le GPU, quindi il pannello deve supportare tutte le versioni e le funzionalità PSR che verranno usate dalle GPU. Ad esempio, il pannello deve supportare uno scenario in cui GPU0 potrebbe usare PSR2 con alcune funzionalità impostate, quindi PSR1 verrà usato per il commutatore, quindi GPU1 potrebbe usare PSR2 con un set diverso di funzionalità.

Garantire che il pannello rimanga in PSR durante il passaggio.

Quando GPU1 imposta una modalità sul pannello, non c'è garanzia che gli attributi di collegamento impostati da GPU1 mentre il pannello si trova in PSR corrispondano alla modalità di ingresso PSR. Ad esempio, la frequenza di aggiornamento o le dimensioni attive potrebbero cambiare. Oggi gli standard di settore, come il DP, non hanno un modo per il pannello di comunicare che può rimanere in modalità PSR mentre gli attributi di collegamento vengono modificati. A lungo termine, vogliamo lavorare per aggiungere questa capacità alla specifica DP. Fino a quando questo accade, per un sistema abilitato per ADS, l'OEM deve scegliere una combinazione TCon/panel/Mux che può rimanere in PSR mentre gli attributi del collegamento (ad esempio, frequenza di aggiornamento, dimensioni attive) cambiano tra due combinazioni esposte nell'EDID. Questo approccio garantisce che PSR possa essere mantenuto attivo durante il cambio.

Affinché il test di ADS HLK verifichi che il PSR venga mantenuto durante il processo di commutazione, è necessario che il sistema operativo sappia se il PSR non era attivo dopo che GPU1 ha testato la modalità. Una sfida è che non viene definito il modo in cui un pannello reagisce se non è in grado di supportare PSR nel training dei collegamenti.

Come parte di DxgkDdiDisplayMuxPostSwitchToPhase2, il driver restituisce un valore booleano in pWasPanelInPSR per informare il sistema operativo se il pannello non si trovava in PSR.

EDID del pannello interno

Affinché il sistema operativo fornisca il comportamento previsto quando si selezionano le modalità di visualizzazione e le topologie con monitor diversi connessi, sono necessarie entrambe le GPU per segnalare l'EDID/DisplayId per la visualizzazione interna. Questo requisito garantisce che il database CCD che archivia le modalità di visualizzazione e le topologie sceglierà le stesse impostazioni indipendentemente dalla GPU che controlla la visualizzazione interna.

L'EDID che i driver segnalano al sistema operativo deve essere l'EDID interrogato dal pannello usando un comando aux senza alcuna modifica.

Attualmente il sistema operativo chiamerà DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) al momento dell'avvio di un driver che segnala un pannello interno. Se il mux viene commutato da quella destinazione integrata, il driver non può comunicare con il pannello per raccogliere le informazioni necessarie. La soluzione è che quando viene avviato un driver e il mux viene commutato lontano dalla sua destinazione interna, il sistema operativo ritarda la chiamata DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) fino a quando il mux non viene prima commutato verso la destinazione interna.

Come il sistema operativo decide se la funzionalità ADS è abilitata su un sistema e se il cambio è consentito

Il sistema operativo esegue l'elenco seguente di controlli per determinare se ADS è disponibile in un sistema. Tutti i controlli devono essere veri affinché ADS sia supportato.

  1. È presente una GPU contrassegnata come ibrida integrata (DXGK_DRIVERCAPS.HybridIntegrated) che:
  2. Esiste una GPU contrassegnata come ibrida discreta (DXGK_DRIVERCAPS. HybridDiscrete) che:
  3. Il nome ACPI mux restituito dal metodo DMID ACPI dai passaggi 1 e 2 corrisponde.
  4. Il dispositivo mux ACPI ha metodi ACPI DMQU, DMCF e DMSL.
  5. Il metodo DMQU mux ACPI ha restituito il nome ACPI del target del pannello interno da una delle GPU.
  6. ADS supporta attualmente solo i sistemi con un singolo pannello interno.
  7. O:
    1. GPU0, GPU1 e ACPI Mux segnalano il supporto completo di ADS.
    2. GPU0, GPU1 e Mux ACPI segnalano tutti il supporto sperimentale o completo di ADS e la chiave del Registro di sistema EnableMDMExperimentalFeature è impostata.

Le condizioni 1 e 2 implicano che entrambi gli adattatori devono essere avviati affinché il mux sia commutato.

Controllo della qualità dell'implementazione delle funzionalità ADS

Affinché ADS fornisca un'esperienza utente ottimale, tutti i componenti seguenti devono collaborare perfettamente:

  1. Funzionalità mux di visualizzazione del sistema operativo.
  2. Metodi ACPI della piattaforma per la commutazione del mux.
  3. Funzionalità di cambio mux display nei driver iGPU e dGPU.

Per aiutare gli IHV/OEM a utilizzare codice di qualità non destinato alla distribuzione nelle versioni, è possibile esporre uno dei seguenti livelli di supporto ADS:

  • Nessun supporto: il driver non supporta alcuna funzionalità ADS.
  • Supporto per lo sviluppo: il driver supporta ADS, ma l'implementazione del driver è ancora in fase di sviluppo e non deve essere usata oltre questo scopo.
  • Supporto sperimentale: il driver supporta ADS, ma non è ancora pronto per la distribuzione. Il sistema operativo non abilita ADS per impostazione predefinita, ma può essere configurato per abilitarlo.
  • Supporto completo: il driver supporta ADS in qualità di spedizione. Il sistema operativo considera che il driver supporta ADS.

Visualizzare gli attributi che devono rimanere invariati dopo un cambio di visualizzazione.

Un interruttore del display non dovrebbe modificare nessuno dei seguenti attributi di visualizzazione:

  1. Risoluzione del desktop
  2. Percorso VidPn (inclusa la modalità di origine VidPn, la modalità di destinazione, il ridimensionamento e così via)
  3. DPI
  4. Impostazione della luce notturna
  5. Gamma
  6. Visualizzare la topologia
  7. HDR attivato/disattivato
  8. Livello bianco SDR
  9. Profilo colore
  10. Tipo di destinazione OPM del monitor
  11. Luminosità dello schermo

Corrispondenza delle capacità della GPU per un'esperienza di switch ininterrotta

Per offrire all'utente un'esperienza di passaggio senza interruzioni, la visualizzazione deve essere configurata nello stesso modo dopo il passaggio come lo era prima del passaggio. Esistono alcune funzionalità GPU che richiedono lo stesso supporto per ottenere questo comportamento. Ad esempio, se una GPU supporta HDR e l'altra no, un passaggio da una GPU all'altra mentre HDR è abilitato non sarebbe senza interruzioni.

La tabella seguente elenca le funzionalità e le funzionalità di visualizzazione della GPU e descrive i requisiti di allineamento tra le due GPU.

funzionalità GPU richieste per avere un supporto fluido
HDR Se il pannello supporta HDR, allora entrambe le GPU devono o supportare HDR fp16 o non supportare HDR.
Cursore Hw No. Il sistema operativo si adatta a diverse funzionalità del cursore senza interruzioni visibili per l'utente.
MPO No. Il sistema operativo si adatta a diverse funzionalità MPO senza interruzioni visibili per l'utente.
PSR Entrambe le GPU devono supportare questa funzionalità.
EDID/DisplayID Entrambe le GPU devono esporre lo stesso EDID/DisplayId.
Limiti di luminosità Entrambe le GPU devono supportare la stessa interfaccia di luminosità e i limiti di luminosità.
Livelli di luminosità Entrambe le GPU devono esporre gli stessi livelli di luminosità e gli stessi intervalli.
Risoluzione Entrambe le GPU devono supportare le stesse modalità di origine e la risoluzione di destinazione.
Frequenza di aggiornamento Per dettagli, vedere il problema se GPU1 non supporta la frequenza di aggiornamento con cui GPU0 esegue il pannello in.
Frequenza di aggiornamento dinamico No. Il sistema operativo si adatta al supporto della frequenza di aggiornamento virtuale diverso.
Frequenza di aggiornamento variabile Per dettagli, vedere il problema se GPU1 non supporta la frequenza di aggiornamento con cui GPU0 esegue il pannello in.

Problema se GPU1 non supporta la frequenza di aggiornamento alla quale GPU0 gestisce il pannello

Se GPU1 non supporta la stessa modalità di GPU0, è probabile che la modalità ridotta venga archiviata nel database della topologia di visualizzazione. Quindi, quando il sistema torna a GPU0, verrà impostata la modalità ridotta. Ad esempio, se GPU0 supporta 120Hz ma GPU1 supporta solo 60Hz, la sequenza seguente potrebbe verificarsi:

  1. Il sistema è configurato in modo che GPU0 controlli lo schermo e la modalità è di 120Hz.
  2. L'utente passa manualmente a GPU1.
  3. Il database della topologia di visualizzazione ha 120Hz archiviato per lo schermo, ma GPU1 non lo supporta, quindi il sistema operativo sceglie 60Hz.
  4. 60Hz viene impostato e archiviato nel database della topologia di visualizzazione.
  5. L'utente torna manualmente a GPU0.
  6. Il display legge 60Hz dal database della topologia.

Per offrire un'esperienza ottimale, un OEM deve selezionare un iGPU e una dGPU che supportano entrambi la frequenza di aggiornamento massima del pannello interno. Se non è possibile e una GPU non è in grado di supportare la frequenza di aggiornamento massima del pannello, la GPU che supporta la frequenza di aggiornamento del pannello deve supportare la funzionalità Frequenza di aggiornamento dinamico di Windows con intervalli che includono:

  • Frequenza di aggiornamento più elevata dell'altra GPU.
  • Frequenza di aggiornamento massima del pannello interno.

Ad esempio, se il pannello può supportare 300Hz e iGPU può supportare solo 60Hz, la dGPU deve supportare VRR con un intervallo di almeno 60Hz a 300Hz.

Per riepilogare, il requisito ADS per la frequenza di aggiornamento è:

  1. iGPU e dGPU supportano la frequenza di aggiornamento massima del pannello interno.
  2. La GPU che supporta la frequenza di aggiornamento massima del pannello interno deve supportare il DRR con un intervallo che va dalla frequenza di aggiornamento più elevata che l'altra GPU può supportare alla frequenza di aggiornamento massima del pannello interno.

HDR e Dolby Vision

Il sistema operativo imposta lo stesso stato HDR/Dolby vision sul pannello interno della GPU1 dopo il passaggio, come era impostato sul pannello interno della GPU0 prima del passaggio. L'utente non deve notare alcuna modifica.

Luce notturna

La luce notturna viene implementata tramite DDI gamma WDDM o matrice di colori. In entrambi questi casi, il sistema operativo imposta gli stessi livelli di illuminazione notturna tramite GPU1 dopo la commutazione, così come faceva con GPU0 prima della commutazione.

Profilo colore

Il sistema operativo applica lo stesso profilo di colore al pannello dopo il cambio come era applicato prima del cambio.

Visualizzazione della schermata di controllo dei bug

Attualmente il sistema operativo supporta la visualizzazione della schermata di controllo dei bug nei dispositivi non POST. Quando si verifica un controllo dei bug, il sistema operativo:

  • Non cambia il mux.
  • Usa il supporto del sistema operativo corrente per visualizzare la schermata di controllo dei bug.

Quando si valutano potenziali target per visualizzare il bug check, il sistema operativo ignora qualsiasi target connesso a un mux che è stato commutato su un altro target.

C'è un piccolo periodo di tempo in cui l'HPD separato dalla GPU0 è stato elaborato, ma l'HPD proveniente da GPU1 non è ancora completamente elaborato. Se si verifica una verifica degli errori durante questo periodo, l'utente non la vedrà. Se si verifica una verifica del bug nel breve lasso di tempo in cui PSR è ancora attivata, il driver che controlla lo schermo deve assicurarsi che il pannello non sia in modalità PSR quando il sistema operativo chiama DxgkDdiSystemDisplayEnable.

Algoritmo di luminosità adattiva basato sui contenuti

In un mondo ideale, l'algoritmo adattivo del contenuto usato da entrambe le GPU dovrebbe produrre lo stesso effetto. Tuttavia, lo stesso effetto probabilmente non si verificherà e l'utente potrebbe notare una differenza quando il pannello interno viene commutato.

Dati di luminosità

Per assicurarsi che l'utente non noti una modifica della luminosità a causa del commutatore, tutti gli attributi di luminosità esposti da GPU0 e GPU1 devono essere identici. Questo requisito garantisce che qualsiasi livello di luminosità prima del passaggio di GPU0 sarà supportato su GPU1 dopo il passaggio.

A tale scopo, i driver per GPU0 e GPU1 devono:

  1. Usare la stessa interfaccia di luminosità, DXGK_BRIGHTNESS_INTERFACE_2 o DXGK_BRIGHTNESS_INTERFACE_3, dove è altamente consigliata la versione 3.
  2. Per l'interfaccia della luminosità v3, entrambi i driver devono esporre la luminosità basata su nits o non calibrata.
  3. Per l'interfaccia della luminosità v2, entrambi i driver devono restituire esattamente gli stessi livelli di luminosità possibili da GetPossibleBrightness.
  4. Per l'interfaccia di luminosità v3, entrambi i driver devono restituire esattamente gli stessi intervalli; cioè, ogni driver deve restituire strutture DXGK_BRIGHTNESS_GET_NIT_RANGES_OUT identiche da GetNitRanges.
  5. Le tabelle interne usate dal driver per convertire i livelli di luminosità forniti dal sistema operativo in impostazioni specifiche del pannello devono essere le stesse.

Nella maggior parte dei portatili, il driver GPU ottiene alcuni o tutti questi dati del livello di luminosità dalla piattaforma in modo non standard. Si prevede che questo scambio di dati da piattaforma a GPU possa essere espanso per ottenere questi requisiti.

Anche se viene eseguita una query sull'interfaccia della luminosità al momento dell'avvio dell'adattatore, il sistema operativo non chiamerà le DDI dell'interfaccia della luminosità fino a quando il pannello interno non è HPD (Hot Plug Detection). HPD si verifica quando il mux è passato alla GPU, così il driver può accedere all'EDID del pannello interno in quel momento.

Sappiamo che esistono modi specifici per il driver per impostare la luminosità del pannello per i pannelli che non supportano PWM. Tuttavia, questo metodo aggiunge complicazioni per il TCon in quanto potrebbe dover supportare il recupero della luminosità in un modo specifico IHV diverso a seconda della GPU connessa tramite il mux.

Configurazione di avvio del mux

Il firmware di sistema controlla la GPU connessa al pannello interno all'ora di inizio del sistema. Il sistema operativo memorizza quale GPU è stata l'ultima a controllare il pannello. Quindi, durante la sequenza di avvio, il sistema operativo commuta il mux, se necessario, in modo che la GPU corretta controlli il pannello.

Per mantenere qualsiasi immagine di avvio quando è necessario un commutatore mux, l'opzione viene eseguita solo quando:

  • Entrambe le GPU sono accese.
  • Il sistema operativo ha eseguito la transizione dalla grafica di avvio che controlla l'output a DWM/shell che controlla l'output.

Di conseguenza, il passaggio avviene dopo la chiamata alla DxgkddiSettimingsfromvidpn sulla GPU che controlla il pannello interno e l'utente noterà uno schermo bloccato mentre il pannello è in PSR durante il passaggio.

Fornire informazioni sul multiplexer al driver

Questa funzionalità è progettata intenzionalmente per fare in modo che il sistema operativo chiami il driver per fornire le informazioni anziché fornire un callback che il driver può chiamare in qualsiasi momento. Questo metodo evita che il driver si confonda se effettua una query sullo stato del sistema operativo durante una sequenza di commutazione.

Il sistema operativo chiama il driver DxgkDdiDisplayMuxUpdateState DDI per fornire al driver lo stato mux corrente nei casi seguenti:

  1. All'avvio del driver, che consente al driver di evitare sequenze di polling tempestive quando il pannello non è connesso.
  2. Di ritorno a D0 da Dx. Quando si torna da alcuni stati di alimentazione (ad esempio, ibernazione), il firmware potrebbe dover reimpostare il mux; quindi il driver non conosce lo stato.

Questi casi insieme alle normali DDI coinvolte nella sequenza di commutazione assicurano che il driver possa determinare il modo in cui un mux viene commutato in qualsiasi momento la GPU è attiva.

Nella prima versione di questa funzionalità non sono previsti piani per cambiare il mux quando il pannello interno non è attivo, quindi tutti i commutatori passeranno attraverso la stessa sequenza.

Ora di inizio dell'adapter

All'avvio, un driver deve rispondere alle richieste di polling dal sistema operativo. Il conducente potrebbe tentare di scoprire se il mux è passato a lui/lei tentando di comunicare, ma ciò potrebbe richiedere molto tempo ed essere inaffidabile. Come parte della sequenza di avvio della GPU, il sistema operativo chiama il DxgkDdiDisplayMuxUpdateState DDI per ogni destinazione connessa a un mux e indica se è passato a tale destinazione.

All'avvio, un driver deve rispondere alle richieste di polling dal sistema operativo. Il driver potrebbe tentare di scoprire se il mux è passato alla GPU comunicando con il sistema operativo, ma potrebbe richiedere molto tempo o inaffidabile.

In alternativa, come parte della sequenza di avvio della GPU, il sistema operativo chiama DxgkDdiDisplayMuxUpdateState per ogni destinazione connessa a un mux e indica se il mux è passato a tale destinazione. Il sistema operativo segnala al driver se il mux viene passato alla GPU del driver prima di chiamare eventuali DDI di polling.

Il driver ADS continua a segnalare il pannello interno al sistema operativo allo stesso modo, con il sistema operativo che chiama DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) per interrogare i dettagli interni del pannello. Il driver deve assicurarsi che DXGK_CHILD_CAPABILITIES.HpdAwareness sia impostato su HpdAwarenessInterruptible per qualsiasi obiettivo connesso a un mux.

Transizione D0

Ogni volta che una GPU con un mux connesso viene restituita allo stato acceso da uno stato a basso consumo, il sistema operativo chiama DxgkDdiDisplayMuxUpdateState per indicare al driver se il mux è connesso alla destinazione o se è passato all'altra GPU.

Sequenza di avvio

La sequenza di avvio seguente evidenzia gli aspetti specifici di ADS. In questa sequenza il sistema viene avviato con:

  • L'iGPU connessa al mux.
  • L'ultima configurazione dell'utente prima del riavvio era che il mux era connesso alla dGPU.

La sequenza di avvio è di natura asincrona, quindi questa sequenza è solo a scopo di esempio.

  1. Il sistema è acceso e l'iGPU è collegato al pannello tramite il mux.
  2. L'iGPU visualizza la schermata di avvio nel pannello.
  3. Windows carica e visualizza l'animazione d'avvio sul coperchio interno.
  4. A causa della presenza di _DEP sia nell'iGPU che nella dGPU, il driver mux del sistema operativo viene avviato prima di entrambi i driver GPU. Il driver mux usa chiamate ACPI per assicurarsi che il mux sia configurato correttamente. Il driver mux verifica che l'implementazione mux ACPI soddisfi i requisiti di ADS.
  5. Dxgkrnl chiama DxgkDdiAddDevice per l'iGPU.
  6. Dxgkrnl chiama DxgkDdiQueryInterface(DXGK_DISPLAYMUX_INTERFACE) per l'iGPU. Anche se il sistema corrente non supporta ADS, il driver restituisce l'interfaccia se supporta ADS.
  7. Dxgkrnl chiama DxgkDdiDisplayMuxGetDriverSupportLevel per ottenere il livello di supporto ADS del driver.
  8. Dxgkrnl chiama DxgkDdiDisplayMuxReportPresence(TRUE) per indicare all'iGPU che il sistema ha un mux ADS funzionante.
  9. Dxgkrnl chiama DxgkDdiStartDevice. Il driver iGPU restituisce il numero di elementi figlio, inclusa la destinazione VidPn per il pannello interno.
  10. Dxgkrnl chiama DxgkDdiDisplayMuxGetRuntimeStatus per verificare se l'iGPU supporta ADS e se il driver ha ottenuto tutte le informazioni necessarie dal sistema.
  11. Dxgkrnl chiama DxgkDdiQueryChildStatus per ogni figlio esposto dall'iGPU.
  12. Una volta Dxgkrnl trova il figlio segnalato da iGPU connesso al mux, chiama DxgkDdiDisplayMuxUpdateState per informare l'iGPU che il mux è connesso a tale destinazione.
  13. Poiché l'iGPU ha esposto un monitor interno connesso, Dxgkrnl imposta una modalità sull'iGPU usando DxgkddiSettimingsfromvidpn.
  14. Dxgkrnl avvia il driver dGPU, quindi ripete i passaggi da 5 a 12 per la dGPU.
  15. Dxgkrnl rileva che iGPU, dGPU e mux sono tutti configurati correttamente, quindi crea una coppia mux e le proprietà PnP Device Interface per la coppia mux.
  16. Dxgkrnl legge l'ultima configurazione mux dal Registro di sistema. Poiché l'ultima configurazione era dGPU, Dxgkrnl ora avvia la sequenza di commutazione del mux descritta in precedenza per passare il mux alla dGPU.

"Driver del pannello di controllo"

I driver del pannello di monitoraggio vengono caricati in base all'ID hardware PnP generato dall'EDID. Dato che l'EDID rimane invariato, il driver del pannello viene caricato quando una gpu controlla il pannello interno. Entrambi i driver espongono la stessa funzionalità di luminosità. Di conseguenza, il caricamento non dovrebbe causare alcun problema e il driver del pannello non dovrà sapere quale GPU è sotto controllo del mux.

Identificare gli obiettivi che un mux controlla

Quando il sistema operativo avvia il driver, chiama il driver DxgkDdiQueryChildRelations per interrogare le informazioni sui figli segnalati. Il driver compila la struttura DXGK_CHILD_DESCRIPTOR per ogni figlio. Il membro AcpiUid è definito come il valore restituito dal metodo _ADR sotto quel figlio nello spazio dei nomi ACPI, il quale consente al sistema operativo di trovare il nome ACPI per quel figlio.

Per ADS, definiamo un metodo DMID ACPI che deve trovarsi all'interno del namespace ACPI figlio per il target. Questo metodo DMID restituisce il nome ACPI del dispositivo mux. Consente al sistema operativo di individuare il nome mux ACPI per la destinazione.

PnP ferma l'adattatore che sta effettuando la scansione verso una destinazione

Il sistema operativo non scambierà il mux quando la GPU che invia il segnale al pannello interno viene arrestata. Gli scenari seguenti illustrano i diversi casi in cui viene arrestata una GPU.

  1. GPU0 è la postazione. È connesso al pannello interno ed è fermo.

    In questo caso, il driver di visualizzazione di base (BDD) assume la modalità attualmente attiva su GPU0 e continua ad aggiornare lo schermo.

  2. GPU0 è il post ma GPU1 è connesso al pannello interno. GPU0 è arrestata.

    A causa della progettazione attuale del sistema operativo, BDD viene avviato su GPU0, causando la segnalazione di un monitor fantasma e la sua visualizzazione nel Pannello di Controllo della visualizzazione.

  3. GPU1 non è il post ed è connesso al pannello interno. GPU1 è fermo.

    A causa della progettazione corrente del sistema operativo, BDD non viene avviato in GPU1 e quindi l'utente non sarà in grado di visualizzare il pannello.

  4. GPU1 non è il post. GPU0 è connesso al pannello interno e GPU1 viene arrestato.

    Non avviene alcun cambiamento e non accade nulla. GPU0 continua a essere visualizzato nel pannello.

Gli scenari 2 e 3 creano un'esperienza non valida per l'utente. La funzionalità ADS modifica il comportamento per risolvere questi due casi.

I plugin/GPU esterni non sono supportati

Non crediamo che ci sia un caso d'uso per questa funzionalità con GPU plug-in.

ADS è limitato solo ai singoli pannelli interni

La prima versione di ADS supporta solo pannelli interni singoli. Tuttavia, la funzionalità è progettata in modo da permettere, in futuro, il supporto del collegamento di display esterni e di più schermi interni (quando supportato dal sistema operativo) con modifiche minime ai driver.

Modifiche correnti della politica dell'adattatore POST

Il sistema operativo in precedenza aveva alcuni criteri relativi all'adattatore POST. Ad esempio, l'adattatore POST era l'unico adattatore che poteva esporre destinazioni interne. Questi tipi di restrizioni vengono rimossi dal sistema operativo con l'introduzione di ADS.

Disabilitare gli effetti visivi all'accensione del monitor

Quando un monitor è connesso in Windows 11, la shell/DWM ha una sequenza di animazione. Questa animazione è disabilitata negli scenari di cambio di visualizzazione.

Disabilitare bonk PnP

Quando un monitor viene aggiunto o rimosso, il sistema PnP riproduce un suono "bonk" per notificare all'utente. Questo "bonk" è disabilitato negli scenari di cambio dello schermo.

Notifiche dell'applicazione

Quando si verifica una commutazione del display, il sistema passa attraverso i normali percorsi di rimozione e arrivo HPD. Di conseguenza, tutte le normali notifiche dell'applicazione vengono attivate come di consueto; Ad esempio, la notifica PnP per HPD out e HPD in e i messaggi della finestra di WM_DISPLAYCHANGE.

API per attivare il switch

Il piano prevede l'uso di un'API pubblica in modo che il pannello di controllo del sistema operativo e IHV possa attivare l'opzione.

Dato che il pannello interno è sempre connesso a una singola GPU, le API di visualizzazione funzionano come previsto insieme alla funzionalità Win+P.

Test HLK

Se un driver GPU o un firmware ACPI riporta supporto completo per ADS, deve superare i test di ADS HLK su un sistema abilitato per ADS.

Pannello interno di HPDing GPU quando il mux viene spento da tale GPU

Il sistema operativo attiva un controllo di bug quando un pannello interno viene segnalato come connesso da un driver mentre quel mux è attualmente commutato via da quel driver.

Transizione AC/DC

Per la prima versione della funzionalità ADS, il sistema operativo non archivierà un'impostazione di mux AC vs DC e non attiverà un cambio mux su una transizione da <AC a> DC.

Transizioni di alimentazione del sistema

La preoccupazione principale per le transizioni di alimentazione è quando il firmware ripristina lo stato del mux (ad esempio, ibernazione) e al momento della ripresa dall'ibernazione il mux non viene commutato sul pannello a cui era impostato prima della transizione di alimentazione.

L'approccio iniziale era quello di ripristinare il mux alla dGPU dopo aver alimentato sia l'iGPU che la dGPU. Il problema di questo approccio è che, a seconda di eventi asincroni diversi, il risultato potrebbe essere più modifiche in modalità.

L'approccio aggiornato per semplificare l'esperienza utente consiste nel fare in modo che il sistema ritrasmette il mux alla destinazione prevista mentre iGPU e dGPU sono in stato di sospensione, evitando così modifiche in più modalità.

Sequenza di transizione dell'alimentazione

Nell'esempio seguente viene descritta una transizione di alimentazione in modalità ibernazione su un sistema ADS.

  1. Il sistema è configurato con mux connesso alla dGPU.
  2. Il sistema entra in ibernazione.
  3. Sia l'iGPU che la dGPU vengono trasferite allo stato di potenza D3.
  4. Il sistema si spegne.
  5. L'utente accende il sistema.
  6. Il firmware configura il mux per l'iGPU e la sequenza di avvio del display iGPU sul pannello interno.
  7. Dxgkrnl legge l'ultima configurazione mux (dGPU in questo caso) e la confronta con la posizione mux corrente usando ACPI (iGPU in questo caso). Dxgkrnl quindi chiama ACPI per passare il mux alla dGPU.
  8. Dxgkrnl effettua la transizione di iGPU a D0, quindi chiama iGPUDxgkDdiDisplayMuxUpdateState per informare il driver che il mux non è connesso.
  9. Dxgkrnl esegue la transizione della dGPU a D0, quindi richiama il DxgkDdiDisplayMuxUpdateState della dGPU per informare il driver che il mux è connesso.
  10. Dxgkrnl imposta una modalità sulla dGPU.

Tutti i sistemi in uno (AIO)

Qualsiasi sistema AIO che vuole supportare ADS deve avere il pannello interno esposto come tipo di destinazione interno su entrambe le GPU.

Dispositivo ACPI Mux

L'OEM è responsabile dell'aggiunta del dispositivo mux nello spazio dei nomi ACPI e della fornitura dei metodi necessari per il funzionamento del mux.

Il driver GPU non deve mai chiamare i metodi ACPI del mux perché il dispositivo mux potrebbe trovarsi in qualsiasi punto dell'albero ACPI. È consigliabile individuare il mux nel predecessore condiviso più vicino di entrambe le GPU.

I dispositivi mux correnti supportano solo due input e non prevediamo che i mux futuri supportino più di questo, quindi la progettazione può presupporre due input e un singolo output per ogni mux.

Il dispositivo mux non può mai essere arrestato mentre il sistema è in esecuzione. Si tratta di un dispositivo di sistema nascosto.

Metodi ACPI del dispositivo Mux

Solo lo stack di driver per un dispositivo ACPI può chiamare per valutare i metodi ACPI nel dispositivo. Pertanto, per chiamare i metodi del dispositivo mux per cambiare il mux, il sistema operativo deve avere un driver caricato per il dispositivo mux. Per questo motivo, il sistema operativo fornisce ora un driver mux di visualizzazione come driver per tutti i mux del commutatore di visualizzazione.

Per avere i metodi seguenti, è necessario un dispositivo mux:

  • _HID identifica il dispositivo mux in base all'ID hardware. Abbiamo riservato 'MSFT0005' per il mux di visualizzazione ACPI.
  • DMQU (Display Mux Query) restituisce lo stato corrente del mux.
  • DMCF (Display Mux Configure) configura il mux.

Metodo _HID (ID hardware)

argomenti :

Nessuno

restituisce:

Stringa ASCII contenente l'ID hardware, ovvero "MSFT0005".

Metodo DMQU (Display Mux Query)

In una versione futura prevediamo di aggiungere ulteriori informazioni alla query. Per abilitare query aggiuntive in futuro, Arg0 viene usato per indicare il tipo di query. Se il metodo DMQU non riconosce un tipo di query, dovrebbe fallire come non supportato.

argomenti :

Arg0: numero intero che specifica il tipo di query. Nella tabella seguente sono elencati i valori del tipo di query e i relativi significati.

Valore del tipo di query Significato
1 Interrogare lo stato attuale dell'interruttore
2 Eseguire una query sul livello di supporto di MUX ADS
3 Eseguire una query sul primo figlio GPU a cui è connesso il mux
4 Eseguire una query sulla seconda GPU figlia a cui è connesso il mux

restituisce:

Se il metodo riconosce il tipo di query specificato, deve restituire i dati appropriati, come descritto nella tabella seguente. Se il metodo non riconosce il tipo di query specificato, deve restituire una stringa vuota.

Valore del tipo di query Restituzione dei dati
1 Stringa ASCII che contiene il nome ACPI del dispositivo figlio GPU a cui è attualmente passato il mux.
2 Intero che rappresenta il livello di supporto ADS. Per informazioni dettagliate, vedere la tabella successiva.
3 Stringa ASCII che contiene il nome ACPI del primo dispositivo figlio GPU al quale è connesso il mux.
4 Stringa ASCII che contiene il nome ACPI del secondo dispositivo figlio della GPU a cui è connesso il mux.

La tabella seguente elenca i valori del livello di supporto ADS e i relativi significati quando il tipo di query è "2".

Dati restituiti Significato
0 Nessun supporto
1 Supporto per lo sviluppo. I sistemi possono essere forniti con questa impostazione senza superare alcun test HLK perché ADS verrà disabilitato per impostazione predefinita nei sistemi dei clienti.
2 Supporto sperimentale. I sistemi possono essere forniti con questa impostazione senza superare alcun test HLK perché ADS verrà disabilitato per impostazione predefinita nei sistemi dei clienti.
3 Supporto completo. ADS verrà abilitato per impostazione predefinita in questo sistema se è associato a driver di grafica completi supportati. Il sistema deve superare i test di ADS HLK per la spedizione.

Metodo DMCF (Display Mux Configure)

argomenti :

Arg0: nome ASCII del dispositivo figlio GPU ACPI verso cui il mux dovrebbe commutare.

restituisce:

Integer 0 significa esito positivo; un valore diverso da zero indica un errore. L'OEM può definire il valore diverso da zero per una diagnostica migliore.

Metodi ACPI del dispositivo GPU

Prima di avviare un driver grafico per una GPU, il sistema deve sapere se il dispositivo ACPI mux è operativo e quale sia il suo stato attuale. A tale scopo, il driver del dispositivo mux ACPI deve essere già avviato. Il sistema usa il metodo ACPI _DEP nello spazio dei nomi ACPI di ogni GPU per garantire la relazione tra dispositivi.

Se una GPU ha già un metodo _DEP, deve aggiungere il nome ACPI del dispositivo mux all'elenco delle dipendenze restituite. Se la GPU non ha già un metodo _DEP, deve aggiungerne una.

Affinché il firmware ACPI dichiari solo la dipendenza di una GPU dal mux se il sistema operativo supporta ADS, viene aggiunta una query ACPI _OSI. Il firmware ACPI può usare questa query per verificare il supporto di ADS. Le versioni del sistema operativo che supportano ADS segnalano il supporto restituendo il valore "true" al comando ACPI _OSI(“DisplayMux”).

Metodi ACPI del dispositivo figlio GPU

Per ogni destinazione connessa a un mux, il dispositivo ACPI del figlio espone un metodo ACPI che restituisce il nome ACPI del dispositivo mux a cui è connesso. Per informazioni dettagliate, vedere Identificare gli obiettivi che un mux controlla.

Metodo DMID (identificatore Display Mux)

argomenti :

Nessuno

restituisce:

Stringa ASCII che contiene il nome ACPI del dispositivo mux ACPI a cui è connessa questa uscita

Esempio

L'esempio seguente illustra come un sistema con due GPU (GPU0 e GPU1) e un mux sia configurato e gestito all'interno del framework ACPI.

  • Il nome ACPI del dispositivo mux è "SB. MUX1'.

  • Per GPU0:

    • Il nome ACPI di GPU0 è "SB. PCI0. GFX0'.
    • Espone il target VidPn 0x40f04, che segnala un valore DXGK_CHILD_DESCRIPTOR AcpiUid di 0x400.
    • Il nome del dispositivo figlio ACPI corrispondente alla destinazione connessa al mux è 'SB.PCI0.GFX0.DD1F'.
    • Il metodo ACPI _ADR in 'SB. PCI0. GFX0. DD1F' restituisce 0x400. Questo valore restituito è il modo in cui il sistema operativo riconosce che questo dispositivo ACPI corrisponde alla destinazione VidPn 0x40f04.
    • Metodo ACPI DMID in 'SB.PCI0.GFX0.DD1F' restituisce 'SB.MUX1'.

  • Per GPU1:

    • Il nome ACPI di GPU1 è "SB. PCI0. PEG0. PEGP'.
    • Espone il target VidPn 0x1103, che riporta un valore DXGK_CHILD_DESCRIPTOR.AcpiUid di 0x100.
    • Il nome del dispositivo figlio ACPI corrispondente alla destinazione connessa al mux è 'SB.PCI0.PEG0.PEGP.EDP1'.
    • Il metodo ACPI _ADR in 'SB.PCI0.PEG0.PEGP.EDP1' restituisce 0x100. Questo valore restituito è il modo in cui il sistema operativo determina che questo dispositivo ACPI corrisponde al target VidPn 0x1103.
    • Metodo ACPI DMID in 'SB. PCI0. PEG0. PEGP. EDP1" restituisce "SB. MUX1'.

  • Il sistema operativo sa che GPU0 con obiettivo 0x40f04 e GPU1 con obiettivo 0x1103 sono collegate allo stesso mux con il nome ACPI 'SB.MUX1'.

  • Se GPU1 è attualmente connesso al pannello, il sistema operativo può passare dal mux a GPU0 chiamando il metodo DMCF in 'SB. MUX1' passando "SB. PCI0. GFX0. DD1F'

Il codice di linguaggio del computer ACPI seguente riguarda le parti pertinenti dell'esempio. Lo pseudocodice per la logica della piattaforma è delimitato da <>.


DefinitionBlock
{
    Device (MUX1) // This is _SB_.MUX1
    {
        Name (_HID, "MSFT0007")  // _HID: Hardware ID

        Method (DMQU, 1, Serialized)  // DMQU: Display Mux Query
        {
            Switch (ToInteger(Arg0))
            {
                Case (1)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    If (<Mux switched to GPU0>)
                    {
                        Return ("_SB_.PCI0.GFX0.DD1F")
                    }
                    Else
                    {
                        Return ("_SB_.PCI0.PEG0.PEGP.EDP1")
                    }
                }
                Case (2) 
                {
                    Return (1)  // Mux only has developmental support
                }
                Case (3)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    Return ("_SB_.PCI0.GFX0.DD1F")
                }
                Case (4)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    Return ("_SB_.PCI0.PEG0.PEGP.EDP1")
                }

            }
            // Unknown type
            Return ("")
        }

        Method (DMCF, 1, Serialized)  // DMCF: Display Mux Configure
        {
            If (<Arg0 does not match either of the GPU children this mux is connected to>)
            {
                Return (1) // Failure, use 1 to indicate this particular failure
            }

            // Switch the mux

            If (<Mux switch was successful>)
            {
                Return (0) // Success
            }
            Else
            {
                Return (2) // Failure, use 2 to indicate this particular failure
            }
        }
    }

    Scope (_SB_.PCI0.GFX0) // ACPI Device for GPU0
    {
        Method (_DEP, 0, NotSerialized)  // _DEP: Dependency on Mux device
        {
            If (_OSI(“DisplayMux”))
            {
                Return (Package {"_SB_.MUX1"})
            }
            Else
            {
                Return (Package (0x00){})
            }
        }

        Device (DD1F) // SB.PCI0.GFX0.DD1F which is child of GPU that is connected to the Mux
        {
            Name (_ADR, 0x400)  // _ADR: Matches the AcpiUid driver reports for the target connected to mux
            Method (DMID, 0, NotSerialized)  // DMID: ACPI name of the mux this target is connected to
            {
                Return ("_SB_.MUX1")
            }
        }
    }

    Scope (_SB_.PCI0.PEG0.PEGP) // ACPI Device for GPU1
    {
        Method (_DEP, 0, NotSerialized)  // _DEP: Dependency on Mux device
        {
            If (_OSI(“DisplayMux”))
            {
                Return (Package {"_SB_.MUX1"})
            }
            Else
            {
                Return (Package (0x00){})
            }
        }

        Device (EDP1) // SB.PCI0.PEG0.PEGP.EDP1 which is child of GPU that is connected to the Mux
        {
            Name (_ADR, 0x100)  // _ADR: Matches the AcpiUid driver reports for the target connected to mux
            Method (DMID, 0, NotSerialized)  // DMID: ACPI name of the mux this target is connected to
            {
                Return ("_SB_.MUX1")
            }
        }
    }
}

Modifiche api

La funzionalità ADS aggiunge le funzionalità API pubbliche seguenti:

  1. Enumerare i dispositivi mux nel sistema.
  2. Eseguire query sul mux; ad esempio, le destinazioni a cui è connesso e la destinazione a cui è attualmente commutato.
  3. Attivare un interruttore multiplexer.
  4. Come rilevare quando il mux è stato commutato.

Enumerare i dispositivi mux nel sistema

Le applicazioni possono usare API plug and play generali per trovare interfacce di dispositivo che rappresentano un mux di visualizzazione funzionante. I componenti in modalità utente possono usare Windows.Devices.Enumeration.DeviceInformation. È possibile usare C# o C++ con queste API per enumerare i dispositivi mux.

// Display Mux device interface
// {93c33929-3180-46d3-8aab-008c84ad1e6e}
DEFINE_GUID(GUID_DEVINTERFACE_DISPLAYMUX, 0x93c33929, 0x3180, 0x46d3, 0x8a, 0xab, 0x00, 0x8c, 0x84, 0xad, 0x1e, 0x6e);

Interfaccia IDisplayMuxDevice

L'interfaccia IDisplayMuxDevice viene aggiunta per rappresentare il dispositivo mux.

Il codice seguente illustra come enumerare i dispositivi mux di visualizzazione, eseguire query sui relativi stati, cambiare la destinazione di visualizzazione attiva e reagire alle modifiche dello stato usando le API di Windows Runtime.

#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Devices.Enumeration.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.Devices.Display.Core.h>

#include <string>
#include <sstream>
#include <iomanip>
#include <windows.h>

namespace winrt
{
using namespace winrt::Windows::Foundation;
using namespace winrt::Windows::Foundation::Collections;
using namespace winrt::Windows::Devices::Enumeration;
using namespace winrt::Windows::Devices::Display;
using namespace winrt::Windows::Devices::Display::Core;
} // namespace winrt

void SwitchDisplayMuxTarget()
{
    // PnP device interface search string for Mux device interface
    std::wstring muxDeviceSelector = L"System.Devices.InterfaceClassGuid:=\"{93c33929-3180-46d3-8aab-008c84ad1e6e}\" AND System.Devices.InterfaceEnabled:=System.StructuredQueryType.Boolean#True";

    // Execute the device interface query
    winrt::DeviceInformationCollection deviceInformations = winrt::DeviceInformation::FindAllAsync(muxDeviceSelector, nullptr).get();
    if (deviceInformations.Size() == 0)
    {
        printf("No DisplayMux devices\n");
        return;
    }
    printf("%ld display mux devices found\n\n", deviceInformations.Size());

    // Only one mux in first release but here is generic code for multiple
    for (unsigned int i = 0; i < deviceInformations.Size(); i++)
    {
        printf("Display Mux device %ld :\n", i);

        // Get the device interface so we can query the info
        winrt::DeviceInformation deviceInfo = deviceInformations.GetAt(i);

        // Get the device id
        std::wstring deviceId = deviceInfo.Id().c_str();
        printf("    Device ID string : %S \n", deviceId.c_str());

        // Create the DisplayMuxDevice object
        auto displayMuxDevice = winrt::DisplayMuxDevice::FromIdAsync(deviceId).get();
        if (!displayMuxDevice)
        {
            printf("Failed to create DisplayMuxDevice object");
            continue;
        }

        // Check if DisplayMux is active
        auto displayMuxActive = displayMuxDevice.IsActive();
        printf("    DisplayMux state : %s \n", displayMuxActive ? "Active" : "Inactive");
        if (!displayMuxActive)
        {
            continue;
        }

        // Register for call back when the state of the DisplayMux changes
        UINT changeCount = 0;
        auto token = displayMuxDevice.Changed([&changeCount](auto, auto Args) -> HRESULT {
            changeCount++;
            return S_OK;
        });

        // Find targets connected to the DisplayMux and the current target
        auto targetsList = displayMuxDevice.GetAvailableMuxTargets();
        winrt::DisplayTarget currentTarget = displayMuxDevice.CurrentTarget();

        // Switch the display mux to the other target
        // NOTE SetPreferredTarget() is a sync method so use .get() to wait for the operation to complete
        printf("\n");
        if (currentTarget == targetsList.GetAt(0))
        {
            printf("DisplayMux currently connected to first target\n");
            displayMuxDevice.SetPreferredTarget(targetsList.GetAt(1)).get();
            printf("Calling SetPreferredTarget to switch DisplayMux to second target\n");
        }
        else if (currentTarget == targetsList.GetAt(1))
        {
            printf("DisplayMux currently connected to second target\n");
            displayMuxDevice.SetPreferredTarget(targetsList.GetAt(0)).get();
            printf("Calling SetPreferredTarget to switch DisplayMux to first target\n");
        }
        else
        {
            printf("Could not find current target in target list\n");
        }

        // Now read the current position
        currentTarget = displayMuxDevice.CurrentTarget();
        targetsList = displayMuxDevice.GetAvailableMuxTargets();
        if (currentTarget == targetsList.GetAt(0))
        {
            printf("DisplayMux is now currently connected to first target\n");
        }
        else if (currentTarget == targetsList.GetAt(1))
        {
            printf("DisplayMux is now currently connected to second target\n");
        }
        else
        {
            printf("Could not find current target in target list\n");
        }

        // Now unregister for change callback and display the
        displayMuxDevice.Changed(token);
        printf("DisplayMux state change callback was called %ld times\n\n", changeCount);
    }
}

Modifiche DDI WDDM per il cambio automatico della visualizzazione

Questa sezione descrive le aggiunte e le modifiche apportate a WDDM DDI per supportare ADS. Queste modifiche sono disponibili a partire da Windows 11, versione 24H2 update 2025.01D (WDDM 3.2).

Interrogazione dell'interfaccia di supporto ADS di KMD

Viene aggiunta la struttura dell'interfaccia DXGK_DISPLAYMUX_INTERFACE_2. Contiene le chiamate da sistema operativo a driver necessarie per supportare ADS versione 2. Il sistema operativo interroga l'interfaccia ADS del driver all'avvio del driver, quando il tipo di interfaccia è impostato su GUID_WDDM_INTERFACE_DISPLAYMUX_2.

(DXGK_DISPLAYMUX_INTERFACE contiene le chiamate da sistema operativo a driver necessarie per supportare la versione 1 della funzionalità ADS. Questa versione è stata usata durante la versione preliminare di ADS.

Funzioni KMD per supportare ADS

KmD implementa le funzioni seguenti per supportare ADS. Dxgkrnl ottiene l'interfaccia funzionale ADS di KMD tramite una chiamata all'interfaccia DxgkddiQueryInterfacedi KMD.

Segnalazione della funzionalità ADS da parte del conducente

Il driver riporta il livello di supporto per ADS quando il sistema operativo chiama DxgkDdiDisplayMuxGetDriverSupportLevel DDI. Se il driver non implementa l'interfaccia DXGK_DISPLAYMUX_INTERFACE, il sistema operativo considera il livello di supporto come DXGK_DISPLAYMUX_SUPPORT_LEVEL_NONE.

Il driver deve segnalare il livello di supporto ADS indipendentemente dal sistema su cui è in esecuzione. Il livello di supporto segnalato dal driver deve essere basato solo sul driver. Il driver non deve tenere conto di nessuno dei criteri seguenti quando si riporta il livello di supporto ADS.

  1. OEM del sistema.
  2. Qualsiasi altra GPU nel sistema.
  3. Presenza o meno del dispositivo mux ACPI.
  4. Presenza o meno delle voci ACPI nel nodo ACPI della GPU.

Aggiornamento per le destinazioni di report all'ora dell'adattatore di avvio

All'avvio, l'adattatore segnala tutti i propri dispositivi figlio tramite il DxgkDdiQueryChildRelations DDI. Il report include eventuali destinazioni interne connesse a un mux. Una destinazione interna include il campo DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength.

Si verifica un problema se il mux viene passato all'altra GPU all'avvio dell'adattatore. In questo caso, il driver non può comunicare con il pannello interno per eseguire una query sulle dimensioni EDID/DisplayId. Pertanto, un driver che espone l'interfaccia GUID_WDDM_INTERFACE_DISPLAYMUX_2 deve impostare DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength a zero all'avvio della scheda se il mux non è attualmente commutato alla GPU del driver. In caso contrario, il sistema operativo non riesce ad avviare l'adapter.

Il sistema operativo aggiorna le informazioni interne sulle dimensioni del descrittore interno nella prima operazione del commutatore mux.

Aggiornamento per la modifica della connessione

Come accennato in precedenza, esiste un modo specifico per ADS per segnalare lo stato interno del pannello durante una sequenza di commutazione automatica della visualizzazione. Per indicare che un pacchetto di modifica della connessione fa parte di una sequenza di commutazione ADS, il flag DisplayMuxConnectionChange viene aggiunto a DXGK_CONNECTION_MONITOR_CONNECT_FLAGS. Quando DisplayMuxConnectionChange è impostato, indica che lo MonitorStatusConnected o MonitorStatusDisconnected stato della connessioneè legato a una commutazione automatica del display.

DisplayMuxConnectionChange deve essere usato solo durante una commutazione ADS e non deve essere usato per altri scopi. Si consiglia di utilizzarlo nelle seguenti occasioni ADS:

  • Mentre il driver sta elaborando DxgkDdiDisplayMuxPreSwitchAway.

    Se il pannello interno è connesso, il driver deve aggiungere un pacchetto DXGK_CONNECTION_CHANGE alla sua lista di modifiche di connessione con DXGK_CONNECTION_CHANGE.ConnectionStatus impostato su MonitorStatusDisconnected e DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange impostato su 1. Queste impostazioni indicano al sistema operativo che il driver ha rilasciato il controllo del pannello interno.

  • Mentre il driver sta elaborando DxgkDdiDisplayMuxPostSwitchToPhase1.

    • Il driver deve prima determinare se il pannello interno è connesso.
    • Se il pannello è collegato, il driver deve aggiungere un pacchetto DXGK_CONNECTION_CHANGE al proprio elenco di modifiche di connessione con DXGK_CONNECTION_CHANGE.ConnectionStatus impostato su MonitorStatusConnected e DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange impostato su 1.
    • Se il pannello non è connesso, il driver deve aggiungere un pacchetto DXGK_CONNECTION_CHANGE all'elenco delle modifiche di connessione con DXGK_CONNECTION_CHANGE.ConnectionStatus impostato su MonitorStatusDisconnected e DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange impostato su 1.

  • Mentre il driver sta elaborando DxgkDdiDisplayMuxSwitchCanceled.

  • Nell'evento in cui viene eseguita una richiesta di polling di destinazione durante una commutazione, DisplayMuxConnectionChange deve essere impostato solo per i pacchetti di modifica della connessione aggiunti da DxgkDdiDisplayMuxPreSwitchAway, DxgkDdiDisplayMuxPostSwitchToPhase1, o DxgkDdiDisplayMuxSwitchCanceled.

Linee guida aggiornate per DxgkDdiSystemDisplayEnable

Quando viene chiamato un driver ADS DxgkDdiSystemDisplayEnable(/windows-hardware/drivers/ddi/dispmprt/nc-dispmprt-dxgkddi_system_display_enable), il driver deve assicurarsi che PSR sia disabilitato alla fine della chiamata alla DDI DxgkDdiSystemDisplayEnable.

Linee guida OEM

Esistono diversi aspetti della funzionalità ADS al di sotto del livello che il sistema operativo controlla nella piattaforma. È essenziale che gli OEM garantiscano il corretto funzionamento. L'elenco seguente riepiloga alcuni dei punti chiave che gli OEM devono prendere in considerazione:

  • Sia il driver ibrido integrato che quello ibrido discreto devono supportare ADS.
  • Il mux selezionato per la piattaforma può essere controllato tramite ACPI.
  • I metodi _HID, DMQU e DMCF del dispositivo mux e dei dispositivi ACPI figli della GPU per gli obiettivi interni sono implementati e incorporano il metodo ACPI DMID.
  • Entrambi i dispositivi ACPI delle GPU devono avere _DEP per indicare la loro dipendenza dal dispositivo ACPI del multiplexer.
  • L'interfaccia di luminosità, le maiuscole e gli intervalli esposti da entrambe le GPU corrispondono esattamente.
  • Come descritto in dettaglio nella sezione dati di luminosità, l'interfaccia della luminosità v3 è altamente consigliata rispetto all'interfaccia della luminosità v2.
  • Se viene usato un driver del pannello del monitor, il codice deve essere indipendente dalla GPU; ovvero, la stessa logica può essere usata quando una qualsiasi GPU controlla il pannello.
  • Almeno per un mux interno, l'azione di cambio del mux non deve generare un evento HPD.
  • Se l'OEM desidera disabilitare il mux in un sistema, il metodo ACPI DMQU deve restituire 0 quando viene chiamato con Arg0 impostato su 2.
  • Il mux deve essere in grado di passare da una GPU all'altra anche quando i driver sono a basso consumo. In questo caso, PSR non verrà usato.
  • Quando il mux passa da una GPU a un'altra, la luminosità del pannello deve essere mantenuta senza problemi di luminosità. Esistono diversi modi per eseguire questa operazione, inclusi i modi seguenti. L'OEM è responsabile di garantire che il sistema mantenga la luminosità tra commutatori.
    • Usa il metodo di controllo della luminosità basato su DisplayPort Aux Nits.
    • Usare un Tcon con la ricostruzione PWM per evitare eventuali problemi di luminosità.
  • Il pannello e il Tcon utilizzati possono rimanere in modalità di auto-aggiornamento (PSR1 per eDP) quando la configurazione del collegamento pre-switch e post-switch viene indicata dall'EDID ed è supportata sia da iGPU che da dGPU. Ciò include, ma non è limitato a:
    • Frequenza di aggiornamento
    • Dimensioni attive
    • Numero di corsie eDP utilizzate e larghezza di banda delle corsie
    • Impostazione eDP DSC
    • versione di eDP VSC SDP utilizzata
    • Versione e funzionalità di PSR utilizzate per scenari non switch