In deciding whether these should be release blockers, it would be helpful to know if they affect other hardware. If folks (who are comfortable with testing pre-release stuff) who have laptops with Intel graphics could test booting a Fedora 44 nightly or just a kernel 6.19 build from Koji and see if they’re affected by any graphical corruption / flickering / tearing, that’d be great. If you do have a problem, please test whether booting with i915.enable_psr=0 avoids it, and maybe whether it differs based on whether an external display is plugged in.
I have a Lenovo Yoga Pro 9 16IAH10 with a Intel(R) Core™ Ultra 9 285H running on up-to-date Fedora 43 Cinnamon.
$ lspci -nn | grep -i vga
00:02.0 VGA compatible controller [0300]: Intel Corporation Arrow Lake-P [Arc Pro 130T/140T] [8086:7d51] (rev 03)
$ uname -r
6.19.13-200.fc43.x86_64
$ head /proc/cpuinfo | grep name
model name : Intel(R) Core(TM) Ultra 9 285H
My login screen would always freeze completely while typing my password. I had to force the system to use the xe driver (instead of the i915) and disable PSR. Using the boot options:
I was just going to say that modern Intel devices (like your laptop) are supposed to use more modern Intel XE driver which is specifically designed for them; i915 is obsolete technology.
I have the same platform (Intel 255H) and I’m on XE for about half a year already, everything works fine (currently using 6.19.13-200.fc43.x86_64).
by the way, as long as Fedora is known as “bleeding edge distro”, is there a reason to have i915 by default and not XE?
I also expected it to use the XE driver by default, but on a fresh Fedora install both i915 and XE are installed and initially both try to bind to the GPU. On my machine the i915 driver “wins” and takes control, which is why I had to add the boot options so that XE would actually bind to the device.
While I was trying to search the internet for help with this freezing issue I found this thread, and since @adamwill was explicitly asking for more affected Intel graphics users, I wanted to confirm that I’m also hitting a problem with PSR.
Given that the GPU is like already a year old (released january 2025), a complete freeze of the display right after a fresh install probably needs some attention.
Actually, this issue was already tracked down and fixed in a later kernel update. It’s related to PSR.
And honestly, I wouldn’t recommend turning on the Xe GPU driver unless you’re on supported hardware. I’m using an ARL-H U285H, and I tried enabling the Xe driver myself. It caused all sorts of problems—Ollama couldn’t read VRAM, games had weird rendering glitches, the whole mess. When I reported it to Intel, they basically said, “The Xe driver is only officially supported on LNL and newer integrated graphics. Yours might let you enable it, but it’s not covered.” Then they ignored me completely.
So unless you’ve got a B580 discrete GPU or an LNL or PTL iGPU, don’t expect Intel to care if you run into issues—even though you’ve technically been able to turn on the Xe driver since Tiger Lake.
Adding configuration detail in case it helps narrow this down on Arrow Lake-U:
The freezes occur with an external HDMI display connected (not the Dell XPS 9320 pattern, where attaching one suppresses the symptom). Both internal and external are running at 60 Hz, so the 120 Hz factor from the ThinkPad P14s case isn’t relevant here either.
The issue is most easily reproduced by playing a YouTube video and entering fullscreen.
When entering fullscreen, the desktop/video can become extremely stuttery. When exiting fullscreen, the display can become severely corrupted, with pixels/artifacts being painted across the screen.
It is not limited to one browser — I have reproduced it with both Firefox and Chrome.
The display can usually be recovered by pressing the power button to lock the screen and then unlocking it. Interestingly, switching to another TTY with Ctrl+Alt+F3 and then returning to the graphical session does not recover the display.
