Estou surpreso que o todo-poderoso Google não tenha uma resposta pronta para a pergunta "o que é VCHIQ?" Sou um nerd de longa data do kernel e não sou um funcionário da Broadcom, nem sou especialista do BCM283 *, mas eis o que eu encontrei para a posteridade (talvez):
No ramo do kernel do Raspberry Pi :
Interface de comunicação do kernel para o VideoCore para a família de produtos BCM2708.
O que vale a pena notar aqui é que o VideoCore é (surpresa surpresa) o controlador de vídeo do SoC que o Pi executa, e parece que essa é uma maneira útil de executar IOCTLs diretos mais ou menos diretos para vários subsistemas conectados à GPU . Isso inclui vídeo não é uma grande surpresa, mas acho que faz sentido que a interface da câmera tenha seu silício no VideoCore, considerando todas as coisas de codec que o vídeo precisa fazer.
Então, por que o controle de áudio também é executado no VideoCore (caso contrário, não seria necessário o VCHIQ para controlá-lo)? Eu suspeito que, dado o VC ter suporte de hardware para H.264 e outros codecs (e porque você pode rotear o áudio através de HDMI), esse era apenas o lugar mais fácil para colocar o silício. Bem, isso e o fato de o chip BCM ter dois MMUs (um para o VC + ARM, outro para uso normal do SO - veja o diagrama na página 5 ), o que torna possível o DMA de cópia zero (não é necessário copiar itens para o silício de áudio - diga a ele que um pedaço de memória pertence a ele e não à CPU. Ainda não sei se eles fazem isso de verdade, mas por que você não faria isso?).
Observe que os IOCTLs no VCHIQ realmente não transferem dados em si - eles configuram o DMA e outras operações entre os pedaços de memória e enviam comandos para vários bits. Isso pode ser super perigoso, pois você pode estragar as estruturas internas de dados do kernel do espaço do usuário, travar a GPU, evitar dados corrompidos, etc. Portanto, não defina / dev / vhciq para o modo 777 !!!
De qualquer forma, a resposta curta para "o que é VCHIQ?" Aqui está:
VCHIQ é uma interface de comando entre o kernel Linux em execução e os periféricos (entre outras coisas) no silício VideoCore. O / dev / vhciq fornece acesso genérico ao espaço do usuário a esses comandos para uso (no mínimo) dos subsistemas de câmera e áudio. É uma interface decentemente perigosa para expor a programas aleatórios, daí as permissões um tanto restritivas por padrão.
Existem pessoas que estão à altura dos olhos no hardware do BCM na comunidade RPi; Eu não sou um deles (talvez até o tornozelo depois de algumas horas de pesquisa :-)). Dito isto, acho que essa é uma visão geral decente de alto nível e gostaria de receber adições / correções.
Na medida em que o www-data requer permissão, isso ocorre porque seu programa CGI está gerando processos filho como esse usuário. Eu não conheço bem esse jogador em particular, mas a melhor prática geralmente seria executar algum daemon de especialidade para controlar o programa que faz interface com o som e controlá-lo a partir do CGI usando um soquete UNIX ou interface semelhante, em vez de gerar diretamente uma criança.
De fato, um fornecedor de segurança foi preso há um tempo atrás por permitir o acesso raiz do servidor da web à sua máquina. Eles provavelmente fizeram isso para facilitar o gerenciamento de processos, em vez de escrever esse tipo de camada intermediária, mas é um não-não de segurança. Dar ao apache basicamente acesso irrestrito ao GPU DMA é uma idéia igualmente ruim (embora muito mais difícil de explorar, admito).
Espero que isso responda sua pergunta.
/dev/vhciqexecutar o áudio em geral - nesse caso, é porque o OP está usandoomxplayerisso, o que provavelmente não é o ideal.