Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Lo stack di driver peer è costituito dai driver caricati per rappresentare le sottounità AV/C attive sul bus IEEE 1394, sulle quali si può agire dal computer. Il controllo del dispositivo esterno deve essere avviato tramite lo stack di driver peer AV/C. Windows carica un'istanza di Avc.sys per ogni dispositivo AV/C esterno nel bus IEEE 1394 ogni volta che un dispositivo è connesso al sistema (o presente durante l'avvio del sistema). Ogni istanza di Avc.sys caricata per supportare un driver di una sottounità peer registra una nuova istanza dell'interfaccia del dispositivo GUID_AVC_CLASS. Per altre informazioni sull'interfaccia del dispositivo GUID_AVC_CLASS, vedere Usando Avc.sys e IOCTL_AVC_CLASS.
I driver delle subunità peer accedono e controllano le loro sottounità tramite l'interfaccia IOCTL_AVC_CLASS esportata da Avc.sys. Avc.sys gestisce il protocollo di comando e risposta AV/C, incluse tutte le interazioni con il protocollo FCP (Function Control Protocol) IEC 61883. Tuttavia, si noti che un driver di subunit peer non è impedito di comunicare e accedere direttamente a determinate funzionalità di 61883.sys quando necessario. Un driver subunit potrebbe dover comunicare direttamente con 61883.sys quando il driver subunit rappresenta una subunit AV/C che usa un formato di flusso non supportato da Microsoft. Un driver subunit può usare l'interfaccia IOCTL_61883_CLASS per comunicare direttamente con 61883.sys quando necessario. Microsoft fornisce il driver con filtro inferiore, Avcstrm.sys, che può essere utile per lo streaming di formati DV e MPEG2. Per altre informazioni su Avcstrm.sys, vedere panoramica dello streaming AV/C.
Un driver di subunit peer può registrarsi per ricevere notifiche e ricevere comandi AV/C da dispositivi AV/C esterni. Per registrarsi, un driver di subunità peer emette un pacchetto di richiesta di I/O IRP_MJ_INTERNAL_DEVICE_CONTROL con il membro IoControlCode del codice di controllo I/O IOCTL_AVC_CLASS e la sottofunzione impostata su AVC_FUNCTION_GET_REQUEST. Questa funzionalità consente a un driver di subunità peer di ricevere richieste AV/C dalla propria subunità e abilita il supporto delle specifiche, come il protocollo CCM (Connection and Compatibility Management) e la protezione del contenuto di trasmissione digitale (DTCP). Per ulteriori informazioni su DTCP, vedere il sito web dell'Amministratore delle Licenze di Trasmissione Digitale .
Si noti che questa funzionalità è progettata per supportare un driver di subunit AV/C virtuale per inviare comandi AV/C al computer (dove il driver subunit si trova nello stack di dispositivi AV/C virtuale) e non per consentire alle sottounizioni AV/C su dispositivi esterni di inviare comandi AV/C al sistema computer.
Stack Peer come destinazione del comando AV/C
Lo stack di driver della subunità pari può contenere driver di filtro WDM aggiuntivi che forniscono funzionalità AV/C mirate specifiche del fornitore o del dispositivo. Tramite questo meccanismo di estensione dello stack di driver peer subunit, i fornitori di terze parti possono implementare in modo indipendente funzionalità a valore aggiunto, ad esempio la protezione della copia 5C, nonché le estensioni all'implementazione AV/C fornita da Microsoft.
I driver subunit possono eseguire questa funzione, ma per i dispositivi con più sottounità, un driver di filtro WDM è il metodo preferito. Il computer viene esposto solo come destinazione AV/C se un driver superiore (sottounità o driver di filtro) si registra per ricevere le richieste in ingresso tramite AVC_FUNCTION_GET_REQUEST. Per altre informazioni sui comandi di unità AV/C, vedere AVC_FUNCTION.
Il caricamento dei driver si basa su identificatori di dispositivo (ID); pertanto, la funzionalità dell'unità può essere caricata in modo selettivo in base a un dispositivo specifico o a un fornitore. Lo stack di driver per subunità virtuali supporta questo meccanismo in modo generico, senza focalizzarsi su un dispositivo specifico.
È importante notare che se lo stack di driver della subunità peer implementa estensioni di unità specifiche del dispositivo, tutti i comandi di unità non gestiti, nonché tutti i comandi di subunità in ingresso, vengono instradati allo stack di driver della subunità virtuale .
Meccanismo di estensione del comando unità
Nel contesto dello stack di driver di sottounità peer, la funzionalità prevista è limitata al supporto dei soli comandi unità AV/C. Se un driver subunità (per una subunità virtuale o subunità peer) si registra per ricevere richieste AV/C, allora Avc.sys supporta solo gli opcodici SUBUNIT_INFO (0x31) e UNIT_INFO (0x30). Per ulteriori informazioni sui codici operativi, vedere la Specifica Generale del Set di Comandi dell'Interfaccia Digitale AV/C, Rev 3.0. Per supportare comandi di unità aggiuntivi, ad esempio quelli per il protocollo CCM o DTCP, Avc.sys fornisce un meccanismo di estensione plug-in. Un qualsiasi numero di driver di filtro subunità o WDM può registrare gli opcode unità che supportano tramite il membro AlternateOpcodes della struttura AVC_COMMAND_IRB, inviata attraverso la funzione AVC_FUNCTION_GET_REQUEST. AlternateOpcodes è una matrice di byte contati; l'elemento 0 è il numero di opcode alternativi nei byte rimanenti. alternateOpcodes viene ignorato quando si invia una risposta, pertanto non è necessario nascondere gli opcode alternativi durante l'elaborazione di una richiesta di unità.
Per utilizzare il meccanismo di estensione predefinito, specificare l'indirizzo dell'unità come 0xff nel membro SubunitAddress della struttura AVC_COMMAND_IRB. Il membro SubunitAddress rimane isolato per i comandi dell'unità (l'indirizzo dell'unità fornito dal driver della sotto-unità esiste ancora). Il driver di subunit virtuale è sempre in grado di disconnettersi dal membro SubunitAddress.