IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)
Code principal : IRP_MJ_DEVICE_CONTROL
IOCTL_MIPI_DSI_TRANSMISSION est émis pour envoyer une séquence de paquets DSI MIPI à un périphérique.
Code principal
Mémoire tampon d’entrée
n/a
Longueur de la mémoire tampon d’entrée
n/a
Mémoire tampon de sortie
n/a
Longueur de la mémoire tampon de sortie
n/a
Mémoire tampon d’entrée/sortie
Structure DXGK_DSI_TRANSMISSION suivie de structures DXGK_DSI_PACKET contenant les paquets.
Longueur de la mémoire tampon d’entrée/sortie
Au moins sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload. Pour plus d’informations, consultez les remarques.
Bloc d’état
> IoStatus.Status est défini sur STATUS_SUCCESS si la requête réussit. Sinon, 'état est défini sur la condition d’erreur appropriée en tant que code NTSTATUS. Pour plus d’informations, consultez valeurs NTSTATUS.
Remarques
Le moniteur, le panneau oem et les pilotes port/miniport doivent gérer les iocTLs de l’interface numérique MIPI (Mobile Industry Processor Interface) (DSI).
Exécution de transmissions
Pour permettre à un pilote de panneau d’interagir sur cette interface privée autrement entre la carte graphique et le matériel du panneau, les transactions ne doivent avoir aucun effet de pilote graphique, autre que le temps occupant le bus, ou ils doivent être entièrement définis afin que le pilote graphique soit en contrôle. Étant donné que le point d’interaction d’un pilote de panneau consiste à 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’implication du pilote graphique. Ces transactions seront traitées comme des exceptions routées explicitement plutôt que comme des transmissions.
Chaque demande de transmission se compose d’une mémoire tampon unique qui est remplie par le pilote du 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 qui inclut des paquets non autorisés. Tous les paquets à l’exception de la dernière sont, par définition DSI, les paquets d’écriture qui peuvent être des écritures courtes, auquel cas la mémoire tampon charge utile est inutilisée ou les écritures longues qui s’intègrent dans la mémoire tampon charge utile. 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 permettra l’espace pour 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 aux séquences de petits paquets d’écriture d’être mis en file d’attente vers le pilote dans un seul appel, mais nécessite que des paquets plus volumineux soient envoyés individuellement. La valeur du champ FinalPacketExtraPayload indique le nombre d’octets supplémentaires alloués, mais cela doit également être pris en compte dans le champ TotalBufferSize.
Le pilote du panneau OEM est chargé de s’assurer que les transmissions qu’il demande ne sont pas en conflit ou interfèrent avec d’autres transmissions que le pilote graphique utilise pour l’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 du panneau ne doit pas changer d’état qui provoquerait des défaillances ultérieures dans le pilote graphique, par exemple en modifiant le minutage du panneau via les 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 du panneau ne doit pas utiliser les commandes DSI pour annuler cette modification, en réponse ou à d’autres fins.
IOCTL_MIPI_DSI_TRANSMISSION est utilisé pour demander une transmission au périphérique contenant un ou plusieurs paquets DSI. Le pilote du panneau doit toujours initialiser TotalBufferSize, PacketCount et les trois premiers octets de chaque paquet. Le pilote du panneau peut remplacer le comportement par défaut à l’aide de valeurs non nulles pour TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode et FinalCommandExtraPayload. Toutes les valeurs non initialisées doivent être définies sur zéro.
Le système d’exploitation garantit 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 responsable de l’initialisation du champ FailedPacket pour DXGK_DSI_INVALID_PACKET_INDEX afin que la validation supplémentaire dans le système d’exploitation ou le pilote ne doit définir le champ que si un problème se trouve avec un paquet particulier. Si la structure DXGK_DSI_TRANSMISSION n’est pas correctement formée, le système d’exploitation définit l’indicateur DXGK_HOST_DSI_INVALID_TRANSMISSION dans le champ HostErrors pour distinguer cela des autres erreurs d’analyse non valides.
Pour être considéré comme bien formé, 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 valeur LongWriteWordCount 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 suivantes, en effectuant le IOCTL sans appeler le pilote graphique :
| Valeur du type de données | Description |
|---|---|
| 0x03 | Écriture courte générique, aucun paramètre |
| 0x13 | Écriture courte générique, paramètre 1 |
| 0x23 | Écriture courte générique, 2 paramètres |
| 0x04 | READ générique, aucun paramètre |
| 0x14 | Paramètre READ générique, 1 |
| 0x24 | Paramètres READ génériques, 2 |
| 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 longue DCS |
Les commandes de lecture et d’écriture génériques nécessitent une compréhension de la spécification du panneau afin que ces commandes puissent être utilisées librement par le pilote du panneau sans provoquer de problèmes pour le pilote graphique tant que le bus n’est pas utilisé excessivement. De même, les commandes MCS DCS sont explicitement définies pour l’utilisation du fabricant afin qu’il n’y ait aucun problème d’interférence entre le pilote graphique et le pilote du 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 permettra d’utiliser par le pilote du panneau bien qu’il existe clairement un risque que les futures MIPI-DCS modifications de spécification 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 l’opération normale et sont potentiellement utilisables par le pilote du panneau afin que le risque de commandes envoyées par le pilote du panneau OEM provoquant 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 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 de fabrication, le IOCTL de transmission est terminé avec l’indicateur de DXGK_HOST_DSI_INVALID_TRANSMISSION défini dans le champ HostErrors 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é chronométrées sont requises avant ou après, telles que dcS soft_reset
- Modification de l’environnement d’exploitation pour la sortie d’images, par exemple dcS set_vsync_timing et enter_sleep_mode
- Utilisation de transactions avec la sémantique de démarrage/continue où le pilote graphique peut également avoir besoin d’accéder aux mêmes données, telles que 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 la capture d’écran
- Écritures de données de pixels
Commandes UCS que le système d’exploitation transmet au pilote graphique
| Sortilège | Commander |
|---|---|
| 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 rejetées par le système d’exploitation
| Sortilège | Commander |
|---|---|
| 01h | soft_reset - remarque : cela 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 |
Note
Les stratégies de validation du système d’exploitation peuvent être modifiées dans les futures versions.
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 à l’aide de DsiTransmission.
L’ajout de transmissions OEM dans une interface déjà utilisée pour envoyer des données de pixel et de contrôle basées sur les demandes de système d’exploitation et les besoins du contrôle périphérique signifie inévitablement que le pilote graphique devra améliorer son séquencement interne pour s’assurer 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 du panneau OEM et doit envoyer l’intégralité de la séquence ininterrompue et sans interlacement d’autres paquets. Le pilote graphique n’est pas tenu de conserver l’ordre de ses propres paquets en ce qui concerne l’heure d’arrivée de la demande de transmission du panneau OEM. Il peut donc choisir d’envoyer des paquets pour configurer le cadre suivant avant (ou après) l’envoi d’une transmission de panneau OEM. Si l’achèvement d’une transmission de panneau OEM démarrée menace de provoquer des paquets critiques à manquer leur fenêtre de temps, le pilote doit signaler la transmission comme annulée. Si une transmission n’a pas démarré, mais que le pilote s’attend à ce que les paquets critiques manquent leur fenêtre de temps, le pilote doit différer le démarrage de la transmission jusqu’à la prochaine période de videment. Si le report d’une transmission d’un panneau OEM aurait dû attendre que plus de deux images démarrent, le pilote doit signaler la transmission telle qu’elle a été supprimée.
Il n’est pas possible pour un pilote graphique de s’assurer que les transmissions qu’il envoie au nom du pilote du panneau ne sont pas en conflit avec les transmissions sur lesquelles il a le contrôle. Le pilote peut choisir d’inspecter les paquets au sein d’une transmission et de rejeter la transmission s’il causerait 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, de sorte que le rejet au niveau du pilote doit idéalement être dû à des préoccupations spécifiques du fournisseur graphique. 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 champ FailedPacket avec l’index du premier paquet à l’origine du rejet de la transmission et définir l’indicateur de HostErrors DXGK_HOST_DSI_DRIVER_REJECTED_PACKET avant de retourner. Si un remplacement en mode de transmission est fourni, le pilote doit vérifier que le remplacement est compatible avec ses contraintes matérielles et, si ce n’est pas le cas, définissez 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 champ FailedPacket 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, dans ce cas.
Le pilote graphique est responsable de la communication des paquets. Il doit donc s’assurer que toutes les sommes de vérification sont calculées et vérifiées. Toute transmission qui se termine par une lecture est 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 peut ne pas connaître le formulaire et la durée pendant laquelle les données retournées seront, mais la taille maximale est la taille maximale de la charge utile pour le paquet final, y compris la FinalPacketExtraPayload. Le système d’exploitation valide que cette valeur n’est pas supérieure à la TargetMaximumReturnPacketSize signalée par le pilote dans ses fonctionnalités pour la cible, mais le pilote doit s’assurer 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 champ ReadWordCount décrivant la transmission.
Il peut arriver que le pilote graphique soit forcé de réinitialiser l’interface de communication sur le panneau, soit le panneau entier en raison d’erreurs qui peuvent ne pas être liées et qui peuvent ne pas être observables au pilote du panneau OEM. Pour résoudre ce problème, le pilote doit signaler DXGK_HOST_DSI_INTERFACE_RESET ou DXGK_HOST_DSI_DEVICE_RESET défini dans le champ HostErrors sur la première tentative de transmission après la réinitialisation afin que le pilote du panneau OEM puisse détecter la situation et récupérer. 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 poursuivre le traitement de la transmission comme d’habitude.
Fin d’une transmission
Lorsque le IOCTL termine le FailedPacket, ReadWordCount, MipiErrors, HostErrors et la charge utile pour 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 du panneau OEM doit utiliser les valeurs de sortie MipiErrors et HostErrors pour déterminer comment récupérer et continuer.
Pour vous assurer que la sortie est retournée à l’appelant pour fournir des détails sur les erreurs, les appels IOCTL et DDI doivent signaler une réussite, même si des erreurs sont trouvées. La réussite n’indique pas que la transaction a réussi, elle indique que les appels pour gérer la transaction ont été effectués comme prévu et que les indicateurs d’erreur ont été définis, le cas échéant. Les é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), d’échecs d’allocation de mémoire ou de transmission de paramètres complètement incorrects, tels que la transmission 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.
Exigences
| Exigence | Valeur |
|---|---|
| client minimum pris en charge | Windows 10, version 2004 |
| d’en-tête | ntddvdeo.h |