Dziwi mnie, że wszechmocny Google nie ma gotowej odpowiedzi na pytanie „czym jest VCHIQ?” Jestem wieloletnim maniakiem jądra i nie jestem pracownikiem Broadcom, ani też ekspertem BCM283 *, ale oto, co znalazłem dla (być może) potomności:
Z gałęzi jądra Raspberry Pi :
Interfejs komunikacyjny z jądra na VideoCore dla rodziny produktów BCM2708.
Warto tutaj zauważyć, że VideoCore jest (zaskakujące zaskoczenie) kontrolerem wideo dla SoC, w którym działa Pi, i wydaje się, że jest to przydatny sposób na uruchomienie mniej lub bardziej bezpośrednich IOCTL-ów do różnych podsystemów podłączonych do GPU . To, że obejmuje to wideo, nie jest żadną niespodzianką, ale wydaje mi się, że ma sens, że interfejs kamery ma swój krzem w VideoCore, biorąc pod uwagę wszystkie kodeki, jakie musi zrobić wideo.
Dlaczego więc sterowanie dźwiękiem odbywa się również przez VideoCore (inaczej nie wymagałoby VCHIQ do sterowania)? Podejrzewam, że biorąc pod uwagę fakt, że VC obsługuje sprzętowo H.264 i inne kodeki (a ponieważ można przesyłać dźwięk przez HDMI), było to najłatwiejsze miejsce na umieszczenie krzemu. Cóż, to i fakt, że chip BCM ma dwa MMU (jeden do VC + ARM, drugi do normalnego użytkowania systemu operacyjnego - patrz schemat na str. 5 ), co umożliwia kopiowanie DMA bez kopiowania (nie trzeba kopiować rzeczy do audio silicon - po prostu powiedz, że do niego należy część pamięci, a nie procesor. Nie wiem jeszcze, czy faktycznie robią to pod przykryciem, ale dlaczego byś tego nie zrobił?).
Zauważ, że IOCTL na VCHIQ tak naprawdę nie przesyłają danych per se - konfigurują DMA i inne operacje między porcjami pamięci i wysyłają polecenia do różnych bitów. Może to być bardzo niebezpieczne, ponieważ możesz potencjalnie wkręcić wewnętrzne struktury danych jądra z przestrzeni użytkownika, zawiesić procesor graficzny, zawiesić uszkodzone dane itp. Więc nie ustawiaj / dev / vhciq na tryb 777 !!!
W każdym razie krótka odpowiedź na „czym jest VCHIQ?” Oto on:
VCHIQ to interfejs poleceń między uruchomionym jądrem Linuksa a urządzeniami peryferyjnymi (między innymi) w krzemie VideoCore. / dev / vhciq zapewnia ogólny dostęp użytkownika do tych komend, których mogą używać (przynajmniej) podsystemy kamery i audio. Jest to dość niebezpieczny interfejs, który może być narażony na przypadkowe programy, stąd domyślnie dość restrykcyjne uprawnienia.
W społeczności RPi są ludzie, którzy mają oko na oku w sprzęcie BCM; Nie jestem jednym z nich (po kilku godzinach badań być może sięgam kostek :-)). To powiedziawszy, uważam, że jest to przyzwoity przegląd na wysokim szczeblu i chętnie przyjmie uzupełnienia / poprawki.
O ile dane www wymagają pozwolenia, dzieje się tak dlatego, że Twój program CGI odradza procesy potomne jako ten użytkownik. Nie znam dobrze tego konkretnego odtwarzacza, ale lepszą praktyką byłoby zwykle uruchomienie jakiegoś specjalnego demona, aby sterować programem, który łączy się z dźwiękiem i sterować nim za pomocą CGI za pomocą gniazda UNIX lub podobnego interfejsu, zamiast bezpośredniego tworzenia dziecka.
Rzeczywiście, sprzedawca zabezpieczeń został zatrzymany jakiś czas temu za umożliwienie dostępu do katalogu głównego swojego serwera internetowego. Prawdopodobnie zrobili to, aby ułatwić zarządzanie procesami, a nie pisać tego rodzaju warstwę środkową, ale jest to zabezpieczenie nie-nie. Dawanie apacheowi w zasadzie nieskrępowanego dostępu do GPU DMA jest równie złym pomysłem (choć przyznaję, że trudniej go wykorzystać).
Mam nadzieję, że to odpowiada na twoje pytanie.
/dev/vhciqgenerowania dźwięku - w tym przypadku dzieje się tak, ponieważ OP używaomxplayergo do tego, co prawdopodobnie nie jest idealne.