IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)

Artikel
08/07/2023

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:

Datentypwert	BESCHREIBUNG
0x03	Generic Short WRITE, keine Parameter
0x13	Generic Short WRITE, 1 Parameter
0x23	Generischer KurzSCHREIBvorgang, 2 Parameter
0x04	Generisches READ, keine Parameter
0x14	Generisches READ, 1 Parameter
0x24	Generisches READ, 2 Parameter
0x05	DCS Short WRITE, keine Parameter
0x15	DCS Short WRITE, 1 Parameter
0x06	DCS READ, keine Parameter
0x29	Generischer langer Schreibvorgang
0x39	DCS Long Write/write_LUT

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

Hex	Get-Help
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

UCS-Befehle, die vom Betriebssystem abgelehnt werden

Hex	Get-Help
01h	soft_reset - Beachten Sie, dass dies über eine 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
36l	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

Hinweis

Die Richtlinien für die Betriebssystemüberprüfung können in zukünftigen Versionen geändert 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.