DXGKDDI_DSITRANSMISSION funzione di callback (dispmprt.h)
La funzione di callback DxgkddiDsiTransmission 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.
Commenti
Per consentire a un driver del pannello OEM di interagire sull'interfaccia privata altrimenti tra la scheda grafica e l'hardware del pannello, le transazioni non devono avere alcun effetto del driver grafico, diversamente dal tempo che occupa il bus o devono essere completamente definite in modo che il driver grafico sia in controllo. Poiché il punto di consentire a un driver del pannello OEM di interagire 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 lo stack di monitoraggio e restituito con i risultati della trasmissione, se presente. Il buffer contiene informazioni complessive sulla trasmissione, con campi di input e di output, seguiti da una matrice di dimensioni variabile delle strutture DXGK_DSI_PACKET . 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 Payload buffer è inutilizzato o scritture lunghe che rientrano nel Payload buffer. L'ultimo pacchetto in una trasmissione, che può essere una lettura o una scrittura, è consentito usare un payload esteso allocando e descrivendo un buffer più grande che consente la lettura o la scrittura di qualsiasi dimensione fino al limite di dati del pacchetto lungo DSI di 64K-1. 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 indica il numero di FinalPacketExtraPayload byte aggiuntivi allocati, ma è necessario tenere conto anche del TotalBufferSize numero di byte aggiuntivi nel campo.
Il driver del pannello OEM è responsabile della garanzia che le trasmissioni richieste non siano in conflitto o interferiscano con altre trasmissioni usate dal driver grafico per la normale interazione con il pannello a causa di richieste eccessive o operazioni di richiesta che causano ritardi nell'elaborazione di altre trasmissioni. Il driver del pannello non deve modificare alcun stato che causerebbe errori successivi nel driver grafico, ad esempio modificando il tempo del pannello tramite i comandi MCS. Analogamente, se il sistema operativo ha richiesto una modifica di visualizzazione, 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 TotalBufferSizePacketCount e i primi tre BYTE di ogni pacchetto. Il driver del pannello può eseguire l'override del comportamento predefinito usando valori non zero per TransmissionMode, ReportMipiErrorsClearMipiErrors, 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 le dimensioni corrette del buffer. Il sistema operativo è responsabile dell'inizializzazione del FailedPacket campo da DXGK_DSI_INVALID_PACKET_INDEX in modo che la convalida aggiuntiva nel sistema operativo o nel driver debba impostare il campo solo se si verifica 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 HostErrors campo per distinguere questo da altri errori di params non validi.
Per essere considerato ben formato, è necessario che tutto sia 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 una lettura
- Solo un pacchetto di scrittura lungo finale può avere un
LongWriteWordCountvalore maggiore 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 comandi DSI diversi dal seguente, 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 | Generic Short WRITE, 2 parametri |
| 0x04 | Generic READ, nessun parametro |
| 0x14 | Generic READ, 1 parametro |
| 0x24 | Generic READ, 2 parametri |
| 0x05 | DCS Short WRITE, nessun parametro |
| 0x15 | PARAMETRO DCS Short WRITE, 1 |
| 0x06 | DCS READ, nessun parametro |
| 0x29 | Scrittura lunga generica |
| 0x39 | Scrittura/write_LUT long DCS |
I comandi generici di lettura e scrittura richiedono la comprensione della specifica del pannello, in modo che questi comandi possano essere usati liberamente dal driver del pannello senza causare problemi per il driver grafico purché il bus non venga usato in modo eccessivo. Analogamente, i comandi MCS DCS vengono definiti in modo esplicito per l'uso del produttore in modo che non ci sia 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, pertanto il sistema operativo consentirà loro di usarli dal driver del pannello, anche se esiste chiaramente un rischio che le future specifiche MIPI-DCS definiscano il comando in modo che i comandi MCS siano preferiti.
I comandi DCS UCS standardizzati verranno usati dal driver grafico durante la normale operazione e potenzialmente utilizzabili dal driver del pannello in modo che il rischio di comandi inviati dal driver del pannello OEM causa problemi con i comandi successivi dei driver grafici deve essere attenuato. A tale scopo, il sistema operativo analizza i comandi DCS e rifiuta i pacchetti che devono causare conflitti a meno che il driver del pannello OEM non imposta il ManufacturingMode flag 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 HostErrors campo senza chiamare il driver grafico.
Le condizioni che richiedono una transazione completamente definita anziché l'uso di una trasmissione sarebbero dove:
- I periodi di inattività temporali 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 delle transazioni con semantica start/continua in cui il driver grafico può 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 vengono inviati come trasmissione:
- Qualsiasi comando che deve essere completamente definito, come descritto in precedenza
- Letture di dati pixel che possono essere usati per lo smantellamento dello schermo
- Scritture di dati pixel
Comandi UCS che il sistema operativo passerà al driver grafico:
| 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 |
Comandi UCS che il sistema operativo rifiuterà:
| Hex | Comando |
|---|---|
| 01h | soft_reset (deve essere inviato tramite un IOCTL_MIPI_DSI_RESET) |
| 10h | enter_sleep_mode |
| 11h | exit_sleep_mode |
| 12 h | 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 |
Implementazione del driver grafico
Se la trasmissione supera la convalida del sistema operativo, il sistema operativo passa il buffer al driver grafico 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 in relazione al momento dell'arrivo della richiesta di trasmissione del pannello OEM, quindi può scegliere di inviare pacchetti per impostare il frame seguente prima (o dopo) di inviare una trasmissione del pannello OEM. Se il completamento di una trasmissione del pannello OEM avviato minaccia di causare la mancata scadenza dei pacchetti critici, il driver deve segnalare la trasmissione come annullata. Se una trasmissione non è stata avviata, ma il conducente si aspetta che i pacchetti critici non perdano l'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 avrebbe causato l'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 eventuali pacchetti considerati non sicuri devono essere contrassegnati 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 letture o 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 FailedPacket campo con l'indice del primo pacchetto, causando il rifiuto della trasmissione e l'impostazione del HostErrors flag DXGK_HOST_DSI_DRIVER_REJECTED_PACKET prima della restituzione. 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 HostErrors flag di DXGK_HOST_DSI_BAD_TRANSMISSION_MODE prima di restituire.
Se si verifica un errore durante la comunicazione, il driver grafico deve aggiornare il FailedPacket campo con l'indice del pacchetto che non è riuscito, tuttavia 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 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 modulo e quanto tempo saranno i dati restituiti, ma la dimensione massima è la dimensione massima del payload per il pacchetto finale, incluso .FinalPacketExtraPayload Il sistema operativo convaliderà che questo valore non è maggiore di quello 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 ReadWordCount campo che descrive la trasmissione.
Ci possono essere casi in cui il driver grafico è costretto a reimpostare l'interfaccia di comunicazione al 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 nel HostErrors primo tentativo di trasmissione dopo la reimpostazione in modo che il driver del pannello OEM possa rilevare la situazione e il ripristino. Il driver non deve inviare questa trasmissione all'hardware, ma il driver del pannello OEM può semplicemente ripetere lo stesso comando se non è necessario alcun ripristino, nel qual caso il driver deve procedere con l'elaborazione della trasmissione come di consueto.
Completamento di una trasmissione
Quando IOCTL completa il FailedPacketpayload , ReadWordCount, MipiErrorsHostErrors e 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 MipiErrors valori di output 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 abbia avuto esito positivo.
Requisiti
| Requisito | Valore |
|---|---|
| Client minimo supportato | Windows 10, versione 2004 |
| Intestazione | dispmprt.h |
Vedi anche
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per