Acquisizione basata su porta video
I dispositivi di acquisizione basati su porte video devono fornire un pin di porta video che si connette alla gestione porte video. Il pin della porta video consente al trasporto basato su hardware di visualizzare il flusso di anteprima senza sovraccarico dell'interconnessione della CPU o del componente periferico (PCI). Un pin separato offre funzionalità di acquisizione (ad esempio, quando il video acquisito deve essere scritto su disco). Durante il processo di acquisizione, i buffer di acquisizione vengono forniti al driver di visualizzazione, che riempie il buffer tramite il mastering del bus. L'interazione tra il minidriver di acquisizione e il driver di visualizzazione viene descritta in dettaglio più avanti in questa sezione e nel trasporto video in modalità kernel.
Nei sistemi che eseguono Microsoft Windows 98 SE o Windows 2000, il filtro Mixer sovrimpressione (parte del filtro Gestione porte video nei sistemi operativi successivi) non supporta le connessioni di porta video nei monitor secondari. La connessione pin non riesce in questo caso. Le connessioni alle porte video nei monitor secondari sono supportate nei sistemi che eseguono Windows Millennium Edition (Windows Me) e Windows XP.
Se un dispositivo supporta l'acquisizione VBI, espone in genere due pin aggiuntivi: VPVBI e VBI. Il filtro di gestione porte video usa il pin VPVBI per allocare le superfici delle porte video per l'acquisizione VBI. Il pin VBI stesso fornisce gli esempi VBI non elaborati.
Il diagramma seguente illustra i percorsi separati per l'acquisizione VPVBI e VBI.
I set di proprietà specifici di questo tipo di grafico di filtro sono KSPROPSETID_VPConfig e KSPROPSETID_VPVBIConfig e PROPSETID_ALLOCATOR_CONTROL.
Uso delle estensioni delle porte video (VPEs)
Nota: i paragrafi seguenti si applicano solo ai sistemi operativi precedenti alla versione successiva di Windows Vista. VPE è disabilitato in Windows Vista se il driver di visualizzazione usa il nuovo modello LDDM (Windows Vista Driver Display Model).
I minidriver di acquisizione video possono usare la funzione DxApi per comunicare con il driver miniport video per consentire il trasporto di video in streaming attraverso il bus di porta video tra l'hardware di acquisizione e l'hardware di visualizzazione. Il flusso è costituito da campi sequenziali di video NTSC, PAL o SECAM e può includere dati di spaziatura vuota (VBI) e timecode (sincronizzazione orizzontale e sincronizzazione verticale). Le caratteristiche del flusso video, tra cui dimensione, formato colore, frequenza, ridimensionamento e ritaglio vengono configurate in modalità utente tramite l'interfaccia VPE DirectDraw. Dopo l'avvio dello streaming, DxApi viene quindi chiamato in modalità kernel per acquisire singoli fotogrammi. Per supportare le modifiche alla visualizzazione, ad esempio modifiche alla risoluzione o al passaggio da prompt dei comandi a schermo intero, i minidriver di acquisizione video devono anche registrarsi con il driver miniport video in modo che possano rispondere a tali eventi di modifica dello schermo.
Le VPN e la funzione DxApi sono state introdotte in DirectDraw DDI con DirectX 5.0. DxApi è supportato dal driver video miniport in Windows 2000 e versioni successive. Un driver miniport di visualizzazione virtuale (miniVDD) supporta DxApi nei sistemi operativi Windows 98 e Windows Me. Per abilitare il trasporto video in modalità kernel tramite DxApi, un minidriver di acquisizione video WDM deve includere il file di intestazione ddkmapi.h (API in modalità kernel DirectDraw) e il collegamento alla libreria dxapi.lib. La libreria DxApi usa la funzionalità esportata da dxapi.sys. DxApi.sys è disponibile solo quando DirectDraw viene caricato perché DxApi fa parte delle VPE per DirectDraw DDI.
DxApi è una singola API in modalità kernel esposta da DxApi.sys. L'estensione porta video è un'API in modalità utente esposta da DDraw.dll. Un minidriver di acquisizione video deve effettuare diverse chiamate a DxApi per configurare e configurare l'hardware della porta video per lo streaming corretto.
DxApi è una singola funzione che incapsula più identificatori di funzione. I minidriver passano l'identificatore di funzione desiderato nel primo argomento a DxApi. Gli argomenti rimanenti di DxApi sono per i buffer allocati dal minidriver per le strutture che corrispondono agli identificatori di funzione e alle lunghezze dei buffer. Il comportamento delle funzioni e delle dimensioni e del formato dei buffer di input e output dipende dall'identificatore di funzione specificato. Questo comportamento è documentato in Funzioni e identificatori DxApi.
WdK fornisce due driver di esempio che illustrano come implementare la funzionalità DxApi . Per il funzionamento dell'esempio ATIWDM è necessario che sia presente hardware specifico. L'esempio TestCap non richiede hardware e funziona su tutte le piattaforme. È possibile usare lo strumento GraphEdt per interagire con uno dei due esempi.
Le funzioni comuni che un minidriver di acquisizione video deve chiamare DxApi per eseguire sono le seguenti:
Aprire un handle in modalità kernel DirectDraw (identificatore di funzione DxApi impostato su DD_DXAPI_OPENDIRECTDRAW). Questa operazione deve essere eseguita in IRQL = PASSIVE_LEVEL.
Ottenere le funzionalità della porta video hardware in modalità kernel (identificatore di funzione DxApi impostato su DD_DXAPI_GETKERNELCAPS).
Registrare i callback per gestire gli eventi DirectDraw, ad esempio la modalità passa a un prompt dei comandi a schermo intero (identificatore di funzione DxApi impostato su DD_DXAPI_REGISTER_CALLBACK).
Aprire un handle per indirizzare le superfici DirectDraw (identificatore di funzione DxApi impostato su DD_DXAPI_OPENSURFACE).
Annullare la registrazione dei callback (identificatore di funzione DxApi impostato su DD_DXAPI_UNREGISTER_CALLBACK).
Chiudi handle per le superfici e directDraw in modalità kernel (identificatore di funzione DxApi impostato su DD_DXAPI_CLOSEHANDLE)
Dispositivi figlio della porta video e risparmio energia
I dispositivi figlio della porta video, ad esempio il tuner TV e le schede combinate di visualizzazione, possono bloccare le transizioni di stato di alimentazione quando il minidriver è in uso. Il blocco della transizione dello stato di alimentazione si verifica quando il minidriver è attivamente in uso (i pin o i filtri sono aperti). Se il minidriver viene caricato ma non dispone di pin o filtri in uso, si verificheranno transizioni dello stato di alimentazione da S0 (completamente alimentato) a stati di alimentazione inferiori (ad esempio, S1, S2, S3 e S4). Il blocco della transizione dello stato di alimentazione si verifica solo con i minidriver della classe Stream che sono client di dispositivi figlio della porta video.
Una rinuncia WHQL è disponibile per i dispositivi che soddisfano questi criteri, in modo che i fornitori possano comunque ottenere un logo.