Workaround: Framework 13 Pro (Intel Core Ultra Series 3) screen tearing / flicker on Arch

Framework Laptop 13 Linux
1

Scope note: this is a Linux fix. It is a kernel module parameter for the Intel xe driver and does nothing on Windows. If you are seeing similar tearing on Windows, this thread will not help you. I hand-verified this on my new motherboard after switching from an AMD Ryzen that didn’t have this problem.

I originally thought this was caused by a loose display cable, but nope.

Which Linux distro are you using? Arch Linux
Which release version? Rolling, no release version
If rolling release, last date updated? 2026-07-26
Which kernel are you using? 7.1.5-arch1-1
Which BIOS version are you using? INSYDE 03.02 (release 3.2, dated 2026-05-26)
Which Framework Laptop 13 model are you using? Intel Core Ultra Series 3 (Core Ultra X7 358H), Laptop 13 Pro, board FRANMJCP07 rev A7

Batch 1 here, running Arch. Hit this within a day of setup and it looked alarming enough that I want it written down before the rest of Batch 1 lands. Short version: it is not your panel, it is not your mainboard, and you do not need to RMA. It is Panel Self Refresh and Panel Replay on the new xe driver against this eDP panel.

Symptoms

If you are here from a search, the plain-language version: the screen tears, flickers, blinks, or flashes black on a brand new Framework Laptop 13 Pro running Linux. It looks like failing hardware. It is (probably) not.

  • Horizontal tear lines or a torn band across the screen, worst during scrolling and window drags.
  • Brief full-screen flicker, screen blinking, or a black flash when the screen content goes mostly static and then updates (notification popups, cursor blink in a terminal).
  • Compositor reports no tearing of its own. On Hyprland hyprctl monitors showed activelyTearing: false while the panel was visibly tearing, which is the giveaway that this is below the compositor.
  • Both the tearing and the flicker only occur inside a desktop environment. A pure TTY (Ctrl+Alt+F2, no compositor running) is completely clean. This is a useful first diagnostic: drop to a TTY, scroll some output, and if it looks fine there but tears under your DE, you are almost certainly looking at this bug rather than a failing panel or cable. It is also why nobody should rush to RMA over it.

Prior art, and why this is not that

“Disable PSR on a Framework” is old advice. There is a 2021 thread (Screen tearing with Linux) where the second reply is already telling people the topic is beaten. So to be clear about what is actually new here:

  • Those threads are 11th/12th/13th gen on the i915 driver. This is Panther Lake on xe. The parameter prefix changed, so i915.enable_psr=0 does nothing on this hardware. It has to be xe.enable_psr=0.
  • Most of the old tearing threads resolve to X11 compositing or fractional scaling, and the fix is “use Wayland” or “use the modesetting driver”. That is a different bug. I am already on Wayland at integer scale 1.0 and still saw this.
  • Panel Replay did not exist in those threads. It is an eDP 1.5 feature, it is a separate knob from PSR, and it is on by default here. If you carry over the old muscle memory and set only xe.enable_psr=0, you may not fix it.

That last point is the entire reason I am posting rather than pointing at the old threads.

The fix

Add these two kernel parameters:

xe.enable_psr=0 xe.enable_panel_replay=0

That is it. Reboot and it is gone.

enable_psr=0 disables Panel Self Refresh. enable_panel_replay=0 disables Panel Replay, which is the newer eDP 1.5 equivalent and is enabled by default on this hardware. I set both at the same time and the problem went away, so I cannot tell you which one was actually responsible. If someone wants to bisect that and report back, it would be useful.

Where to put it

Depends on your bootloader. Note that these are module parameters for the xe driver, so they must be on the kernel command line at boot. There is no runtime toggle.

systemd-boot (what archinstall gives you by default): edit your entry under /boot/loader/entries/. The filename is date-stamped from install time, so mine is 2025-02-09_06-02-29_linux.conf. Append to the existing options line, do not add a second one:

options cryptdevice=PARTUUID=<yours>:root root=/dev/mapper/root rw rootfstype=ext4 xe.enable_psr=0 xe.enable_panel_replay=0

Do the same in your -fallback.conf entry. If you only patch the main entry, the fallback boot will tear and you will think the fix regressed.

GRUB: add to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then grub-mkconfig -o /boot/grub/grub.cfg.

Either way, confirm it took after reboot:

cat /proc/cmdline

You should see both parameters at the end.

What if you want the power saving back

PSR and Panel Replay exist to save battery by letting the panel hold its own framebuffer while content is static. Turning them off costs you some idle battery life. Before giving up on them entirely, worth trying:

xe.psr_safest_params=1

That keeps PSR on but replaces the VBT-supplied timing parameters with conservative ones. If that alone fixes it, the bug is bad values in the VBT rather than PSR itself, which is useful information for anyone filing upstream.

You can also try xe.enable_psr=1 (cap at PSR1, no PSR2) as a middle ground. I have not tested either of these myself, since the full disable solved it and I stopped there.

My exact config, for comparison

  • Framework Laptop 13 Pro (Intel Core Ultra Series 3), board FRANMJCP07 rev A7, Batch 1
  • BIOS: INSYDE 03.02, dated 2026-05-26
  • CPU: Intel Core Ultra X7 358H
  • GPU: Panther Lake, Arc B390, PCI ID 8086:b082 rev 04
  • Panel: BOE 0x095F, 2256x1504, eDP-1, glossy variant
  • Arch Linux, last full upgrade 2026-07-26
  • Kernel 7.1.5-arch1-1, mesa 26.1.5, linux-firmware 20260622, systemd 261.2
  • Wayland, Hyprland 0.56.0
  • Bootloader: systemd-boot 257.2, Secure Boot disabled
  • Root on LUKS (relevant only because it makes my kernel command line long, see the systemd-boot example below)

I run the panel at a manually set 48 Hz to save power (it supports 60). That is unrelated to the bug, but mentioning it so nobody reads a low refresh rate in my output as a symptom.

If you are on this hardware and reading this in a panic

Try the two parameters before you open a support ticket. If they fix it, you have a driver-side workaround and a working machine, and it is worth adding your panel model and BIOS version to this thread so we can see whether this is panel-lottery or universal to the Batch 1 config.

If they do not fix it, post your cat /proc/cmdline, your panel model from hyprctl monitors or drm_info, and your kernel version, and someone can help narrow it down.

4 Likes
2

Just a short follow-up here as I was running into the same on Fedora 44, kernel 7.1.5: xe.psr_safest_params=1 ended up being sufficient to solve this issue for now.

Coming from a Framework 13 upgraded to a Core Ultra Series 3 mainboard with the 2.2k matte display.