DXGKDDI_DSITRANSMISSION Rückruffunktion (dispmprt.h)
Die DxgkddiDsiTransmission Rückruffunktion führt eine DSI-Übertragung (Display Serial Interface) durch.
Syntax
DXGKDDI_DSITRANSMISSION DxgkddiDsitransmission;
NTSTATUS DxgkddiDsitransmission(
[in] HANDLE Context,
[in] D3DDDI_VIDEO_PRESENT_TARGET_ID TargetId,
[out] PDXGK_DSI_TRANSMISSION pArgs
)
{...}
Parameter
[in] Context
[in] TargetId
Zielbezeichner des Monitors.
[out] pArgs
Zeiger auf eine DXGI_DSI_TRANSMISSION Struktur.
Rückgabewert
DxgkddiDsiTransmission gibt STATUS_SUCCESS zurück, wenn dies erfolgreich ist; andernfalls wird eine der in Ntstatus.hdefinierten Fehlercodes zurückgegeben.
Bemerkungen
Damit ein OEM-Paneltreiber über die andernfalls 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 die Steuerung hat. Da der Zeitpunkt der Interaktion eines OEM-Paneltreibers darin besteht, Unterstützung für benutzerdefinierte Panelfeatures bereitzustellen, die für den Grafiktreiber undurchsichtig sind, sollen vollständig definierte Vorgänge auf Transaktionen beschränkt werden, bei denen der Paneltreiber einen standardisierten Vorgang ausführen muss, der ohne Beteiligung des Grafiktreibers nicht ausgeführt werden kann. Solche Transaktionen werden als Ausnahmen behandelt, die explizit und nicht als Übertragungen weitergeleitet werden.
Jede DSI-Übertragungsanforderung besteht aus einem einzelnen Puffer, der vom OEM-Paneltreiber gefüllt wird, den Monitorstapel übergeben und bei Bedarf mit den Ergebnissen der Übertragung zurückgegeben wird. Der Puffer enthält allgemeine Informationen zur Übertragung mit Eingabe- und Ausgabefeldern, gefolgt von einem Array mit variabler Größe von DXGK_DSI_PACKET Strukturen. Die Pakete werden in DSI-Ausdrücken beschrieben, sodass jedes DSI-Paket beschrieben werden kann, das Betriebssystem analysiert jedoch die Pakete und lehnt alle Übertragungen ab, die Pakete enthalten, die unzulässig sind. Alle Pakete mit Ausnahme der letzten sind, nach DSI-Definition, Pakete zu schreiben, die entweder kurze Schreibvorgänge sein können, in diesem Fall ist der Payload Puffer nicht verwendet, oder lange Schreibvorgänge, die in den Payload Puffer passen. Das letzte Paket in einer Übertragung, die ein Lese- oder Schreibvorgang sein kann, kann eine erweiterte Nutzlast verwenden, indem ein größerer Puffer zugeordnet und beschrieben wird, der Speicherplatz für Lese- oder Schreibvorgänge bis zum DSI-Long-Paketdatenlimit von 64K-1-Datenbytes ermöglicht. Dadurch können Sequenzen kleiner Schreibpakete an den Treiber in einem einzigen Anruf in die Warteschlange gestellt werden, erfordern jedoch, dass größere Pakete einzeln gesendet werden. Der Wert des Felds FinalPacketExtraPayload gibt an, wie viele zusätzliche Bytes zugeordnet wurden, dies muss jedoch auch im Feld TotalBufferSize berücksichtigt werden.
Der OEM-Paneltreiber ist dafür verantwortlich, sicherzustellen, dass die von ihr angeforderten Übertragungen keine Konflikte verursachen oder andere Übertragungen beeinträchtigen, die der Grafiktreiber für die normale Interaktion mit dem Panel verwendet, da übermäßige Anforderungen erforderlich sind 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 der Panelanzeigedauer über MCS-Befehle. Wenn das Betriebssystem eine Anzeigeänderung angefordert hat, z. B. über den Grafiktreiber, z. B. eine Erhöhung der Helligkeit, darf der Paneltreiber keine DSI-Befehle verwenden, um diese Änderung entweder als Reaktion oder für andere Zwecke rückgängig zu machen.
Die IOCTL_MIPI_DSI_TRANSMISSION wird verwendet, um eine Übertragung an das Peripheriegerät mit einem oder mehreren DSI-Paketen anzufordern. 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überschreiben. Alle nicht initialisierten Werte müssen auf Null festgelegt werden.
Das Betriebssystem stellt sicher, dass die Sequenz von DSI-Paketen wohlgeformt ist, mit gültigen Informationen in allen definierten Feldern und korrekten Puffergrößen. Das Betriebssystem ist dafür verantwortlich, das feld FailedPacket in DXGK_DSI_INVALID_PACKET_INDEX zu initialisieren, sodass eine weitere Überprüfung im Betriebssystem oder Treiber nur das Feld festlegen muss, wenn ein Problem mit einem bestimmten Paket gefunden wird. Wenn die DXGK_DSI_TRANSMISSION nicht wohlgeformt 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 wohlgeformt zu sein, muss folgendes wahr sein:
- 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 endgültiges langes Schreibpaket kann einen
LongWriteWordCountWert aufweisen, der größer als [DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE] ist.
Paketüberprüfung
Obwohl das Betriebssystem nicht versucht, den Inhalt aller Pakete vollständig zu überprüfen, wird eine Übertragung mit anderen DSI-Befehlen als den folgenden abgelehnt, ohne den Grafiktreiber aufzurufen:
| Datentypwert | Beschreibung |
|---|---|
| 0x03 | Generic Short WRITE, no parameters |
| 0x13 | Generic Short WRITE, 1 Parameter |
| 0x23 | Generic Short WRITE, 2 Parameter |
| 0x04 | Generisches LESEN, keine Parameter |
| 0x14 | Generic READ, 1 Parameter |
| 0x24 | Generische READ-Parameter, 2 Parameter |
| 0x05 | DCS Short WRITE, keine Parameter |
| 0x15 | DCS Short WRITE, 1 Parameter |
| 0x06 | DCS READ, keine Parameter |
| 0x29 | Generischer langer Schreibzugriff |
| 0x39 | DCS Long Write/write_LUT |
Generische Lese- und Schreibbefehle erfordern ein Verständnis der Panelspezifikation, sodass die Erwartung besteht, 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 Herstellerverwendung definiert, sodass es kein Problem mit Störungen zwischen dem Grafiktreiber und dem Paneltreiber geben sollte.
Für DCS UCS werden nicht definierte Befehle vom Grafiktreiber verwendet, sodass sie vom Paneltreiber verwendet werden können, obwohl es eindeutig ein Risiko gibt, 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 vom Paneltreiber verwendet werden, sodass das Risiko von Befehlen, die vom OEM-Paneltreiber gesendet werden, Probleme mit nachfolgenden Grafiktreiberbefehlen verursachen muss, verringert werden. Dazu 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 die Kennzeichnung festgelegt ist, sich das System jedoch nicht im Fertigungsmodus befindet, wird die Übertragungs-IOCTL mit dem im feld HostErrors festgelegten DXGK_HOST_DSI_INVALID_TRANSMISSION Flag abgeschlossen, ohne den Grafiktreiber aufzurufen.
Bedingungen, die eine vollständig definierte Transaktion anstelle einer Übertragung erfordern würden, wären:
- Zeitliche Leerlaufzeiten 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-/Fortsetzungsemantik, 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:
- Jeder Befehl, der vollständig definiert werden muss, wie oben beschrieben
- Lesevorgänge von Pixeldaten, die für bildschirmabwrackend verwendet werden können
- Schreiben von Pixeldaten
UCS-Befehle, die vom Betriebssystem an den Grafiktreiber übergeben werden:
| Fluch | Befehl |
|---|---|
| 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:
| Fluch | Befehl |
|---|---|
| 01h | soft_reset (muss über eine IOCTL_MIPI_DSI_RESETgesendet werden) |
| 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 |
Implementierung des Grafiktreibers
Wenn die Übertragung die Betriebssystemüberprüfung übergibt, übergibt das Betriebssystem den Puffer an den Grafiktreiber, indem DxgkDsiTransmission DDI aufgerufen wird.
Das Hinzufügen von OEM-Übertragungen zu einer Schnittstelle, die bereits verwendet wird, um Pixel- und Steuerdaten basierend auf Betriebssystemanforderungen und den Anforderungen der Peripheriesteuerung zu senden, 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 keine Pakete innerhalb einer Übertragung vom OEM-Paneltreiber neu anordnen und muss die gesamte Sequenz unterbrechungsfrei und ohne Interleaving anderer Pakete senden. Der Grafiktreiber ist nicht verpflichtet, die Reihenfolge seiner eigenen Pakete im Hinblick auf die Ankunft der OEM-Panelübertragungsanforderung aufrechtzuerhalten. Daher können Sie pakete senden, um den folgenden Frame vor (oder nach) zu senden, um eine OEM-Panelübertragung zu senden. Wenn der Abschluss einer gestarteten OEM-Panelübertragung gefährdet, 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 das Starten der Übertragung bis zum nächsten Leerlauf verzögern. Wenn das Zurückstellen einer OEM-Panelübertragung dazu führen würde, dass sie auf mehr als zwei Frames wartet, sollte der Treiber das Getriebe als verworfen melden.
Es ist nicht möglich, dass ein Grafiktreiber sicherstellen kann, dass die Übertragungen, die er im Auftrag des Paneltreibers sendet, nicht mit den Übertragungen in Konflikt stehen, über die es kontrolle hat. Der Treiber kann sich entscheiden, Pakete innerhalb einer Übertragung zu prüfen und die Übertragung abzulehnen, wenn sie Probleme verursachen würden, aber alle Pakete, die als unsicher eingestuft werden, sollten für ablehnung auf Betriebssystemebene gekennzeichnet werden, sodass die Ablehnung auf Treiberebene idealerweise auf spezifischen Bedenken des Grafikanbieters zurückzuführen sein sollte. Der Treiber darf nicht versuchen, entweder Lese- oder Schreibvorgänge zwischenzuspeichern oder zu optimieren, auch wenn die Pakete als standardisierte Befehle erscheinen.
Wenn der Grafiktreiber eine Übertragung aufgrund eines Problems mit einem Paket ablehnt, muss es 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 es zurückgegeben wird. Wenn eine Außerkraftsetzung für den Übertragungsmodus bereitgestellt wird, sollte der Treiber überprüfen, ob die Außerkraftsetzung mit den Hardwareeinschränkungen kompatibel ist. Andernfalls legen Sie das HostErrors DXGK_HOST_DSI_BAD_TRANSMISSION_MODE Flag vor der Rückgabe fest.
Wenn während der Kommunikation ein Fehler auftritt, sollte der Grafiktreiber das FailedPacket Feld mit dem Index des Pakets aktualisieren, das fehlgeschlagen ist, kann jedoch in allen Fällen nicht möglich sein, dass der Treiber das Paket identifizieren kann, damit der Treiber den Standardwert verlassen sollte, DXGK_DSI_INVALID_PACKET_INDEX für solche Fälle.
Der Grafiktreiber ist für die Kommunikation der Pakete verantwortlich, daher müssen Sie 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" alle Parameter enthalten, und die Antwort kann entweder ein kurzes oder langes Paket sein. Der Grafiktreiber weiß möglicherweise nicht, welches Formular und wie lange die zurückgegebenen Daten sein, aber die maximale Größe ist die volle Größe der Nutzlast für das endgültige Paket, einschließlich des FinalPacketExtraPayload. Das Betriebssystem überprüft, ob dieser Wert nicht größer als die vom Treiber in seinen Funktionen für das Ziel gemeldete TargetMaximumReturnPacketSize ist, aber der Treiber muss sicherstellen, dass dieser Puffer nicht von einem Peripheriegerät überlastet wird, das mehr Daten meldet, und dass Daten aus dem Peripheriegerät nicht abgeschnitten werden, da die MaximumReturnPacketSize derzeit auf das Peripheriegerät angewendet wird. 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 zurückzusetzen, oder das gesamte Panel aufgrund von Fehlern, die möglicherweise nicht mit dem OEM-Paneltreiber zusammenhängen und nicht feststellbar sind. Um dies zu bewältigen, muss der Treiber entweder DXGK_HOST_DSI_INTERFACE_RESET oder DXGK_HOST_DSI_DEVICE_RESET im Feld HostErrors auf dem ersten Übertragungsversuch nach dem Zurücksetzen festlegen, 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 denselben 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 das IOCTL die FailedPacket, ReadWordCount, MipiErrors, HostErrors und Nutzlast für ein Lesepaket (endgültig) abgeschlossen hat, wurde je nach Ergebnis möglicherweise aktualisiert. Wenn fehler beim Verarbeiten der Übertragung gefunden wurden, muss der OEM-Paneltreiber die MipiErrors und HostErrors Ausgabewerte verwenden, um zu bestimmen, wie sie wie wie sie wiederhergestellt 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. Der Erfolg weist nicht darauf hin, dass die Transaktion erfolgreich war, es gibt an, dass die Aufrufe zur Behandlung der Transaktion erwartungsgemäß ausgeführt wurden und falls zutreffend Fehlerkennzeichnungen festgelegt wurden. Fehler können für Bedingungen wie z. B. einen nicht unterstützten DDI-Aufruf (vermutlich aufgrund eines Treiberkonflikts), Speicherzuordnungsfehler oder das Übergeben vollständig fehlerhafter Parameter, z. B. das Übergeben eines NULL-Puffers, weiterhin gemeldet werden. Wenn für einen erfolgreichen Aufruf keine Fehler gemeldet werden, sollte der Aufrufer davon ausgehen, dass die Transaktion erfolgreich war.
Anforderungen
| Anforderung | Wert |
|---|---|
| mindestens unterstützte Client- | Windows 10, Version 2004 |
| Header- | dispmprt.h |