I am using Raspberry Pi 3 and raspbian jessie and I came across /dev/vchiq by trying to call program (omxplayer) with perg-cgi which would play some music on my RiPi. And I coudn't get it to work.

When I opened it with my browser (e.g. localhost/muzikica/pusti.pl)[apache2] it said "failed to open vchiq instance". So I changed /dev/vchiq file's permissions to xx7 and it worked until I didn't restart my RiPi. So figured it out and added www-data (user which is executing my program that my pusti.pl script would call) to video group, because /dev/vchiq is part of video group to. And it worked!

What is /dev/vchiq and why does www-data needs at least read and write permissions to play sound on my Raspberry Pi?

2 Answers 2


I'm amazed that the almighty Google doesn't have a ready answer to the question "what is VCHIQ?" I'm a longtime kernel geek and not a Broadcom employee, nor am I BCM283* expert, but here's what I've found for (maybe) posterity:

From the Raspberry Pi kernel branch:

Kernel to VideoCore communication interface for the BCM2708 family of products.

What's worth noting here is that the VideoCore is (surprise surprise) the video controller for the SoC that the Pi runs, and it would appear that this is a handy way to run more-or-less direct IOCTLs to various subsystems hooked into the GPU. That this includes video is no big surprise, but I guess it makes sense that the camera interface has its silicon within VideoCore given all the codec stuff video needs to do.

So why is audio control run through the VideoCore as well (otherwise it wouldn't need VCHIQ to control it)? I suspect that, given the fact that VC has hardware support for H.264 and other codecs (and because you can route audio through HDMI), it was just the easiest place to put the silicon. Well, that and the fact that the BCM chip has two MMUs (one for the VC+ARM, another for normal OS use--see diagram on pg 5), which makes zero-copy DMA possible (no need to copy things to the audio silicon--just tell it that a chunk of memory belongs to it and not the CPU. Dunno yet if they actually do this under the covers, but why wouldn't you?).

Note that the IOCTLs on VCHIQ don't really transfer data per se--they set up DMA and other operations between memory chunks and send commands to various bits. This can be super dangerous, as you could potentially screw with internal kernel data structures from userspace, crash the GPU, sling around corrupt data, etc. So don't set /dev/vchiq to mode 777!!!

In any case, the short answer to "what is VCHIQ?" Here it is:

VCHIQ is a command interface between the running Linux kernel and peripherals (among other things) in the VideoCore silicon. /dev/vchiq provides generic userspace access to those commands for use by (at minimum) the camera and audio subsystems as well. It's a decently dangerous interface to expose to random programs, hence the somewhat restrictive permissions by default.

There are people that are up to their eyeballs in the BCM hardware in the RPi community; I'm not one of them (I'm perhaps ankle-deep after a couple of hours of research :-) ). That said, I think this is a decent high-level overview and would welcome additions/corrections.

As far as why www-data requires permission, that would be because your CGI program is spawning child processes as that user. I don't know that particular player well, but better practice would usually be to run some specialty daemon to control the program that's interfacing to sound and controlling it from CGI using a UNIX socket or similar interface rather than directly spawning a child.

Indeed, a security vendor got busted a while back for allowing their web server root access to their machine. They probably did this to ease process management rather than writing this type of middle layer, but it's a security no-no. Giving apache basically unfettered access to GPU DMA is an equally bad idea (though much harder to exploit I admit).

Hopefully this answers your question.

  • 1
    "So why is audio control run through the VideoCore as well (otherwise it wouldn't need VCHIQ to control it)?" -> Note that you shouldn't need access to /dev/vhciq to run audio generally -- in this case it's because the OP is using omxplayer to do it, which is probably not ideal.
    – goldilocks
    Sep 7, 2016 at 10:19
  • Hmm. I expect there's an ALSA driver that creates the appropriate user land interfaces. I know nothing about omxplayer other than a 5-second Google search and wonder if it's doing anything interesting with that extra access on audio (like using a hardware codec) or just stupidly opening a device it doesn't need. Fascinating, and I'd also imagine that ALSA driver uses VHCIQ under the covers (directly within kernelspace, natch). Neat stuff!
    – BJ Black
    Sep 7, 2016 at 10:25
  • 1
    I've no idea if this is what actually happens, but speculation... The GPU has hardware MPEG decode and that might include MP3 audio (can't find a ref either way), and a hardware decoder would likely consume a bit less juice than software decode. Totally not worth it for the security cost, but possibly interesting.
    – BJ Black
    Sep 7, 2016 at 11:03
  • 1
    Huh. Neat. Just looking through pqru.qr.ai and it looks like the ALSA driver does indeed use VHCIQ under the covers (no need to talk to /dev/vhciq because it can call the kernel API directly, but still...).
    – BJ Black
    Sep 7, 2016 at 11:16
  • 5
    Sure. Basically what's happening here is that the Broadcom chip is cut into two main parts--the CPU (which is what Linux talks to and runs general-purpose software) and the GPU (that runs an independent firmware and handles video, etc.). VCHIQ is the interface that the CPU uses to talk to the GPU. This is a simplification, but likely good enough for now.
    – BJ Black
    Sep 7, 2016 at 20:38

In my case I had the same problem when I created a new user besides the default user, and I had problems not only with the sound but also the configuration of the wifi, access to serial port etc ... Then I opened the / etc / group file. And I added my user to all groups where user 'pi' was inserted, and everything worked perfectly. As follows:

root: x: 0:
daemon: x: 1:
bin: x: 2:
sys: x: 3:
adm: x: 4: pi,carlos
tty: x: 5: pi, carlos
disk: x: 6:
lp: x: 7:
mail: x: 8:
news: x: 9:
uucp: x: 10:
man: x: 12:
proxy: x: 13:
kmem: x: 15:
dialout: x: 20: pi, carlos
fax: x: 21:
voice: x: 22:
cdrom: x: 24: pi, carlos
floppy: x: 25:
tape: x: 26:
sudo: x: 27: pi, carlos
audio: x: 29: pi, carlos, press
dip: x: 30:
www-data: x: 33:
backup: x: 34:
operator: x: 37:
list: x: 38:
irc: x: 39:
src: x: 40:
gnats: x: 41:
shadow: x: 42:
utmp: x: 43:
video: x: 44: pi, carlos
sasl: x: 45:
plugdev: x: 46: pi, carlos
staff: x: 50:
games: x: 60: pi, carlos
users: x: 100: pi, carlos
nogroup: x: 65534:
input: x: 101: pi, carlos
systemd-journal: x: 102:
systemd-timesync: x: 103:
systemd-network: x: 104:
systemd-resolve: x: 105:
systemd-bus-proxy: x: 106:
crontab: x: 107:
netdev: x: 108: pi, carlos
pi: x: 1000:
messagebus: x: 109:
ssh: x: 110:
bluetooth: x: 111:
avahi: x: 112:
spi: x: 999: pi, carlos
i2c: x: 998: pi, carlos
gpio: x: 997: pi, Carlos
lightdm: x: 113:
epmd: x: 114:
ssl-cert: x: 115:
Carlos: x: 1001:
rtkit: x: 116:
press: x: 117:
pulse-access: x: 118:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.