Partager via

Mises à jour pour les versions 1.10 et ultérieures de l'IddCx

  • Article

Cet article décrit les mises à jour effectuées dans la version 1.10 d’IddCx. Un seul binaire de pilote d’affichage indirect (IDD) construit avec IddCx 1.10 peut s’exécuter sur Windows 10, version 1803 et les versions supérieures, en utilisant des vérifications d’exécution pour vérifier si les modifications DDI d’IddCx 1.10 sont disponibles sur ce système. Pour plus d’informations, veuillez consulter la section Construire un pilote WDF pour plusieurs versions de Windows.

Les modifications d’IddCx 1.10 se divisent en plusieurs catégories :

  • Mise à jour de la version IddCxGetVersion (console et à distance). Pour une liste complète des informations sur les versions liées à IddCx, veuillez consulter la section Versions IddCx.
  • Ajout de la prise en charge HDR10 (High Dynamic Range) et SDR (Standard Dynamic Range) Wide Color Gamut (WCG) pour les affichages indirects.

Version mise à jour de IddCxGetVersion

La valeur renvoyée par IddCxGetVersion a été mise à jour mais diffère en fonction du système d’exploitation :

  • La plateforme Windows 11 version 24H2 retourne 0x1A80 (IDDCX_VERSION_GERMANIUM).
  • La mise à jour de septembre pour Windows 11, version 22H2, renvoie 0x1A00 (IDDCX_VERSION_SV3).

Ce contrôle de version est important pour les pilotes à distance où le comportement du système d’exploitation diffère légèrement.

Prise en charge large des gammes de couleurs HDR et SDR

Pour une introduction à la gestion des couleurs sous Windows, y compris SDR WCG, veuillez consulter la section DirectX avec des couleurs avancées sur les écrans HDR et SDR.

Prise en charge du DDI du pilote et du système d’exploitation

Dans la mesure du possible, les DDI existants ont été étendus pour permettre à un pilote de signaler la prise en charge de :

  • HDR10
  • SDR WCG
  • La réception de données décrivant toute trame HDR envoyée à un IDD

Des variantes plus récentes des DDI existants ont été ajoutées lorsque les DDI existants ne pouvaient pas être étendus. Dans la plupart des cas, ces changements s’appliquent aussi bien aux pilotes de console qu’aux pilotes à distance, mais quelques détails spécifiques aux pilotes à distance sont également définis.

Les pilotes version 1.10 et supérieures prenant en charge le HDR doivent utiliser les variantes DDI plus récentes. Les pilotes plus anciens ou ceux qui ne prennent pas en charge le HDR peuvent continuer à utiliser les fonctions existantes. Un aperçu des modifications est donné dans les sections qui suivent celle-ci.

Le tableau suivant répertorie les DDI implémentés par les pilotes ajoutés dans IddCx 1.10 et nomme l’équivalent précédent s’il en existe un. Le système d’exploitation peut appeler ces fonctions si le pilote les signale, même pour les adaptateurs qui n’essaient pas de prendre en charge le HDR.

Fonctions du pilote appelées par le système d’exploitation pour les adaptateurs HDR Fonction équivalente précédente
EVT_IDD_CX_ADAPTER_QUERY_TARGET_INFO S/O
EVT_IDD_CX_MONITOR_SET_DEFAULT_HDR_METADATA* S/O
EVT_IDD_CX_PARSE_MONITOR_DESCRIPTION2** EVT_IDD_CX_PARSE_MONITOR_DESCRIPTION
EVT_IDD_CX_MONITOR_QUERY_TARGET_MODES2 EVT_IDD_CX_MONITOR_QUERY_TARGET_MODES
EVT_IDD_CX_ADAPTER_COMMIT_MODES2 EVT_IDD_CX_ADAPTER_COMMIT_MODES

* : La fonction n’est pas appelée pour les pilotes à distance.

** : La fonction peut ne pas être appelée pour les pilotes à distance en fonction des indicateurs d’adaptateur définis par le pilote.

Le tableau suivant répertorie les fonctions implémentées par le système d’exploitation ajoutées dans IddCx 1.10 et nomme tout équivalent précédent. Un pilote version 1.10 peut appeler les variantes plus récentes une fois qu’il a déterminé que ces fonctions sont disponibles dans le système d’exploitation sur lequel le pilote s’exécute.

Fonctions plus récentes qu’un pilote doit appeler pour les adaptateurs HDR Équivalent précédent
IddCxSwapChainReleaseAndAcquireBuffer2 IddCxSwapChainReleaseAndAcquireBuffer/IddCxSwapChainReleaseAndAcquireSystemBuffer
IddCxMonitorQueryHardwareCursor3 IddCxMonitorQueryHardwareCursor2 ou IddCxMonitorQueryHardwareCursor
IddCxAdapterDisplayConfigUpdate2* IddCxAdapterDisplayConfigUpdate*
IddCxMonitorUpdateModes2 IddCxMonitorUpdateModes

* : À utiliser uniquement pour les pilotes à distance.

Signalement de la prise en charge HDR de l’adaptateur

Les pilotes versions 1.10 et supérieures doivent définir l’indicateur IDDCX_ADAPTER_FLAGS_CAN_PROCESS_FP16 ajouté à IDDCX_ADAPTER_FLAGS pour signaler la prise en charge des surfaces FP16. Les surfaces FP16 peuvent être utilisées pour HDR10 ou simplement pour SDR WCG. Définir cet indicateur implique qu’un pilote fait tout ce qui est nécessaire pour activer HDR10 ou SDR WCG, y compris :

Signalement des capacités HDR des cibles

Si un pilote souhaite activer le HDR pour un adaptateur, il doit fournir des informations supplémentaires sur chaque connecteur cible via sa fonction EVT_IDD_CX_ADAPTER_QUERY_TARGET_INFO. Des informations spécifiques au connecteur cible sont nécessaires car seules certaines des cibles disponibles peuvent prendre en charge certains aspects du HDR.

Métadonnées HDR

Lorsque le pilote fournit un descripteur de moniteur contenant des métadonnées HDR, le système d’exploitation appelle EVT_IDD_CX_MONITOR_SET_DEFAULT_HDR_METADATA pour fournir les métadonnées HDR par défaut au pilote. Le pilote doit conserver ces données par défaut et les utiliser lors de l’envoi de trames d’informations HDR10 (SMPTE ST.2086) au moniteur. Lorsque le pilote appelle IddCxSwapChainReleaseAndAcquireBuffer2, le système d’exploitation fournit également des informations sur les métadonnées HDR. Si ces métadonnées indiquent que les valeurs par défaut doivent être utilisées, cela fait référence aux données par défaut stockées.

Lorsque le mode HDR est activé, le système d’exploitation envoie l’état des métadonnées HDR avec chaque trame. Ces métadonnées indiquent au pilote quelles métadonnées HDR utiliser via la structure IDDCX_METADATA2 introduite. Les métadonnées sont soit un nouveau bloc de métadonnées, soit une indication que le pilote doit utiliser soit les métadonnées par défaut fournies précédemment par le système d’exploitation, soit les mêmes métadonnées que pour la trame précédente.

Note : Les métadonnées HDR ne sont pas disponibles pour les pilotes à distance car les métadonnées HDR10 doivent provenir du sous-système d’affichage du client.

Signalement des modes HDR

Lorsqu’un écran est connecté à une cible, le système d’exploitation interroge le pilote sur les modes moniteur et cibles actuellement pris en charge. Pour annoncer correctement les capacités HDR, des informations supplémentaires sont nécessaires pour chacun de ces modes, de sorte qu’un pilote HDR doit exposer les DDI introduits dans la version 1.10 suivants :

Ces modes étendus indiquent les profondeurs de bits possibles et les formats de surface qui peuvent être utilisés. Un pilote peut également mettre à jour une liste de modes cibles en appelant IddCxMonitorUpdateModes2.

Le système d’exploitation déduit les variations des modes pour HDR et SDR WCG en fonction des informations renvoyées par le rappel EVT_IDD_CX_ADAPTER_QUERY_TARGET_INFO du pilote avant que des modes ne soient signalés.

Le système d’exploitation valide les modes afin d’essayer de détecter les modes répétés qui devraient être combinés et signalés comme un seul mode. Par exemple, une cible prenant en charge le 1080p à 60 Hz en 8 bits et 10 bits par canal doit être signalée comme un seul mode. Cependant, si la cible prend en charge ces modes mais qu’ils nécessitent des quantités de bande passante différentes, il est toujours acceptable que ces modes soient signalés séparément.

Un type de gamma ajouté

Le DDI existant EVT_IDD_CX_MONITOR_SET_GAMMA_RAMP a été étendu de sorte que le système d’exploitation puisse fournir la transformation matricielle 3x4 nécessaire pour prendre en charge les écrans HDR aux pilotes qui annoncent la prise en charge HDR.

Niveau de blanc SDR

Les données de pixels du curseur de souris sont toujours en SDR. Lorsqu’un moniteur est réglé en mode HDR, le niveau de blanc SDR doit être appliqué aux curseurs de souris. IddCx v.10 fournit cette capacité à deux endroits :

  • Elle a été ajoutée aux métadonnées par trame reçues par un pilote lorsqu’il appelle IddCxSwapChainReleaseAndAcquireBuffer2.
  • Elle fait également partie de la fonction introduite IddCxMonitorQueryHardwareCursor3, de sorte qu’un pilote peut rendre les mises à jour du curseur au niveau de blanc correct sans avoir besoin de recevoir une nouvelle trame. Le niveau de blanc SDR par défaut est de 80 nits.

Espace colorimétrique de la surface

Même si le pilote a signalé l’espace colorimétrique dans le cadre des informations de mode, le système d’exploitation signale l’espace colorimétrique réel utilisé par une trame spécifique dans la structure IDDCX_METADATA2 introduite.

HDR avec les pilotes à distance

Dans la mesure du possible, le comportement du système d’exploitation et du pilote doit être le même pour un pilote à distance que pour un pilote de console. Les exceptions sont les suivantes :

  • Les métadonnées HDR ne sont pas fournies aux pilotes à distance. Le système client est censé fournir ces métadonnées en fonction de l’écran physiquement connecté. Il est inutile d’utiliser des métadonnées déterminées par le serveur.
  • La transformation matricielle 3x4 des couleurs n’est pas non plus envoyée. Encore une fois, un pilote à distance est censé utiliser les données équivalentes provenant du système client.
  • Les pilotes à distance peuvent fournir les données de colorimétrie et le niveau de blanc SDR à utiliser sur le serveur.
  • Les modes moniteur sont également facultatifs pour les pilotes à distance. Si un pilote à distance définit l’indicateur IDDCX_ADAPTER_FLAGS_ALL_TARGET_MODES_MONITOR_COMPATIBLE pour l’adaptateur, le système d’exploitation ne lui demandera pas de modes moniteur et utilisera à la place uniquement les modes cibles. Cette capacité permet à un pilote de spécifier des modes inhabituels sans avoir besoin de signaler le mode moniteur équivalent ; par exemple, en fonction de la taille de la fenêtre du client plutôt que de la taille du moniteur.

Prise en charge d’un pilote 1.10 exécuté sur des versions antérieures

Les pilotes version 1.10 qui s’exécutent sur des versions plus anciennes de Windows doivent prendre plusieurs mesures pour garantir la compatibilité. En particulier, les pilotes doivent :

  • Continuer d’exporter toutes les fonctions existantes telles que EVT_IDD_CX_PARSE_MONITOR_DESCRIPTION, EVT_IDD_CX_MONITOR_QUERY_TARGET_MODES, et EVT_IDD_CX_ADAPTER_COMMIT_MODES.
  • Utiliser la macro IDD_CX_CLIENT_CONFIG_INIT pour définir la taille de la structure IDD_CX_CLIENT_CONFIG.
  • Ne pas essayer d’appeler des fonctions implémentées par le système d’exploitation qui ne sont pas disponibles dans les versions plus anciennes. Utiliser IDD_IS_FUNCTION_AVAILABLE pour vérifier la disponibilité.
  • Aucune des fonctions de la version 1.10 ne peut être exportée. Un pilote peut utiliser la macro IDD_IS_FIELD_AVAILABLE pour vérifier s’il est sûr de définir le rappel EvtIddCxXxx dans la structure IDD_CX_CLIENT_CONFIG.
  • IDD_IS_FIELD_AVAILABLE peut également aider un pilote à déterminer s’il est sûr de définir IDDCX_ADAPTER_FLAGS_CAN_PROCESS_FP16 ou IDDCX_ADAPTER_FLAGS_ALL_TARGET_MODES_MONITOR_COMPATIBLE. Si l’un des DDI de la version 1.10 n’est pas disponible, le pilote ne doit pas définir l’indicateur.

Un exemple de la façon dont IDD_IS_FIELD_AVAILABLE peut être utilisé :

    if (IDD_IS_FIELD_AVAILABLE(IDD_CX_CLIENT_CONFIG, EvtIddCxParseMonitorDescription2))
    {
        IddCxClientConfig.EvtIddCxParseMonitorDescription2 = ParseMonitorDescription2;
    }

Pour plus d’informations, veuillez consulter la section Construire des pilotes IddCx 1.4.