Skip to content

nvidia.lua forces LIBVA_DRIVER_NAME=nvidia on hybrid laptops where the iGPU drives the displays, breaking browser video (repro of #11168 on Arrow Lake + Blackwell) #11173

Closed as duplicate
Closed as duplicate
nvidia.lua forces LIBVA_DRIVER_NAME=nvidia on hybrid laptops where the iGPU drives the displays, breaking browser video (repro of #11168 on Arrow Lake + Blackwell)#11173
Labels
bugSomething isn't workingduplicateThis issue or pull request already exists

Description

@kimm-stensborg
kimm-stensborg
opened on Sep 10, 2026

System details

Intel Core Ultra 7 255H (Arrow Lake, Arc 130T/140T iGPU) + NVIDIA RTX PRO 500 Blackwell Laptop GPU, Omarchy 4.0.3-1

What's wrong?

Second independent reproduction of #11168 (closed by its author, not by a maintainer, and with no fix merged), this time on different hardware: an Arrow Lake iGPU with a Blackwell dGPU, and three displays.

default/hypr/nvidia.lua sets LIBVA_DRIVER_NAME=nvidia (plus NVD_BACKEND=direct and __GLX_VENDOR_LIBRARY_NAME=nvidia) whenever omarchy-hw-nvidia and omarchy-hw-nvidia-gsp succeed. It does not check whether NVIDIA is the GPU that actually renders or drives the displays. On this hybrid laptop NVIDIA drives neither, so browsers decode video on NVDEC while compositing on the Intel iGPU, and video playback breaks. Turning off hardware acceleration in the browser fixes it, which matches the cross-GPU dmabuf import failure described in #11168.

Every display is on the Intel iGPU:

card0-eDP-1: connected -> i915    (AU Optronics B160UAN04.9)
card0-DP-5:  connected -> i915    (Lenovo T27QD-40)
card0-DP-7:  connected -> i915    (Lenovo T27QD-40)

Hyprland renders on the Intel node:

/dev/dri/by-path/pci-0000:00:02.0-render -> renderD129   (Intel, i915)
/dev/dri/by-path/pci-0000:01:00.0-render -> renderD128   (NVIDIA)

Hyprland fds: card0 x6, renderD129 x6, renderD128 x1

Chrome follows the compositor onto the Intel node:

/opt/google/chrome/chrome --type=gpu-process --ozone-platform=wayland --render-node-override=/dev/dri/renderD129 ...

But the session environment forces the NVIDIA VA-API driver:

LIBVA_DRIVER_NAME=nvidia
NVD_BACKEND=direct
__GLX_VENDOR_LIBRARY_NAME=nvidia

The Intel VA-API driver works fine on the node the browser actually uses:

$ LIBVA_DRIVER_NAME=iHD vainfo --display drm --device /dev/dri/renderD129
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 26.2.4 ()
      VAProfileH264High   : VAEntrypointVLD
      VAProfileHEVCMain10 : VAEntrypointVLD
      VAProfileVP9Profile0: VAEntrypointVLD
      ...

omarchy-hw-hybrid-gpu correctly returns true on this machine, but nvidia.lua never consults it or anything like it.

Steps to reproduce

  1. Hybrid Intel + NVIDIA (GSP) laptop, with the displays wired to the Intel iGPU.
  2. Log in to a stock Omarchy session. nvidia.lua exports LIBVA_DRIVER_NAME=nvidia.
  3. Play a video in Chrome, Chromium or Brave with hardware acceleration on. Playback is broken.
  4. Turn hardware acceleration off. Playback works.

Suggested fix

As in #11168: export LIBVA_DRIVER_NAME=nvidia only when NVIDIA is the compositor's render device, not merely present. Checking which GPU drives the connected displays (or AQ_DRM_DEVICES when set) would cover it. Alternatively, leave LIBVA_DRIVER_NAME unset on hybrid systems; libva already picks the right driver per render node. __GLX_VENDOR_LIBRARY_NAME=nvidia comes from the same branch and probably deserves the same condition.

Workaround

In ~/.config/hypr/hyprland.lua, after require("default.hypr.omarchy"):

hl.env("LIBVA_DRIVER_NAME", "iHD")
hl.env("__GLX_VENDOR_LIBRARY_NAME", "mesa")

Versions

  • Omarchy 4.0.3-1, Hyprland 0.56.2 (efb5099), kernel 7.2.3-arch1-3
  • GPUs: Intel Arrow Lake-P Arc 130T/140T (8086:7d51, i915) + NVIDIA RTX PRO 500 Blackwell Laptop (10de:2db9, nvidia-open-dkms 610.57.04)
  • google-chrome / chromium 152.0.7977.82-1, brave-bin 1.94.121-1
  • mesa 1:26.2.2-1, libva 2.24.1-1, libva-nvidia-driver 0.0.18-1, intel-media-driver 26.2.4-1

Activity

  1. danielalbornozm commented on Sep 11, 2026

    @danielalbornozm
    danielalbornozm
    on Sep 11, 2026

    Thanks! I had the same problem with video playback.
    System: Intel Corporation Alder Lake-P GT2 [Iris Xe Graphics] + NVIDIA Corporation GA106M [GeForce RTX 3050 Ti Mobile / Max-Q].
    Fix applied: hl.env("LIBVA_DRIVER_NAME", "iHD")`

  2. RajdeepVerma commented on Sep 17, 2026

    @RajdeepVerma
    RajdeepVerma
    on Sep 17, 2026

    A counter-case worth factoring into the fix here, because the obvious version of it would regress my machine.

    AMD Renoir iGPU (0000:06:00.0) + GTX 1650 Mobile (0000:01:00.0), Omarchy 4.0.4-1, Aquamarine 0.15.0. Same mismatch you describe — nvidia.lua exports LIBVA_DRIVER_NAME=nvidia while Aquamarine renders on the iGPU — and the same symptom, Chromium flickering on video.

    But here the wiring is the other way round: my only external display (DP-1) is physically on the NVIDIA card, and only the internal eDP-1 is on the iGPU. So "the iGPU drives the displays → stop exporting NVIDIA VA-API" is not the right rule for this machine. NVIDIA genuinely owns the output being looked at; the thing that is wrong is the render device, not the VA-API driver. Fixing it by making NVIDIA primary (AQ_DRM_DEVICES NVIDIA-first) resolved the flicker and kept NVDEC.

    So the invariant that covers both cases isn't "follow the iGPU" — it's the VA-API driver and the Aquamarine render device must agree, and the render device should be the GPU that owns the connected outputs. On your machine that lands on Intel; on mine it lands on NVIDIA.

    Concretely, a check keyed on omarchy-hw-hybrid-gpu plus "is any connected connector on the NVIDIA card?" would separate the two, where a check keyed on "is the iGPU rendering?" would not. Full write-up of my side, including two Aquamarine mgpu footguns that show up once NVIDIA is made primary: #12289

  3. andyholst commented on Sep 22, 2026

    @andyholst
    andyholst
    on Sep 22, 2026

    Duplicate of #8215 — same root cause (nvidia.lua forces LIBVA_DRIVER_NAME=nvidia on hybrid laptops). See that issue for full details, regression history, and workaround.

    Local fix: browser launchers export LIBVA_DRIVER_NAME=iHD + MESA_LOADER_DRIVER_OVERRIDE=iris scoped to browser processes only (system stays on NVIDIA for games/CUDA).

  4. omarchybot
    added
    bugSomething isn't working
    on Sep 27, 2026

  5. omarchybot commented on Oct 11, 2026

    @omarchybot
    omarchybot
    on Oct 11, 2026
    Collaborator

    Thanks for the detailed second reproduction. This is the same bug as #8215, which is older and still open: default/hypr/nvidia.lua exporting LIBVA_DRIVER_NAME=nvidia (and __GLX_VENDOR_LIBRARY_NAME=nvidia) whenever a GSP-era NVIDIA GPU is present, so a browser compositing on the iGPU decodes on NVDEC and cannot import the frames. Same mechanism, same symptom, same fix.

    Where it stands, checked against the source:

    • quattro already changes this in 6ecf4bf ("Only force NVIDIA VA-API/GLX env when NVIDIA drives the display"): LIBVA_DRIVER_NAME and __GLX_VENDOR_LIBRARY_NAME are now set only when bin/omarchy-hw-nvidia-display says NVIDIA owns boot_vga. It is not in v4.0.4, so it reaches users with the next release. On a machine like yours, where the Intel iGPU is the boot display and drives every output, that gate leaves both variables unset and libva picks iHD for the render node the browser uses. Your hl.env workaround remains the way to get there before then.
    • Open pull request Only point the session at NVIDIA when NVIDIA is driving the screen #9483 refines that detector with DRM connector wiring. The counter-case @RajdeepVerma raised above, an external display wired to the NVIDIA card, is the kind of machine it is aimed at.

    This was reviewed by Claude Opus 5.5 alone. The second opinion (Codex Medium) answers, but its daily review budget was already spent, so it did not check this, and without it the bot does not close a duplicate. The issue stays open for the maintainer to close in favour of #8215. Nothing was run on a worker, since none has hybrid GPU hardware; the comparison is from the reports and the code on quattro.

  6. jandrusk commented on Oct 13, 2026

    @jandrusk
    jandrusk
    on Oct 13, 2026

    Looks like this is the same hybrid LIBVA issue as #8215 / #11168.

    On current quattro, default/hypr/nvidia.lua already gates LIBVA_DRIVER_NAME / __GLX_VENDOR_LIBRARY_NAME on omarchy-hw-nvidia-display (landed via #11690). If you're still on 4.0.4 without that, see backport #13902.

    Can we close this as fixed-on-quattro and keep discussion on #8215?

  7. omarchybot commented on Oct 14, 2026

    @omarchybot
    omarchybot
    on Oct 14, 2026
    Collaborator

    Closing this as a duplicate of #8215, which is older and still open. Both report the same bug on hybrid Intel + NVIDIA laptops whose displays are on the iGPU: default/hypr/nvidia.lua exports LIBVA_DRIVER_NAME=nvidia (and __GLX_VENDOR_LIBRARY_NAME=nvidia) whenever a GSP-era NVIDIA GPU is present, so a browser compositing on the iGPU decodes on NVDEC and the cross-GPU frame import breaks playback. Same cause, same symptom, same fix.

    Nothing new since the last comment here changes where it stands: on quattro, 6ecf4bf gates both variables on bin/omarchy-hw-nvidia-display, so a machine like this one, with every output on the Intel iGPU, leaves them unset. Discussion of the fix and of the counter-case @RajdeepVerma raised, an external display wired to the NVIDIA card, continues on #8215.

    Claude Opus 5.5 compared the two reports and checked nvidia.lua on quattro; Codex Medium was asked separately whether they are the same item before this was closed. Nothing was run on a worker, since none has hybrid GPU hardware. If this turns out to be a different problem, it can be reopened.

  8. omarchybot
    added
    duplicateThis issue or pull request already exists
    on Oct 14, 2026
  9. omarchybot
    closed this as duplicateon Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingduplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions