Disable PSR2 selective fetch on the Dell Latitude 9440 2-in-1

[pelifix]

On a Dell Latitude 9440 2-in-1 (Raptor Lake-P / Iris Xe, AUO B140QAN eDP panel), a fresh Omarchy install is unusably slow: the pointer and keystrokes land late, while every CPU, GPU, memory, and disk stat reads idle and there are no IRQ storms. It looks like a machine that cannot keep up, and it sends people hunting for a performance problem that is not there.

Disabling PSR2 removes it. i915.enable_psr2_sel_fetch=0 drops the panel to PSR1: self-refresh and its power saving stay, and only PSR2's partial-frame updates are given up. The drop-in goes to /etc/limine-entry-tool.d/, matching install/hardware/asus/fix-asus-ptl-b9406-display.sh, which works around the same class of problem on an ASUS panel.

i915 also logs this once per boot on the affected machine:

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

To be straight about what that line is worth: it is drm_info_once and it sets full_update = true, so it is the driver's own fallback to a full-frame update, not a failed commit. It says selective fetch is unhappy on this panel; it does not by itself explain the lag. The experiment is what is established here, not the mechanism. I'm reporting it to i915 upstream separately, where the real fix belongs.

Verified on the affected machine: it ran two weeks with PSR off entirely (i915.enable_psr=0) and no lag, and narrowing that to selective fetch keeps the lag away:

Sink support: PSR = yes [0x03], Panel Replay = no
PSR mode: PSR1 enabled
Source PSR/PanelReplay status: IDLE

Notes for review:

• Kernel versions: tested, still needed on 7.2.4. The lag was diagnosed on 7.1.9, so I booted 7.2.4 with the workaround removed to check whether a newer i915 had already fixed it. It has not — the lag came back immediately, with PSR mode: PSR2 enabled and PSR2 selective fetch: enabled confirmed in debugfs while the machine was lagging. This is a current bug, not a stale workaround.
• The Dell XPS 13 9440 shares the model number and is a different machine on a different GPU. omarchy-hw-dell-latitude-9440 requires the word Latitude; there is a test asserting XPS 9440 does not match.
• The migration is included because hardware leaves only run at install time, so machines installed before this never get the workaround. It is idempotent, and it leaves a hand-applied i915.enable_psr setting alone rather than adding a drop-in that contradicts it. Happy to drop it if install-time-only is the preference here — the comparable B9406 fix shipped without one.
• Tested with the new test/shell.d/latitude-9440-display-test.sh (10 checks), plus ./test/cli and the bin-style, limine-defaults, migrate-*, ptl-kernel-migration, t2-hardware, and brcmfmac-supplicant suites.

🤖 Generated with Claude Code

[pelifix]

Following up on the kernel-version caveat in the description — I said I'd test 7.2.4 without the workaround before merge, so I have.

Booted with the drop-in disabled and drm.debug=0xe. The lag reproduced immediately. Captured from debugfs while the machine was actually lagging:

Sink support: PSR = yes [0x03], Panel Replay = no
PSR mode: PSR2 enabled
Source PSR/PanelReplay ctl: enabled [0x80004a26]
Source PSR/PanelReplay status: SU_STANDBY [0x64000110]
PSR2 selective fetch: enabled

Re-enabling i915.enable_psr2_sel_fetch=0 clears it again.

So 7.2.4 has not fixed this and the workaround is still required on the current kernel. I've updated the description to say so; no code changes, the diff is unchanged.

One caveat on evidence, to avoid overstating it: Selective fetch area calculation failed in pipe A appeared exactly once in that boot, but that's just drm_info_once doing its job — the count carries no information about severity and shouldn't be read as a frequency. The experiment is still the thing that's established here, not the mechanism. The i915 report is in progress separately.