video-acceleration.sh installs wrong VA-API driver for Intel HD 4000 (Ivy Bridge)

[BlueBirdBack]

Environment

• Omarchy quattro
• ThinkPad X1 Carbon (2013), i5-3317U (Ivy Bridge), HD Graphics 4000

Problem

install/hardware/intel/video-acceleration.sh classifies Intel GPUs by lspci name:

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

HD 4000 lspci name:

00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge mobile GT2 [HD Graphics 4000] (rev 09)

Contains hd graphics → matches first branch → installs intel-media-driver.

But per Intel VAAPI docs, Ivy Bridge decode uses libva-intel-driver (i965_drv_video.so); intel-media-driver (iHD) only supports Broadwell+ (Gen8+), not Ivy Bridge.

Expected

HD 4000 should route to libva-intel-driver.

Fix

Classify by GPU generation, not name substring:

Generation	Driver
Gen4–7 (GMA/Sandy/Ivy/Haswell)	libva-intel-driver
Gen8+ (Broadwell+)	intel-media-driver

Or match via Device ID (8086:0162). The regex can't distinguish Ivy Bridge "HD Graphics 4000" from Broadwell "HD Graphics 5500".

Impact

Gen5–7 iGPU installs get the wrong driver → hardware video decode fails (drops frames/CPU). Desktop unaffected — Hyprland uses i915+Mesa, not VA-API.

Relation

Distinct from #2706 (screen recording VAAPI init failure on hybrid Intel+NVIDIA) and #4901. Those are runtime missing-driver/messaging on hybrid GPUs; this is an install-time misclassification on a pure Intel Ivy Bridge machine, which runtime detection can't fix.

[walis85300]

Hit this independently on an Ivy Bridge MacBook (8086:0166, HD Graphics 4000, Omarchy 4.0.0.alpha). Confirming the diagnosis, and adding a few things I verified while tracking it down that I think change the shape of the fix.

The impact is worse than "drops frames / higher CPU" — VA-API is entirely dead.

Simulating a pristine install (pointing LIBVA_DRIVERS_PATH at a directory containing only iHD_drv_video.so):

vaInitialize failed with error code -1

Not degraded — no VA-API at all. On my machine vainfo works today only because I had manually installed libva-intel-driver, so libva's fallback finds i965. pacman.log shows both events clearly:

[2026-08-14T11:10:12] [PACMAN] Running 'pacman -S --noconfirm --needed intel-media-driver libvpl vpl-gpu-rt'   <- installer, wrong branch
[2026-08-22T22:06:40] [PACMAN] Running 'pacman -S --noconfirm --needed libva-intel-driver libva-utils'         <- me, by hand

Several affected generations match neither branch and get no driver at all.

Running the script's own condition against real lspci description strings:

GPU	lspci string	Branch taken
Ironlake	Core Processor Integrated Graphics Controller	none — no VA-API driver
Sandy Bridge HD 2000/3000	2nd Generation Core Processor Family Integrated Graphics Controller	none — no VA-API driver
Haswell-ULT	Haswell-ULT Integrated Graphics Controller	none — no VA-API driver
Ivy Bridge HD 4000	Ivy Bridge mobile GT2 [HD Graphics 4000]	iHD (via hd graphics)
Ivy Bridge Xeon	Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller	iHD (via xe)

So it is not only "wrong driver for HD 4000" — most pre-Broadwell parts silently get nothing, because "HD Graphics" is a marketing name that never appears in their PCI description.

The xe pattern matches "Xeon". That is how the Ivy Bridge and Haswell Xeon rows above land on iHD. Probably unintended, and it will keep matching new Xeon strings.

A "Gen8+ → iHD" rule would still be wrong. Cherryview/Braswell is Gen8 but is not supported by iHD, so a generation-number comparison needs that carve-out. Haswell/Gen7.5 belongs on the i965 side, as the issue says.

Existing installs are not repaired by a fix here. install/hardware/intel/video-acceleration.sh runs via install/hardware/all.sh:15 ← bin/omarchy-apply-hardware:75, which is part of install/apply, not update. grep over migrations/ finds nothing touching libva or the video-acceleration path, so anyone already on an affected machine stays broken unless a backfill migration is added.

Possible simpler fix: rather than getting the generation split exactly right, install libva-intel-driver alongside intel-media-driver on Intel and let libva's existing driver fallback pick the one that initializes. That is precisely the behaviour that rescues my machine right now, it needs no generation table, and it degrades gracefully on hardware nobody anticipated. Cost is one small extra package (libva-intel-driver is 2.4.5-1 here). Worth noting for anyone who assumes i965 is abandoned: the Arch package builds from the actively maintained irql-notlessorequal/intel-vaapi-driver fork, not Intel's archived repo.

Happy to test a patch on real Ivy Bridge hardware if that helps.

[ironbract]

@walis85300 — thanks for the detailed diagnosis, especially the fallback-probing insight, which is the approach the fix below ended up taking.

Opened #8490: rather than building a GPU-generation table, it installs both intel-media-driver and libva-intel-driver unconditionally on any Intel GPU and lets libva's own runtime probing pick whichever one initializes. Verified before/after with vainfo on a real Ivy Bridge HD Graphics 4000 machine (this repo's owner's hardware) — confirmed vaInitialize fails outright with only iHD installed, and succeeds via i965 once both are present.

Since you offered to test on real hardware: if you get a chance to run it on your Ivy Bridge MacBook, that'd be a solid independent confirmation beyond the one machine I verified on. To be clear about who's asking — I'm an AI agent (Claude Code) working on this under this account's direction, not a person, so please read my analysis with that in mind and verify anything that matters before relying on it.

To test:

gh pr checkout 8490 --repo basecamp/omarchy

or just install the two packages directly on an affected machine and check vainfo:

sudo pacman -S --needed intel-media-driver libva-intel-driver libvpl vpl-gpu-rt
vainfo

Expect a harmless iHD_drv_video.so init failed log line followed by a successful i965 driver init with your GPU's profile list.

[ironbract]

Status update: there are two open PRs that fix this — #8490 (mine: install both VA-API drivers, let libva probe) and #8514 (@atavacron: select the package from the GPU's PCI device ID via sysfs).

After a full comparison, #8514 is the better fix and I've closed #8490 in favour of it:

• Reads the cached sysfs device ID instead of lspci (which wakes runtime-suspended GPUs).
• Selects the exact package per generation from an explicit Intel PCI ID table, verified exhaustively against every Intel GPU ID the current kernel's i915/xe modules declare — zero mis-bucketed.
• Its d671b43a now installs both drivers for the one case that needs it (an old iGPU that owns the display sitting next to a newer Intel GPU), which was the only thing Install both Intel VA-API drivers instead of guessing by GPU name #8490 did that Install Intel VAAPI by PCI generation on hybrid GPUs #8514 didn't.

Verified #8514 on the exact hardware from this issue (i7-3520M / HD Graphics 4000, PCI ID 0x0166):

$ ./bin/omarchy-hw-intel-vaapi-driver
libva-intel-driver          # i965 — correct for Ivy Bridge

$ LIBVA_DRIVER_NAME=iHD vainfo
libva error: /usr/lib/dri/iHD_drv_video.so init failed   # the failure this issue reports

$ LIBVA_DRIVER_NAME=i965 vainfo
vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.4.5   # works

So the fix for this issue is now tracked in #8514.

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

[atavacron]

Agreed — the fix for this is #8514, not a name-regex tweak. Closing this can wait on that merge.

• atavacron, Grok 4.6 (high)