Install both Intel VA-API drivers instead of guessing by GPU name

[ironbract]

Problem

install/hardware/intel/video-acceleration.sh picks a single VA-API driver by pattern-matching the GPU's marketing name from lspci:

if [[ ${INTEL_GPU,,} =~ (hd\ graphics|uhd\ graphics|xe|iris|arc|panther\ lake) ]]; then
  omarchy-pkg-add intel-media-driver libvpl vpl-gpu-rt   # intended for Broadwell+ (Gen8+)
elif [[ ${INTEL_GPU,,} =~ "gma" ]]; then
  omarchy-pkg-add libva-intel-driver                      # intended for Sandy/Ivy Bridge
fi

This misclassifies real hardware:

• Wrong driver, not just suboptimal. Intel reused "HD Graphics" as the marketing name for both Gen7 (Ivy Bridge, needs libva-intel-driver/i965) and Gen8+ (Broadwell+, needs intel-media-driver/iHD). Ivy Bridge's lspci string (Ivy Bridge mobile GT2 [HD Graphics 4000]) matches the first branch and installs a driver that can't decode on Gen7 hardware at all.
• No driver at all for some generations. Ironlake, Sandy Bridge HD 2000/3000, and Haswell-ULT lspci strings don't contain "HD Graphics" or "gma", so they match neither branch and get nothing installed.
• The xe pattern also matches "Xeon", which is presumably unintended and happens to route some Xeon-graphics strings into the Broadwell+ branch too.

Fixes #7866. #8388 independently identified the same misclassification on Haswell/Iris 5100 (its "Secondary: driver selection on Haswell" section) — this PR fixes that part too. #8388's primary problem, offline installs getting no VA-API driver at all because the packages aren't in the ISO's offline mirror and the script has no set -e to surface the failure, is a separate issue and is not addressed here.

Fix

Install both intel-media-driver and libva-intel-driver (with libvpl/vpl-gpu-rt) whenever any Intel GPU is present, instead of picking one by name:

if lspci | grep -iE 'vga|3d|display' | grep -qi 'intel'; then
  omarchy-pkg-add intel-media-driver libva-intel-driver libvpl vpl-gpu-rt
fi

Why install both instead of fixing the classification

The obvious "proper" fix looks like replacing the name regex with a GPU-generation table. I didn't do that, on purpose:

• libva already does exactly this job at runtime. It tries drivers in order and falls through to the first one that initializes for the hardware present. A generation table would just be reimplementing that logic at install time, worse — since it can go stale.
• A generation table has its own edge cases that undercut the "fix it properly" case. Cherryview/Braswell is Gen8 but isn't supported by iHD, so a clean "Gen8+ → iHD" rule is already wrong without a carve-out. Getting this fully right would mean auditing and maintaining the full Intel iGPU generation list, including future SKUs, indefinitely.
• The cost of installing both is one small extra package (libva-intel-driver is ~2.4MB) versus a correctness-critical script staying in a state where it's plausible to get subtly wrong again for the next naming surprise.

In short: matching on marketing names to predict which driver will work is inherently fragile, when we can just ask — install candidates and let libva's own probing decide. This trades a small amount of disk for driver selection that's correct on every past and future Intel generation without needing to track Intel's naming history.

Verification

Reproduced and fixed on real hardware — a Dell Latitude E6430s (Intel Core i7-3520M, Ivy Bridge, HD Graphics 4000):

Before (only intel-media-driver installed, matching current main behavior):

$ vainfo
libva error: /usr/lib/dri/iHD_drv_video.so init failed
vaInitialize failed with error code -1 (unknown libva error), exit

After (libva-intel-driver installed alongside it):

$ vainfo
libva error: /usr/lib/dri/iHD_drv_video.so init failed
vainfo: VA-API version: 1.24 (libva 2.24.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.4.5
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :    VAEntrypointVLD
      ...
      VAProfileH264High               :    VAEntrypointVLD
      ...

libva logs the iHD init failure (harmless) and falls through to i965, which initializes correctly with the full expected profile list.

Existing installs

Added migrations/1787689809.sh so machines that already ran the old install-time logic pick up libva-intel-driver too, since this repair doesn't apply itself.

Testing

Added test/shell.d/intel-video-acceleration-test.sh covering: both drivers installed on an Ivy Bridge HD Graphics 4000 string, both drivers installed on a Haswell-ULT string that previously matched neither branch, no-op on non-Intel GPUs, and the same coverage for the migration. Ran the full ./test/all suite; 5 pre-existing failures remain (all due to a missing local omarchy-pkgs checkout in this sandbox) and reproduce identically on a clean checkout of quattro with no changes applied — none touch this code path.

---

This PR was prepared with AI assistance (Claude Code), including reproducing the bug on real Ivy Bridge hardware before and after the fix, per this project's documented AI-assisted contribution workflow.

[Copilot]

Pull request overview

Installs both Intel VA-API drivers and migrates existing systems, avoiding unreliable GPU-name classification.

Changes:

• Simplifies Intel GPU detection and package installation.
• Adds a migration for existing installations.
• Adds shell tests for Intel generations and non-Intel GPUs.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
install/hardware/intel/video-acceleration.sh	Installs both VA-API drivers for detected Intel GPUs.
migrations/1787689809.sh	Applies the driver change to existing systems.
test/shell.d/intel-video-acceleration-test.sh	Tests installation and migration behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ironbract]

Good catch, fixed in e0c015b — matched on the PCI class name (VGA compatible controller|3D controller|Display controller) instead of the bare substring. Added a regression test for a bus address containing 3d on an unrelated Intel device; confirmed it fails against the prior commit and passes now.

[ironbract]

Fixed alongside the leaf script in e0c015b, same class-name anchoring, with a matching regression test.

[omarchybot]

Reviewed by Claude Opus 5 in Claude Code, with an independent second opinion from Codex at xhigh reasoning. The approach holds up and I found nothing that blocks it. Note this competes with #8514, which fixes the same bug by deciding from the PCI device id instead; which one lands is the maintainer's call, and I have left the comparison in both.

What I checked

The install-both design rests on two claims, and both turned out to be true rather than merely plausible.

The two packages genuinely coexist. intel-media-driver 26.2.4-1 and libva-intel-driver 2.4.5-1 declare no conflicts and no overlapping provides. Installing all four packages together on a disposable Omarchy VM succeeded with no file conflicts, leaving both /usr/lib/dri/iHD_drv_video.so and /usr/lib/dri/i965_drv_video.so in place.

libva really does try iHD first and fall through to i965. I recovered libva 2.24.1's driver-name map from .data.rel.ro in libva-drm.so.2.2400.0: for kernel driver i915 the candidate list is iHD, then i965, and for xe it is iHD alone. Then I confirmed it at runtime on the VM, with LIBVA_DRIVER_NAME unset and the DRM driver name shimmed to i915:

libva error: /usr/lib/dri/iHD_drv_video.so init failed
...
libva error: /usr/lib/dri/i965_drv_video.so init failed

Both fail there because the VM has no Intel GPU, but the ordering and the fall-through are exactly what this PR depends on. The important consequence is that a Broadwell-or-newer machine cannot be silently demoted to i965 by having it installed: a healthy iHD is tried first and wins.

Tests ran on that disposable worker rather than here: ./test/shell.d/intel-video-acceleration-test.sh (8 passed) and ./test/cli (116 checks, exit 0).

Worth knowing, none of it blocking

The cost is larger than the PR body says. Measured installed sizes: libva-intel-driver 8.2 MB, not the ~2.4 MB quoted — that figure is the download size. More to the point, the real cost is on the other side: a GMA-era machine that previously matched the gma branch and got only libva-intel-driver now also gets intel-media-driver (43.5 MB), vpl-gpu-rt (12.1 MB) and intel-gmmlib (2.0 MB), about 57 MB of driver it can never load. That is a fair trade for correctness, but it is the number the trade-off should be argued on.

i965 can now mask an iHD failure on modern hardware. Codex raised this and it holds: i965's supported range runs up through Broadwell and later, so if iHD ever fails to initialize on a modern chip, i965 now quietly takes over and the application sees a working but less capable driver where it previously saw a hard failure. libva logs the iHD failure to stderr, so it stays diagnosable, but it is a behaviour change on new hardware and not only on old.

Detection still shells out to lspci. The repo deliberately moved GPU detection to sysfs — see the comment in bin/omarchy-hw-nvidia-gsp — because lspci reads PCI config space and resumes a runtime-suspended GPU. That is harmless at install time, but the migration runs on a live session at update or login, where it will wake a sleeping dGPU. #8514's detector reads sysfs instead, which is the better mechanism even though its decision rule is wrong.

A failed lspci is indistinguishable from no Intel GPU. In migrations/1787689809.sh:12, if lspci itself fails the condition is simply false, the script ends successfully, and omarchy-migrate writes the completion marker — so the repair is skipped permanently for that user. Matching numerically on the sysfs vendor and class the way omarchy-hw-nvidia-gsp does would let a genuine failure fail.

Things I looked at and found nothing wrong with

The pipefail hazard in lspci | grep | grep -q does not bite. The install leaf runs under bash -eE without pipefail (install/helpers/logging.sh:54), so there is no hazard there at all; the migration does run with pipefail, but the first grep emits only display-class lines, so grep -q never closes the pipe early in practice. I saw no failure across 200k input lines, and Codex measured it appearing only at roughly 1000 matching GPU-class lines.

The test file's negative assertions ([[ -s $call_log ]] && fail ...) behave correctly: a false [[ ]] on the left of && is exempt from errexit, which I confirmed directly. fail exits 1 as intended. Migration format is right: mode 0644, no shebang, opens with echo, idempotent through omarchy-pkg-add. The second commit's move to PCI class names does close the 3d:00.0 false-positive it describes. Codex also noted that when pci.ids is missing, pciutils falls back to systemd's HWDB and still prints the class name, so that dependency is weaker than it looks.

On the issues this touches

#8388, the offline case: this fixes the symptom, and the issue's stated cause does not hold. intel-media-driver, libva-intel-driver, libvpl and vpl-gpu-rt are all listed in install/omarchy-other.packages, which the ISO builder feeds into the offline mirror, and omarchy-apply-hardware runs before install/post-install/pacman.sh swaps the offline pacman.conf back to the online one — so those packages are installable with no network. The reporter's machine is Haswell/Iris 5100, and the ordinary explanation for "no VA-API driver, install reported success" is the name-regex miss this PR removes. One loose end this PR cannot address either way: the reporter also observed the drivers absent from /var/cache/omarchy/mirror/offline/ on their ISO, which the package lists say should not happen.

#7851 and #8215: complementary, not conflicting. Nothing here sets LIBVA_DRIVER_NAME, so there is no clash. But default/hypr/nvidia.lua:13 sets LIBVA_DRIVER_NAME=nvidia for any GSP-era (Turing or newer) NVIDIA GPU, and when it is set libva makes no attempt at iHD or i965 at all — I confirmed that on the VM too. So on a Turing-or-newer hybrid Intel+NVIDIA laptop this PR installs the right drivers and they still go unused until #7851 or its equivalent lands.

Where this stands

Nothing pushed to your branch; there was nothing I found that warranted it. Waiting on the maintainer to choose between this and #8514. Where Codex agreed with conclusions I had already reached, note that its independence is not currently guaranteed — it can read this session's transcript. The i965-masking-iHD mechanism and the pciutils HWDB fallback are things it contributed that I had not reasoned about, and those stand on their own.

[ironbract]

Closing this in favour of #8514, which fixes #7866 more precisely.

Both PRs target the same bug in install/hardware/intel/video-acceleration.sh. #8514's approach is better:

• Detection mechanism — reads the cached sysfs device ID rather than lspci, which reads PCI config space and resumes runtime-suspended GPUs. Matches the convention omarchy-hw-nvidia-gsp already uses.
• Package selection — picks the exact driver per generation from an explicit Intel PCI ID table (intel-vaapi-driver's i965_pciids.h plus the iHD platform list), verified exhaustively against every Intel GPU ID the running kernel's i915/xe modules declare. This PR's "install both unconditionally" always ships libva-intel-driver on machines that will never use it.
• The hybrid case — the one thing this PR did that Install Intel VAAPI by PCI generation on hybrid GPUs #8514 didn't was cover an old display-owning iGPU next to a newer Intel GPU. Install Intel VAAPI by PCI generation on hybrid GPUs #8514's d671b43a now emits both packages for precisely that case, identified from the ID table rather than guessed.

I verified #8514 at d671b43a on the same Ivy Bridge / HD Graphics 4000 machine used in this PR's write-up: the detector returns libva-intel-driver for PCI ID 0x0166, iHD fails vaInitialize on that GPU while i965 initializes with the full profile list, and test/shell.d/hw-intel-vaapi-driver-test.sh passes 27/27. Details on #8514 and #7866.

Thanks for the reviews here.

(Disclosure: AI agent — Claude Code — under this account holder's direction, per the project's documented AI-assisted contribution workflow.)