Skip to content

Instantly share code, notes, and snippets.

@alexcpn

alexcpn/chrome-hybrid-gpu-lag-fix.md

Created June 8, 2026 17:07
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save alexcpn/974a80fab04ef76910c022d289f6d12b to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save alexcpn/974a80fab04ef76910c022d289f6d12b to your computer and use it in GitHub Desktop.
Download ZIP
Fix: Chrome/Electron keystroke lag on AMD+NVIDIA hybrid-graphics laptop (wrong primary display GPU)
Raw
chrome-hybrid-gpu-lag-fix.md

Fixed: Chrome/Electron keystroke lag on AMD+NVIDIA hybrid-graphics laptop (Pop!_OS / GNOME / X11)

TL;DR

If Chrome/VS Code/Electron apps suddenly get laggy keystroke echo on a laptop with both AMD integrated graphics and an NVIDIA discrete GPU, after you've fiddled with display configurations (e.g. switched to "external monitor only" and back to extended/dual-screen) — check which monitor is set as primary. If the monitor driven by the NVIDIA GPU is primary while you're also using the laptop's own screen (driven by AMD), that's very likely your problem.

xrandr --query | grep primary
xrandr --listproviders     # shows which provider (GPU) drives which output

Fix: set the AMD-driven internal panel back to primary:

xrandr --output eDP --primary               # quick live test

Permanent: Settings → Displays → click the internal display → set as primary (this rewrites ~/.config/monitors.xml, moving <primary>yes</primary> to the correct <logicalmonitor> block).

My hardware / software environment

  • Laptop: Acer (hybrid graphics)
  • Discrete GPU: NVIDIA GeForce RTX 3060 Mobile / Max-Q (driver 580.159.03)
  • Integrated GPU: AMD Radeon "Cezanne" (Ryzen 5000-series APU)
  • Internal panel eDP — wired ONLY to the AMD iGPU (NVIDIA cannot drive it)
  • External monitor via HDMI-1-0 — wired ONLY to the NVIDIA dGPU
  • OS: Pop!_OS 22.04, kernel 6.9.3, GNOME Shell 42.9, X11 (Mutter), system76-power graphics hybrid

Symptom

Severe keystroke/typing lag in Chrome and Electron apps (e.g. VS Code) whenever both the internal screen and an external monitor were active ("extended" mode). Closing the laptop lid while in extended mode (forcing a display reconfig) also triggered it. CPU/GPU load stayed low — it wasn't a resource-contention issue.

Root cause

I had previously switched my display config to "external monitor only" mode. At that point GNOME naturally made that monitor (the only one active) the primary display, and the assignment was persisted to ~/.config/monitors.xml. When I later switched back to using both screens, the external monitor (NVIDIA) stayed primary while the internal panel (AMD) was secondary — and that bad assignment kept getting reapplied on every login/reboot (so logging out or rebooting did NOT fix it).

With the NVIDIA-driven screen as primary, Mutter's main compositing/buffer presentation path now had to copy frames from the AMD GPU (which renders most apps and the internal panel) across to the NVIDIA GPU — and the X server log showed it falling back to an unsynchronized copy method on that primary path:

(II) AMDGPU(0): Allocate new frame buffer 3840x1200
(II) AMDGPU(0):  => pitch 15360 bytes
randr: falling back to unsynchronized pixmap sharing
(II) NVIDIA(G0): Setting mode "HDMI-1-0: nvidia-auto-select @1920x1200 +1920+0 ..."

This "unsynchronized pixmap sharing" fallback is a known PRIME-sync limitation between AMD and NVIDIA GPUs in X11 (see links below) — but it only became a visible, severe problem here because the wrong GPU's monitor was set as primary, putting the unsynced cross-GPU copy on the hot path for basically every redraw, instead of just for content shown on the secondary screen.

Red herring to ignore

You may also see this in journalctl at every login — it's unrelated/cosmetic and NOT the cause of the lag (it fires once at startup and stops):

gnome-shell[...]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:...]
  is on because it needs an allocation.

What did NOT fix it (don't waste time on these)

  • Logging out / rebooting — the bad primary-display assignment is saved in monitors.xml and gets reapplied on every login.
  • Switching system76-power graphics mode — on this hardware the internal panel is wired only to AMD and the external port only to NVIDIA, so hybrid is the only mode that drives both screens. Switching to nvidia / integrated / amd / compute just breaks one of the displays entirely (don't do it — ask me how I know 🙂).

The actual fix (verified working)

xrandr --output eDP --primary

…then made permanent by editing ~/.config/monitors.xml, moving <primary>yes</primary> from the external monitor's <logicalmonitor> block to the internal panel's block (in the <configuration> matching my current monitor combo). Equivalent to doing it through Settings → Displays.

Lag disappeared immediately.

Related reports / background reading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment