Tracing a Laggy Ubuntu Desktop to Intel Display Power Saving

A fresh Ubuntu install on my Dell Latitude 7430 felt like a remote desktop session over bad Wi-Fi. Windows dragged behind the pointer, menus appeared late, and ordinary desktop motion felt disconnected from my hand.

The hardware did not suggest an obvious shortage: a 12th Gen Intel Core i7, 30 GB of RAM, NVMe storage, and Intel Iris Xe graphics. GNOME was my first suspect, so I tried Xubuntu. The lag remained.

That was the useful turn in the investigation. The question was no longer whether one desktop environment was too heavy. It was which layer could make a responsive computer look and feel slow.

The Usual Checks Did Not Explain It

I started with the familiar resource and rendering checks:

free -h
df -h
top
glxinfo -B
iostat -xz 1 3

Memory was available, swap was unused, and storage latency was low. Mesa reported hardware acceleration:

OpenGL renderer string: Mesa Intel(R) Iris(R) Xe Graphics (ADL GT2)
Accelerated: yes

Even glxgears stayed near the panel’s 60 Hz refresh rate:

301 frames in 5.0 seconds = 60.171 FPS

That result did not prove the desktop was healthy. glxgears was useful here only as a coarse check that rendering was accelerated and frames were being presented. It said nothing useful about pointer-to-display latency or whether every screen update arrived when it should.

A desktop interaction crosses several layers:

input device
  -> kernel input path
  -> display server
  -> compositor
  -> GPU driver
  -> internal panel

CPU, memory, disk, and aggregate frame-rate checks can all look normal while a delay later in that chain makes the whole machine feel sluggish.

First, I Stabilized the Baseline

The installation was on Ubuntu 26.04 with kernel 7.0.0-14-generic, while the configured repositories already offered 7.0.0-22. The generic kernel meta-packages were also missing. That did not explain the symptom, but it made driver investigation harder because the installation was not following the repository’s normal kernel update path.

I updated the system and restored the meta-packages:

sudo apt update
sudo apt full-upgrade
sudo apt install linux-generic linux-image-generic linux-headers-generic
sudo update-grub

fwupdmgr also offered a critical Dell firmware update:

fwupdmgr get-updates
sudo fwupdmgr update

After reboot, the machine reported kernel 7.0.0-22-generic and BIOS 1.39.1. The updates were worth doing, but the desktop still lagged. That distinction matters: they improved the debugging baseline; they were not the observed fix.

Cleanup Reduced Noise, Not the Lag

The boot and session logs contained several unrelated problems:

• failed Snap user services during login
• enabled SSSD sockets without a configured SSSD domain
• sensor and Wacom errors from iio-sensor-proxy
• multiple pointer-like devices
• XFCE compositing while I was testing Xubuntu

I tried performance mode, disabled XFCE compositing, detached unused Wacom and PS/2 devices, and disabled services that this laptop did not need. Those changes made the logs quieter and removed variables, but they did not make the desktop feel normal.

I am deliberately not presenting that cleanup as a recipe. Disabling input devices trades away their functions, and removing authentication or session components can break a machine that actually uses them. More importantly, none of those changes produced the result I was looking for.

The Display Driver Supplied a Better Lead

This Intel display-driver warning matched the symptom more closely:

i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A

The i915 debug state showed PSR2 selective fetch enabled:

sudo cat /sys/kernel/debug/dri/1/i915_edp_psr_status

dri/1 was the Intel device on this installation; that number is not universal.

The relevant output was:

PSR mode: PSR2 enabled
PSR2 selective fetch: enabled

Panel Self Refresh (PSR) lets a compatible internal panel retain an unchanged frame so the display link and memory controller can enter lower-power states. Framebuffer Compression (FBC) reduces display memory traffic. Both are legitimate power-saving mechanisms, not suspicious features by themselves. The kernel documentation describes the tracking PSR needs when the front buffer changes and notes cases where FBC must be disabled to preserve correct screen updates .

The warning did not prove that PSR caused the lag. It gave me a testable lead in the one part of the stack that the earlier checks had not exercised: how updates reached the internal panel.

The PSR/FBC Workaround

I added a GRUB drop-in:

sudoedit /etc/default/grub.d/intel-ui-latency.cfg

with:

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT i915.enable_psr=0 i915.enable_fbc=0"

Then I regenerated the boot configuration and rebooted:

sudo update-grub
sudo reboot

After reboot, I confirmed that both parameters appeared in /proc/cmdline. The desktop was finally responsive: pointer motion, window dragging, and menus behaved as I expected from the hardware.

This is the boundary of what that test established:

• The earlier package, firmware, compositor, device, and service changes had not removed the lag.
• Disabling PSR and FBC together changed the observed behavior after reboot.
• The i915 selective-fetch warning made the display-power path the strongest lead.
• Because I disabled both features in one test, I did not isolate PSR from FBC.
• I also did not roll back every earlier cleanup change and repeat the test as a controlled experiment.

So I treat this as a successful workaround for this laptop and kernel combination, not evidence that PSR2 is generally broken or that either parameter belongs on every Intel laptop.

Both settings sacrifice power-saving behavior, so battery life may be worse. They are also easy to roll back. To restore the defaults, remove the drop-in, rebuild GRUB, and reboot:

sudo rm /etc/default/grub.d/intel-ui-latency.cfg
sudo update-grub
sudo reboot

Returning to GNOME

Xubuntu had been a diagnostic detour rather than a solution. Once the display workaround was in place, I switched the machine back to GDM and the Ubuntu session:

echo /usr/sbin/gdm3 | sudo tee /etc/X11/default-display-manager
sudo systemctl disable lightdm.service
sudo systemctl enable gdm3.service
rm ~/.dmrc

I also changed the stored AccountsService session back to:

Session=ubuntu
XSession=ubuntu

GNOME was responsive too. Changing desktop environments had altered the surface of the problem without touching the layer that mattered.

A Better Order for This Diagnosis

If another Linux laptop has healthy resource numbers but the desktop still feels delayed, I would work through it in this order:

1. Bring packages, the kernel update path, and firmware to a known baseline.
2. Check memory, swapping, storage latency, thermals, and hardware acceleration.
3. Treat a frame-rate result as a rendering clue, not an input-latency measurement.
4. Inspect boot and display-driver logs for a clue that matches the symptom.
5. Make one reversible subsystem change at a time and record what actually changes.
6. Keep cleanup separate from diagnosis; a quieter log is not the same as a fixed desktop.

These commands cover the first pass:

uname -r
apt-cache policy linux-generic linux-image-generic
glxinfo -B
systemctl --failed
systemctl --user --failed
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
sudo journalctl -b -k

On this Latitude, the useful evidence was not high CPU use or slow storage. It was one i915 selective-fetch warning, followed by a reversible boot-parameter test that changed the behavior. The workaround is less satisfying than an isolated upstream fix, but it is an honest description of what made this machine usable again.