Proposed as a Blocker for 44-beta by Fedora user tpopela using the blocker tracking app because:

 The laptop can't be normally used with the default configuration unless Intel's Panel Self Refresh is disabled.

Created attachment 2128874 [details]
kernel log

Same here. On the latest Kernel 6.19, graphical issues such as screen tearing and stuttering appear immediately after booting into GNOME. Everything works fine on 6.18. More precisely, this problem started with Kernel 6.19 RC2 and is still present in the stable release.

After testing with i915.enable_psr=0, the issue indeed disappears.

ThinkPad P14s, Intel U285H.

+5 in https://pagure.io/fedora-qa/blocker-review/issue/2028 , marking accepted.

Has anyone given a rawhide kernel a test to see if the issue was fixed with the drm pull?

I've tried kernel-6.20.0-0.rc0.260217g9702969978695.10.fc45 and it is still broken.

Tomas, are you willing to bisect the kernel to figure out the commit that broke it?

No, I don't have the capacity to do so.

Tomas, uploading a short video would be nice, so that people have a good idea of how it looks like.

We've tested our QA laptops and unfortunately none of them seem to exhibit this bug.

Similar but not the same (might be related, though) - bug 2441941

> Tomas, uploading a short video would be nice, so that people have a good idea of how it looks like.

You internally have the access (at least Petr) to the recordings, feel free to upload it somewhere and share it here.

Created attachment 2130700 [details]
flickering example video

Hum, has anyone seen this on anything other than a P14s ? I kinda had the impression it was known to affect a wide range of systems, but if it's just one, it might not be a Beta blocker really...

Hi, I conducted a test on another Chromebook of mine, also running Fedora 43 with an Intel CPU and integrated GPU. I installed and tested Kernel 6.19.3 and did not encounter any PSR-related issues.

Kernel:https://koji.fedoraproject.org/koji/buildinfo?buildID=2944717
CPU:Intel Celeron 6305
GPU:Intel UHD G4(TGL GT2)


However, it's currently difficult to determine whether this issue is specific to the P14, or to certain ThinkPad models.

Have any users with Intel MTL or ARL performed tests? I personally suspect this might be specific to MTL/ARL GPUs.Intel has had some commits with bugs in both 6.18 and 6.19; 6.18 even caused some Sycl-related issues that were only fixed later.

If this is specific to certain ThinkPad models... I know there's someone named Mark Pearson who should be responsible for Lenovo product Linux support. I wonder if we could seek his help, since ThinkPads also come with Fedora pre-installed and will inevitably encounter Kernel 6.19-related issues.

From what I recall, I installed and tested Kernel 6.19 back when it was still at RC1, and I encountered this issue at that time. I suspect that something in the DRM/next or similar PRs after the 6.19 Merge Window opened may have caused this situation.

Hi @plumis,

>> Have any users with Intel MTL or ARL performed tests? 

I have no issues with
Version: ThinkPad P1 Gen 7
+
lspci -k | grep -A 3 -i "VGA\|3D"
00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Arc Graphics] (rev 08)
	Subsystem: Lenovo Device 2235
	Kernel driver in use: i915
	Kernel modules: i915, xe

kernel-6.19.3-300.fc44.x86_64
mesa-dri-drivers-25.3.5-2.fc44.x86_64
---

It would also be great if anyone affected can try past kernel builds from https://koji.fedoraproject.org/koji/packageinfo?packageID=8 and identify the last working one and the first broken one.

Thank you very much for your testing. It seems the issue is becoming even more complex.
I have tested several devices I have on hand, all running a consistent environment: Fedora 43 + Intel GPU + Kernel 6.19.3. The results are as follows:

- Chromebook (Intel Celeron 6305): Normal
- Surface Go 2 (Intel Core m3-8100Y / 4454Y): Normal
- ThinkPad P14s Gen 6: Faulty (exhibits the same tearing/stuttering)

Combined with the original reporter Tomas’s ThinkPad P14s Gen 5, it appears that this issue specifically affects the base-model ThinkPad P14s series with Intel graphics. Since the Gen 6 and Gen 5 are minor iterations of each other, I suspect this might be related to the Display Panel.

For reference, my screen is a 3K (3072 x 1920) IPS panel. I am not sure if Tomas has the exact same panel configuration.

I also attempted the following troubleshooting steps, but none of them resolved the issue:

- Switching from the i915 driver to the experimental Xe driver.
- Toggling Mutter’s VRR (Variable Refresh Rate) settings (both enabling and disabling).
- Testing the newly released Kernel 7.0 RC1.

I tried to extract useful information from the logs, but unfortunately, they appear silent; there is no mention of PSR or any related errors in the kernel logs (dmesg).

I checked Intel PSR commits log and find nothing useful:
https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/i915/display/intel_psr.c

If this is indeed panel-specific, it is difficult to determine if this is exclusive to the P14s. Lenovo uses this same panel model in many other devices, such as the ThinkBook 14+ and likely in future generations of the P14s as well.

I accidentally tried connecting an external monitor to test, and I made some new discoveries.

When I adjust the refresh rate to 60Hz, everything works normally. When I set it back to 120Hz, screen tearing and stuttering occur. Both my P14s and Tomas's P14s display panels should support 120Hz refresh rate, so we have the same problem.

Could the reason the P1 Gen 7 has no issues be because its screen refresh rate is 60Hz?

So, is one of the reasons for reproducing this issue the high refresh rate?

After kernel 6.19, will Intel core laptops using high refresh rate screens encounter screen tearing issues, and can disabling PSR solve it?

> For reference, my screen is a 3K (3072 x 1920) IPS panel. I am not sure if Tomas has the exact same panel configuration.

Yes, I do.

https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771

Want to give https://koji.fedoraproject.org/koji/taskinfo?taskID=142945237 a try? It is a scratch build, so not secure boot signed unfortunately.

(In reply to Justin M. Forbes from comment #20)
> Want to give https://koji.fedoraproject.org/koji/taskinfo?taskID=142945237 a
> try? It is a scratch build, so not secure boot signed unfortunately.

Just tried.
Still have issue.

I'm calling for a re-vote on blocker status here, since despite sending out a call for testing we've yet to receive any report that this affects any systems other than P14s with 120Hz display, and there is a clear workaround for it. Based on current information I think it'd be OK to release Beta with this as a documented known issue.

I am all for this being a final blocker, but it seems a bit much making it a beta blocker as a bug impacting limited hardware with a known workaround in my opinion. As there is no upstream fix just yet, the timeframe for a fix in Fedora is still unclear.

During Beta Go/NoGo meeting [1]:

!agreed 2438442 - RejectedBlocker (Beta) - this is rejected as we have no clear indication it affects a very wide range of hardware. It's only positively confirmed to affect certain variants of a single laptop model (Thinkpad P14s with 120Hz screen). Per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? our decision is that's not broad enough to merit the bug being a Beta blocker

[1] https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-03-05/

Transferring the proposal to a FinalBlocker instead.

https://patchwork.freedesktop.org/series/162864/
here is a patch from intel for testing about fix this issue.

Discussed in a blocker review meeting [1] on 2026-03-09. The outcome was:

!agreed 2438442 - RejectedBlocker (Final) - this is rejected per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? , because so far we still have no indication this affects more than a single laptop model, and blocking the release for a workaroundable issue on a single laptop model isn't really in line with past reality. Note "Bugs that affect only a single adapter or small group of closely-related adapters are almost never taken as blockers" in the FAQ.

[1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/

https://koji.fedoraproject.org/koji/taskinfo?taskID=143171521 is a build you can test that patch with

(In reply to Justin M. Forbes from comment #27)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=143171521 is a build you
> can test that patch with

Thanks for your building.
It seems still havent fix this issue yet.
It seems we need to continue communicating with the Intel upstream developers, report the logs, and seek their assistance to resolve this.

In fact, another laptop user with a Lenovo Yoga 7 Pro (Intel) has encountered the same issue, but from openSUSE:
https://bugzilla.opensuse.org/show_bug.cgi?id=1259036
It's possible they are using the same LCD panel, a 14.5" 3K (3072x1920) IPS, or possibly the OLED version, but both are 120Hz with VRR, and also on MTL and newer platforms.

If anyone has a SUSE bugzilla account, it'd be great if they could comment there and link to this bug and https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771 .

I have an account for progress.opensuse.org , but apparently it's not the same auth system...

Currently, the OpenSUSE user who reported the issue has already gotten involved on the i915 side:

https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771

Based on the current situation, all affected systems share the same 3K IPS display panel and/or high-refresh-rate screens. Intel appears to have narrowed down the root cause to a potential incompatibility between Panel Self-Refresh (PSR) and Variable Refresh Rate (VRR).

It's unclear whether this issue is related to the display panel manufacturer or to a conflict between VRR and PSR. Given that GNOME 50 enables VRR support by default, it's possible that other users may be affected as well.

Affected users report that the issue disappears after disabling and then re-enabling PSR2:


$ echo 1 > /sys/kernel/debug/dri/1/i915_edp_psr_debug  # disable PSR
$ echo 0 > /sys/kernel/debug/dri/1/i915_edp_psr_debug  # re-enable PSR


Intel has now provided a new patch for testing (the previous one didn't work). 

https://patchwork.freedesktop.org/series/162920/

To be honest, I'm not a kernel developer and I'm not very experienced with applying patches and compiling the kernel—I tried several times yesterday but wasn't successful.

(In reply to plumlis from comment #31)
> Given that GNOME 50 enables VRR
> support by default, it's possible that other users may be affected as well.

I don't think that's correct. With Fedora 44 Beta and a VRR display, the VRR option in available by default, but *disabled* by default. Also, the display runs at 60 Hz by default (while my display can do 144 Hz). I need to switch both manually. Tested with a Live image.

Also, interestingly, in comment 16 you said that disabling VRR doesn't help (only lowering refresh rate does). So I wonder whether this can really be attributed to VRR and how. But anyway, I just wanted to point out that in a default state, Fedora seems be running with conservative values (60 Hz, no VRR) and changes must be done manually. Unless this is hardware-specific.

(In reply to plumlis from comment #31)
> Intel has now provided a new patch for testing (the previous one didn't
> work). 
> 
> https://patchwork.freedesktop.org/series/162920/
> 
> To be honest, I'm not a kernel developer and I'm not very experienced with
> applying patches and compiling the kernel—I tried several times yesterday
> but wasn't successful.

I've started the scratch build with that patch in https://koji.fedoraproject.org/koji/taskinfo?taskID=143202465 (it is still building)

Kamil: I wonder if the reason we're not seeing this more is that on *most* systems we default to 60Hz even if the panel is 120Hz-capable, but on the affected systems we default to 120Hz? It's just a theory, but it might explain things.

(In reply to Kamil Páral from comment #32)
> With Fedora 44 Beta and a VRR display, the VRR option in available by default, but *disabled* by default.

That's right.

> Unless this is hardware-specific.

It's not. mutter prefers modes which don't allow VRR over the corresponding modes which allow VRR, so the default configuration never allows VRR.

Moreover, in the attached video, VRR can't really be active (mutter doesn't enable the VRR_ENABLED CRTC property), even if VRR was enabled in mutter's display configuration, because there's no single surface which covers the display (since the top bar is visible).

> So I wonder whether this can really be attributed to VRR and how.

It seems unlikely, though it might still be possible in theory, if the kernel driver enables VRR signalling even while the VRR_ENABLED property is disabled (e.g. to avoid glitches when toggling the property, though I thought this could only be necessary in some cases with HDMI display connections, i.e. not with internal panels). Note that in this case mutter couldn't do anything to avoid the issue, per above VRR is effectively disabled in the KMS API in the attached video anyway.

However, I don't see any mention of VRR in the referenced gitlab issue or patch series, so it's not clear where the "Intel appears to have narrowed down the root cause to a potential incompatibility between Panel Self-Refresh (PSR) and Variable Refresh Rate (VRR)" statement is coming from.