== My uncertainties around X drivers for modern Intel integrated graphics When I switched from [[my old office hardware HomeMachine2011]] to [[my new office machine WorkMachine2017]], I got surprised by [[how well the X server coped with not actually having a hardware driver for my graphics card XBasicDriverPerfSurprise]]. That experience left me jumpy about making sure that any new hardware I used was actually being driven properly by X, instead of X falling back to something that was just good enough that I didn't know I should be getting better. All of which is the lead up to me switching my home machine over to new modern Intel-based hardware, using Intel's generally well regarded onboard graphics. Everything looked good, but then I decided to find out if it actually was good, and now I'm confused. (The specific hardware is only slightly different from [[my original plans HomeMachine2017]].) Let's start with the first issue, which is how to determine what X modules you're actually using. People who are expert in reading the X log files can probably work this out from the logs but it left me confused and puzzled, so I've now resorted to brute force. X server modules are shared libraries (well, shared objects), so the X server has to map them into its address space in order to use them. If we assume that it unmaps modules it's not using, we can use _lsof_ to determine what current modules it has. On my machine, this reports that the driver it has loaded is [[the _modesetting_ driver http://jlk.fjfi.cvut.cz/arch/manpages/man/modesetting.4]], along with _libfb.so_ and [[_libglamoregl.so_ https://www.freedesktop.org/wiki/Software/Glamor/]] (and various Mesa things). Staring at the X logs led me to see: .pn prewrap on > modeset(0): [DRI2] Setup complete > modeset(0): [DRI2] DRI driver: i965 > modeset(0): [DRI2] VDPAU driver: va_gl > [...] > AIGLX: Loaded and initialized i965 That seems pretty definite; I'm using the modesetting driver, not the Intel driver. This raises another question, which is whether or not this is a good thing. Although I initially thought there might be problems, a bunch of research in the process of writing this entry suggests that using the modesetting driver is the right answer (eg [[the Arch wiki entry on Intel graphics https://wiki.archlinux.org/index.php/intel_graphics]], which led me to [[the announcement that Fedora was switching over to modesetting https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AUPYPJMFJZMHPEKN24LBABZKIEOV4NU5/]]). In fact now that I look back at [[my earlier entry XBasicDriverPerfSurprise]], a commentator even talked about this switch. (Before I found this information, I tried forcing X to use the Intel driver. This sort of worked (with complaints about an unrecognized chipset), but Chrome didn't like life so I gave up pretty much immediately. This might be fixed in the latest git tree of the driver, but if modesetting X works and is preferred, my motivation for building the driver from source is low.) Unfortunately this leaves me with questions and concerns that I don't have answers to. The first issue is that I don't know how much GPU accelerated OpenGL I have active in this configuration. Since I can run some OpenGL stress tests without seeing the CPU load go up very much, I'm probably not using much software rendering and it's mostly hardware. Certainly _xdriinfo_ reports that I have DRI through an i965 driver and _glxinfo_ seems to know about the hardware. (Specifically, _glxinfo_ reports in several sections that it's using 'Mesa DRI Intel(R) HD Graphics (Coffeelake 3x8 GT2) (0x3e92)'. The 0x3e92 matches the PCI ID of the integrated graphics controller.) The second issue is video playback, which for reasons beyond the scope of this entry is one of my interests. One of the ways that I noticed problems [[the first time around XBasicDriverPerfSurprise]] was that _vdpauinfo_ was completely unhappy. This time around it's partially unhappy, but it says its using the 'OpenGL/VAAPI backend for VDPAU'. [[VAAPI https://en.wikipedia.org/wiki/Video_Acceleration_API]] ([[also https://www.freedesktop.org/wiki/Software/vaapi/]]) is an Intel project, and it has its own information command, _vainfo_. Unfortunately _vainfo_ is not happy with my system; if I can read its messages correctly, it's unable to initialize the hardware driver it wants to use. Of course I don't know whether this even matters for basic video playback, even of 1080p content, or if common Linux video players use VAAPI (or VDPAU). (Part of the issue may be that I have a bit of a Frankenstein mess of packages, with some VAAPI related packages coming from [[RPM Fusion https://rpmfusion.org/]], including the libva Intel driver package itself. Possibly I should trim down those packages somewhat.)