DXGKDDI_DSITRANSMISSION função de retorno de chamada (dispmprt.h)

A função de retorno de chamada DxgkddiDsiTransmission executa uma transmissão de DSI (Interface Serial de Exibição).

Sintaxe

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 do monitor.

[out] pArgs

Ponteiro para uma estrutura DXGI_DSI_TRANSMISSION .

Retornar valor

DxgkddiDsiTransmission retornará STATUS_SUCCESS se tiver êxito; caso contrário, retornará um dos códigos de erro definidos em Ntstatus.h.

Comentários

Para permitir que um driver de painel OEM interaja sobre a interface privada entre o adaptador gráfico e o hardware do painel, as transações não devem ter nenhum efeito de driver gráfico, além de tempo ocupando o barramento, ou devem ser totalmente definidas para que o driver gráfico esteja no controle. Como o ponto de permitir que um driver de painel OEM interaja é fornecer suporte para recursos de painel personalizados opacos para o driver gráfico, as operações totalmente definidas destinam-se a ser restritas a transações em que o driver de painel precisa executar uma operação padronizada que não pode ser executada sem o envolvimento do driver gráfico. Essas transações serão tratadas como exceções roteadas explicitamente e não como transmissões.

Cada solicitação de transmissão de DSI consiste em um único buffer que é preenchido pelo driver do painel OEM, passado para baixo na pilha do monitor e retornado com os resultados da transmissão, se houver. O buffer contém informações gerais sobre a transmissão, com campos de entrada e saída, seguidos por uma matriz de tamanho variável de estruturas DXGK_DSI_PACKET . Os pacotes são descritos em termos de DSI, de modo que qualquer pacote DSI possa ser descrito, no entanto, o sistema operacional analisará os pacotes e rejeitará qualquer transmissão que inclua pacotes que não são permitidos. Todos os pacotes, exceto o último, são, por definição de DSI, pacotes de gravação que podem ser gravações curtas, nesse caso, o Payload buffer não é usado ou gravações longas que se encaixam dentro do Payload buffer. O último pacote em uma transmissão, que pode ser uma leitura ou uma gravação, tem permissão para usar uma carga estendida alocando e descrevendo um buffer maior que permitirá espaço para leituras ou gravações de qualquer tamanho até o limite de dados de pacote longo de DSI de 64K-1 bytes de dados. Isso permite que sequências de pacotes de gravação pequenos sejam enfileiradas no driver em uma única chamada, mas exige que pacotes maiores sejam enviados individualmente. O valor do FinalPacketExtraPayload campo indica quantos bytes extras foram alocados, mas isso também deve ser contabilizado no TotalBufferSize campo .

O driver do painel OEM é responsável por garantir que as transmissões solicitadas não entrem em conflito ou interfiram com outras transmissões que o driver gráfico usa para interação normal com o painel devido a solicitações excessivas ou operações de solicitação que causariam atrasos no processamento de outras transmissões. O driver do painel não deve alterar nenhum estado que cause falhas subsequentes no driver gráfico, por exemplo, alterando o tempo do painel por meio de comandos MCS. Da mesma forma, se o sistema operacional solicitou uma alteração de exibição, por meio do driver gráfico, por exemplo, um aumento no brilho, o driver do painel não deve usar comandos DSI para desfazer essa alteração, seja em resposta ou para outras finalidades.

O IOCTL_MIPI_DSI_TRANSMISSION é usado para solicitar uma transmissão para o periférico que contém um ou mais pacotes DSI. O driver do painel sempre deve inicializar TotalBufferSizee PacketCount os três primeiros BYTES de cada pacote. O driver do painel pode substituir o comportamento padrão usando valores diferentes de zero para TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPortManufacturingMode e FinalCommandExtraPayload. Todos os valores não inicializados devem ser definidos como zero.

O sistema operacional garantirá que a sequência de pacotes DSI esteja bem formada, com informações válidas em todos os campos definidos e tamanhos de buffer corretos. O sistema operacional é responsável por inicializar o FailedPacket campo para DXGK_DSI_INVALID_PACKET_INDEX para que a validação adicional no sistema operacional ou driver só precise definir o campo se um problema for encontrado com um pacote específico. Se o DXGK_DSI_TRANSMISSION não estiver bem formado, o sistema operacional definirá o sinalizador DXGK_HOST_DSI_INVALID_TRANSMISSION no HostErrors campo para distingui-lo de outros erros de parâmetros inválidos.

Para ser considerado bem formado, todos os seguintes devem ser verdadeiros:

• 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
• Somente o último pacote tem permissão para ser lido
• Somente um pacote de gravação longa final pode ter um LongWriteWordCount valor maior que [DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE]

Validação de pacote

Embora o sistema operacional não tente validar totalmente o conteúdo de todos os pacotes, ele rejeitará uma transmissão contendo comandos DSI diferentes dos seguintes, concluindo o IOCTL sem chamar o driver gráfico:

Valor do tipo de dados	Descrição
0x03	GENERIC Short WRITE, sem parâmetros
0x13	Generic Short WRITE, 1 parâmetro
0x23	Generic Short WRITE, 2 parâmetros
0x04	READ genérico, sem parâmetros
0x14	Leia genérico, parâmetro 1
0x24	LEIA genérico, 2 parâmetros
0x05	DCS Short WRITE, sem parâmetros
0x15	DCS Short WRITE, 1 parâmetro
0x06	LEITURA DO DCS, sem parâmetros
0x29	Gravação longa genérica
0x39	Gravação/write_LUT longa do DCS

Comandos genéricos de leitura e gravação exigem a compreensão da especificação do painel, portanto, a expectativa é que esses comandos possam ser usados livremente pelo driver do painel sem causar problemas para o driver gráfico, desde que o barramento não seja usado excessivamente. Da mesma forma, os comandos MCS do DCS são definidos explicitamente para uso do fabricante, portanto, não deve haver nenhum problema com a interferência entre o driver gráfico e o driver do painel.

Para o DCS UCS, não se espera que comandos indefinidos sejam usados pelo driver gráfico, portanto, o sistema operacional permitirá que eles sejam usados pelo driver de painel, embora haja claramente um risco de que futuras alterações de especificação MIPI-DCS definam o comando para que os comandos MCS sejam preferenciais.

Os comandos DO DCS UCS padronizados serão usados pelo driver gráfico durante a operação normal e potencialmente utilizáveis pelo driver de painel, portanto, o risco de comandos enviados pelo driver do painel OEM causando problemas com comandos de driver de gráficos subsequentes precisa ser mitigado. Para fazer isso, o sistema operacional analisará comandos DCS e rejeitará pacotes que devem causar conflitos, a menos que o driver do painel OEM defina o ManufacturingMode sinalizador e o sistema operacional confirme que o sistema está no modo de fabricação. Se o sinalizador estiver definido, mas o sistema não estiver no modo de fabricação, o IOCTL de transmissão será concluído com o sinalizador DXGK_HOST_DSI_INVALID_TRANSMISSION definido no HostErrors campo sem chamar o driver gráfico.

As condições que exigiriam uma transação totalmente definida em vez de usar uma transmissão seriam as seguintes:

• Períodos ociosos cronometrado são necessários antes ou depois, como DCS soft_reset
• Alterando o ambiente operacional para saída de quadro, como set_vsync_timing DCS e enter_sleep_mode
• Usar transações com semântica de início/continuação em que o driver gráfico também pode precisar acessar os mesmos dados, como DCS write_memory_start/write_memory_continue

Além disso, há classes de comandos DCS que serão rejeitadas pelo sistema operacional quando enviadas como uma transmissão:

• Qualquer comando que precise ser totalmente definido, conforme descrito acima
• Leituras de dados de pixel que podem ser usados para extração de tela
• Gravações de dados de pixel

Comandos UCS que o sistema operacional passará para o driver gráfico:

Hex	Comando
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 o sistema operacional rejeitará:

Hex	Comando
01h	soft_reset (deve ser enviado por meio de um 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

Implementação do driver gráfico

Se a transmissão passar pela validação do sistema operacional, o sistema operacional passará o buffer para o driver gráfico chamando DxgkDsiTransmission DDI.

Adicionar transmissões OEM em uma interface que já está sendo usada para enviar dados de pixel e controle com base em solicitações do sistema operacional e nas necessidades de controle periférico, inevitavelmente significa que o driver gráfico precisará aprimorar seu sequenciamento interno para garantir que esse fluxo adicional de pacotes possa ser incorporado corretamente. O driver gráfico não deve reordenar pacotes dentro de uma transmissão do driver do painel OEM e deve enviar toda a sequência ininterrupta e sem intercalação de outros pacotes. O driver gráfico não é necessário para manter a ordem de seus próprios pacotes em relação ao momento da chegada da solicitação de transmissão do painel OEM, portanto, pode optar por enviar pacotes para configurar o quadro a seguir antes (ou depois) de enviar uma transmissão de painel OEM. Se a conclusão de uma transmissão iniciada do painel OEM ameaça fazer com que os pacotes críticos percam a janela de tempo, o driver deverá relatar a transmissão como cancelada. Se uma transmissão não tiver sido iniciada, mas o driver esperar que ela faça com que os pacotes críticos percam a janela de tempo, o driver deverá adiar a inicialização da transmissão até o próximo período de espaço em branco. Se adiar uma transmissão de painel OEM faria com que ela estivesse aguardando mais de dois quadros iniciar, o driver deverá relatar a transmissão como descartada.

Não é possível que um driver gráfico garanta que as transmissões enviadas em nome do driver do painel não entrem em conflito com as transmissões sobre as quais ele tem controle. O driver pode optar por inspecionar pacotes dentro de uma transmissão e rejeitar a transmissão se eles causarem problemas, mas quaisquer pacotes considerados não seguros devem ser sinalizados para rejeição no nível do sistema operacional, portanto, a rejeição no nível do driver deve ser ideal devido a preocupações específicas do fornecedor de gráficos. O driver não deve tentar armazenar em cache nem otimizar leituras ou gravações, mesmo que os pacotes pareçam ser comandos padronizados.

Se o driver gráfico rejeitar uma transmissão devido a um problema com um pacote, ele deverá atualizar o FailedPacket campo com o índice do primeiro pacote, fazendo com que a transmissão seja rejeitada e definir o HostErrors sinalizador DXGK_HOST_DSI_DRIVER_REJECTED_PACKET antes de retornar. Se uma substituição de modo de transmissão for fornecida, o driver deverá verificar se a substituição é compatível com suas restrições de hardware e, caso contrário, defina o HostErrors sinalizador DXGK_HOST_DSI_BAD_TRANSMISSION_MODE antes de retornar.

Se ocorrer uma falha durante a comunicação, o driver gráfico deverá atualizar o FailedPacket campo com o índice do pacote que falhou, no entanto, pode não ser possível, em todos os casos, que o driver identifique o pacote para que o driver deixe o valor padrão, DXGK_DSI_INVALID_PACKET_INDEX para esses casos.

O driver gráfico é responsável pela comunicação dos pacotes, portanto, deve garantir que todas as somas marcar sejam calculadas e verificadas. Qualquer transmissão que termine com uma leitura será um pacote curto, portanto, os campos Data0 e Data1 contêm parâmetros e a resposta pode ser um pacote curto ou longo. O driver gráfico pode não saber qual formulário e por quanto tempo os dados retornados ficarão, mas o tamanho máximo é o tamanho total do conteúdo do pacote final, incluindo o FinalPacketExtraPayload. O sistema operacional validará que esse valor não é maior do que o TargetMaximumReturnPacketSize relatado pelo driver em seus recursos para o destino, mas o driver deve garantir que esse buffer não seja invadido por um periférico relatando mais dados e que os dados do periférico não sejam truncados devido a serem maiores do que o MaximumReturnPacketSize atualmente aplicado ao periférico. O driver grava o número de bytes lidos no buffer no ReadWordCount campo que descreve a transmissão.

Pode haver casos em que o driver gráfico é forçado a redefinir a interface de comunicação para o painel ou todo o painel devido a erros que podem não estar relacionados e podem não ser observados para o driver do painel OEM. Para lidar com isso, o driver deve relatar DXGK_HOST_DSI_INTERFACE_RESET ou DXGK_HOST_DSI_DEVICE_RESET definidos no HostErrors campo na primeira tentativa de transmissão após a redefinição para que o driver do painel OEM possa detectar a situação e se recuperar. O driver não deve enviar essa transmissão para o hardware, mas o driver do painel OEM pode simplesmente repetir o mesmo comando se nenhuma recuperação for necessária, caso em que o driver deve prosseguir com o processamento da transmissão como de costume.

Concluindo uma transmissão

Quando o IOCTL conclui o FailedPacketconteúdo , ReadWordCount, MipiErrorsHostErrors e para um pacote de leitura (final) pode ter sido atualizado dependendo do resultado. Se forem encontrados erros durante o processamento da transmissão, o driver do painel OEM precisará usar os MipiErrors valores de saída e HostErrors para determinar como recuperar e continuar.

Para garantir que a saída seja retornada ao chamador para fornecer detalhes de quaisquer erros, as chamadas IOCTL e DDI precisam relatar um êxito, mesmo se forem encontrados erros. Êxito não indica que a transação foi bem-sucedida, indica que as chamadas para lidar com a transação prosseguiram conforme o esperado e os sinalizadores de erro foram definidos, se apropriado. Falhas ainda podem ser relatadas para condições como uma chamada DDI sem suporte (presumivelmente devido a uma incompatibilidade de driver), falhas de alocação de memória ou passagem de parâmetros completamente inválidos, como passar um buffer NULL. Se nenhum erro for relatado para uma chamada bem-sucedida, o chamador deverá assumir que a transação foi bem-sucedida.

Requisitos

Requisito	Valor
Cliente mínimo com suporte	Windows 10, versão 2004
Cabeçalho	dispmprt.h

Confira também

DXGI_DSI_TRANSMISSION