To perhaps supplement the acronyms somewhat... There are two basic parts to graphics drivers: kernel and userspace. All policy is in userspace; for graphics, t

To perhaps supplement the acronyms somewhat... There are two basic parts to graphics drivers: kernel and userspace. All policy is in userspace; for graphics, this means things like rendering APIs (Cairo, GTK, X11, GL, VG). The kernel part manages the card's low-level state, handling its memory, outputs, onboard audio, power states, and so forth, but doesn't actually control how the card renders things. The big complexity is how many different userspace clients there are that can ask the graphics card to render something fancy for them. In the X11 world, there's the internal X11 driver, which speaks EXA and uses the card to draw the general desktop, but there's also GLX, which goes through Mesa to get GL commands translated into commands for the specific graphics card. On top of those, there's special drivers for video, with four (!!) different APIs: Xvideo, Xvideo MC, VDPAU, VAAPI, and those each require helper code. VDPAU and VAAPI each require external helper libraries too. Still with me? Awesome. Your toolkits also have graphics stuff, although they usually target an intermediate API rather than a specific card. These include Cairo, GTK, Qt, Wx, Pango, and so forth. Usually these toolkits speak the neutral X11 protocol, but they might decide to speak GL if they think it can make things go faster.