DXGKDDI_DSITRANSMISSION funzione di callback (dispmprt.h)
La DxgkddiDsiTransmission funzione di callback esegue una trasmissione DSI (Display Serial Interface).
Sintassi
DXGKDDI_DSITRANSMISSION DxgkddiDsitransmission;
NTSTATUS DxgkddiDsitransmission(
[in] HANDLE Context,
[in] D3DDDI_VIDEO_PRESENT_TARGET_ID TargetId,
[out] PDXGK_DSI_TRANSMISSION pArgs
)
{...}
Parametri
[in] Context
[in] TargetId
Identificatore di destinazione del monitoraggio.
[out] pArgs
Puntatore a una struttura DXGI_DSI_TRANSMISSION.
Valore restituito
DxgkddiDsiTransmission restituisce STATUS_SUCCESS se ha esito positivo; in caso contrario, restituisce uno dei codici di errore definiti in Ntstatus.h.
Osservazioni
Per consentire a un driver del pannello OEM di interagire sull'interfaccia altrimenti privata tra la scheda grafica e l'hardware del pannello, le transazioni non devono avere alcun effetto driver grafico, diversamente dal tempo occupato dal bus, oppure devono essere completamente definite in modo che il driver grafico sia controllato. Poiché il punto di consentire l'interazione di un driver di pannello OEM consiste nel fornire supporto per le funzionalità del pannello personalizzate che sono opache per il driver grafico, le operazioni completamente definite devono essere limitate alle transazioni in cui il driver del pannello deve eseguire un'operazione standardizzata che non può essere eseguita senza il coinvolgimento del driver grafico. Tali transazioni verranno considerate come eccezioni indirizzate in modo esplicito anziché come trasmissioni.
Ogni richiesta di trasmissione DSI è costituita da un singolo buffer che viene riempito dal driver del pannello OEM, passato allo stack di monitoraggio e restituito con i risultati della trasmissione, se presente. Il buffer contiene informazioni generali sulla trasmissione, con campi di input e output, seguiti da una matrice di dimensioni variabili di DXGK_DSI_PACKET strutture. I pacchetti sono descritti in termini DSI, in modo che qualsiasi pacchetto DSI possa essere descritto, tuttavia il sistema operativo analizzerà i pacchetti e rifiuterà qualsiasi trasmissione che include pacchetti che non sono consentiti. Tutti i pacchetti tranne l'ultimo sono, per definizione DSI, pacchetti di scrittura che possono essere scritture brevi, nel qual caso il buffer Payload è inutilizzato o scritture lunghe che rientrano nel buffer Payload. L'ultimo pacchetto in una trasmissione, che può essere una lettura o una scrittura, può usare un payload esteso allocando e descrivendo un buffer più grande che consente lo spazio per le letture o le scritture di qualsiasi dimensione fino al limite di dati lungo pacchetto DSI di 64K-1 byte di dati. In questo modo, le sequenze di pacchetti di scrittura di piccole dimensioni devono essere accodate al driver in una singola chiamata, ma richiedono che i pacchetti più grandi vengano inviati singolarmente. Il valore del campo FinalPacketExtraPayload indica il numero di byte aggiuntivi allocati, ma questo deve essere tenuto conto anche nel campo TotalBufferSize.
Il driver del pannello OEM è responsabile di garantire che le trasmissioni richieste non siano in conflitto o interferiscano con altre trasmissioni usate dal driver grafico per l'interazione normale con il pannello a causa di richieste eccessive o richieste di operazioni che potrebbero causare ritardi nell'elaborazione di altre trasmissioni. Il driver del pannello non deve modificare alcuno stato che provocherebbe errori successivi nel driver grafico, ad esempio modificando l'intervallo del pannello tramite i comandi MCS. Analogamente, se il sistema operativo ha richiesto una modifica dello schermo, tramite il driver grafico, ad esempio un aumento della luminosità, il driver del pannello non deve usare i comandi DSI per annullare tale modifica, in risposta o per altri scopi.
Il IOCTL_MIPI_DSI_TRANSMISSION viene usato per richiedere una trasmissione alla periferica contenente uno o più pacchetti DSI. Il driver del pannello deve sempre inizializzare TotalBufferSize, PacketCount e i primi tre BYTE di ogni pacchetto. Il driver del pannello può eseguire l'override del comportamento predefinito usando valori diversi da zero per TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode e FinalCommandExtraPayload. Tutti i valori non inizializzati devono essere impostati su zero.
Il sistema operativo garantisce che la sequenza di pacchetti DSI sia ben formata, con informazioni valide in tutti i campi definiti e dimensioni corrette del buffer. Il sistema operativo è responsabile dell'inizializzazione del campo FailedPacket per DXGK_DSI_INVALID_PACKET_INDEX in modo che un'ulteriore convalida nel sistema operativo o nel driver debba impostare il campo solo se viene rilevato un problema con un pacchetto specifico. Se il DXGK_DSI_TRANSMISSION non è ben formato, il sistema operativo imposta il flag DXGK_HOST_DSI_INVALID_TRANSMISSION nel campo HostErrors per distinguere questo da altri errori di parametri non validi.
Per essere considerato ben formato, il seguente deve essere tutto vero:
- 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 l'ultimo pacchetto può essere letto
- Solo un pacchetto di scrittura lungo finale può avere un valore di
LongWriteWordCountmaggiore di [DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE]
Convalida dei pacchetti
Anche se il sistema operativo non tenterà di convalidare completamente il contenuto di tutti i pacchetti, rifiuterà una trasmissione contenente tutti i comandi DSI diversi dai seguenti, completando IOCTL senza chiamare il driver grafico:
| Valore del tipo di dati | Descrizione |
|---|---|
| 0x03 | SCRITTURA breve generica, nessun parametro |
| 0x13 | Generic Short WRITE, 1 parametro |
| 0x23 | Scrittura breve generica, 2 parametri |
| 0x04 | LETTURA generica, nessun parametro |
| 0x14 | Parametro READ generico, 1 |
| 0x24 | Generic READ, 2 parametri |
| 0x05 | DCS Short WRITE, nessun parametro |
| 0x15 | DCS Short WRITE, 1 parametro |
| 0x06 | DCS READ, nessun parametro |
| 0x29 | Scrittura lunga generica |
| 0x39 | Scrittura/write_LUT DCS Long |
I comandi generici di lettura e scrittura richiedono la comprensione della specifica del pannello, in modo che l'aspettativa sia che questi comandi possano essere usati liberamente dal driver del pannello senza causare problemi per il driver grafico, purché il bus non venga utilizzato eccessivamente. Analogamente, i comandi MCS DCS vengono definiti in modo esplicito per l'uso da parte del produttore, pertanto non dovrebbe esserci alcun problema con l'interferenza tra il driver grafico e il driver del pannello.
Per DCS UCS, i comandi non definiti non devono essere usati dal driver di grafica, quindi il sistema operativo consentirà di usarli dal driver del pannello, anche se esiste chiaramente un rischio che le modifiche future MIPI-DCS specifiche definiscino il comando in modo che i comandi MCS siano preferiti.
I comandi DCS UCS standardizzati verranno usati dal driver di grafica durante il normale funzionamento e sono potenzialmente utilizzabili dal driver del pannello, quindi è necessario attenuare il rischio di comandi inviati dal driver del pannello OEM che causano problemi con i comandi del driver grafico successivi. A tale scopo, il sistema operativo analizzerà i comandi DCS e rifiuterà i pacchetti che dovrebbero causare conflitti, a meno che il driver del pannello OEM non imposti il flag ManufacturingMode e il sistema operativo conferma che il sistema è in modalità di produzione. Se il flag è impostato ma il sistema non è in modalità di produzione, la trasmissione IOCTL verrà completata con il flag DXGK_HOST_DSI_INVALID_TRANSMISSION impostato nel campo HostErrors senza chiamare il driver grafico.
Le condizioni che richiedono una transazione completamente definita invece di usare una trasmissione sarebbero le seguenti:
- I periodi di inattività temporizzato sono necessari prima o dopo, ad esempio DCS soft_reset
- Modifica dell'ambiente operativo per l'output del frame, ad esempio set_vsync_timing DCS e enter_sleep_mode
- Uso di transazioni con semantica di inizio/continuazione in cui il driver grafico potrebbe anche dover accedere agli stessi dati, ad esempio DCS write_memory_start/write_memory_continue
Sono inoltre disponibili classi di comandi DCS che verranno rifiutati dal sistema operativo quando inviati come trasmissione:
- Qualsiasi comando che deve essere completamente definito, come descritto in precedenza
- Letture di dati pixel che possono essere usati per lo scraping dello schermo
- Scritture di dati pixel
Comandi UCS che il sistema operativo passerà al driver grafico:
| Malocchio | Comando |
|---|---|
| 00h | Nop |
| 26h | set_gamma_curve |
| 2Dh | write_LUT |
| 51h | set_display_brightness |
| 52h | get_display_brightness |
| 53h | write_control_display |
| 54 ore | 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 ore | get_image_checksum_rgb |
| 15h | get_image_checksum_ct |
| 3Fh | get_3D_control |
| 45h | get_scanline |
Comandi UCS che il sistema operativo rifiuterà:
| Malocchio | Comando |
|---|---|
| 01h | soft_reset (deve essere inviato tramite 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 |
| 28 ore | 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 |
| 34 ore | 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 |
| 44 ore | set_tear_scanline |
| A1h | read_DDB_start |
| A2h | read_PPS_start |
| A8h | read_DDB_continue |
| A9h | read_PPS_continue |
Implementazione del driver grafico
Se la trasmissione supera la convalida del sistema operativo, il sistema operativo passa il buffer al driver di grafica chiamando DxgkDsiTransmission DDI.
L'aggiunta di trasmissioni OEM in un'interfaccia già usata per inviare dati sia pixel che di controllo in base alle richieste del sistema operativo e alle esigenze del controllo delle periferiche, significa inevitabilmente che il driver grafico dovrà migliorare la sequenziazione interna per garantire che questo flusso aggiuntivo di pacchetti possa essere incorporato correttamente. Il driver grafico non deve riordinare i pacchetti all'interno di una trasmissione dal driver del pannello OEM e deve inviare l'intera sequenza senza interruzioni e senza interleaving di altri pacchetti. Il driver grafico non è necessario per mantenere l'ordine dei propri pacchetti rispetto all'ora di arrivo della richiesta di trasmissione del pannello OEM, quindi può scegliere di inviare pacchetti per configurare il frame seguente prima (o dopo) l'invio di una trasmissione del pannello OEM. Se il completamento di una trasmissione del pannello OEM avviato minaccia di causare il mancato intervallo di tempo dei pacchetti critici, il driver deve segnalare la trasmissione come annullata. Se una trasmissione non è stata avviata, ma il conducente si aspetta che non si verifichino pacchetti critici per il loro intervallo di tempo, il conducente deve rinviare l'avvio della trasmissione fino al successivo periodo di vuoto. Se il rinvio di una trasmissione del pannello OEM provocherebbe l'attesa dell'avvio di più di due fotogrammi, il driver dovrebbe segnalare la trasmissione come eliminata.
Non è possibile che un driver grafico assicuri che le trasmissioni inviate per conto del driver del pannello non siano in conflitto con le trasmissioni su cui ha il controllo. Il driver può scegliere di controllare i pacchetti all'interno di una trasmissione e rifiutare la trasmissione se causerebbero problemi, ma qualsiasi pacchetto considerato non sicuro deve essere contrassegnato per il rifiuto a livello di sistema operativo, quindi il rifiuto a livello di driver dovrebbe essere idealmente dovuto a problemi specifici del fornitore di grafica. Il driver non deve tentare di memorizzare nella cache o ottimizzare le letture o le scritture, anche se i pacchetti sembrano essere comandi standardizzati.
Se il driver grafico rifiuta una trasmissione a causa di un problema con un pacchetto, deve aggiornare il campo FailedPacket con l'indice del primo pacchetto che causa il rifiuto della trasmissione e impostare il flag di HostErrors DXGK_HOST_DSI_DRIVER_REJECTED_PACKET prima di restituire. Se viene fornito un override della modalità di trasmissione, il driver deve verificare che l'override sia compatibile con i vincoli hardware e, in caso contrario, impostare il flag HostErrors DXGK_HOST_DSI_BAD_TRANSMISSION_MODE prima di restituire.
Se si verifica un errore durante la comunicazione, il driver di grafica deve aggiornare il campo FailedPacket con l'indice del pacchetto che non è riuscito, ma potrebbe non essere possibile in tutti i casi affinché il driver identifichi il pacchetto in modo che il driver lasci il valore predefinito, DXGK_DSI_INVALID_PACKET_INDEX per tali casi.
Il driver grafico è responsabile della comunicazione dei pacchetti, quindi deve garantire che tutte le somme di controllo vengano calcolate e verificate. Qualsiasi trasmissione che termina con una lettura sarà un pacchetto breve, quindi i campi Data0 e Data1 contengono parametri e la risposta può essere un pacchetto breve o lungo. Il driver grafico potrebbe non sapere quale forma e quanto tempo saranno i dati restituiti, ma la dimensione massima è la dimensione completa del payload per il pacchetto finale, incluso il FinalPacketExtraPayload. Il sistema operativo convaliderà che questo valore non sia maggiore del TargetMaximumReturnPacketSize segnalato dal driver nelle relative funzionalità per la destinazione, ma il driver deve garantire che questo buffer non venga sovraccaricato da una periferica che segnala più dati e che i dati della periferica non vengano troncati a causa di dimensioni maggiori rispetto a MaximumReturnPacketSize attualmente applicate alla periferica. Il driver scrive il numero di byte letti nel buffer nel campo ReadWordCount che descrive la trasmissione.
Ci possono essere casi in cui il driver grafico è costretto a reimpostare l'interfaccia di comunicazione sul pannello o l'intero pannello a causa di errori che potrebbero non essere correlati a e potrebbero non essere osservabili al driver del pannello OEM. Per risolvere questo problema, il driver deve segnalare DXGK_HOST_DSI_INTERFACE_RESET o DXGK_HOST_DSI_DEVICE_RESET impostato nel campo HostErrors nel primo tentativo di trasmissione dopo il ripristino in modo che il driver del pannello OEM possa rilevare la situazione e ripristinare. Il driver non deve inviare questa trasmissione all'hardware, ma il driver del pannello OEM può semplicemente ritentare lo stesso comando se non è necessario alcun recupero, nel qual caso il driver deve procedere con l'elaborazione della trasmissione come di consueto.
Completamento di una trasmissione
Quando IOCTL completa il FailedPacket, ReadWordCount, MipiErrors, HostErrors e payload per un pacchetto di lettura (finale) potrebbe essere stato aggiornato a seconda del risultato. Se sono stati rilevati errori durante l'elaborazione della trasmissione, il driver del pannello OEM deve usare i valori di output MipiErrors e HostErrors per determinare come ripristinare e procedere.
Per assicurarsi che l'output venga restituito al chiamante per fornire i dettagli di eventuali errori, le chiamate IOCTL e DDI devono segnalare un esito positivo, anche se vengono rilevati errori. L'esito positivo non indica che la transazione ha avuto esito positivo, indica che le chiamate per gestire la transazione procedevano come previsto e che sono stati impostati flag di errore, se appropriato. Gli errori possono comunque essere segnalati per condizioni come una chiamata DDI non supportata (presumibilmente a causa di una mancata corrispondenza del driver), errori di allocazione della memoria o passaggio di parametri completamente non valido, ad esempio il passaggio di un buffer NULL. Se non vengono segnalati errori per una chiamata riuscita, il chiamante deve presupporre che la transazione sia stata eseguita correttamente.
Fabbisogno
| Requisito | Valore |
|---|---|
| client minimo supportato | Windows 10, versione 2004 |
| intestazione | dispmprt.h |