DXGKDDI_DSITRANSMISSION回呼函式 (dispmprt.h)
DxgkddiDsiTransmission 回呼函式會執行顯示序列介面 (DSI) 傳輸。
語法
DXGKDDI_DSITRANSMISSION DxgkddiDsitransmission;
NTSTATUS DxgkddiDsitransmission(
[in] HANDLE Context,
[in] D3DDDI_VIDEO_PRESENT_TARGET_ID TargetId,
[out] PDXGK_DSI_TRANSMISSION pArgs
)
{...}
參數
[in] Context
[in] TargetId
監視器的目標標識碼。
[out] pArgs
DXGI_DSI_TRANSMISSION 結構的指標。
傳回值
如果成功，DxgkddiDsiTransmission 會傳回STATUS_SUCCESS;否則會傳回 Ntstatus.h 中定義的其中一個錯誤碼。
備註
若要允許 OEM 面板驅動程式透過圖形適配卡與面板硬體之間的私用介面互動，交易必須沒有圖形驅動程式效果，而不是佔用總線的時間，或者必須完整定義它們，才能控制圖形驅動程式。 由於允許 OEM 面板驅動程式互動的重點是提供對圖形驅動程式不透明之自定義面板功能的支援，因此完整定義的作業僅限於面板驅動程式需要執行標準化作業，而不需要圖形驅動程式介入就能執行標準化作業。 這類交易會被視為明確路由傳送的例外狀況，而不是傳輸。
每個 DSI 傳輸要求是由 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 而且每個封包的前三個字節。 面板驅動程式可能會使用、ReportMipiErrors、 ManufacturingModeClearMipiErrorsSecondaryPort和 FinalCommandExtraPayload的非零值覆TransmissionMode寫預設行為。 所有未初始化的值都必須設定為零。
OS 可確保 DSI 封包的順序格式正確，且所有已定義的欄位和正確的緩衝區大小都有有效的資訊。 OS 負責將欄位初始化 FailedPacket 為DXGK_DSI_INVALID_PACKET_INDEX，如此一來，OS 或驅動程式中的進一步驗證只有在發現特定封包發生問題時，才需要設定字段。 如果 DXGK_DSI_TRANSMISSION 格式不正確，OS 會在 欄位中設定DXGK_HOST_DSI_INVALID_TRANSMISSION旗 HostErrors 標，以區別其他無效的參數錯誤。
若要視為格式正確，下列項目必須全部成立：
- 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
- 只允許讀取最後一個封包
- 只有最後的長寫入封包可以有
LongWriteWordCount大於 [DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE] 的值
封包驗證
雖然 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 將會完成，並在不呼叫圖形驅動程序的情況下，在欄位中設定 HostErrors DXGK_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 |
| 45 小時 | get_scanline |
OS 將拒絕的 UCS 命令：
| Hex | 命令 |
|---|---|
| 01h | soft_reset (必须透过 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 |
圖形驅動程序實作
如果傳輸通過OS驗證，OS會呼叫 DxgkDsiTransmission DDI，將緩衝區傳遞至圖形驅動程式。
將 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。 OS 會驗證此值是否大於 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 呼叫也需要回報成功。 成功不會指出交易成功，它表示在適當情況下，處理交易的呼叫會如預期般繼續，並已設定錯誤旗標。 由於驅動程式不相符) 、記憶體配置失敗或傳遞完全不正確的參數，例如傳遞 NULL 緩衝區等不受支援的 DDI 呼叫 (，仍可能會回報失敗。 如果未回報成功呼叫的錯誤，則呼叫端應該假設交易成功。
規格需求
| 需求 | 值 |
|---|---|
| 最低支援的用戶端 | Windows 10 (版本 2004) |
| 標頭 | dispmprt.h |