Framework 13 Pro (Core Ultra Series 3 / Panther Lake) on Arch: full GPU enablement writeup (Batch 1)

Framework 13 Pro, Batch 1. Three GPU problems, all userspace pointing at the wrong driver. Exact fixes below.

Distro: Arch (rolling, updated 2026-07-26) | Kernel: 7.1.5-arch1-1 | BIOS: 03.02
Model: Not in your list. Laptop 13 Pro (Core Ultra Series 3), SKU FRANMJCP07, Core Ultra X7 358H, Arc B390 8086:b082. Template stops at Ultra Series 1.

The fix

sudo pacman -S vulkan-intel lib32-vulkan-intel   # Steam/Proton
sudo pacman -S intel-media-driver libva-utils    # video decode
env | grep -i LIBVA                              # must NOT say nvidia

vulkaninfo --summary | grep deviceName   # -> Intel(R) Arc(tm) B390 (PTL)
vkcube                                   # must render
vainfo | grep -E 'VP9|AV1'               # must list profiles

Then fully quit and relaunch your browser and Steam. Running processes keep their launch environment. Mine had been up 16 hours and kept software-decoding after every fix was in place.

Fedora: mesa-vulkan-drivers + .i686. Debian/Ubuntu: mesa-vulkan-drivers + :i386, intel-media-va-driver-non-free. Untested, Arch is what I ran.

Panther Lake is xe, not i915

readlink /sys/class/drm/card0/device/driver | xargs basename

Anything keyed on i915 silently does nothing here. This caused three of the four problems below.

Failed to detect any valid GPUs in the current config

ERROR at vulkaninfo.h:249:vkEnumeratePhysicalDevices failed with ERROR_INITIALIZATION_FAILED

ls /usr/share/vulkan/icd.d/ showed only radeon_icd.json — the AMD driver, no AMD GPU. On Arch the Vulkan drivers are separate packages from mesa, which is what hides this. No ICD means every Proton title fails to launch. OpenGL worked fine throughout (glxinfo -B showed GL 4.6), so a working desktop tells you nothing.

lib32-vulkan-intel is mandatory, not optional. Proton has 32-bit components. vulkaninfo only reports 64-bit, so check by hand: ls /usr/lib32/libvulkan_intel.so.

vaInitialize failed with error code -1 (unknown libva error)

Two causes stacked.

No backend: ls /usr/lib/dri/ | grep iHD was empty. I had iris_dri.so/crocus_dri.so, which are 3D, not video. intel-media-driver supplies iHD_drv_video.so.

Wrong driver forced: after installing it, vainfo still failed, but LIBVA_DRIVER_NAME=iHD vainfo --display drm --device /dev/dri/renderD128 worked perfectly. My environment had LIBVA_DRIVER_NAME=nvidia on a machine with no NVIDIA GPU. This looks exactly like a broken driver and is not one.

Source was HyDE (Hyprland), which unconditionally sources ~/.config/hypr/nvidia.conf containing env = LIBVA_DRIVER_NAME,nvidia. HyDE also ships a correct autodetect at ~/.config/uwsm/env.d/01-gpu.sh that identified this machine as intel-only and set nothing — the hardcoded file overrode the good detection. Run env | grep -i LIBVA regardless of desktop.

Objective decode test (don’t trust GUIs) — Panther Lake puts media on its own tile, gt1:

A=$(cat /sys/class/drm/card0/device/tile0/gt1/gtidle/idle_residency_ms); sleep 3
B=$(cat /sys/class/drm/card0/device/tile0/gt1/gtidle/idle_residency_ms)
echo "idle $((B-A))ms of 3000ms"

Broken: 2898ms of 3000ms idle during video playback, idle_status = gt-c6, engine powered down.

btop shows no GPU

btop 1.4.7 reads Intel stats only via the i915 PMU. Open PR #1457 adds xe support:

git clone -b feature/xe-gpu-support https://github.com/deveworld/btop.git ~/src/btop-xe
cd ~/src/btop-xe && make GPU_SUPPORT=true -j$(nproc)
install -Dm755 bin/btop ~/.local/bin/btop
hash -r

Then set shown_boxes = "proc cpu mem gpu0" in ~/.config/btop/btop.conf.

Gotcha: launching the old btop with gpu0 set validates it against a GPU count of zero and silently rewrites your config back to stock. A stale shell hash undoes your edit every launch — hence hash -r.

RC and MC replace ENC/DEC on xe: RC = render/compute (rcs ccs bcs), MC = media (vcs vecs). Main bar is max(RC, MC). MC pinned at 0% during video playback is the tell that hardware decode is broken — that’s how I found the VA-API problem.

Bonus: ignore this gamemode error

gamemoded -t reports Governor was not set to performance (was actually powersave). On intel_pstate, powersave is the normal dynamic governor — mine sat at 4.19GHz of a 4.80GHz max while reporting it. gamemode string-compares the governor name and doesn’t know about energy_performance_preference. Harmless.

For gaming just use gamemoderun %command% as a Steam launch option; it takes a power-profiles-daemon hold and releases it on exit, so there’s nothing to persist.


Hardware’s been solid. No benchmarks yet — will follow up. Curious whether LIBVA_DRIVER_NAME=nvidia shows up outside HyDE for other Batch 1 owners.

1 Like