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 pantalla (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.
Observaciones
Para permitir que un controlador del 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 estar completamente definidos para que el controlador gráfico 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 gráfico, 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 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 los últimos son, por definición de DSI, paquetes de escritura que pueden ser escrituras cortas, en cuyo caso el búfer de Payload no se usa o escrituras largas que caben en el búfer de Payload. 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. 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 campo FinalPacketExtraPayload indica cuántos bytes adicionales se han asignado, pero también se debe tener en cuenta en el campo TotalBufferSize.
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 usa 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 provocaría errores posteriores en el controlador gráfico, 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 en el brillo, el controlador del panel no debe usar comandos DSI para deshacer ese cambio, ya sea en respuesta o para 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 TotalBufferSize, PacketCount y los tres primeros BYTES de cada paquete. El controlador del panel puede invalidar el comportamiento predeterminado mediante valores distintos de cero para TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode 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 campo de FailedPacket 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 un formato correcto, el sistema operativo establecerá la marca DXGK_HOST_DSI_INVALID_TRANSMISSION en el campo HostErrors para distinguirlo de otros errores de parámetros no válidos.
Para considerarse bien formado, 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 valor de
LongWriteWordCountmayor 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 cualquier comando DSI distinto del siguiente, 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 | Escritura breve genérica, 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 que el bus no se use excesivamente. Del mismo modo, los comandos MCS de DCS 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.
Para 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 MIPI-DCS especificación 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 causa problemas con los comandos del controlador de 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 marca de ManufacturingMode 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 campo HostErrors sin llamar al controlador gráfico.
Las condiciones que requerirían una transacción totalmente definida en lugar de usar una transmisión serían las siguientes:
- Los períodos de inactividad con tiempo de inactividad se requieren 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 es posible que el controlador de gráficos también necesite 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 describió 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:
| Maleficio | Mandar |
|---|---|
| 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 |
Comandos UCS que rechazará el sistema operativo:
| Maleficio | Mandar |
|---|---|
| 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 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 asegurarse de que esta secuencia adicional de paquetes se puede incorporar correctamente. El controlador de gráficos no debe reordenar paquetes dentro de una transmisión desde el controlador del panel OEM y debe enviar toda la secuencia ininterrumpida 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 aplazar una transmisión del panel OEM provocaría que hubiera estado esperando que se iniciaran más de dos fotogramas, el controlador debe notificar la transmisión como descartada.
No es posible que un controlador gráfico garantice 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 campo FailedPacket con el índice del primer paquete que provoca que se rechace la transmisión y establezca la marca HostErrors 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 marca HostErrors 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 campo FailedPacket con el índice del paquete que, sin embargo, puede que no sea posible en todos los casos para que el controlador identifique el paquete, por lo que el controlador debe 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 cualquier parámetro 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 el FinalPacketExtraPayload. El sistema operativo validará que este valor no es mayor que el TargetMaximumReturnPacketSize notificado por el controlador en sus funcionalidades para el destino, pero el controlador debe asegurarse de que este búfer no se supere mediante un informe periférico de más datos y que los datos del periférico no se truncan debido a que maximumReturnPacketSize se aplica actualmente al periférico. El controlador escribe el número de bytes leídos en el búfer en el campo ReadWordCount que describe la transmisión.
Puede haber casos en los que el controlador de gráficos se ve obligado a restablecer la interfaz de comunicaciones en el panel, o todo el panel debido a errores que pueden no estar relacionados con y puede que no sean observables para el controlador del panel OEM. Para solucionar esto, el controlador debe notificar DXGK_HOST_DSI_INTERFACE_RESET o DXGK_HOST_DSI_DEVICE_RESET establecido en el campo HostErrors 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 simplemente puede 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 el FailedPacket, ReadWordCount, MipiErrors, HostErrors y carga de un paquete de lectura (final) puede haberse actualizado en función del resultado. Si se encontraron errores durante el procesamiento de la transmisión, el controlador del panel OEM debe usar el MipiErrors y HostErrors valores de salida para determinar cómo recuperar 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 se han establecido las llamadas para controlar la transacción según lo previsto y se han establecido las marcas de error, si procede. Los errores todavía se pueden notificar para condiciones como una llamada DDI no admitida (supuestamente debido a un error de coincidencia de controladores), 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 | Valor |
|---|---|
| cliente mínimo admitido | Windows 10, versión 2004 |
| encabezado de | dispmprt.h |