IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntd)
主要程式代碼： IRP_MJ_DEVICE_CONTROL
系統會發出IOCTL_MIPI_DSI_TRANSMISSION ，以將MIPI DSI 封包序列傳送至周邊。
主要程序代碼
輸入緩衝區
n/a
輸入緩衝區長度
n/a
輸出緩衝區
n/a
輸出緩衝區長度
n/a
輸入/輸出緩衝區
DXGK_DSI_TRANSMISSION結構，後面接著包含封包的DXGK_DSI_PACKET結構。
輸入/輸出緩衝區長度
至少 sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload。 如需詳細資訊，請參閱。
狀態區塊
Irp->如果要求成功，IoStatus.Status 會設定為 STATUS_SUCCESS。 否則， Status 會設定為適當的錯誤條件作為NTSTATUS程式代碼。 如需詳細資訊，請參閱 NTSTATUS值。
備註
監視器、oem 面板和顯示埠/迷你埠驅動程序必須處理行動產業處理器介面， (MIPI) 數位序列介面 (DSI) IOCTLs。
執行傳輸
若要允許面板驅動程式透過這個非私用介面在圖形適配卡和面板硬體之間互動，交易必須沒有圖形驅動程式效果，而不是佔用總線的時間，或者必須完全定義它們，才能控制圖形驅動程式。 由於允許面板驅動程式互動的重點是針對圖形驅動程式不透明的自定義面板功能提供支援，因此完整定義的作業僅限於面板驅動程式需要執行標準化作業，而不需要圖形驅動程式介入就能執行標準化作業。 這類交易會被視為明確路由傳送的例外狀況，而不是傳輸。
每個傳輸要求都包含由 OEM 面板驅動程式填滿的單一緩衝區、傳遞至監視堆疊，並在傳輸結果中傳回。如果有的話。 緩衝區包含傳輸的整體資訊，包含輸入和輸出字段，後面接著可變大小的 DXGK_DSI_PACKET 結構陣列。 封包會以 DSI 詞彙描述，因此可以描述任何 DSI 封包，不過 OS 會剖析封包，並拒絕包含不允許封包的任何傳輸。 除了最後一個封包之外，DSI 定義會寫入可能是簡短寫入的封包，在此情況下 未使用Payload 緩衝區，或符合 Payload 緩衝區內的長寫入。 傳輸中最後一個封包可能是讀取或寫入，可藉由配置並描述較大的緩衝區來使用擴充承載，以允許讀取或寫入任何大小的空間，最多可達 64K-1 個數據位元組的 DSI 長封包數據限制。 這可讓小型寫入封包序列在單一呼叫中排入驅動程式佇列，但確實需要個別傳送較大的封包。 FinalPacketExtraPayload 字段的值指出已配置的額外位元組數目，但這也必須在 TotalBufferSize 位元段中考慮。
OEM 面板驅動程式負責確保其要求的傳輸不會衝突，也不會干擾圖形驅動程式用於與面板正常互動的其他傳輸，因為要求過多或要求作業會導致處理其他傳輸延遲。 面板驅動程式不得變更任何會導致圖形驅動程式後續失敗的狀態，例如透過MCS命令變更面板計時。 同樣地，如果 OS 已透過圖形驅動程式要求顯示變更，例如亮度增加，面板驅動程式不得使用 DSI 命令來復原該變更，不論是回應或其他用途。
IOCTL_MIPI_DSI_TRANSMISSION 可用來要求傳輸至包含一或多個 DSI 封包的周邊。 面板驅動程式一律必須初始化 TotalBufferSize、 PacketCount 和每個封包的前三個 BYTES。 面板驅動程式可以使用 TransmissionMode、 ReportMipiErrors、 ClearMipiErrors、 SecondaryPort、 ManufacturingMode 和 FinalCommandExtraPayload 的非零值覆寫預設行為。 所有未初始化的值都必須設定為零。
OS 可確保 DSI 封包的順序格式正確，且所有已定義的欄位和正確的緩衝區大小都有有效的資訊。 OS 負責將 FailedPacket 字段初始化為DXGK_DSI_INVALID_PACKET_INDEX，如此一來，如果特定封包發現問題，則 OS 或驅動程式中的進一步驗證只需要設定欄位。 如果 DXGK_DSI_TRANSMISSION 結構格式不正確，OS 會在 HostErrors 欄位中設定DXGK_HOST_DSI_INVALID_TRANSMISSION旗標，以區別其他無效的參數錯誤。
若要視為格式正確，下列項目必須全部成立：
- 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
- 只允許讀取最後一個封包
- 只有最後的長寫入封包可以有大於 DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE 的LongWriteWordCount值
封包驗證
雖然 OS 不會嘗試完整驗證所有封包的內容，但它會拒絕包含下列任何 DSI 命令的傳輸，而不需要呼叫圖形驅動程式即可完成 IOCTL：
| 數據類型值 | Description |
|---|---|
| 0x03 | 泛型簡短寫入，無參數 |
| 0x13 | 一般簡短寫入，1 個參數 |
| 0x23 | 一般簡短寫入，2 個參數 |
| 0x04 | 泛型 READ，無參數 |
| 0x14 | 一般 READ，1 個參數 |
| 0x24 | 一般 READ，2 個參數 |
| 0x05 | DCS 簡短寫入，無參數 |
| 0x15 | DCS 簡短寫入，1 個參數 |
| 0x06 | DCS READ，無參數 |
| 0x29 | 泛型長寫入 |
| 0x39 | DCS 長寫入/write_LUT |
一般讀取和寫入命令需要瞭解面板規格，因此預期面板驅動程式可以自由使用這些命令，而不會造成圖形驅動程序的問題，只要總線未過度使用。 同樣地，DCS MCS 命令會明確定義供製造商使用，因此圖形驅動程式與面板驅動程式之間的干擾應該不會有任何問題。
針對 DCS UCS，圖形驅動程式不預期會使用未定義的命令，因此 OS 會允許面板驅動程式使用這些命令，不過未來 MIPI-DCS 規格變更會定義命令，因此建議使用 MCS 命令。
標準化的DCS UCS命令將會由圖形驅動程式在正常作業期間使用，而且面板驅動程式可能會使用，因此 OEM 面板驅動程式傳送的命令風險會導致後續圖形驅動程式命令發生問題需要減輕。 若要這樣做，除非 OEM 面板驅動程式設定 ManufacturingMode 旗標，且 OS 會確認系統處於製造模式，否則 OS 會剖析 DCS 命令，並拒絕預期會造成衝突的封包。 如果已設定旗標，但系統不在製造模式中，傳輸 IOCTL 將會完成，並在欄位中設定HostErrorsDXGK_HOST_DSI_INVALID_TRANSMISSION旗標，而不需呼叫圖形驅動程式。
需要完整定義交易而非使用傳輸的條件會是：
- DCS soft_reset
- 變更畫面輸出的作業環境，例如DCS set_vsync_timing和enter_sleep_mode
- 使用具有開始/繼續語意的交易，圖形驅動程式可能也需要存取相同的數據，例如 DCS write_memory_start/write_memory_continue
此外，當傳送為傳輸時，OS 會拒絕 DCS 命令的類別：
- 任何需要完整定義的命令，如上所述
- 可用於螢幕擷取的像素數據讀取
- 寫入像素數據
OS 將傳遞至圖形驅動程式的 UCS 命令
| Hex | 命令 |
|---|---|
| 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 |
| 14 小時 | get_image_checksum_rgb |
| 15 小時 | get_image_checksum_ct |
| 3Fh | get_3D_control |
| 45h | get_scanline |
OS 將拒絕的 UCS 命令
| Hex | 命令 |
|---|---|
| 01h | soft_reset - 請注意，這必須透過IOCTL_MIPI_DSI_RESET傳送 |
| 10h | enter_sleep_mode |
| 11 小時 | exit_sleep_mode |
| 12h | enter_partial_mode |
| 13 小時 | enter_normal_mode |
| 20 小時 | exit_invert_mode |
| 21 小時 | enter_invert_mode |
| 28 小時 | 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 |
注意
未來版本可能會修改 OS 驗證原則。
圖形驅動程序實作
如果傳輸通過OS驗證，OS 會使用 DsiTransmission 將緩衝區傳遞至圖形驅動程式。
將 OEM 傳輸新增至介面，以根據 OS 要求和控制數據以及周邊控制的需求來傳送圖元和控制數據，不一定表示圖形驅動程式必須增強其內部排序，以確保可以正確納入這個額外的封包串流。 圖形驅動程式不得從 OEM 面板驅動程式重新排序傳輸中的封包，而且必須不中斷且不會交錯其他封包的整個序列。 圖形驅動程式不需要維護自己的封包順序，以符合 OEM 面板傳輸要求抵達時間，因此可以選擇在傳送封包之前 (或) 傳送 OEM 面板傳輸之前，先傳送封包來設定下列框架。 如果完成已啟動的 OEM 面板傳輸威脅導致重大封包遺漏其時間範圍，驅動程式應該回報已取消的傳輸。 如果傳輸尚未啟動，但驅動程式預期它會造成重大封包遺漏其時間範圍，則驅動程式應該延遲開始傳輸，直到下一個空白期間為止。 如果延遲 OEM 面板傳輸會導致它等待兩個以上的畫面開始，驅動程式應該將傳輸回報為已捨棄。
圖形驅動程式無法確保它代表面板驅動程式傳送的傳輸不會與其擁有控制權的傳輸衝突。 驅動程式可能會選擇檢查傳輸內的封包，並在發生問題時拒絕傳輸，但任何被視為不安全的封包都應該標示為操作系統層級拒絕，因此驅動程式層級拒絕最好是因為圖形廠商的特定考慮所造成。 驅動程式不得嘗試快取或優化讀取或寫入，即使封包似乎為標準化命令也一樣。
如果圖形驅動程式因為封包發生問題而拒絕傳輸，它必須以第一個封包的索引更新 FailedPacket 欄位，導致傳輸遭到拒絕，並在傳回之前設定 HostErrors DXGK_HOST_DSI_DRIVER_REJECTED_PACKET旗標。 如果提供傳輸模式覆寫，驅動程式應該先確認覆寫與其硬體條件約束相容，如果沒有，請先設定 HostErrors DXGK_HOST_DSI_BAD_TRANSMISSION_MODE旗標再傳回。
如果在通訊期間發生失敗，圖形驅動程式應該使用失敗的封包索引來更新 FailedPacket 欄位，不過在驅動程序識別封包的所有情況下都可能無法識別封包，因此驅動程式應該保留預設值，DXGK_DSI_INVALID_PACKET_INDEX這類情況。
圖形驅動程式負責封包的通訊，因此必須確定會計算和驗證任何檢查總和。 以讀取結尾的任何傳輸都會是簡短封包，因此 Data0 和 Data1 欄位包含任何參數，而回應可能是簡短或長封包。 圖形驅動程式可能不知道傳回數據的格式和長度，但最大大小是最終封包承載的完整大小，包括 FinalPacketExtraPayload。 操作系統會驗證此值是否大於 TargetMaximumReturnPacketSize 驅動程式在其目標功能中回報的值，但驅動程式必須確定周邊報告更多數據不會覆寫此緩衝區，而且來自周邊的數據不會因為大於目前套用至周邊的 MaximumReturnPacketSize 而遭到截斷。 驅動程式會將讀取到緩衝區 ReadWordCount 的位元組數目寫入描述傳輸的欄位中。
在某些情況下，圖形驅動程式會強制將通訊介面重設為面板，或因為可能與 OEM 面板驅動程式無關的錯誤而造成整個面板。 若要解決這個問題，驅動程式必須在重設之後的第一次傳輸嘗試之後回報DXGK_HOST_DSI_INTERFACE_RESET或DXGK_HOST_DSI_DEVICE_RESET設定 HostErrors ，讓 OEM 面板驅動程式可以偵測情況並復原。 如果不需要復原，驅動程式不得將此傳輸傳送至硬體，但 OEM 面板驅動程式可能會直接重試相同的命令，在此情況下，驅動程式應該如往常一樣處理傳輸。
完成傳輸
當 IOCTL 完成FailedPacket讀取 (最終) 封包的 、ReadWordCount、 MipiErrorsHostErrors 和 承載時，可能會根據結果更新。 如果在處理傳輸時發現錯誤，OEM 面板驅動程式必須使用 MipiErrors 和 HostErrors 輸出值來判斷如何復原並繼續。
為了確保輸出會傳回給呼叫端，以提供任何錯誤的詳細數據，即使發現錯誤，IOCTL 和 DDI 呼叫也需要回報成功。 成功不表示交易成功，它表示處理交易的呼叫會如預期般繼續，並已設定錯誤旗標。 可能仍會針對不支援的 DDI 呼叫等狀況回報失敗， (可能是因為驅動程式不符) 、記憶體配置失敗或傳遞完全不正確的參數，例如傳遞 NULL 緩衝區。 如果成功呼叫未回報任何錯誤，則呼叫端應該假設交易成功。
規格需求
| 需求 | 值 |
|---|---|
| 最低支援的用戶端 | Windows 10 (版本 2004) |
| 標頭 | ntdhseo.h |