Partager via

Commutateur d’affichage automatique

  • Article

Important

Certaines informations concernent un produit en préversion susceptible d’être sensiblement modifié avant sa publication commerciale. Microsoft n’offre aucune garantie, expresse ou implicite, en ce qui concerne les informations fournies ici.

Cet article décrit la fonctionnalité de basculement d'affichage automatique (ADS) qui permet au panneau interne d'un ordinateur portable de basculer sans interruption entre un GPU intégré (iGPU) et un GPU discret (dGPU). ADS est une fonctionnalité WDDM facultative prise en charge à partir de Windows 11, version 24H2 update 2025.01D (WDDM 3.2).

Dans cet article :

  • GPU0 fait référence au GPU auquel le panneau intégré est actuellement connecté.
  • GPU1 fait référence au GPU vers lequel le panneau doit être basculé.

Aperçu

Certains ordinateurs portables libérés ont un appareil multiplexeur (mux) qui permet au panneau interne de basculer entre le GPU intégré (iGPU) et le GPU discret (dGPU). Le pilote graphique déclenche actuellement et effectue le commutateur dans ces ordinateurs portables sans aucune connaissance du système d’exploitation, ce qui conduit à certaines expériences utilisateur non souhaitées.

ADS permet au système d’exploitation de contrôler l’utilisation d’un dispositif mux dans le système afin de basculer entre l’iGPU et le dGPU lors de l’affichage sur le panneau interne. Par conséquent, le système d’exploitation peut offrir une meilleure expérience utilisateur.

La version initiale d’ADS prend uniquement en charge le basculement du panneau interne entre le processeur iGPU et le processeur dGPU. À l’avenir, cette fonctionnalité peut également être développée pour prendre en charge le multiplexage des connecteurs externes dans les ordinateurs portables.

Conception de haut niveau

En général, le système doit s’assurer que le contenu du panneau interne s’affiche sans scintillements ni bugs pendant que la commutation est en cours. Le système d’exploitation ne limite pas cette fonctionnalité à un protocole d’affichage particulier. Cet article se concentre sur la façon d’implémenter ADS avec eDP, mais il existe davantage de normes industrielles qui peuvent être utilisées (par exemple, MIPI ou DSI). Une conception de plateforme est libre d'utiliser un autre protocole de connexion d’affichage si elle peut obtenir la même expérience sans aucune autre modification du système d’exploitation.

Les sous-sections de cette section identifient les aspects de conception de la fonctionnalité et détaillent l’approche générale pour chaque aspect.

Contrôle de l’appareil mux

Pour réduire les dépendances entre les pilotes graphiques iGPU et dGPU, le mux est exposé en tant que périphérique distinct que le système d’exploitation peut contrôler indépendamment des pilotes graphiques. Les avantages de cette approche sont les suivants :

  1. Il réduit la complexité du pilote graphique, car le pilote n’a pas besoin de savoir comment contrôler chaque mux différent qu’un OEM peut utiliser.
  2. Il réduit ou élimine les dépendances entre les pilotes graphiques, ce qui réduit les mises à jour des pilotes et facilite la sélection des GPU et des muxes.
  3. Le système d’exploitation peut changer le mux lorsqu’un pilote graphique n’est pas disponible.

Exposition du dispositif mux

Étant donné que cette solution concerne la commutation entre l’iGPU interne et le dGPU, il est pertinent d’exposer le mux via ACPI.

Fonctionnalités du pilote mux

Le pilote mux doit répondre aux exigences fonctionnelles de haut niveau suivantes :

  1. Il doit fournir l’état du mux, le périphérique qui contrôle actuellement le panneau interne, ainsi que toutes les capacités disponibles.
  2. Il doit fournir un moyen de déclencher un commutateur et de signaler l’état du commutateur.

Pour plus d’informations sur le dispositif ACPI du mux et ses méthodes, veuillez consulter la section ACPI.

Pour effectuer une commutation transparente, le dispositif multiplexeur requiert les conditions suivantes à tout moment durant la commutation GPU :

  1. Puissance du panneau. À tout moment, le mux doit recevoir l'alimentation électrique du panneau de l’une des GPU. Il est normal que les deux GPU fournissent la puissance du panneau en même temps.
  2. Les signaux de contrôle compatibles avec la luminosité provenant des deux GPU lors du basculement.
  3. Niveau de luminosité (largeur d'impulsion modulée) des deux processeurs graphiques lors de la commutation.

Le mux bascule les informations suivantes entre les deux GPU et le panneau :

  1. Signal de contrôle activé par la luminosité
  2. Niveau de luminosité (largeur d’impulsion modulée)
  3. Ligne auxiliaire DisplayPort (DP)
  4. Ligne de détection de branchement à chaud (HPD)
  5. Ligne de données DP

Le mux doit pouvoir commuter lorsque le panneau n’est pas actif. Au moins pour le basculement du panneau interne, le mux ne doit pas déclencher de signaux HPD vers le GPU lors du basculement.

Le pilote GPU ne doit jamais appeler les méthodes ACPI de multiplexage.

Commutateur d’affichage automatique DDI

Plusieurs DDIs sont ajoutés pour répondre aux exigences de mux. Il existe cinq moments différents où l’OS appelle les DDIs d’un pilote lors d’un changement de mux, en utilisant les fonctions suivantes. Les différents appels dépendent de l’étape de la commutation et du fait que le pilote contrôle ou non le GPU qui gère actuellement l’affichage.

DDI Description
DxgkDdiDisplayMuxPreSwitchAway Appelez le pilote actuellement connecté à l'écran. Cet appel informe le pilote que le système prévoit de transférer l'affichage vers un autre GPU (de GPU0 à GPU1).
DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData Appel pour collecter toutes les données privées de commutation auprès du pilote actuellement connecté au panneau (provenant du GPU0).
DxgkDdiDisplayMuxPreSwitchTo Appelez le conducteur actuellement non connecté à l'écran. Cet appel informe le pilote que le système d’exploitation envisage de basculer l’affichage vers ce GPU (vers GPU1).
DxgkDdiDisplayMuxSwitchCanceled Contacter le conducteur pour indiquer que la séquence de commutation a été annulée avant la fin de la commutation.
DxgkDdiDisplayMuxPostSwitchAway Le commutateur mux est opérationnel et le pilote de GPU0 n’est plus connecté à l’écran.
DxgkDdiDisplayMuxPostSwitchToPhase1 La commutation du mux est terminée et le pilote du GPU1 est désormais connecté à l’affichage. Ce pilote doit maintenant effectuer des tâches de phase 1.
DxgkDdiDisplayMuxPostSwitchToPhase2 Le commutateur mux a terminé son processus et le pilote de GPU1 est maintenant connecté à l'écran. Ce pilote doit maintenant effectuer des tâches de phase 2.
DxgkDdiDisplayMuxUpdateState Appelé au démarrage de l’adaptateur et pour revenir à l’état d’alimentation D0 afin d’informer le pilote de l’état actuel du mux.

Il existe des actions explicites que le pilote doit effectuer à chaque étape. Ces actions sont décrites plus loin dans cet article.

Pour une liste complète des mises à jour DDI liées à l’ADS, veuillez consulter la section Modifications DDI WDDM pour la commutation automatique d’affichage.

Partage de données entre GPU0 et GPU1

Il peut y avoir des cas où une meilleure expérience utilisateur peut être générée quand :

  • GPU0 et GPU1 proviennent du même IHV.
  • GPU0 peut transmettre des informations à GPU1 concernant la configuration d’affichage opaque au système d’exploitation.

Un blob de données est décrit par un GUID que le pilote de GPU1 peut identifier rapidement s’il le comprend. De manière générale, le système d’exploitation appelle le GPU0 pour obtenir le GUID et les données du blob avant la commutation, puis les transmet au GPU1 avant qu’il ne soit sollicité pour le HPD sur l’affichage.

Le pilote de GPU1 est responsable des opérations suivantes :

  • Vérifier qu’il comprend le GUID du blob.
  • Validation de chaque élément de données dans l’objet blob afin d’éviter les effets néfastes des données incorrectes dans l’objet blob.

Interopérabilité des pilotes

Si un pilote WDDM prend en charge ADS, il doit prendre en charge ADS quel que soit le système OEM sur lequel il s’exécute ou l’autre GPU sur le système.

Séquence de commutateurs

Bien qu’il soit techniquement possible de se détacher d’un GPU lorsque le pilote de ce GPU est arrêté, ce scénario n’est actuellement pas supporté. Ainsi, la commutation n’est effectuée que lorsque les deux GPU disposent de pilotes chargés qui prennent en charge le DDI de commutation.

La séquence suivante est une vue générale de l’ensemble de la séquence de commutateurs lorsque le panneau est actif, où GPU0 et GPU1 représentent respectivement l’iGPU et le dGPU. GPU0 est actuellement connecté au panneau interne via le mux et nous voulons basculer vers un affichage par GPU1 sur le panneau.

  1. Un appel de commutateur est effectué au niveau de l’API.
  2. Le système d’exploitation collecte les attributs de l’état actuel du panneau interne (HDR, mode, taux d’actualisation, etc.) et recherche le mode d’affichage temporaire.
  3. Le système d’exploitation désactive l’exécution de toute topologie d’affichage en raison des HPD provenant de n’importe quel GPU du système.
  4. Le système d’exploitation appelle le pilote du GPU1 via DxgkDdiDisplayMuxPreSwitchTo, en lui transmettant le niveau de luminosité actuel. Le pilote doit effectuer les opérations suivantes uniquement si le couvercle est ouvert :
    • Activez l’alimentation sur le panneau.
    • Réglez le signal d'activation de la luminosité.
    • Définissez le niveau de luminosité transmis par le système d’exploitation.
  5. Le système d’exploitation empêche l’appel de DxgkDdiQueryConnectionChange sur le GPU0 afin de garantir que le HPD du couvercle éloigné ne puisse être traité qu’après la commutation du mux.
  6. Le système d’exploitation appelle le DDI DxgkDdiDisplayMuxPreSwitchAway du pilote du GPU0. Le pilote doit :
    • Si le couvercle est actif, activez PSR1 (l’actualisation automatique du panneau 1) sur le panneau et vérifiez qu’il n’est pas désactivé tant que le système d’exploitation n’a pas demandé la désactivation ultérieurement dans la séquence.
    • Ajouter un paquet à sa liste de changements de connexion avec DXGK_CONNECTION_CHANGE dont ConnectionStatus est défini sur MonitorStatusDisconnected et MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange défini sur 1.
    • Le GPU0 ne peut pas ajouter de paquets de changement de connexion pour la cible du couvercle dans sa file d’attente. Le système d’exploitation effectue un bug check si tel est le cas.
    • Renvoyer la taille de tout blob de données ADS privé (GUID et données) au système d’exploitation. Si le pilote GPU0 échoue cet appel, il doit s’assurer que les paquets d’état de connexion ADS qu’il a placés dans la file d’attente sont supprimés avant de retourner.
  7. Si le pilote du GPU0 a renvoyé une taille de données privées non nulle, le système d’exploitation alloue cette taille et la transmet au callback DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData du GPU0 afin d’obtenir les données privées de commutation.
  8. Le système d’exploitation appelle la méthode ACPI de mux pour passer du GPU0 au GPU1.
  9. Le système d’exploitation permet au DxgkDdiQueryConnectionChange de GPU0 d’être appelé à nouveau.
  10. Le système d’exploitation appelle DxgkDdiQueryConnectionChanges du GPU0 pour traiter le paquet de connexion MonitorStatusDisconnected dont DisplayMuxConnectionChange est défini sur 1.
  11. Le système d’exploitation appelle DxgkddiSettimingsfromvidpn du GPU0 pour désactiver le chemin de l’affichage depuis lequel la commutation est effectuée. Le pilote du GPU0 doit :
    • Éteindre le panneau électrique.
    • Désactivez le signal de luminosité.
    • Cesser d’envoyer le niveau de luminosité au mux.
  12. Le système d’exploitation traite le départ de l’affichage. Elle ne déclenche pas de modification de topologie pour éviter les modifications inutiles de topologie.
  13. Après la commutation Le pilote doit :
    • Déterminez si le couvercle est ouvert ou fermé.
    • Ajoutez le paquet à sa liste de modifications de connexion avec DXGK_CONNECTION_CHANGE' s :
      • Bit MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange activé.
      • ConnectionStatus défini sur MonitorStatusConnected si le couvercle est ouvert ou MonitorStatusDisconnected si le couvercle est fermé.
    • Si le couvercle est fermé, désactivez l’alimentation et le signal de luminosité activé pour le panneau.
  14. Si le système d’exploitation n’a pas encore appelé DxgkDdiQueryAdapterInfo avec DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 pour la cible interne du GPU1, alors il le fait. À la suite de cet appel, le système d’exploitation appelle DxgkDdiQueryDeviceDescriptor également.
  15. Le système d’exploitation appelle DxgkDdiQueryConnectionChange du GPU1 pour traiter l’événement dans sa liste de changements de connexion. Cet appel entraîne l’exécution de DxgkDdiQueryDeviceDescriptor pour le nouveau moniteur détecté par HPD.
  16. Le système d’exploitation réactive les changements de topologie d’affichage en raison des HPD.
  17. Le système d’exploitation traite de manière asynchrone les paquets de connexion à partir du GPU0 et du GPU1 avec DisplayMuxConnectionChange défini sur 1.
  18. Si le GPU1 a mis en file MonitorStatusConnected :
    • Le système d’exploitation appelle les fonctions DWM de GPU1 pour énumérer les modes.
    • DxgkddiSettimingsfromvidpn est appelé sur GPU1 pour activer le chemin d’affichage.
    • DWM restitue et présente le cadre au chemin d’affichage sur GPU1.
    • Le système d’exploitation attend que le premier frame soit rendu visible.
  19. Le système d’exploitation appelle le callback DxgkDdiDisplayMuxPostSwitchToPhase2 du GPU1, où le pilote doit désactiver le PSR1 de l’affichage si MonitorStatusConnected a été mis en file par le GPU1 ; sinon, il ne doit rien faire.
  20. Le système d’exploitation appelle DxgkDdiDisplayMuxPreSwitchAway du GPU0. Bien qu’il n’y ait pas d’actions attendues du conducteur, cet appel est utile pour tout nettoyage ou tenue de comptes lié au changement.
  21. Le système d’exploitation collecte les attributs de l’état actuel du panneau interne. Si l’état du panneau diffère de ce qui a été enregistré précédemment, le système d’exploitation déclenche la télémétrie.

Cette séquence de commutateurs est la même pour iGPU->dGPU et dGPU->iGPU. Il peut être nécessaire de changer le mux lorsque le panneau est inactif. Dans ce cas, cette séquence n’est pas nécessaire et le système d’exploitation peut simplement appeler des méthodes ACPI sur le mux pour basculer.

La plupart du système d’exploitation ne sait pas que le pilote est en mode PSR. Par conséquent, le pilote doit toujours générer des synchronisations Vsync, signaler que les flips sont terminés, et ainsi de suite, même si l'utilisateur ne voit pas ces activités.

Processus de récupération

Si une défaillance se produit pendant une étape de la séquence de commutateurs, le nettoyage suivant est effectué :

  1. Le système d’exploitation appelle DxgkDdiDisplayMuxSwitchCanceled du GPU0 si DxgkDdiDisplayMuxPreSwitchAway du GPU0 a été appelé avec succès mais que son DxgkDdiDisplayMuxPostSwitchAway n’a pas été appelé.
  2. Le système d’exploitation appelle DxgkDdiDisplayMuxSwitchCanceled du GPU1 si DxgkDdiDisplayMuxPreSwitchTo du GPU1 a été appelé avec succès mais que son DxgkDdiDisplayMuxPostSwitchToPhase2 n’a pas été appelé.
  3. Le système d’exploitation réactive les modifications de topologie d’affichage si elles sont désactivées.
  4. Le système d’exploitation réactive les appels à DxgkDdiQueryConnectionChange sur le GPU0 s’ils avaient été désactivés.
  5. Le système d’exploitation interroge la connectivité du couvercle sur le GPU auquel le couvercle est connecté.
  6. Le système d’exploitation déclenche une réinitialisation de configuration d’affichage (SDC) définie. Le pilote qui a le panneau connecté via le mux (retourné par DxgkDdiDisplayMuxSwitchCanceled) doit s’assurer que le PSR est désactivé.

Événements inhabituels qui peuvent se produire pendant la transition

  • L'utilisateur connecte ou déconnecte un moniteur externe

    Dans le cadre de la séquence de commutation, nous désactivons le traitement par le système d’exploitation des événements HPD. De cette manière, tout HPD est mis en file d’attente et traité conjointement avec l’arrivée du couvercle dans une opération atomique.

  • Une autre application appelle SDC pendant la transition

    Pendant le basculement, les appels à "SDC" sont bloqués et seront exécutés une fois que le basculement est terminé.

  • Le pilote est désactivé pendant le changement.

    Lorsqu’un pilote est arrêté, les appels de la séquence de commutation échouent et la séquence de récupération est activée. La section PnPStop explique également comment elle garantit que l’écran est toujours visible.

Scénarios de fermeture de couvercle

Le pilote peut généralement utiliser l’une des approches suivantes pour détecter les événements d’ouverture/fermeture de couvercle :

Cependant, pour WDDM en général, les pilotes doivent utiliser l’approche DxgkDdiNotifyAcpiEvent car elle permet de synchroniser l’état de Dxgkrnl avec celui du pilote. Étant donné que l’iGPU et le dGPU peuvent chacun jouer le rôle de GPU1 dans une séquence de commutation, il est pertinent que tous les pilotes ADS suivent l’état du couvercle même lorsque celui-ci est basculé hors de leur contrôle.

Une fois que le système d’exploitation traite l’événement DisplayMuxConnectionChange à partir du GPU0, il considère que GPU0 ne possède plus l’état du couvercle et par conséquent GPU0 ne peut plus signaler de paquets d’état de connexion pour cette cible tant que le couvercle n’est plus bas. Si GPU0 le fait, le système d’exploitation vérifie les bogues. Une fois que le système d’exploitation a traité l'DisplayMuxConnectionChange provenant de GPU1, il considère GPU1 comme le propriétaire de l’état du couvercle. Tous les événements d’ouverture ou de fermeture du couvercle peuvent être ignorés entre ces deux événements, car GPU1 est censé connaître l’état du couvercle et signaler le paquet DisplayMuxConnectionChange correct.

Lorsque le système d’exploitation considère que le pilote possède le panneau

Le tableau suivant décrit les étapes de séquence auxquelles le système d’exploitation considère qu’un GPU appartient au panneau. Le GPU propriétaire peut signaler des modifications connectives à l’aide de la séquence de commutateurs. Les numéros d’étape proviennent de la séquence de commutateur décrite précédemment.

Étape de départ Étape d’arrivée Quel GPU contrôle le panneau
Avant la commutation Étape 5 GPU0
Étape 6 Étape 12 Aucun GPU
Étape 13 Après le basculement GPU1

Le système d’exploitation effectue un bugcheck s’il détecte un paquet de changement de connexion dans la file d’attente du pilote pour une cible multiplexée alors que le GPU ne contrôle pas le panneau.

Rafraîchissement autonome du panneau (PSR)

La fonctionnalité ADS utilise PSR pour éviter les erreurs pendant la transition. Plus précisément, PSR1 (mode de mise à jour plein écran) est utilisé afin que GPU0 et GPU1 n’ont pas besoin de négocier le mode PSR à utiliser.

Même dans PSR1, il existe des fonctionnalités facultatives que le panneau doit prendre en charge :

Capacité du récepteur Détails Récepteur exposé via
DPCD & version eDP Exposer eDP v1.3 ou supérieur. DPCD
Capacité et version du PSR Le récepteur doit prendre en charge la version 1. DPCD 00070h bit 7:0
Prendre en charge VSC SDP pour transmettre l’état du PSR Uniquement pour le PSR ; le récepteur doit prendre en charge au minimum la révision 2 avec jusqu’à 8 octets valides pour transmettre l’état du PSR et la valeur de la CRC. DPCD 170
Le récepteur doit rapporter correctement l’état lié au PSR Le récepteur doit exposer l’état, par exemple : erreur de CRC du lien, erreur de stockage du RFB, statut du rafraîchissement autonome du dispositif récepteur, nombre maximal d’images de resynchronisation, dernière latence réelle de synchronisation dans le récepteur et dernier SDP PSR reçu. Les DPCD 2008h, 2009h, 200Ah doivent refléter l’état correct du récepteur.

Lorsque le GPU1 effectue un entraînement de liaison dans le cadre d’un appel DxgkddiSettimingsfromvidpn à partir du système d’exploitation, le pilote ne connaît pas les paramètres de la voie DP et de la bande passante utilisés par le GPU0. Il doit donc effectuer une séquence d’entraînement de liaison complète plutôt qu’un entraînement de liaison rapide. Le système d’exploitation ne négociera aucune stratégie PSR entre les GPU. Le panneau doit donc prendre en charge toutes les versions et fonctionnalités de PSR que les GPU utiliseront. Par exemple, le panneau doit prendre en charge un scénario où GPU0 peut utiliser PSR2 avec certaines fonctionnalités définies, alors PSR1 sera utilisé pour le commutateur, alors GPU1 peut utiliser PSR2 avec un autre ensemble de fonctionnalités.

S’assurer que le panneau reste en PSR pendant la transition

Lorsque GPU1 définit un mode sur le panneau, il n’existe aucune garantie que les attributs de liaison définis par GPU1 pendant que le panneau est dans PSR correspondent au mode d’entrée PSR. Par exemple, le taux d’actualisation ou la taille active peut changer. Aujourd’hui, le DP ou d’autres normes industrielles ne disposent pas d’un moyen pour que le panneau indique qu’il peut rester en PSR pendant que les attributs du lien sont modifiés. À long terme, nous voulons travailler pour obtenir cette fonctionnalité ajoutée à la spécification DP. Jusqu’à ce que cela se produise, pour un système compatible ADS, l’OEM doit choisir une combinaison TCon/panel/Mux qui peut rester dans PSR alors que les attributs de liaison (par exemple, le taux d’actualisation, la taille active) changent entre deux combinaisons exposées dans l’EDID. Cette approche garantit que le PSR peut être conservé actif pendant la transition.

Pour que le test ADS HLK vérifie que le PSR est conservé pendant le processus de basculement, nous aimerions que le système d’exploitation sache si le PSR n’était pas actif après le test de GPU1 sur le mode. Le problème est qu’il n’est pas défini comment un panneau réagira s’il ne peut pas supporter le PSR durant la formation de lien.

Dans le cadre de DxgkDdiDisplayMuxPostSwitchToPhase2, le pilote renvoie une valeur booléenne dans pWasPanelInPSR pour informer le système d’exploitation s’il a détecté que le panneau n’était pas en PSR.

EDID du panneau interne

Pour que le système d’exploitation fournisse le comportement attendu lors de la sélection des modes d’affichage et des topologies avec différents moniteurs connectés, les deux GPU sont nécessaires pour signaler l’EDID/DisplayId pour l’affichage interne. Cette exigence garantit que la base de données CCD qui stocke les modes d’affichage et les topologies sélectionne ces mêmes paramètres, quel que soit le GPU qui contrôle l’affichage interne.

L’EDID que les pilotes signalent au système d’exploitation doit être le EDID interrogé à partir du panneau à l’aide de la commande aux sans aucune modification.

Actuellement, le système d’exploitation appelle DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) lors du démarrage d’un pilote qui signale un panneau interne. Si le mux est déconnecté de cette cible intégrée, le conducteur ne peut pas communiquer avec le panneau pour collecter les informations requises. La solution consiste à ce que, lorsqu’un pilote est démarré et que le mux est basculé hors de sa cible interne, le système d’exploitation retarde l’appel à DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) jusqu’à ce que le mux soit d’abord basculé vers la cible interne.

Comment le système d’exploitation décide si la fonctionnalité ADS est activée sur un système et que le commutateur est autorisé

Le système d’exploitation effectue la liste suivante de vérifications pour déterminer si ADS est disponible sur un système. Toutes les vérifications doivent être vraies pour que ADS soit pris en charge.

  1. Il existe un GPU identifié comme hybride intégré (DXGK_DRIVERCAPS.HybridIntegrated) qui :
  2. Il y a un GPU qui est marqué comme hybride discret (DXGK_DRIVERCAPS.HybridDiscrete) qui :
  3. Le nom ACPI du mux renvoyé par la méthode ACPI DMID aux étapes 1 et 2 correspond.
  4. Le périphérique multiplexeur ACPI dispose des méthodes ACPI DMQU, DMCF et DMSL.
  5. La méthode ACPI DMQU du mux a renvoyé le nom ACPI de la cible du panneau interne provenant de l’un des GPU.
  6. ADS prend actuellement uniquement en charge les systèmes avec un seul panneau interne.
  7. Ou:
    1. GPU0, GPU1 et l’ACPI du mux indiquent tous un support complet de l’ADS.
    2. GPU0, GPU1 et Mux ACPI indiquent tous qu'ils prennent en charge soit le support ADS expérimental, soit complet, et la clé de registre EnableMDMExperimentalFeature est définie.

Les conditions 1 et 2 impliquent que les deux adaptateurs doivent être démarrés pour que le mux puisse être commuté.

Contrôle de la qualité du déploiement des fonctionnalités ADS

Pour que ADS offre une expérience utilisateur optimale, tous les composants suivants doivent fonctionner ensemble parfaitement :

  1. La fonctionnalité de mux d’affichage du système d’exploitation.
  2. Les méthodes ACPI de la plateforme pour la commutation du mux.
  3. Fonctionnalité de commutation du multiplexeur d'écran dans les pilotes iGPU et dGPU.

Pour aider les IHV/OEM à proposer du code de qualité non prêt pour la livraison dans les versions, ils peuvent exposer l’un des niveaux de support ADS suivants :

  • Aucun support : le pilote ne prend pas en charge aucune fonctionnalité ADS.
  • Prise en charge du développement : le pilote prend en charge ADS, mais son implémentation est toujours en cours de développement et ne devrait pas être utilisée à d'autres fins.
  • Support expérimental : le pilote prend en charge ADS mais n’est pas encore de qualité « ship ». Le système d’exploitation n’active pas ADS par défaut, mais peut être configuré pour l’activer.
  • Support complet : le pilote prend en charge ADS de qualité « ship ». Le système d’exploitation considère que le pilote prend en charge ADS.

Afficher les attributs qui doivent être conservés après un changement d’affichage

Un commutateur d’affichage ne doit pas modifier les attributs d’affichage suivants :

  1. Résolution de bureau
  2. Chemin VidPn (y compris le mode source VidPn, le mode cible, la mise à l’échelle, etc.)
  3. DPI
  4. Paramètre de l’éclairage nocturne
  5. Gamma
  6. Afficher la topologie
  7. HDR activé/désactivé
  8. Niveau de blanc SDR
  9. Profil de couleur
  10. Type de cible OPM du moniteur
  11. Luminosité de l’affichage

Correspondance des capacités GPU pour une expérience de basculement fluide

Pour donner à l’utilisateur une expérience de basculement fluide, l’affichage doit être configuré de la même façon après le commutateur qu’il était avant le commutateur. Il existe certaines fonctionnalités GPU dont les deux GPU ont besoin de la même prise en charge pour atteindre ce comportement. Par exemple, si une carte graphique prend en charge HDR et l’autre ne le fait pas, alors un basculement alors que HDR est activé sur une carte graphique ne serait pas sans heurt.

Le tableau suivant répertorie les fonctionnalités et fonctionnalités d’affichage GPU, et décrit les exigences d’alignement entre les deux GPU.

Fonctionnalité Les GPU doivent prendre en charge de manière transparente
HDR Si le panneau prend en charge HDR, alors les deux GPU doivent soit prendre en charge FP16 HDR, soit ne pas prendre en charge HDR.
Curseur matériel Non. Le système d’exploitation s’adapte à différentes fonctionnalités de curseur sans interruption visible à l’utilisateur.
MPO Non. Le système d’exploitation s’adapte à différentes fonctionnalités DU MPO sans interruption visible pour l’utilisateur.
PSR Les deux GPU doivent prendre en charge cette fonctionnalité.
EDID/DisplayID Les deux GPU doivent exposer le même EDID/DisplayId.
Limite de luminosité Les deux GPU doivent prendre en charge la même interface de luminosité et les mêmes limites de luminosité.
Niveaux de luminosité Les deux GPU doivent exposer les mêmes niveaux de luminosité et intervalles.
Résolution Les deux GPU doivent prendre en charge les mêmes modes source et résolution cible.
Taux d’actualisation Veuillez consulter la section Problème si le GPU1 ne prend pas en charge le taux de rafraîchissement auquel le GPU0 fait fonctionner le panneau pour plus de détails.
Taux d’actualisation dynamique Non. Le système d'exploitation s'adapte à la prise en charge de différents taux d'actualisation virtuels.
Taux d’actualisation variable Veuillez consulter la section Problème si le GPU1 ne prend pas en charge le taux de rafraîchissement auquel le GPU0 fait fonctionner le panneau pour plus de détails.

Problème si GPU1 ne prend pas en charge le taux d’actualisation sur lequel GPU0 exécute le panneau

Si GPU1 ne prend pas en charge le même mode que GPU0, le mode réduit est probablement stocké dans la base de données de topologie d’affichage. Ensuite, lorsque le système bascule vers GPU0, le mode réduit est défini. Par exemple, si GPU0 prend en charge 120Hz, mais gpu1 prend uniquement en charge 60Hz, la séquence suivante peut se produire :

  1. Le système est configuré de sorte que GPU0 contrôle l’affichage et que le mode est de 120Hz.
  2. L’utilisateur bascule manuellement vers GPU1.
  3. La base de données de topologie d’affichage a 120Hz stockée pour l’affichage, mais GPU1 ne le prend pas en charge et le système d’exploitation opte pour 60Hz.
  4. 60Hz est défini et stocké dans la base de données de topologie d’affichage.
  5. L’utilisateur bascule manuellement vers GPU0.
  6. La base de données de topologie d’affichage lit 60 Hz depuis la base de données.

Pour offrir la meilleure expérience, un OEM doit sélectionner un iGPU et un processeur dGPU qui prennent tous deux en charge le taux d’actualisation maximal du panneau interne. Si cela n’est pas possible et qu’un GPU ne peut pas prendre en charge le taux d’actualisation maximal du panneau, le GPU qui prend en charge le taux d’actualisation du panneau doit prendre en charge la fonctionnalité Taux d’actualisation dynamique Windows (DRR) avec des plages qui incluent :

  • Taux d’actualisation le plus élevé de l’autre GPU.
  • Taux d’actualisation le plus élevé du panneau interne.

Par exemple, si le panneau peut prendre en charge 300Hz et iGPU ne peut prendre en charge que 60Hz, le processeur dGPU doit prendre en charge VRR avec une plage d’au moins 60Hz à 300Hz.

Pour résumer, l’exigence ADS pour le taux d’actualisation est la suivante :

  1. Les processeurs iGPU et dGPU prennent en charge le taux d’actualisation maximal du panneau interne.
  2. Le GPU qui prend en charge le taux de rafraîchissement maximal du panneau interne doit prendre en charge le DRR avec une plage allant du taux de rafraîchissement le plus élevé que l’autre GPU peut prendre en charge au taux de rafraîchissement maximal du panneau interne.

HDR et Dolby Vision

Le système d’exploitation définit le même état HDR/Dolby Vision sur le panneau interne de GPU1 après le changement, comme cela était défini sur le panneau interne de GPU0 avant le changement. L’utilisateur ne doit pas remarquer de modifications.

Lumière nocturne

L’éclairage nocturne est implémenté via les DDIs de gamma ou de matrice de couleurs WDDM. Dans ces deux cas, le système d’exploitation définit les mêmes niveaux de veille nocturne via GPU1 après le commutateur tel qu’il l’a fait avec GPU0 avant le commutateur.

Profil de couleur

Le système d'exploitation applique le même profil de couleur au panneau après le basculement qu'avant le basculement.

Affichage de l’écran de vérification des bogues

Actuellement, le système d’exploitation prend en charge l’affichage de l’écran de vérification des bogues sur les appareils non POST. Lorsqu'une vérification des bogues se produit, le système d'exploitation :

  • Ne change pas le mux.
  • Utilise la prise en charge actuelle du système d’exploitation pour afficher l’écran de vérification des bogues.

Lors de l’évaluation des cibles potentielles pour afficher le bug check, l’OS ignore toute cible connectée à un mux qui est commuté vers une autre cible.

Il existe une courte période pendant laquelle le HPD de détachement de GPU0 a été traité, mais que le HPD d’attachement de GPU1 n’a pas encore été entièrement traité. Si un bug check se produit pendant cette période, l’utilisateur ne verra pas le bug check. Si un bug check se produit durant la courte période où le PSR est encore activé, le pilote contrôlant l’affichage doit s’assurer que le panneau n’est pas en mode PSR lorsque le système d’exploitation appelle DxgkDdiSystemDisplayEnable.

Algorithme de luminosité adaptative du contenu

Dans un monde idéal, l’algorithme adaptatif de contenu utilisé par les deux GPU doit produire le même effet. Toutefois, le même effet ne se produira probablement pas et l'utilisateur peut remarquer une différence lorsque le panneau interne est changé.

Données de luminosité

Pour vous assurer que l’utilisateur ne remarque pas de changement de luminosité en raison du commutateur, tous les attributs de luminosité exposés par GPU0 et GPU1 doivent être identiques. Cette exigence garantit que tout niveau de luminosité avant le basculement sur GPU0 sera pris en charge par GPU1 après le basculement.

Pour cela, les pilotes de GPU0 et GPU1 doivent :

  1. Utilisez la même interface de luminosité, DXGK_BRIGHTNESS_INTERFACE_2 ou DXGK_BRIGHTNESS_INTERFACE_3, où la version 3 est fortement recommandée.
  2. Pour l'interface de luminosité v3, les deux drivers doivent exposer soit une luminosité basée sur des nits, soit une luminosité non étalonnée.
  3. Pour l’interface de luminosité v2, les deux pilotes doivent renvoyer exactement les mêmes niveaux de luminosité possibles depuis GetPossibleBrightness.
  4. Pour l’interface brightness v3, les deux pilotes doivent renvoyer exactement les mêmes plages ; c’est-à-dire que chaque pilote doit renvoyer des structures identiques DXGK_BRIGHTNESS_GET_NIT_RANGES_OUT depuis GetNitRanges.
  5. Les tables internes que le pilote utilise pour convertir les niveaux de luminosité fournis par le système d’exploitation en paramètres spécifiques au panneau doivent être identiques.

Dans la plupart des ordinateurs portables, le pilote GPU obtient certaines ou toutes ces données de niveau de luminosité de la plateforme de manière non standard. Nous nous attendons à ce que cet échange de données de plateforme à GPU puisse être étendu pour atteindre ces exigences.

Bien que l’interface de luminosité soit interrogée au démarrage de l’adaptateur, le système d’exploitation n’appellera aucun des DDIs de l’interface de luminosité tant que le panneau interne n’aura pas été détecté par HPD. HPD se produit une fois que le mux est basculé vers le GPU afin que le pilote ait accès à l’EDID du panneau interne à ce moment-là.

Nous comprenons qu’il existe des méthodes spécifiques aux IHV pour que le pilote règle la luminosité du panneau lorsque celui-ci ne prend pas en charge le PWM. Cependant, cette méthode ajoute une complication pour le TCon car il pourrait devoir prendre en charge la récupération de la luminosité d’une manière spécifique à l’IHV, en fonction du GPU connecté via le mux.

Configuration de démarrage du mux

Le microprogramme système contrôle le GPU connecté au panneau interne au moment du démarrage du système. Le système d’exploitation stocke quel GPU était le dernier à avoir contrôlé le panneau. Ensuite, pendant la séquence de démarrage, le système d’exploitation bascule le mux si nécessaire afin que le GPU approprié contrôle le panneau.

Pour conserver une image de démarrage lorsqu'une commutation mux est nécessaire, elle est effectuée uniquement lorsque :

  • Les deux GPUs sont alimentés.
  • Le système d'exploitation a évolué des graphiques de démarrage contrôlant la sortie vers DWM/shell contrôlant la sortie.

Ainsi, la commutation survient après l’appel DxgkddiSettimingsfromvidpn sur le GPU qui contrôle le panneau interne, et l’utilisateur constatera un écran figé pendant que le panneau est en PSR durant la commutation.

Fournir des informations mux au pilote

Cette fonctionnalité est intentionnellement conçue pour que le système d’exploitation appelle le pilote pour fournir les informations plutôt qu’un rappel que le pilote peut appeler à tout moment. Cette méthode évite que le pilote soit confus s’il interroge l’état du système d’exploitation pendant une séquence de commutateurs.

Le système d’exploitation appelle le pilote DxgkDdiDisplayMuxUpdateState DDI pour fournir au pilote l’état actuel du mux dans les cas suivants :

  1. Au démarrage du pilote, ce qui permet d’éviter des séquences d’interrogation chronométrées lorsque le panneau n’est pas connecté.
  2. Lors du retour à D0 à partir de Dx. Lorsque vous revenez à partir de certains états d’alimentation (par exemple, veille prolongée), le microprogramme peut avoir à réinitialiser le mux ; par conséquent, le pilote ne connaît pas l’état.

Ces cas, ainsi que les DDI normaux impliqués dans la séquence de commutation, garantissent que le pilote peut déterminer de quelle manière un mux est basculé à tout moment où le GPU est actif.

Dans la première version de cette fonctionnalité, il n’existe aucun plan pour changer le mux lorsque le panneau interne n’est pas actif, de sorte que tous les commutateurs passent par la même séquence.

Heure de début de l’adaptateur

Lorsqu’un pilote démarre, il doit répondre aux demandes d’interrogation du système d’exploitation. Le pilote pourrait tenter de déterminer si le mux lui est basculé en essayant de communiquer, mais cela pourrait être long ou peu fiable. Dans le cadre de la séquence de démarrage du GPU, le système d’exploitation appelle le DDI DxgkDdiDisplayMuxUpdateState pour chaque cible connectée à un mux et indique si le mux est basculé sur cette cible.

Lorsqu’un pilote démarre, il doit répondre aux demandes d’interrogation du système d’exploitation. Le pilote peut tenter de découvrir si le mux est basculé vers son GPU en communiquant avec le système d’exploitation, mais cela peut prendre du temps ou ne pas être fiable.

Au lieu de cela, dans le cadre de la séquence de démarrage gpu, le système d’exploitation appelle DxgkDdiDisplayMuxUpdateState pour chaque cible connectée à un mux et indique si le mux est basculé vers cette cible. Le système d’exploitation informe le pilote si le mux est basculé sur le GPU du pilote avant d’appeler les DDIs d’interrogation.

Le pilote ADS continue de signaler le panneau interne au système d’exploitation de la même façon, avec le système d’exploitation appelant DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) pour interroger les détails du panneau interne. Le pilote doit s’assurer que DXGK_CHILD_CAPABILITIES.HpdAwareness est défini sur HpdAwarenessInterruptible pour toute cible connectée à un mux.

Transition vers D0

Chaque fois qu’un GPU avec un mux connecté est remis sous tension à partir d’un état de faible consommation d'énergie, le système d’exploitation appelle DxgkDdiDisplayMuxUpdateState pour indiquer au pilote si le mux est connecté à sa cible ou basculé vers l’autre GPU.

Séquence de démarrage

La séquence de démarrage suivante met en évidence des aspects spécifiques à ADS. Dans cette séquence, le système démarre avec :

  • IGPU connecté au mux.
  • La dernière configuration de l’utilisateur avant le redémarrage était que le mux était connecté au processeur dGPU.

La séquence de démarrage est asynchrone de manière naturelle, cette séquence est donc fournie uniquement à titre d'exemple.

  1. Le système est activé et l’iGPU est connecté au panneau par le biais du mux.
  2. Le processeur iGPU affiche l’écran de démarrage dans le panneau.
  3. Windows charge et affiche l’animation de démarrage sur le couvercle interne.
  4. En raison de _DEP sur l’iGPU et le dGPU, le pilote mux du système d’exploitation est démarré avant l’un ou l’autre pilote GPU. Le pilote mux utilise des appels ACPI pour s’assurer que le mux est configuré correctement. Le pilote mux vérifie que l’implémentation de mux ACPI répond aux exigences ADS.
  5. Dxgkrnl appelle DxgkDdiAddDevice pour l’iGPU.
  6. Dxgkrnl appelle DxgkDdiQueryInterface(DXGK_DISPLAYMUX_INTERFACE) pour l’iGPU. Même si le système actuel ne prend pas en charge ADS, le pilote renvoie son interface s’il la prend en charge.
  7. Dxgkrnl appelle DxgkDdiDisplayMuxGetDriverSupportLevel pour obtenir le niveau de support ADS du pilote.
  8. Dxgkrnl appelle DxgkDdiDisplayMuxReportPresence(TRUE) pour informer l'iGPU que le système dispose d’un mux ADS fonctionnel.
  9. Dxgkrnl appelle DxgkDdiStartDevice. Le pilote de l’iGPU renvoie le nombre d’enfants, y compris la cible VidPn pour le panneau interne.
  10. Dxgkrnl appelle DxgkDdiDisplayMuxGetRuntimeStatus pour vérifier si l’iGPU prend en charge ADS et si le pilote a obtenu toutes les informations requises du système.
  11. Dxgkrnl appelle DxgkDdiQueryChildStatus pour chaque enfant exposé par l’iGPU.
  12. Dès que Dxgkrnl trouve l’enfant rapporté par l’iGPU connecté au mux, il appelle DxgkDdiDisplayMuxUpdateState pour informer l’iGPU que le mux est connecté à cette cible.
  13. Parce que l’iGPU a exposé un moniteur interne connecté, Dxgkrnl configure un mode sur l’iGPU en utilisant DxgkddiSettimingsfromvidpn.
  14. Dxgkrnl démarre le pilote dGPU, puis répète les étapes 5-12 pour le dGPU.
  15. Dxgkrnl détecte que l’iGPU, le dGPU et le mux sont configurés correctement, de sorte qu’il crée une paire mux et les propriétés PnP Device Interface pour la paire mux.
  16. Dxgkrnl lit la dernière configuration de mux à partir du Registre. Étant donné que la dernière configuration était dGPU, Dxgkrnl démarre maintenant la séquence de commutateurs mux décrite précédemment pour basculer le mux vers le dGPU.

Pilotes de panneau

Les pilotes de panneaux de moniteur sont chargés en fonction de l’ID matériel PnP généré à partir de l’EDID. Étant donné que l’EDID reste le même, le pilote du panneau est chargé lorsque l’un des GPU contrôle le panneau interne. Les deux pilotes exposeront la même fonctionnalité de luminosité. Par conséquent, le chargement ne doit pas provoquer de problème et le pilote du panneau n’a pas besoin de savoir quel GPU est en contrôle du mux.

Identifier les cibles contrôlées par un mux

Lorsque le système d’exploitation démarre le pilote, il appelle DxgkDdiQueryChildRelations du pilote pour obtenir des informations sur les enfants rapportés. Le pilote remplit la structure DXGK_CHILD_DESCRIPTOR pour chaque enfant. Le membre AcpiUid est défini comme la valeur retournée par la méthode _ADR pour cet enfant dans l’espace de nommage ACPI, ce qui permet au système d’exploitation de trouver le nom ACPI de cet enfant.

Pour ADS, nous définissons une méthode ACPI DMID qui doit se trouver dans l’espace de noms ACPI de l’enfant pour la cible. Cette méthode DMID retourne le nom ACPI de l’appareil mux. Il permet au système d'exploitation de trouver le nom ACPI du mux pour la cible.

Arrêt PnP de l’adaptateur qui transmet vers une cible

Le système d’exploitation ne basculera pas le mux lorsque le GPU qui pilote le panneau interne est arrêté. Les scénarios suivants passent par les différents cas d’arrêt d’un GPU.

  1. GPU0 est le post. Il est connecté au panneau interne et est arrêté.

    Dans ce cas, le pilote d’affichage de base (BDD) prend le mode actif sur GPU0 et continue de mettre à jour l’écran.

  2. GPU0 est le post, mais GPU1 est connecté au panneau interne. GPU0 est arrêté.

    En raison de la conception actuelle du système d’exploitation, BDD est démarré sur GPU0, ce qui entraîne le signalement et l’affichage d’un moniteur fantôme dans le CPL d’affichage.

  3. GPU1 n’est pas le poste et est connecté au panneau interne. GPU1 est arrêté.

    En raison de la conception actuelle du système d’exploitation, BDD n’est pas démarré sur GPU1 et, par conséquent, l’utilisateur ne pourra pas voir le panneau.

  4. GPU1 n’est pas le post. GPU0 est connecté au panneau interne et GPU1 est arrêté.

    Aucun changement ne se produit et rien ne se passe. GPU0 continue à s’afficher sur le panneau.

Les scénarios 2 et 3 créent une mauvaise expérience pour l’utilisateur. La fonctionnalité ADS modifie le comportement pour résoudre ces deux cas.

Les GPU externes/plug-in ne sont pas pris en charge

Nous ne pensons pas qu’il existe un cas d’usage pour cette fonctionnalité avec des GPU de plug-in.

ADS est limité à des panneaux internes uniques uniquement

La première version d’ADS prend uniquement en charge des panneaux internes uniques. Toutefois, la fonctionnalité est conçue de manière à ce qu'elle puisse prendre en charge le multiplexage des affichages externes et de plusieurs affichages internes (lorsqu'ils sont pris en charge par le système d'exploitation) dans le futur, avec des modifications minimales des pilotes.

Modifications actuelles de la politique d’adaptateur POST

Le système d’exploitation avait précédemment des stratégies concernant l’adaptateur POST. Par exemple, l’adaptateur POST était le seul adaptateur qui pouvait exposer des cibles internes. Ces types de restrictions sont supprimés du système d’exploitation avec l’introduction d’ADS.

Désactiver les effets visuels d’arrivée du moniteur

Lorsqu’un moniteur est connecté dans Windows 11, l’interpréteur de commandes/DWM a une séquence d’animation. Cette animation est désactivée dans les scénarios de changement d'affichage.

Désactiver le bonk PnP

Lorsqu’un moniteur est ajouté ou supprimé, le système PnP émet un son « bonk » pour avertir l’utilisateur. Ce « bonk » est désactivé dans les scénarios de commutation d’affichage.

Notifications d’application

Lorsqu’une commutation d’affichage se produit, le système suit les chemins habituels de retrait et d’arrivée HPD. Ainsi, toutes les notifications d’application normales se déclenchent comme d’habitude ; par exemple, la notification Pnp pour le HPD de sortie et le HPD d’entrée ainsi que les messages de fenêtre WM_DISPLAYCHANGE.

API pour déclencher le commutateur

Le plan consiste à disposer d’une API publique pour que le système d’exploitation et le panneau de configuration IHV puissent déclencher le commutateur.

Étant donné que le panneau interne n’est jamais connecté à un seul GPU, les API d’affichage fonctionnent comme prévu avec la fonctionnalité Win+P.

Test HLK

Si un pilote GPU ou un microprogramme ACPI signale la prise en charge complète d’ADS, il doit passer les tests ADS HLK sur un système compatible ADS.

Détection HPD par le GPU pour le panneau interne lorsque le mux est basculé hors de ce GPU

L’OS déclenche un bug check lorsqu’un panneau interne est signalé comme connecté par un pilote alors que le mux est actuellement commuté loin de ce pilote.

Transition AC/DC

Pour la première version de la fonctionnalité ADS, le système d’exploitation ne stockera pas un paramètre de mux AC/DC et ne déclenchera pas de commutation de mux lors d'une transition de <AC à> DC.

Transitions de l’alimentation du système

La principale préoccupation lors des transitions d’alimentation est lorsque le firmware réinitialise l’état du mux (par exemple, en cas de mise en veille prolongée), et qu’au redémarrage, le mux n’est pas basculé sur le panneau qu’il était avant la transition d’alimentation.

L’approche initiale était de basculer le mux vers le processeur dGPU après avoir activé à la fois l’iGPU et le processeur dGPU. Le problème avec cette approche est que, selon différents événements asynchrones, le résultat peut être plusieurs modifications en mode.

L’approche mise à jour pour simplifier l’expérience utilisateur est que le système bascule le mux vers la cible attendue alors que l’iGPU et le dGPU sont endormis, évitant ainsi plusieurs modifications en mode.

Séquence de transition d’alimentation

L’exemple suivant décrit une transition d’alimentation en veille prolongée sur un système ADS.

  1. Le système est configuré avec mux connecté au processeur dGPU.
  2. Le système entre en veille prolongée.
  3. Les processeurs iGPU et dGPU sont passés à l’alimentation D3.
  4. Le système est éteint.
  5. L'utilisateur allume le système.
  6. Le firmware configure le mux sur l’iGPU et la séquence de démarrage de l’affichage de l’iGPU pour le panneau interne.
  7. Dxgkrnl lit la dernière configuration de mux (dGPU dans ce cas) et la compare à la position actuelle du mux à l’aide d’ACPI (iGPU dans ce cas). Dxgkrnl appelle ensuite ACPI pour basculer le mux vers le dGPU.
  8. Dxgkrnl fait passer l’iGPU en D0, puis appelle DxgkDdiDisplayMuxUpdateState de l’iGPU pour informer le pilote que le mux n’y est pas connecté.
  9. Dxgkrnl fait passer le dGPU en D0, puis appelle DxgkDdiDisplayMuxUpdateState du dGPU pour informer le pilote que le mux y est connecté.
  10. Dxgkrnl définit un mode sur le dGPU.

Tous dans un système (AIO)

Tout système AIO souhaitant prendre en charge ADS doit exposer le panneau interne en tant que type de cible interne sur les deux GPU.

Dispositif ACPI du mux

L’OEM est chargé d’ajouter l’appareil mux dans l’espace de noms ACPI et de fournir les méthodes nécessaires pour utiliser le mux.

Le pilote GPU ne doit jamais appeler les méthodes ACPI du mux, car l’appareil mux peut se trouver n’importe où dans l’arborescence ACPI. La recommandation consiste à localiser le mux sous l’ancêtre partagé le plus proche des deux GPU.

Les appareils mux actuels prennent uniquement en charge deux entrées et nous ne nous attendons pas à ce que les futurs mux prennent en charge plus que cela, de sorte que la conception peut supposer deux entrées et une seule sortie pour chaque mux.

L’appareil mux ne peut jamais être arrêté pendant l’exécution du système. C’est un dispositif système caché.

Méthodes ACPI du dispositif mux

Seule la pile de pilotes d’un dispositif ACPI peut appeler les méthodes ACPI de ce dispositif. Par conséquent, pour appeler les méthodes de l’appareil du mux afin de commuter le mux, l’OS doit disposer d’un pilote chargé pour l’appareil du mux. Pour cette raison, le système d’exploitation fournit désormais un pilote de mux d’affichage en tant que pilote pour tous les mux de commutation d’affichage.

Un appareil mux doit avoir les méthodes suivantes :

  • _HID identifie l’appareil mux par ID matériel. Nous avons réservé « MSFT0005 » pour le mux d’affichage ACPI.
  • DMQU (Display Mux Query) retourne l’état actuel du mux.
  • DMCF (Display Mux Configure) configure le mux.

Méthode _HID (ID matériel)

Arguments :

Aucun

Retours :

Chaîne ASCII contenant l’ID matériel, qui est « MSFT0005 ».

Méthode DMQU (Display Mux Query)

Dans une prochaine version, nous prévoyons d’ajouter des informations supplémentaires à interroger. Pour activer des requêtes supplémentaires à l’avenir, Arg0 est utilisé pour indiquer le type de requête. Si la méthode DMQU ne comprend pas un type de requête, elle doit échouer comme non prise en charge.

Arguments :

Arg0 : entier spécifiant le type de requête. Le tableau suivant répertorie les valeurs de type de requête et leurs significations.

Valeur du type de requête Signification
1 Interroger l’état du commutateur actuel
2 Interroger le niveau de support ADS du mux
3 Interroger le premier processus enfant du GPU auquel le mux est connecté
4 Sélectionner la deuxième carte graphique enfant à laquelle le mux est connecté

Retours :

Si la méthode comprend le type de requête spécifié, elle doit retourner les données appropriées, comme indiqué dans le tableau suivant. Si la méthode ne comprend pas le type de requête spécifié, elle doit retourner une chaîne vide.

Valeur du type de requête Retourner des données
1 Chaîne ASCII contenant le nom ACPI du périphérique enfant GPU auquel le mux est actuellement commuté.
2 Entier représentant le niveau de support ADS. Pour plus d’informations, consultez le tableau suivant.
3 Chaîne ASCII contenant le nom ACPI du premier dispositif enfant GPU auquel le mux est connecté.
4 Chaîne ASCII contenant le nom ACPI du deuxième dispositif enfant GPU auquel le mux est connecté.

Le tableau suivant répertorie les valeurs de niveau de prise en charge ADS et leurs significations lorsque le type de requête est 2.

Données retournées Signification
0 Aucune prise en charge
1 Prise en charge du développement. Les systèmes peuvent être fournis avec ce paramètre sans passer les tests HLK, car ADS est désactivé par défaut sur les systèmes clients.
2 Support expérimental. Les systèmes peuvent être fournis avec ce paramètre sans passer les tests HLK, car ADS est désactivé par défaut sur les systèmes clients.
3 Prise en charge complète. L’ADS sera activé par défaut sur ce système s’il est associé à des pilotes graphiques pleinement supportés. Le système doit passer les tests ADS HLK pour être expédié.

Méthode DMCF (Display Mux Configure)

Arguments :

Arg0: nom ASCII du périphérique enfant ACPI GPU vers lequel le mux doit basculer.

Retours :

Entier 0 signifie réussite, un nombre différent de zéro indique un échec. L’OEM peut définir la valeur non nulle pour de meilleurs diagnostics.

Méthodes ACPI d’appareil GPU

Avant le démarrage d’un pilote graphique pour un GPU, le système doit savoir si le périphérique ACPI mux fonctionne et quel est son état actuel. Pour ce faire, le pilote du périphérique multiplexer ACPI doit déjà être démarré. Le système utilise la méthode ACPI _DEP sous l'espace de noms ACPI associé à chaque GPU pour garantir la relation entre les appareils.

Si un GPU a déjà une méthode _DEP, il doit ajouter le nom ACPI de l’appareil mux à la liste de dépendance retournée. Si le GPU n’a pas encore de méthode _DEP, il doit en ajouter un.

Pour que le microprogramme ACPI déclare uniquement la dépendance d’un GPU sur le mux si le système d’exploitation prend en charge ADS, une requête ACPI _OSI est ajoutée. Le microprogramme ACPI peut utiliser cette requête pour vérifier la prise en charge d’ADS. Les versions des systèmes d'exploitation qui prennent en charge ADS indiqueront leur prise en charge en renvoyant "true" à la commande ACPI _OSI(“DisplayMux”).

Méthodes ACPI des dispositifs enfants GPU

Pour chaque cible connectée à un mux, l’appareil ACPI de cet enfant expose une méthode ACPI qui retourne le nom ACPI de l’appareil mux auquel il est connecté. Pour plus d’informations, consultez Identifier les cibles qu'un mux contrôle.

Méthode DMID (Identifiant de mux d’affichage)

Arguments :

Aucun

Retours :

Chaîne ASCII qui contient le nom ACPI de l’appareil ACPI mux auquel cette sortie est connectée

Exemple

L’exemple suivant montre comment un système avec deux GPU (GPU0 et GPU1) et un mux est configuré et géré dans l’infrastructure ACPI.

  • Le nom ACPI de l’appareil mux est ' SB. MUX1'.

  • Pour GPU0 :

    • Le nom ACPI du GPU0 est « SB.PCI0.GFX0 ».
    • Elle expose la cible VidPn 0x40f04, qui renvoie une valeur DXGK_CHILD_DESCRIPTOR.AcpiUid de 0x400.
    • Le nom du dispositif enfant ACPI correspondant à la cible connectée au multiplexeur est 'SB.PCI0.GFX0.DD1F'.
    • La méthode ACPI _ADR sous ' SB. PCI0. GFX0. DD1F retourne 0x400. La valeur de retour permet au système d'exploitation de savoir que cet appareil ACPI correspond à la cible VidPn 0x40f04.
    • Méthode ACPI DMID sous ' SB. PCI0. GFX0. DD1F » retourne ' SB. MUX1'.

  • Pour GPU1 :

    • Le nom ACPI du GPU1 est 'SB.PCI0.PEG0.PEGP'.
    • Elle expose la cible VidPn 0x1103, qui renvoie une valeur DXGK_CHILD_DESCRIPTOR.AcpiUid de 0x100.
    • Le nom de l’appareil enfant ACPI correspondant à la cible connectée au mux est « SB.PCI0.PEG0.PEGP.EDP1 ».
    • La méthode ACPI _ADR sous 'SB.PCI0.PEG0.PEGP.EDP1' retourne 0x100. Cette valeur de retour permet au système d'exploitation de savoir que cet appareil ACPI correspond à la cible VidPn 0x1103.
    • La méthode ACPI DMID sous 'SB.PCI0.PEG0.PEGP.EDP1' retourne 'SB.MUX1'.

  • Le système d’exploitation sait que les 0x40f04 cibles GPU0 et les 0x1103 cibles GPU1 sont connectées au même mux avec le nom ACPI ' SB. MUX1'.

  • Si GPU1 est actuellement connecté au panneau, le système d'exploitation peut basculer le mux vers GPU0 en appelant la méthode DMCF sur 'SB.MUX1' en passant 'SB.PCI0.GFX0.DD1F'.

Le code de langage d’ordinateur ACPI suivant concerne les parties pertinentes de l’exemple. Le pseudocode pour la logique de la plateforme est entouré par <>.


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")
            }
        }
    }
}

Modifications de l’API

La fonctionnalité ADS ajoute la fonctionnalité d’API publique suivante :

  1. Énumérez les appareils mux dans le système.
  2. Interroger des informations sur le mux ; par exemple, à quelles cibles il est connecté et sur quelle cible il est actuellement basculé.
  3. Déclenchez un commutateur mux.
  4. Comment détecter quand le mux a été changé.

Énumérer les appareils mux dans le système

Les applications peuvent utiliser des API de plug-and-play générales pour rechercher des interfaces d’appareil qui représentent un mux d’affichage fonctionnel. Les composants en mode utilisateur peuvent utiliser Windows.Devices.Enumeration.DeviceInformation. C# ou C++ peut être utilisé avec ces API pour énumérer les appareils 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);

L'interface IDisplayMuxDevice

L’interface IDisplayMuxDevice est ajoutée pour représenter l’appareil mux.

Le code suivant montre comment énumérer les appareils mux d’affichage, interroger leurs états, changer la cible d’affichage active et réagir aux modifications d’état à l’aide des API 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);
    }
}

Modifications DDI WDDM pour la commutation automatique d’affichage

Cette section décrit les ajouts et modifications apportés à WDDM DDI pour prendre en charge ADS. Ces modifications sont disponibles à partir de Windows 11, version 24H2 update 2025.01D (WDDM 3.2).

Interrogation de l’interface de support ADS du KMD

La structure d’interface DXGK_DISPLAYMUX_INTERFACE_2 est ajoutée. Il contient les appels du système d'exploitation vers le pilote nécessaires pour prendre en charge la version 2 d'ADS. Le système d’exploitation interroge l’interface ADS prise en charge par le pilote au démarrage du pilote, avec InterfaceType défini sur GUID_WDDM_INTERFACE_DISPLAYMUX_2.

(DXGK_DISPLAYMUX_INTERFACE contient les appels de système d’exploitation à pilote nécessaires pour prendre en charge la version 1 de la fonctionnalité ADS. Cette version a été utilisée pendant la préversion d’ADS.)

Fonctions KMD pour supporter ADS

KMD implémente les fonctions suivantes pour prendre en charge ADS. Dxgkrnl obtient l’interface fonctionnelle ADS du KMD grâce à un appel à DxgkddiQueryInterface du KMD.

Capacité ADS signalée par le pilote

Le pilote indique son niveau de support ADS lorsque le système d’exploitation appelle son DDI DxgkDdiDisplayMuxGetDriverSupportLevel. Si le pilote n’implémente pas l’interface DXGK_DISPLAYMUX_INTERFACE, le système d’exploitation considère le niveau de support comme DXGK_DISPLAYMUX_SUUPORT_LEVEL_NONE.

Le pilote doit rapporter son niveau de support ADS quel que soit le système sur lequel il fonctionne. Le niveau de support rapporté par le pilote doit être uniquement basé sur le pilote. Le pilote ne doit pas tenir compte des critères suivants lors de la création de rapports sur son niveau de prise en charge ADS :

  1. Le fabricant du système.
  2. Tout autre GPU dans le système.
  3. La présence ou non de l’appareil ACPI du mux.
  4. Présence ou non des entrées ACPI sous le nœud ACPI du GPU.

Mise à jour pour le rapport des cibles au démarrage de l’adaptateur

Lorsque l’adaptateur démarre, il rapporte tous ses dispositifs enfants via le DDI DxgkDdiQueryChildRelations. Le rapport inclut toutes les cibles internes connectées à un mux. Une cible interne inclut le champ DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength.

Un problème se produit si le mux est basculé vers l’autre GPU au démarrage de l’adaptateur. Dans ce cas, le pilote ne peut pas communiquer avec le panneau interne pour interroger la taille EDID/DisplayId. Ainsi, un pilote qui expose l’interface GUID_WDDM_INTERFACE_DISPLAYMUX_2 doit définir DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength à zéro au démarrage de l’adaptateur si le mux n’est pas actuellement basculé sur le GPU du pilote. Sinon, le système d’exploitation échoue au démarrage de l’adaptateur.

Le système d'exploitation met à jour ses informations internes sur la taille du descripteur interne lors de la première commutation mux.

Mise à jour pour la modification de la connexion

Comme mentionné précédemment, il existe une méthode spécifique à ADS pour signaler l’état du panneau interne pendant une séquence de changement d’affichage automatique. Pour indiquer qu’un paquet de modification de connexion fait partie d’une séquence de commutateurs ADS, l’indicateur DisplayMuxConnectionChange est ajouté à DXGK_CONNECTION_MONITOR_CONNECT_FLAGS. Lorsque DisplayMuxConnectionChange est activé, cela indique que le statut de connexion MonitorStatusConnected ou MonitorStatusDisconnected est lié à une commutation automatique d’affichage.

DisplayMuxConnectionChange ne doit être utilisé que durant une commutation ADS et ne doit pas être employé à d’autres fins. Il doit être utilisé lors des occasions ADS suivantes :

  • Pendant que le pilote traite DxgkDdiDisplayMuxPreSwitchAway.

    Si le panneau interne est connecté, le pilote doit ajouter un paquet DXGK_CONNECTION_CHANGE à sa liste de modifications de connexion avec DXGK_CONNECTION_CHANGE.ConnectionStatus défini sur MonitorStatusDisconnected et DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange défini sur 1. Ces paramètres indiquent au système d’exploitation que le pilote a libéré le contrôle du panneau interne.

  • Pendant que le pilote traite DxgkDdiDisplayMuxPostSwitchToPhase1.

    • Le pilote doit d’abord déterminer si le panneau interne est connecté.
    • Si le panneau est connecté, le pilote doit ajouter un paquet DXGK_CONNECTION_CHANGE à sa liste de modifications de connexion avec DXGK_CONNECTION_CHANGE.ConnectionStatus défini sur MonitorStatusConnected et DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange défini sur 1.
    • Si le panneau n'est pas connecté, le pilote doit ajouter un paquet de type DXGK_CONNECTION_CHANGE à sa liste de modifications de connexion, avec DXGK_CONNECTION_CHANGE.ConnectionStatus défini sur MonitorStatusDisconnected et DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange défini sur 1.

  • Pendant que le pilote traite DxgkDdiDisplayMuxSwitchCanceled.

  • Dans le cas où une demande d’interrogation de cible survient pendant une commutation, DisplayMuxConnectionChange ne doit être défini que pour les paquets de changement de connexion ajoutés depuis DxgkDdiDisplayMuxPreSwitchAway, DxgkDdiDisplayMuxPostSwitchToPhase1 ou DxgkDdiDisplayMuxSwitchCanceled.

Conseils mis à jour pour DxgkDdiSystemDisplayEnable

Lorsqu’un DDI DxgkDdiSystemDisplayEnable(/windows-hardware/drivers/ddi/dispmprt/nc-dispmprt-dxgkddi_system_display_enable) d’un pilote ADS est appelé, le pilote doit s’assurer que le PSR est désactivé à la fin de l’appel du DDI DxgkDdiSystemDisplayEnable.

Conseils OEM

Il existe plusieurs aspects de la fonctionnalité ADS qui sont au-dessous du niveau que le système d’exploitation contrôle dans la plateforme. Il est essentiel que les oem s’assurent qu’elles fonctionnent correctement. La liste suivante récapitule certains des points clés que les OEM doivent prendre en compte :

  • Les pilotes hybrides intégrés et discrets doivent tous deux prendre en charge ADS.
  • Le mux sélectionné pour la plateforme est en mesure d’être contrôlé via ACPI.
  • Les méthodes _HID, DMQU et DMCF sous le dispositif mux et les dispositifs ACPI enfants GPU pour les cibles internes sont implémentées et possèdent la méthode ACPI DMID.
  • Les appareils ACPI des deux GPUs doivent disposer de _DEP pour marquer leur dépendance à l’appareil ACPI du mux.
  • L’interface de luminosité/les limites/plages exposées par les deux GPU correspondent exactement.
  • Comme indiqué dans la section Données de luminosité, l’interface de luminosité v3 est fortement recommandée par rapport à l’interface de luminosité v2.
  • Si un pilote de panneau de surveillance est utilisé, le code doit être indépendant du GPU ; autrement dit, la même logique peut être utilisée lorsque l’un des GPU est dans le contrôle du panneau.
  • Au moins pour un mux interne, l’acte de basculement du mux ne doit pas générer d’événement HPD.
  • Si l’OEM souhaitait désactiver le mux dans un système, la méthode ACPI DMQU doit retourner 0 lorsqu’elle est appelée avec Arg0 définie sur 2.
  • Le mux doit être en mesure de basculer entre les GPU même lorsque les pilotes sont en faible puissance. Dans ce cas, PSR ne sera pas utilisé.
  • Lorsque le mux passe d’un GPU à un autre, la luminosité du panneau doit être conservée sans aucune glissance de luminosité. Il existe plusieurs façons de le faire, notamment les méthodes suivantes. L’OEM est chargé de s’assurer que le système conserve la luminosité entre les commutateurs.
    • Utiliser le contrôle de la luminosité basé sur DisplayPort Aux Nits.
    • Utiliser un Tcon avec reconstruction PWM pour éviter tout problème de luminosité.
  • Le panneau et le Tcon utilisés peuvent rester en mode rafraîchissement autonome (PSR1 pour eDP) lorsque la configuration du lien avant et après commutation est exposée par l’EDID et prise en charge par l’iGPU et le dGPU. Cela inclut, mais n’est pas limité aux éléments suivants :
    • Taux d’actualisation
    • Taille active
    • Nombre de voies eDP utilisées et bande passante de voies
    • Paramètre eDP DSC
    • Version eDP VSC SDP utilisée
    • Version et fonctionnalités PSR utilisées pour les scénarios sans commutateur