DXGKDDI_DSITRANSMISSION función de devolución de llamada (dispmprt.h)
La función de devolución de llamada DxgkddiDsiTransmission realiza una transmisión de interfaz serie de visualización (DSI).
Sintaxis
DXGKDDI_DSITRANSMISSION DxgkddiDsitransmission;
NTSTATUS DxgkddiDsitransmission(
[in] HANDLE Context,
[in] D3DDDI_VIDEO_PRESENT_TARGET_ID TargetId,
[out] PDXGK_DSI_TRANSMISSION pArgs
)
{...}
Parámetros
[in] Context
[in] TargetId
Identificador de destino del monitor.
[out] pArgs
Puntero a una estructura de DXGI_DSI_TRANSMISSION .
Valor devuelto
DxgkddiDsiTransmission devuelve STATUS_SUCCESS si se realiza correctamente; de lo contrario, devuelve uno de los códigos de error definidos en Ntstatus.h.
Comentarios
Para permitir que un controlador de panel OEM interactúe sobre la interfaz privada en caso contrario entre el adaptador de gráficos y el hardware del panel, las transacciones no deben tener ningún efecto de controlador gráfico, excepto el tiempo que ocupa el bus o deben definirse completamente para que el controlador de gráficos esté en control. Dado que el punto de permitir que un controlador del panel OEM interactúe es proporcionar compatibilidad con características de panel personalizadas que son opacas para el controlador de gráficos, las operaciones totalmente definidas están pensadas para restringirse a las transacciones en las que el controlador del panel necesita realizar una operación estandarizada que no se puede realizar sin la participación del controlador gráfico. Estas transacciones se tratarán como excepciones enrutadas explícitamente en lugar de como transmisiones.
Cada solicitud de transmisión DSI consta de un único búfer que se rellena por el controlador del panel OEM, pasa la pila del monitor y se devuelve con los resultados de la transmisión, si existe. El búfer contiene información general sobre la transmisión, con campos de entrada y salida, seguidos de una matriz de tamaño variable de DXGK_DSI_PACKET estructuras. Los paquetes se describen en términos de DSI, de modo que cualquier paquete DSI se pueda describir, sin embargo, el sistema operativo analizará los paquetes y rechazará cualquier transmisión que incluya paquetes que no se permitan. Todos los paquetes excepto el último son, por definición de DSI, los paquetes de escritura que pueden ser escrituras cortas, en cuyo caso el Payload búfer no se usa o las escrituras largas que caben dentro del Payload búfer. El último paquete de una transmisión, que puede ser de lectura o escritura, puede usar una carga extendida mediante la asignación y descripción de un búfer mayor que permitirá espacio para lecturas o escrituras de cualquier tamaño hasta el límite de datos de paquetes largos DSI de 64K-1 bytes de datos. Esto permite que las secuencias de paquetes de escritura pequeños se ponen en cola en el controlador en una sola llamada, pero requiere que los paquetes más grandes se envíen individualmente. El valor del FinalPacketExtraPayload campo indica cuántos bytes adicionales se han asignado, pero también se debe tener en cuenta en el TotalBufferSize campo .
El controlador del panel OEM es responsable de garantizar que las transmisiones que solicita no entren en conflicto o interfieran con otras transmisiones que el controlador gráfico utiliza para la interacción normal con el panel debido a solicitudes excesivas o operaciones de solicitud que provocarían retrasos en el procesamiento de otras transmisiones. El controlador del panel no debe cambiar ningún estado que cause errores posteriores en el controlador de gráficos, por ejemplo, cambiar el tiempo del panel a través de comandos MCS. Del mismo modo, si el sistema operativo ha solicitado un cambio de pantalla, a través del controlador de gráficos, por ejemplo, un aumento del brillo, el controlador del panel no debe usar comandos DSI para deshacer ese cambio, ya sea en respuesta o con otros fines.
El IOCTL_MIPI_DSI_TRANSMISSION se usa para solicitar una transmisión al periférico que contiene uno o varios paquetes DSI. El controlador del panel siempre debe inicializar TotalBufferSizey PacketCount los tres primeros BYTES de cada paquete. El controlador de panel puede invalidar el comportamiento predeterminado mediante valores distintos de cero para TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPortManufacturingMode y FinalCommandExtraPayload. Todos los valores sin inicializar deben establecerse en cero.
El sistema operativo garantizará que la secuencia de paquetes DSI esté bien formada, con información válida en todos los campos definidos y tamaños de búfer correctos. El sistema operativo es responsable de inicializar el FailedPacket campo en DXGK_DSI_INVALID_PACKET_INDEX para que la validación adicional en el sistema operativo o el controlador solo necesite establecer el campo si se encuentra un problema con un paquete determinado. Si el DXGK_DSI_TRANSMISSION no tiene el formato correcto, el sistema operativo establecerá la marca DXGK_HOST_DSI_INVALID_TRANSMISSION en el HostErrors campo para distinguirlo de otros errores de parámetros no válidos.
Para considerarse bien formado, todo lo siguiente debe ser 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
- Solo se permite que el último paquete sea una lectura.
- Solo un paquete de escritura larga final puede tener un
LongWriteWordCountvalor mayor que [DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE]
Validación de paquetes
Aunque el sistema operativo no intentará validar completamente el contenido de todos los paquetes, rechazará una transmisión que contenga comandos DSI distintos de los siguientes, completando el IOCTL sin llamar al controlador de gráficos:
| Valor de tipo de datos | Descripción |
|---|---|
| 0x03 | Escritura corta genérica, sin parámetros |
| 0x13 | Generic Short WRITE, 1 parámetro |
| 0x23 | Generic Short WRITE, 2 parámetros |
| 0x04 | LECTURA genérica, sin parámetros |
| 0x14 | Read genérico, 1 parámetro |
| 0x24 | Lectura genérica, 2 parámetros |
| 0x05 | DCS Short WRITE, sin parámetros |
| 0x15 | DCS Short WRITE, 1 parámetro |
| 0x06 | DCS READ, sin parámetros |
| 0x29 | Escritura larga genérica |
| 0x39 | Escritura y write_LUT largos de DCS |
Los comandos genéricos de lectura y escritura requieren comprender la especificación del panel, por lo que la expectativa es que el controlador del panel pueda usar libremente estos comandos sin causar problemas para el controlador de gráficos siempre y cuando el bus no se use excesivamente. Del mismo modo, los comandos DCS MCS se definen explícitamente para el uso del fabricante, por lo que no debe haber ningún problema con la interferencia entre el controlador gráfico y el controlador del panel.
En el caso de DCS UCS, no se espera que los comandos no definidos los use el controlador de gráficos, por lo que el sistema operativo les permitirá usarlos por el controlador del panel, aunque existe claramente un riesgo de que los cambios futuros en la especificación MIPI-DCS definan el comando, por lo que se prefieren los comandos MCS.
El controlador de gráficos usará los comandos DCS UCS estandarizados durante el funcionamiento normal y es posible que el controlador del panel pueda usarlos, por lo que es necesario mitigar el riesgo de comandos enviados por el controlador del panel OEM que provoca problemas con comandos de controladores gráficos posteriores. Para ello, el sistema operativo analizará los comandos dcS y rechazará los paquetes que se espera que causen conflictos a menos que el controlador del panel OEM establezca la ManufacturingMode marca y el sistema operativo confirme que el sistema está en modo de fabricación. Si se establece la marca pero el sistema no está en modo de fabricación, el IOCTL de transmisión se completará con la marca DXGK_HOST_DSI_INVALID_TRANSMISSION establecida en el HostErrors campo sin llamar al controlador de gráficos.
Las condiciones que requerirían una transacción totalmente definida en lugar de usar una transmisión serían las siguientes:
- Se requieren períodos de inactividad con tiempo de inactividad antes o después, como DCS soft_reset
- Cambio del entorno operativo para la salida de fotogramas, como dcs set_vsync_timing y enter_sleep_mode
- Uso de transacciones con semántica de inicio/continuación, donde el controlador de gráficos también puede necesitar acceder a los mismos datos, como DCS write_memory_start/write_memory_continue
Además, hay clases de comandos dcS que el sistema operativo rechazará cuando se envíe como transmisión:
- Cualquier comando que deba definirse por completo, como se ha descrito anteriormente.
- Lecturas de datos de píxeles que se podrían usar para la extracción de pantalla
- Escrituras de datos de píxeles
Comandos UCS que el sistema operativo pasará al controlador de gráficos:
| Hex | Get-Help |
|---|---|
| 00 h | 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 |
Comandos UCS que rechazará el sistema operativo:
| Hex | Get-Help |
|---|---|
| 01h | soft_reset (debe enviarse a través de un 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 |
Implementación del controlador gráfico
Si la transmisión pasa la validación del sistema operativo, el sistema operativo pasa el búfer al controlador de gráficos llamando a DxgkDsiTransmission DDI.
Agregar transmisiones OEM a una interfaz que ya se está usando para enviar datos de píxeles y de control basados en las solicitudes del sistema operativo y las necesidades de control periférico, inevitablemente significa que el controlador de gráficos tendrá que mejorar su secuencia interna para garantizar que esta secuencia adicional de paquetes se pueda incorporar correctamente. El controlador gráfico no debe reordenar los paquetes dentro de una transmisión desde el controlador del panel OEM y debe enviar toda la secuencia sin interrupciones y sin intercalar otros paquetes. El controlador gráfico no es necesario para mantener el orden de sus propios paquetes con respecto a la hora de llegada de la solicitud de transmisión del panel OEM, por lo que puede optar por enviar paquetes para configurar el siguiente fotograma antes (o después) de enviar una transmisión del panel OEM. Si la finalización de una transmisión iniciada del panel OEM amenaza con provocar que los paquetes críticos pierdan su período de tiempo, el controlador debe notificar la transmisión como cancelada. Si no se ha iniciado una transmisión, pero el controlador espera que provoque que los paquetes críticos pierdan su período de tiempo, el controlador debe aplazar el inicio de la transmisión hasta el siguiente período de espacio en blanco. Si aplazara una transmisión del panel OEM provocaría que hubiera estado esperando que se iniciaran más de dos fotogramas, el controlador debe informar de la transmisión tal como se quitó.
No es posible que un controlador gráfico se asegure de que las transmisiones que envía en nombre del controlador del panel no entren en conflicto con las transmisiones sobre las que tiene control. El controlador puede optar por inspeccionar los paquetes dentro de una transmisión y rechazar la transmisión si causarían problemas, pero los paquetes que se consideran no seguros deben marcarse para el rechazo del nivel del sistema operativo, por lo que el rechazo del nivel de controlador debería deberse idealmente a problemas específicos del proveedor de gráficos. El controlador no debe intentar almacenar en caché ni optimizar las lecturas o escrituras, incluso si los paquetes parecen ser comandos estandarizados.
Si el controlador de gráficos rechaza una transmisión debido a un problema con un paquete, debe actualizar el FailedPacket campo con el índice del primer paquete que hace que la transmisión se rechace y establezca la HostErrors marca DXGK_HOST_DSI_DRIVER_REJECTED_PACKET antes de devolver. Si se proporciona una invalidación del modo de transmisión, el controlador debe comprobar que la invalidación es compatible con sus restricciones de hardware y, si no es así, establezca la HostErrors marca DXGK_HOST_DSI_BAD_TRANSMISSION_MODE antes de devolverla.
Si se produce un error durante la comunicación, el controlador de gráficos debe actualizar el FailedPacket campo con el índice del paquete que produjo un error, pero es posible que no sea posible en todos los casos para que el controlador identifique el paquete para que el controlador deba dejar el valor predeterminado, DXGK_DSI_INVALID_PACKET_INDEX para estos casos.
El controlador de gráficos es responsable de la comunicación de los paquetes, por lo que debe asegurarse de que las sumas de comprobación se calculan y comprueban. Cualquier transmisión que termine con una lectura será un paquete corto, por lo que los campos Data0 y Data1 contienen parámetros y la respuesta puede ser un paquete corto o largo. Es posible que el controlador de gráficos no sepa qué formulario y cuánto tiempo serán los datos devueltos, pero el tamaño máximo es el tamaño completo de la carga para el paquete final, incluido .FinalPacketExtraPayload El sistema operativo validará que este valor no es mayor que el notificado por el TargetMaximumReturnPacketSize controlador en sus funcionalidades para el destino, pero el controlador debe asegurarse de que este búfer no está saturado por un periférico que informa de más datos y que los datos del periférico no se truncan debido a que es mayor que maximumReturnPacketSize aplicado actualmente al periférico. El controlador escribe el número de bytes leídos en el búfer en el ReadWordCount campo que describe la transmisión.
Puede haber casos en los que el controlador de gráficos se vea obligado a restablecer la interfaz de comunicaciones al panel o a todo el panel debido a errores que pueden no estar relacionados y puede que no sean observables para el controlador del panel OEM. Para solucionarlo, el controlador debe notificar DXGK_HOST_DSI_INTERFACE_RESET o DXGK_HOST_DSI_DEVICE_RESET establecer en el HostErrors campo en el primer intento de transmisión después del restablecimiento para que el controlador del panel OEM pueda detectar la situación y recuperarse. El controlador no debe enviar esta transmisión al hardware, pero el controlador del panel OEM puede simplemente reintentar el mismo comando si no se requiere ninguna recuperación, en cuyo caso el controlador debe continuar con el procesamiento de la transmisión como de costumbre.
Finalización de una transmisión
Cuando el IOCTL completa la FailedPacketcarga , ReadWordCount, MipiErrorsHostErrors y para un paquete de lectura (final) se puede haber actualizado según el resultado. Si se encontraron errores durante el procesamiento de la transmisión, el controlador del panel OEM debe usar los MipiErrors valores de salida y HostErrors para determinar cómo recuperarse y continuar.
Para asegurarse de que la salida se devuelve al autor de la llamada para proporcionar detalles de los errores, las llamadas IOCTL y DDI deben notificar un éxito, incluso si se encuentran errores. Correcto no indica que la transacción se realizó correctamente, indica que las llamadas para controlar la transacción continuaron según lo previsto y se han establecido las marcas de error, si procede. Es posible que todavía se notifiquen errores en condiciones como una llamada DDI no admitida (probablemente debido a un error de coincidencia del controlador), errores de asignación de memoria o pasar parámetros completamente incorrectos, como pasar un búfer NULL. Si no se notifica ningún error para una llamada correcta, el autor de la llamada debe suponer que la transacción se realizó correctamente.
Requisitos
| Requisito | Value |
|---|---|
| Cliente mínimo compatible | Windows 10, versión 2004 |
| Encabezado | dispmprt.h |