IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)

Hauptcode: IRP_MJ_DEVICE_CONTROL

IOCTL_MIPI_DSI_TRANSMISSION wird ausgegeben, um eine Sequenz von MIPI DSI-Paketen an ein Peripheriegerät zu senden.

Hauptcode

IRP_MJ_DEVICE_CONTROL

Eingabepuffer

–

Eingabepufferlänge

–

Ausgabepuffer

–

Länge des Ausgabepuffers

–

Eingabe-/Ausgabepuffer

Eine DXGK_DSI_TRANSMISSION-Struktur gefolgt von DXGK_DSI_PACKET Strukturen, die die Pakete enthalten.

Länge des Eingabe-/Ausgabepuffers

Mindestens sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload. Einzelheiten finden Sie in den Hinweisen.

Statusblock

Irp->IoStatus.Status ist auf STATUS_SUCCESS festgelegt, wenn die Anforderung erfolgreich ist. Andernfalls wird Status auf die entsprechende Fehlerbedingung als NTSTATUS-Code festgelegt. Weitere Informationen finden Sie unter NTSTATUS-Werte.

Hinweise

Monitor-, OEM-Panel- und Anzeigeport-/Miniporttreiber müssen IOCTLs (MIPI) Digital Serial Interface (DSI) von Mobile Industry Processor Interface (MIPI) verarbeiten.

Durchführen von Übertragungen

Damit ein Paneltreiber über diese ansonsten private Schnittstelle zwischen Grafikkarte und Panelhardware interagieren kann, müssen die Transaktionen entweder keinen Grafiktreibereffekt haben, außer der Zeit, die den Bus belegt, oder sie müssen vollständig definiert sein, damit der Grafiktreiber steuern kann. Da der Punkt der Interaktion eines Paneltreibers darin besteht, unterstützung für benutzerdefinierte Panelfeatures bereitzustellen, die für den Grafiktreiber undurchsichtig sind, sind vollständig definierte Vorgänge auf Transaktionen beschränkt, bei denen der Paneltreiber einen standardisierten Vorgang ausführen muss, der nicht ohne die Beteiligung des Grafiktreibers ausgeführt werden kann. Solche Transaktionen werden als ausnahmen behandelt, die explizit und nicht als Übertragungen weitergeleitet werden.

Jede Übertragungsanforderung besteht aus einem einzelnen Puffer, der vom OEM-Paneltreiber gefüllt, den Monitorstapel übergeben und ggf. mit den Ergebnissen der Übertragung zurückgegeben wird. Der Puffer enthält allgemeine Informationen zur Übertragung mit Eingabe- und Ausgabefeldern, gefolgt von einem Array von variablen Größen DXGK_DSI_PACKET Strukturen. Die Pakete werden in DSI-Begriffen beschrieben, sodass jedes DSI-Paket beschrieben werden kann, aber das Betriebssystem analysiert die Pakete und lehnt jede Übertragung ab, die unzulässige Pakete enthält. Alle Pakete mit Ausnahme der letzten sind nach DSI-Definition Schreibpakete, die entweder kurze Schreibvorgänge sein können, wobei der Nutzlastpuffer nicht verwendet wird, oder lange Schreibvorgänge, die in den Nutzlastpuffer passen. Das letzte Paket in einer Übertragung, bei dem es sich um ein Lese- oder Schreibpaket handelt, kann eine erweiterte Nutzlast verwenden, indem ein größerer Puffer zugewiesen und beschrieben wird, der Speicherplatz für Lese- oder Schreibvorgänge beliebiger Größe bis zum DSI-Datenlimit für lange Pakete von 64K-1-Datenbytes ermöglicht. Dadurch können Sequenzen von kleinen Schreibpaketen in einer Warteschlange an den Treiber in einem einzelnen Aufruf eingereiht werden, erfordert jedoch, dass größere Pakete einzeln gesendet werden. Der Wert des Felds FinalPacketExtraPayload gibt an, wie viele zusätzliche Bytes zugewiesen wurden. Dies muss jedoch auch im Feld TotalBufferSize berücksichtigt werden.

Der OEM-Paneltreiber ist dafür verantwortlich, sicherzustellen, dass die angeforderten Übertragungen nicht in Konflikt stehen oder andere Übertragungen stören, die der Grafiktreiber für die normale Interaktion mit dem Panel verwendet, da übermäßige Anforderungen oder Vorgänge angefordert werden, die zu Verzögerungen bei der Verarbeitung anderer Übertragungen führen würden. Der Paneltreiber darf keinen Zustand ändern, der nachfolgende Fehler im Grafiktreiber verursachen würde, z. B. das Ändern des Panel-Timings über MCS-Befehle. Wenn das Betriebssystem eine Anzeigeänderung über den Grafiktreiber angefordert hat, z. B. eine Erhöhung der Helligkeit, darf der Paneltreiber keine DSI-Befehle verwenden, um diese Änderung rückgängig zu machen, weder als Reaktion noch für andere Zwecke.

IOCTL_MIPI_DSI_TRANSMISSION wird verwendet, um eine Übertragung an das Peripheriegerät anzufordern, das mindestens ein DSI-Paket enthält. Der Paneltreiber muss immer TotalBufferSize, PacketCount und die ersten drei BYTES jedes Pakets initialisieren. Der Paneltreiber kann das Standardverhalten mit Werten ungleich Null für TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode und FinalCommandExtraPayload außer Kraft setzen. Alle nicht initialisierten Werte müssen auf Null festgelegt werden.

Das Betriebssystem stellt sicher, dass die Sequenz der DSI-Pakete wohlgeformt ist, mit gültigen Informationen in allen definierten Feldern und den richtigen Puffergrößen. Das Betriebssystem ist für die Initialisierung des FailedPacket-Felds für DXGK_DSI_INVALID_PACKET_INDEX verantwortlich, sodass eine weitere Überprüfung im Betriebssystem oder Treiber das Feld nur festlegen muss, wenn ein Problem mit einem bestimmten Paket gefunden wird. Wenn die DXGK_DSI_TRANSMISSION Struktur nicht gut formatiert ist, legt das Betriebssystem das DXGK_HOST_DSI_INVALID_TRANSMISSION-Flag im Feld HostErrors fest, um dies von anderen ungültigen Paramsfehlern zu unterscheiden.

Um als wohlgeformt gelten zu können, müssen alle zutreffen:

• 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
• Nur das letzte Paket darf ein Lesevorgang sein.
• Nur ein letztes Paket mit langen Schreibvorgängen kann einen LongWriteWordCount-Wert aufweisen, der größer als DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE

Paketüberprüfung

Obwohl das Betriebssystem nicht versucht, den Inhalt aller Pakete vollständig zu überprüfen, lehnt es eine Übertragung ab, die andere DSI-Befehle als die folgenden enthält, und schließt die IOCTL ab, ohne den Grafiktreiber aufzurufen:

Generische Lese- und Schreibbefehle erfordern ein Verständnis der Panelspezifikation, sodass davon auszugehen ist, dass diese Befehle vom Paneltreiber frei verwendet werden können, ohne Probleme für den Grafiktreiber zu verursachen, solange der Bus nicht übermäßig verwendet wird. Ebenso sind DCS MCS-Befehle explizit für die Verwendung durch den Hersteller definiert, sodass es kein Problem mit Störungen zwischen dem Grafiktreiber und dem Paneltreiber geben sollte.

Für DCS UCS wird nicht erwartet, dass nicht definierte Befehle vom Grafiktreiber verwendet werden, sodass das Betriebssystem sie vom Paneltreiber verwenden kann, obwohl eindeutig das Risiko besteht, dass zukünftige MIPI-DCS-Spezifikationsänderungen den Befehl definieren, sodass MCS-Befehle bevorzugt werden.

Standardisierte DCS UCS-Befehle werden vom Grafiktreiber während des normalen Betriebs verwendet und können möglicherweise vom Paneltreiber verwendet werden, sodass das Risiko, dass vom OEM-Paneltreiber gesendete Befehle Probleme mit nachfolgenden Grafiktreiberbefehlen verursachen, verringert werden muss. Zu diesem Zweck analysiert das Betriebssystem DCS-Befehle und lehnt Pakete ab, die zu Konflikten führen sollen, es sei denn, der OEM-Paneltreiber legt das ManufacturingMode Flag fest und das Betriebssystem bestätigt, dass sich das System im Fertigungsmodus befindet. Wenn das Flag festgelegt ist, sich das System aber nicht im Fertigungsmodus befindet, wird die IOCTL der Übertragung abgeschlossen, indem das DXGK_HOST_DSI_INVALID_TRANSMISSION Flag im HostErrors Feld festgelegt ist, ohne den Grafiktreiber aufzurufen.

Bedingungen, bei denen anstelle einer Übertragung eine vollständig definierte Transaktion erforderlich wäre, wären:

• Zeitzeiträume im Leerlauf sind vor oder nach erforderlich, z. B. DCS-soft_reset
• Ändern der Betriebsumgebung für die Frameausgabe, z. B. DCS-set_vsync_timing und enter_sleep_mode
• Verwenden von Transaktionen mit Start-/Weitersemantik, bei denen der Grafiktreiber möglicherweise auch auf dieselben Daten zugreifen muss, z. B. DCS-write_memory_start/write_memory_continue

Darüber hinaus gibt es Klassen von DCS-Befehlen, die vom Betriebssystem abgelehnt werden, wenn sie als Übertragung gesendet werden:

• Alle Befehle, die wie oben beschrieben vollständig definiert werden müssen
• Lesevorgänge von Pixeldaten, die zum Screen Scraping verwendet werden könnten
• Schreiben von Pixeldaten

UCS-Befehle, die das Betriebssystem an den Grafiktreiber übergibt

UCS-Befehle, die vom Betriebssystem abgelehnt werden

Grafiktreiberimplementierung

Wenn die Übertragung die Überprüfung des Betriebssystems besteht, übergibt das Betriebssystem den Puffer mithilfe von DsiTransmission an den Grafiktreiber.

Das Hinzufügen von OEM-Übertragungen zu einer Schnittstelle, die bereits zum Senden von Pixel- und Steuerungsdaten auf Grundlage von Betriebssystemanforderungen und den Anforderungen der Peripheriesteuerung verwendet wird, bedeutet zwangsläufig, dass der Grafiktreiber seine interne Sequenzierung verbessern muss, um sicherzustellen, dass dieser zusätzliche Datenstrom von Paketen ordnungsgemäß integriert werden kann. Der Grafiktreiber darf Pakete innerhalb einer Übertragung vom OEM-Paneltreiber nicht neu anordnen und muss die gesamte Sequenz ununterbrochen und ohne Verschachtelung anderer Pakete senden. Der Grafiktreiber ist nicht verpflichtet, die Reihenfolge seiner eigenen Pakete in Bezug auf den Zeitpunkt der Ankunft der OEM-Panelübertragungsanforderung aufrechtzuerhalten. Daher kann es sich entscheiden, Pakete zu senden, um den folgenden Frame vor (oder nach) dem Senden einer OEM-Panelübertragung einzurichten. Wenn der Abschluss einer gestarteten OEM-Panelübertragung dazu führt, dass kritische Pakete ihr Zeitfenster verpassen, sollte der Treiber die Übertragung als abgebrochen melden. Wenn eine Übertragung nicht gestartet wurde, aber der Treiber erwartet, dass kritische Pakete ihr Zeitfenster verpassen, sollte der Treiber den Start der Übertragung bis zum nächsten Leerungszeitraum zurückstellen. Wenn das Zurückstellen eines OEM-Panel-Getriebes dazu führen würde, dass es auf mehr als zwei Frames gewartet hat, um zu starten, sollte der Treiber das Getriebe als gelöscht melden.

Es ist nicht möglich, dass ein Grafiktreiber sicherstellen kann, dass die übertragungen, die er im Namen des Paneltreibers sendet, nicht mit den Übertragungen, über die er gesteuert hat, in Konflikt stehen. Der Treiber kann Pakete innerhalb einer Übertragung überprüfen und die Übertragung ablehnen, wenn sie Probleme verursachen würden, aber alle Pakete, die als unsicher angesehen werden, sollten für die Ablehnung auf Betriebssystemebene gekennzeichnet werden, sodass die Ablehnung auf Treiberebene idealerweise auf spezifischen Problemen des Grafikanbieters zurückzuführen ist. Der Treiber darf nicht versuchen, Lese- oder Schreibvorgänge zwischenzuspeichern oder zu optimieren, auch wenn es sich bei den Paketen um standardisierte Befehle handelt.

Wenn der Grafiktreiber eine Übertragung aufgrund eines Problems mit einem Paket ablehnt, muss er das FailedPacket Feld mit dem Index des ersten Pakets aktualisieren, das dazu führt, dass die Übertragung abgelehnt wird, und das HostErrors DXGK_HOST_DSI_DRIVER_REJECTED_PACKET-Flag festlegen, bevor er zurückgibt. Wenn eine Außerkraftsetzung des Übertragungsmodus bereitgestellt wird, sollte der Treiber überprüfen, ob die Außerkraftsetzung mit den Hardwareeinschränkungen kompatibel ist. Andernfalls sollte das flag DXGK_HOST_DSI_BAD_TRANSMISSION_MODE vor der HostErrors Rückgabe festgelegt werden.

Wenn während der Kommunikation ein Fehler auftritt, sollte der Grafiktreiber das FailedPacket Feld mit dem Index des Pakets aktualisieren, bei dem ein Fehler aufgetreten ist. Möglicherweise ist es jedoch nicht möglich, dass der Treiber das Paket identifiziert, sodass der Treiber in solchen Fällen den Standardwert DXGK_DSI_INVALID_PACKET_INDEX belassen sollte.

Der Grafiktreiber ist für die Kommunikation der Pakete verantwortlich und muss daher sicherstellen, dass alle Prüfsummen berechnet und überprüft werden. Jede Übertragung, die mit einem Lesevorgang endet, ist ein kurzes Paket, sodass die Felder Data0 und Data1 parameter enthalten, und die Antwort kann entweder ein kurzes oder langes Paket sein. Der Grafiktreiber weiß möglicherweise nicht, welche Form und wie lange die zurückgegebenen Daten sein werden, aber die maximale Größe ist die volle Größe der Nutzlast für das endgültige Paket, einschließlich .FinalPacketExtraPayload Das Betriebssystem überprüft, ob dieser Wert nicht größer als der TargetMaximumReturnPacketSize vom Treiber in seinen Funktionen für das Ziel gemeldete Wert ist, aber der Treiber muss sicherstellen, dass dieser Puffer nicht von einem Peripheriegerät, das mehr Daten meldet, überlaufen wird, und dass die Daten vom Peripheriegerät nicht abgeschnitten werden, da sie größer sind als die derzeit auf das Peripheriegerät angewendete MaximumReturnPacketSize. Der Treiber schreibt die Anzahl der in den Puffer gelesenen Bytes in das ReadWordCount Feld, das die Übertragung beschreibt.

Es kann Fälle geben, in denen der Grafiktreiber gezwungen ist, entweder die Kommunikationsschnittstelle auf das Panel oder das gesamte Panel zurückzusetzen, weil Fehler auftreten, die möglicherweise nicht mit dem OEM-Paneltreiber zusammenhängen und für diesen nicht sichtbar sind. Um dies zu beheben, muss der Treiber entweder DXGK_HOST_DSI_INTERFACE_RESET oder DXGK_HOST_DSI_DEVICE_RESET melden, die HostErrors beim ersten Übertragungsversuch nach dem Zurücksetzen im Feld festgelegt wurden, damit der OEM-Paneltreiber die Situation erkennen und wiederherstellen kann. Der Treiber darf diese Übertragung nicht an die Hardware senden, aber der OEM-Paneltreiber kann einfach den gleichen Befehl wiederholen, wenn keine Wiederherstellung erforderlich ist. In diesem Fall sollte der Treiber mit der Verarbeitung der Übertragung wie gewohnt fortfahren.

Abschließen einer Übertragung

Wenn die IOCTL abgeschlossen ist, wurden die FailedPacketNutzlast , ReadWordCount, MipiErrorsHostErrors und für ein gelesenes (endgültiges) Paket möglicherweise je nach Ergebnis aktualisiert. Wenn bei der Verarbeitung der Übertragung Fehler gefunden wurden, muss der OEM-Paneltreiber die MipiErrors Ausgabewerte und HostErrors verwenden, um zu bestimmen, wie wie wie und fortgesetzt werden soll.

Um sicherzustellen, dass die Ausgabe an den Aufrufer zurückgegeben wird, um Details zu Fehlern bereitzustellen, müssen IOCTL- und DDI-Aufrufe einen Erfolg melden, auch wenn Fehler gefunden werden. Erfolg gibt nicht an, dass die Transaktion erfolgreich war. Er gibt an, dass die Aufrufe zur Behandlung der Transaktion wie erwartet verlaufen sind und fehlerflags festgelegt wurden, falls angebracht. Fehler können weiterhin für Bedingungen wie einen nicht unterstützten DDI-Aufruf (vermutlich aufgrund eines Treiberkonflikts), Speicherbelegungsfehler oder das Übergeben vollständig fehlerhafter Parameter wie das Übergeben eines NULL-Puffers gemeldet werden. Wenn für einen erfolgreichen Aufruf keine Fehler gemeldet werden, sollte der Aufrufer davon ausgehen, dass die Transaktion erfolgreich war.

Anforderungen

Weitere Informationen

DsiTransmission

DXGK_DSI_PACKET

DXGK_DSI_TRANSMISSION

IOCTL_MIPI_DSI_QUERY_CAPS

IOCTL_MIPI_DSI_RESET