DXGKDDI_DSITRANSMISSION fonction de rappel (dispmprt.h)

  • Article

La fonction de rappel DxgkddiDsiTransmission effectue une transmission DSI (Display Serial Interface).

Syntaxe

DXGKDDI_DSITRANSMISSION DxgkddiDsitransmission;

NTSTATUS DxgkddiDsitransmission(
  [in]  HANDLE Context,
  [in]  D3DDDI_VIDEO_PRESENT_TARGET_ID TargetId,
  [out] PDXGK_DSI_TRANSMISSION pArgs
)
{...}

Paramètres

[in] Context

[in] TargetId

Identificateur cible du moniteur.

[out] pArgs

Pointeur vers une structure DXGI_DSI_TRANSMISSION .

Valeur retournée

DxgkddiDsiTransmission retourne STATUS_SUCCESS si elle réussit ; sinon, il retourne l’un des codes d’erreur définis dans Ntstatus.h.

Remarques

Pour permettre à un pilote de panneau OEM d’interagir sur l’interface privée par ailleurs entre la carte graphique et le matériel du panneau, les transactions doivent être sans effet de pilote graphique, autre que le temps d’occupation du bus, ou elles doivent être entièrement définies pour que le pilote graphique soit sous contrôle. Étant donné que le point de permettre à un pilote de panneau OEM d’interagir est de fournir une prise en charge des fonctionnalités de panneau personnalisées qui sont opaques pour le pilote graphique, les opérations entièrement définies sont destinées à être limitées aux transactions où le pilote de panneau doit effectuer une opération standardisée qui ne peut pas être effectuée sans l’intervention du pilote graphique. Ces transactions seront traitées comme des exceptions routées explicitement plutôt que comme des transmissions.

Chaque demande de transmission DSI se compose d’une mémoire tampon unique qui est remplie par le pilote de panneau OEM, transmise à la pile du moniteur et retournée avec les résultats de la transmission, le cas échéant. La mémoire tampon contient des informations globales sur la transmission, avec des champs d’entrée et de sortie, suivis d’un tableau de taille variable de structures DXGK_DSI_PACKET . Les paquets sont décrits en termes DSI, de sorte que tout paquet DSI peut être décrit, mais le système d’exploitation analyse les paquets et rejette toute transmission incluant les paquets qui ne sont pas autorisés. Tous les paquets à l’exception du dernier sont, par définition DSI, des paquets d’écriture qui peuvent être des écritures courtes, auquel cas la Payload mémoire tampon est inutilisée, ou des écritures longues qui tiennent dans la Payload mémoire tampon. Le dernier paquet d’une transmission, qui peut être une lecture ou une écriture, est autorisé à utiliser une charge utile étendue en allouant et en décrivant une mémoire tampon plus grande qui permet d’espacer les lectures ou les écritures de toute taille jusqu’à la limite de données de paquets longs DSI de 64 Ko-1 octets de données. Cela permet de mettre en file d’attente des séquences de petits paquets d’écriture vers le pilote dans un seul appel, mais nécessite que les paquets plus volumineux soient envoyés individuellement. La valeur du champ indique le FinalPacketExtraPayload nombre d’octets supplémentaires qui ont été alloués, mais cela doit également être pris en compte dans le TotalBufferSize champ.

Le pilote de panneau OEM est chargé de s’assurer que les transmissions qu’il demande n’entrent pas en conflit ou n’interfèrent pas avec d’autres transmissions que le pilote graphique utilise pour une interaction normale avec le panneau en raison de demandes excessives ou de demandes d’opérations qui entraîneraient des retards dans le traitement d’autres transmissions. Le pilote de panneau ne doit pas modifier l’état qui entraînerait des défaillances ultérieures dans le pilote graphique, par exemple la modification du minutage du panneau via des commandes MCS. De même, si le système d’exploitation a demandé une modification d’affichage, via le pilote graphique, par exemple une augmentation de la luminosité, le pilote de panneau ne doit pas utiliser les commandes DSI pour annuler cette modification, que ce soit en réponse ou à d’autres fins.

Le IOCTL_MIPI_DSI_TRANSMISSION est utilisé pour demander une transmission au périphérique contenant un ou plusieurs paquets DSI. Le pilote de panneau doit toujours initialiser TotalBufferSize, PacketCount et les trois premiers octets de chaque paquet. Le pilote de panneau peut remplacer le comportement par défaut en utilisant des valeurs autres que zéro pour TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPortManufacturingMode et FinalCommandExtraPayload. Toutes les valeurs non initialisées doivent être définies sur zéro.

Le système d’exploitation s’assure que la séquence de paquets DSI est bien formée, avec des informations valides dans tous les champs définis et des tailles de mémoire tampon correctes. Le système d’exploitation est chargé d’initialiser le FailedPacket champ pour DXGK_DSI_INVALID_PACKET_INDEX de sorte qu’une validation supplémentaire dans le système d’exploitation ou le pilote doit uniquement définir le champ si un problème est détecté avec un paquet particulier. Si le DXGK_DSI_TRANSMISSION n’est pas correctement formé, le système d’exploitation définit l’indicateur de DXGK_HOST_DSI_INVALID_TRANSMISSION dans le champ pour le HostErrors distinguer des autres erreurs de paramètres non valides.

Pour être considérés comme bien formés, les éléments suivants doivent tous être vrais :

  • TotalBufferSize >= sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload
  • FinalPacketExtraPayload <= 64K-1-DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE (0xFFF7)
  • TotalBufferSize <= ROUND_TO_PAGES( sizeof(DXGK_DSI_TRANSMISSION) + (0xFE * sizeof(DXGK_DSI_PACKET)) + 0xFFF7 )
  • PacketCount != 0
  • Seul le dernier paquet est autorisé à être lu
  • Seul un paquet d’écriture long final peut avoir une LongWriteWordCount valeur supérieure à [DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE]

Validation des paquets

Bien que le système d’exploitation ne tente pas de valider entièrement le contenu de tous les paquets, il rejette une transmission contenant des commandes DSI autres que les commandes suivantes, en effectuant l’IOCTL sans appeler le pilote graphique :

Valeur du type de données Description
0x03 Écriture courte générique, aucun paramètre
0x13 Generic Short WRITE, 1 paramètre
0x23 Écriture courte générique, 2 paramètres
0x04 LECTURE générique, aucun paramètre
0x14 Read générique, paramètre 1
0x24 LECTURE générique, 2 paramètres
0x05 DCS Short WRITE, aucun paramètre
0x15 DCS Short WRITE, 1 paramètre
0x06 DCS READ, aucun paramètre
0x29 Écriture longue générique
0x39 Écriture/write_LUT longues DCS

Les commandes de lecture et d’écriture génériques nécessitent une compréhension de la spécification du panneau, de sorte que l’on s’attend à ce que ces commandes puissent être utilisées librement par le pilote de panneau sans causer de problèmes pour le pilote graphique tant que le bus n’est pas utilisé de manière excessive. De même, les commandes MCS DCS sont explicitement définies pour une utilisation par le fabricant. Il ne doit donc pas y avoir de problème d’interférence entre le pilote graphique et le pilote de panneau.

Pour DCS UCS, les commandes non définies ne sont pas censées être utilisées par le pilote graphique. Par conséquent, le système d’exploitation les autorisera à être utilisées par le pilote de panneau, bien qu’il existe clairement un risque que les futures modifications de spécification MIPI-DCS définissent la commande afin que les commandes MCS soient préférées.

Les commandes UCS DCS standardisées seront utilisées par le pilote graphique pendant un fonctionnement normal et sont potentiellement utilisables par le pilote de panneau, de sorte que le risque que les commandes envoyées par le pilote du panneau OEM provoquent des problèmes avec les commandes de pilotes graphiques suivantes doit être atténué. Pour ce faire, le système d’exploitation analyse les commandes DCS et rejette les paquets qui sont censés provoquer des conflits, sauf si le pilote du panneau OEM définit l’indicateur ManufacturingMode et que le système d’exploitation confirme que le système est en mode de fabrication. Si l’indicateur est défini mais que le système n’est pas en mode fabrication, la transmission IOCTL est effectuée avec l’indicateur DXGK_HOST_DSI_INVALID_TRANSMISSION défini dans le HostErrors champ sans appeler le pilote graphique.

Les conditions qui nécessiteraient une transaction entièrement définie au lieu d’utiliser une transmission seraient les suivantes :

  • Les périodes d’inactivité chrono timed sont requises avant ou après, telles que DCS soft_reset
  • Modification de l’environnement d’exploitation pour la sortie de trame, par exemple set_vsync_timing DCS et enter_sleep_mode
  • Utilisation de transactions avec une sémantique de démarrage/continue où le pilote graphique peut également avoir besoin d’accéder aux mêmes données, comme DCS write_memory_start/write_memory_continue

En outre, il existe des classes de commandes DCS qui seront rejetées par le système d’exploitation lorsqu’elles sont envoyées en tant que transmission :

  • Toute commande qui doit être entièrement définie, comme décrit ci-dessus
  • Lectures de données de pixels qui peuvent être utilisées pour le raclage d’écran
  • Écritures de données de pixels

Commandes UCS que le système d’exploitation transmettra au pilote graphique :

Hex Commande
00h Nop
26h set_gamma_curve
2Dh write_LUT
51h set_display_brightness
52h get_display_brightness
53h write_control_display
54h get_control_display
55h write_power_save
56h get_power_save
5Eh set_CABC_min_brightness
5Fh get_CABC_min_brightness
03h get_compression_mode
05h get_error_count_on_DSI
06h get_red_channel
07h get_green_channel
08h get_blue_channel
0Ah get_power_mode
0Bh get_address_mode
0Ch get_pixel_format
0Dh get_display_mode
0Eh get_signal_mode
0Fh get_diagnostic_result
14h get_image_checksum_rgb
15h get_image_checksum_ct
3Fh get_3D_control
45h get_scanline

Commandes UCS que le système d’exploitation rejette :

Hex Commande
01h soft_reset (doit être envoyé via un IOCTL_MIPI_DSI_RESET)
10h enter_sleep_mode
11h exit_sleep_mode
12h enter_partial_mode
13h enter_normal_mode
20h exit_invert_mode
21h enter_invert_mode
28h set_display_off
29h set_display_on
2Ah set_column_address
2Bh set_page_address
2Ch write_memory_start
2Eh read_memory_start
30h set_partial_rows
31h set_partial_columns
33h set_scroll_area
34h set_tear_off
35h set_tear_on
36h set_address_mode
37h set_scroll_start
38h exit_idle_mode
39h enter_idle_mode
3Ah set_pixel_format
3Ch write_memory_continue
3Dh set_3D_control
3Eh read_memory_continue
40h set_vsync_timing
44h set_tear_scanline
A1h read_DDB_start
A2h read_PPS_start
A8h read_DDB_continue
A9h read_PPS_continue

Implémentation du pilote graphique

Si la transmission réussit la validation du système d’exploitation, le système d’exploitation transmet la mémoire tampon au pilote graphique en appelant DxgkDsiTransmission DDI.

L’ajout de transmissions OEM dans une interface qui est déjà utilisée pour envoyer à la fois des données de pixels et de contrôle en fonction des demandes du système d’exploitation et des besoins du contrôle périphérique signifie inévitablement que le pilote graphique devra améliorer son séquencement interne pour garantir que ce flux supplémentaire de paquets peut être incorporé correctement. Le pilote graphique ne doit pas réorganiser les paquets au sein d’une transmission à partir du pilote de panneau OEM et doit envoyer l’ensemble de la séquence sans interruption et sans entrelacement d’autres paquets. Le pilote graphique n’étant pas tenu de maintenir l’ordre de ses propres paquets en ce qui concerne l’heure d’arrivée de la demande de transmission de panneau OEM, il peut donc choisir d’envoyer des paquets pour configurer la trame suivante avant (ou après) l’envoi d’une transmission de panneau OEM. Si la fin d’une transmission de panneau OEM démarrée risque de faire manquer aux paquets critiques leur fenêtre de temps, le pilote doit signaler l’annulation de la transmission. Si une transmission n’a pas démarré mais que le pilote s’attend à ce qu’elle provoque des paquets critiques manquer leur fenêtre de temps, le pilote doit différer le démarrage de la transmission jusqu’à la prochaine période d’videment. Si le report d’une transmission d’un panneau OEM l’oblige à attendre plus de deux images pour démarrer, le pilote doit signaler la transmission comme ayant été abandonnée.

Il n’est pas possible pour un pilote graphique de s’assurer que les transmissions qu’il envoie pour le compte du pilote de panneau ne sont pas en conflit avec les transmissions sur lesquelles il contrôle. Le pilote peut choisir d’inspecter les paquets au sein d’une transmission et de rejeter la transmission s’ils provoquent des problèmes, mais tous les paquets considérés comme non sécurisés doivent être marqués pour le rejet au niveau du système d’exploitation. Par conséquent, le rejet au niveau du pilote doit idéalement être dû à des préoccupations spécifiques du fournisseur de graphiques. Le pilote ne doit pas tenter de mettre en cache ou d’optimiser les lectures ou les écritures, même si les paquets semblent être des commandes standardisées.

Si le pilote graphique rejette une transmission en raison d’un problème avec un paquet, il doit mettre à jour le FailedPacket champ avec l’index du premier paquet, ce qui entraîne le rejet de la transmission et définir l’indicateur HostErrors DXGK_HOST_DSI_DRIVER_REJECTED_PACKET avant de retourner. Si une substitution de mode de transmission est fournie, le pilote doit vérifier que la substitution est compatible avec ses contraintes matérielles et, si ce n’est pas le cas, définir l’indicateur HostErrors DXGK_HOST_DSI_BAD_TRANSMISSION_MODE avant de retourner.

Si une défaillance se produit pendant la communication, le pilote graphique doit mettre à jour le FailedPacket champ avec l’index du paquet qui a échoué, mais il peut ne pas être possible dans tous les cas pour le pilote d’identifier le paquet afin que le pilote conserve la valeur par défaut, DXGK_DSI_INVALID_PACKET_INDEX pour de tels cas.

Le pilote graphique est responsable de la communication des paquets et doit donc s’assurer que les sommes case activée sont calculées et vérifiées. Toute transmission se terminant par une lecture, sera un paquet court, de sorte que les champs Data0 et Data1 contiennent tous les paramètres et la réponse peut être un paquet court ou long. Le pilote graphique ne sait peut-être pas quelle forme et combien de temps seront les données retournées, mais la taille maximale est la taille totale de la charge utile pour le paquet final, y compris le FinalPacketExtraPayload. Le système d’exploitation valide que cette valeur n’est pas supérieure à la TargetMaximumReturnPacketSize valeur signalée par le pilote dans ses fonctionnalités pour la cible, mais le pilote doit s’assurer à la fois que cette mémoire tampon n’est pas dépassée par un périphérique signalant plus de données et que les données du périphérique ne sont pas tronquées en raison d’une taille supérieure à la valeur MaximumReturnPacketSize actuellement appliquée au périphérique. Le pilote écrit le nombre d’octets lus dans la mémoire tampon dans le ReadWordCount champ décrivant la transmission.

Il peut y avoir des cas où le pilote graphique est forcé de réinitialiser l’interface de communication au panneau ou le panneau entier en raison d’erreurs qui peuvent ne pas être liées au pilote de panneau OEM et peuvent ne pas être observables avec le pilote de panneau OEM. Pour ce faire, le pilote doit signaler DXGK_HOST_DSI_INTERFACE_RESET ou DXGK_HOST_DSI_DEVICE_RESET défini dans le champ lors de la HostErrors première tentative de transmission après la réinitialisation afin que le pilote du panneau OEM puisse détecter la situation et se rétablir. Le pilote ne doit pas envoyer cette transmission au matériel, mais le pilote du panneau OEM peut simplement réessayer la même commande si aucune récupération n’est requise, auquel cas le pilote doit continuer à traiter la transmission comme d’habitude.

Fin d’une transmission

Lorsque le IOCTL termine la FailedPacketcharge utile , ReadWordCount, HostErrorsMipiErrorset d’un paquet de lecture (final) peut avoir été mis à jour en fonction du résultat. Si des erreurs ont été détectées lors du traitement de la transmission, le pilote de panneau OEM doit utiliser les MipiErrors valeurs de sortie et HostErrors pour déterminer comment récupérer et continuer.

Pour garantir que la sortie est retournée à l’appelant afin de fournir des détails sur les erreurs, les appels IOCTL et DDI doivent signaler un succès, même si des erreurs sont détectées. La réussite n’indique pas que la transaction a réussi, elle indique que les appels pour gérer la transaction se sont déroulés comme prévu et que les indicateurs d’erreur ont été définis, le cas échéant. Des échecs peuvent toujours être signalés pour des conditions telles qu’un appel DDI non pris en charge (probablement en raison d’une incompatibilité de pilote), des échecs d’allocation de mémoire ou la transmission de paramètres complètement incorrects, tels que le passage d’une mémoire tampon NULL. Si aucune erreur n’est signalée pour un appel réussi, l’appelant doit supposer que la transaction a réussi.

Configuration requise

Condition requise Valeur
Client minimal pris en charge Windows 10, version 2004
En-tête dispmprt.h

Voir aussi

DXGI_DSI_TRANSMISSION