IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntdvertitaeo.h)
Codice principale: IRP_MJ_DEVICE_CONTROL
IOCTL_MIPI_DSI_TRANSMISSION viene emesso per inviare una sequenza di pacchetti DSI MIPI a una periferica.
Codice principale
Buffer di input
n/d
Lunghezza del buffer di input
n/d
Buffer di output
n/d
Lunghezza del buffer di output
n/d
Buffer di input/output
Struttura DXGK_DSI_TRANSMISSION seguita da strutture DXGK_DSI_PACKET contenenti i pacchetti.
Lunghezza del buffer di input/output
Almeno sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload
. Per ulteriori informazioni, vedere Note.
Blocco dello stato
Irp->IoStatus.Status è impostato su STATUS_SUCCESS se la richiesta ha esito positivo. In caso contrario, status è impostato sulla condizione di errore appropriata come codice NTSTATUS. Per altre informazioni, vedere Valori NTSTATUS.
Commenti
IOCTL IOCT (Mobile Industry Processor Interface, MIPI) Digital Serial Interface (DSI) devono gestire i driver porta/miniport monitor, pannello OEM e display.
Esecuzione di trasmissioni
Per consentire a un driver del pannello di interagire su questa interfaccia privata diversamente tra la scheda grafica e l'hardware del pannello, le transazioni devono non 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 a un driver del pannello 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 è 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 generali sulla trasmissione, con campi di input e output, seguiti da una matrice di dimensioni variabili di 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 non consentiti. Tutti i pacchetti tranne l'ultimo sono, per definizione DSI, i pacchetti di scrittura che possono essere brevi scritture, nel qual caso il buffer del payload non è usato o le 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 la lettura o le scritture di qualsiasi dimensione fino al limite di dati del pacchetto lungo 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 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 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.
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 in modo da 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 la struttura DXGK_DSI_TRANSMISSION non è ben formata, il sistema operativo imposterà 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 una lettura
- Solo un pacchetto di scrittura lungo finale può avere un valore LongWriteWordCount 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 | Scrittura breve generica, 2 parametri |
0x04 | READ generico, nessun parametro |
0x14 | Parametro READ generico, 1 |
0x24 | Parametri READ generici, 2 |
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 grafico, quindi il sistema operativo consentirà di usarli dal driver del pannello, anche se esiste chiaramente un rischio che le modifiche alle specifiche MIPI-DCS future definiscano il comando in modo che i comandi MCS siano preferiti.
I comandi UCS DCS standardizzati verranno usati dal driver grafico durante il normale funzionamento e sono potenzialmente utilizzabili dal driver del pannello in modo che il rischio di comandi inviati dal driver del pannello OEM che causano problemi con i comandi successivi del driver del driver grafico devono essere mitigati. 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 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 invece di usare una trasmissione sono le seguenti:
- I periodi di inattività temporali sono necessari prima o dopo, ad esempio DCS soft_reset
- Modifica dell'ambiente operativo per l'output dei frame, ad esempio dcs set_vsync_timing e enter_sleep_mode
- Uso delle transazioni con semantica di inizio/continuazione in cui il driver grafico può anche dover accedere agli stessi dati, ad esempio DCS write_memory_start/write_memory_continue
Inoltre, esistono 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
Hex | 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à
Hex | Comando |
---|---|
01h | soft_reset : nota, questo 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 |
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 |
Nota
I criteri di convalida del sistema operativo possono essere modificati nelle versioni future.
Implementazione del driver grafico
Se la trasmissione supera la convalida del sistema operativo, il sistema operativo passa il buffer al driver grafico usando DsiTransmission.
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 per consentire al driver di identificare 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 FailedPacket
payload , ReadWordCount
, MipiErrors
HostErrors
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 | ntdvertitaeo.h |