IOCTL_MIPI_DSI_TRANSMISSION IOCTL （ntddvdeo.h）
发出 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（如果请求成功）。 否则，状态 设置为 NTSTATUS 代码的相应错误条件。 有关详细信息，请参阅 NTSTATUS 值。
言论
监视器、oem 面板和显示端口/微型端口驱动程序必须处理移动行业处理器接口（MIPI）数字串行接口（DSI）IOCTL。
执行传输
若要允许面板驱动程序通过这种非专用接口在图形适配器和面板硬件之间进行交互，事务必须没有图形驱动程序效果，而不是占用总线的时间，或者必须完全定义它们，以便图形驱动程序处于控制状态。 由于允许面板驱动程序交互的要点是为图形驱动程序不透明自定义面板功能提供支持，因此完全定义的作仅限于面板驱动程序需要执行标准化作的事务，无需图形驱动程序参与即可执行。 此类事务将被视为显式路由的异常，而不是传输。
每个传输请求由 OEM 面板驱动程序填充的单个缓冲区组成，通过监视器堆栈传递并返回传输结果（如果有）。 缓冲区包含有关传输的总体信息，包括输入和输出字段，后跟 DXGK_DSI_PACKET 结构的可变大小数组。 数据包以 DSI 术语进行描述，因此可以描述任何 DSI 数据包，但 OS 将分析数据包并拒绝包含不允许数据包的任何传输。 除最后一个数据包之外的所有数据包都由 DSI 定义，写入数据包可能是短写入，在这种情况下，未使用 Payload 缓冲区，或适合 有效负载 缓冲区中的长写入。 传输中的最后一个数据包（可以是读取或写入）可以通过分配和描述更大的缓冲区来使用扩展有效负载，该缓冲区允许读取或写入任何大小（最大为 64K-1 数据字节）的 DSI 长数据包数据限制。 这允许在单个调用中将小型写入数据包的序列排入驱动程序队列，但确实要求单独发送更大的数据包。 FinalPacketExtraPayload 字段的值指示已分配的额外字节数，但还必须在 totalBufferSize 字段中考虑这一点。
OEM 面板驱动程序负责确保它请求的传输不会冲突或干扰图形驱动程序用于正常交互面板的其他传输，因为请求过多或请求作会导致处理其他传输时出现延迟。 面板驱动程序不得更改导致图形驱动程序中后续故障的任何状态，例如通过 MCS 命令更改面板计时。 同样，如果 OS 通过图形驱动程序请求显示更改，例如亮度增加，面板驱动程序不得使用 DSI 命令撤消该更改，无论是响应还是出于其他目的。
IOCTL_MIPI_DSI_TRANSMISSION 用于请求传输到包含一个或多个 DSI 数据包的外围设备。 面板驱动程序必须始终初始化 totalBufferSize，PacketCount 和每个数据包的前三个字节。 面板驱动程序可以使用非零值替代默认行为，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标志，以将此与其他无效参数错误区分开来。
要被视为格式良好，必须全部为 true：
- 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：
| 数据类型值 | 描述 |
|---|---|
| 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 面板驱动程序发送的命令导致后续图形驱动程序命令出现问题的风险。 为此，OS 将分析 DCS 命令并拒绝预期会导致冲突的数据包，除非 OEM 面板驱动程序设置 ManufacturingMode 标志，并且 OS 确认系统处于制造模式。 如果设置了标志，但系统不在制造模式下，则传输 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 命令
| 十六进制 | 命令 |
|---|---|
| 00h | nop |
| 26 小时 | set_gamma_curve |
| 2Dh | write_LUT |
| 51 小时 | set_display_brightness |
| 52 小时 | get_display_brightness |
| 53 小时 | write_control_display |
| 54 小时 | get_control_display |
| 55 小时 | write_power_save |
| 56h | get_power_save |
| 5Eh | set_CABC_min_brightness |
| 5Fh | get_CABC_min_brightness |
| 03 小时 | get_compression_mode |
| 05 小时 | 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 命令
| 十六进制 | 命令 |
|---|---|
| 01 小时 | soft_reset - 请注意，这必须通过 IOCTL_MIPI_DSI_RESET 发送 |
| 10 小时 | enter_sleep_mode |
| 11 小时 | exit_sleep_mode |
| 12 小时 | enter_partial_mode |
| 13 小时 | enter_normal_mode |
| 20 小时 | exit_invert_mode |
| 21 小时 | enter_invert_mode |
| 28 小时 | set_display_off |
| 29 小时 | set_display_on |
| 2Ah | set_column_address |
| 2Bh | set_page_address |
| 2Ch | write_memory_start |
| 2Eh | read_memory_start |
| 30 小时 | set_partial_rows |
| 31 小时 | set_partial_columns |
| 33 小时 | set_scroll_area |
| 34 小时 | set_tear_off |
| 35 小时 | set_tear_on |
| 36 小时 | set_address_mode |
| 37 小时 | set_scroll_start |
| 38 小时 | exit_idle_mode |
| 39 小时 | enter_idle_mode |
| 3Ah | set_pixel_format |
| 3Ch | write_memory_continue |
| 3Dh | set_3D_control |
| 3Eh | read_memory_continue |
| 40h | set_vsync_timing |
| 44 小时 | 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 面板传输会导致它等待两个以上的帧启动，驱动程序应将传输报告为已删除。
图形驱动程序无法确保它代表面板驱动程序发送的传输不会与其拥有控制权的传输发生冲突。 驱动程序可以选择检查传输中的数据包并拒绝传输（如果会导致问题），但任何被认为不安全的数据包都应标记为 OS 级别拒绝，因此最好是由于图形供应商特定问题导致的驱动程序级别拒绝。 即使数据包似乎是标准化命令，驱动程序也不能尝试缓存或优化读取或写入。
如果图形驱动程序因数据包问题而拒绝传输，则必须使用第一个数据包的索引更新 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 大于 MaximumReturnPacketSize，因此不会截断来自外围设备的数据。 驱动程序将读取缓冲区中的字节数写入描述传输的 ReadWordCount 字段中。
在某些情况下，图形驱动程序被迫将通信接口重置到面板，或者整个面板因错误而可能与 OEM 面板驱动程序无关，并且可能无法观察到。 若要解决此问题，驱动程序必须在重置后的第一次传输尝试报告DXGK_HOST_DSI_INTERFACE_RESET或DXGK_HOST_DSI_DEVICE_RESET在 HostErrors 字段中设置，以便 OEM 面板驱动程序能够检测情况并恢复。 驱动程序不得将此传输发送到硬件，但如果不需要恢复，OEM 面板驱动程序可能只需重试相同的命令，在这种情况下，驱动程序应像往常一样继续处理传输。
完成传输
当 IOCTL 完成读取（最终）数据包的 FailedPacket、ReadWordCount、MipiErrors、HostErrors 和有效负载时，可能会根据结果更新。 如果在处理传输时发现错误，OEM 面板驱动程序需要使用 MipiErrors 和 HostErrors 输出值来确定如何恢复并继续。
为了确保将输出返回到调用方以提供任何错误的详细信息，即使发现错误，IOCTL 和 DDI 调用也需要报告成功。 成功并不表示事务成功，它表示处理事务的调用按预期进行，并且已设置错误标志（如果适用）。 对于不受支持的 DDI 调用（大概由于驱动程序不匹配）、内存分配失败或传递完全错误的参数（例如传递 NULL 缓冲区）等条件，仍可能会报告失败。 如果成功调用未报告任何错误，则调用方应假定事务成功。
要求
| 要求 | 价值 |
|---|---|
| 最低支持的客户端 | Windows 10 版本 2004 |
| 标头 | ntddvdeo.h |