dog turdles all the way down

it took a lot of back-and-forth with Claude before this "solution" was figured out.

The Year of the Linux Desktop, my ass.

 

Intel NUC8 (i3-8109U) — i915 Display Fix for Linux

Hardware

• Device: Intel NUC8 (NUC8i3BEH / NUC8i3BEK or similar)
• CPU/GPU: Intel Core i3-8109U with Iris Plus Graphics 655 (Coffee Lake GT3e)
• PCI Device ID: 8086:3ea5
• Display output: HDMI (internally routed through an LSPCON — a DisplayPort-to-HDMI Level Shifter/Protocol Converter)
• No discrete GPU

OS

• Ubuntu 26.04 (kernel 7.0.0-22-generic)
• X11 with LightDM
• Intel DDX driver (xserver-xorg-video-intel) using SNA acceleration

The Problem

The Iris Plus 655 (device ID 3ea5) is not in the i915 driver's default probe list and requires i915.force_probe=3ea5 to load. Once loaded, the driver initializes correctly — firmware loads, the GPU is recognized, and the framebuffer is created.

However, the NUC's HDMI port is not a direct HDMI output. It is wired through an LSPCON chip that converts DisplayPort to HDMI. The display therefore appears as DP-1 to the kernel and X11, not HDMI-A-1.

The core issue is a boot-time race condition: when the display manager (LightDM) starts during early boot and performs its initial modeset, the LSPCON chip has not yet completed link training. The modeset fails silently — X11 logs show a successful configuration, but the monitor receives no signal. The screen remains blank.

Key observations that led to diagnosing the race condition:

• The i915 driver loads and initializes without errors.
• X11 starts, reads the monitor's EDID, selects the correct mode (3440x1440@60), and reports success — yet the monitor shows no signal.
• Manually restarting LightDM from a text console always works.
• Switching to a VT (Ctrl+Alt+F2) and back reliably resets the display link.
• Using video=DP-1:1920x1080@60e or video=DP-1:3440x1440@60e in the kernel command line results in User-defined mode not supported errors in dmesg — the LSPCON isn't ready to accept modesets that early.
• chvt over SSH does not produce the same link reset as a physical VT switch or a console-initiated VT switch.

The Fix

Kernel Parameters

In /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="i915.force_probe=3ea5 i915.enable_psr=0 i915.enable_dc=0 i915.enable_guc=0 acpi_osi=Linux"

These disable Panel Self Refresh (PSR), Display C-states (DC), and GuC firmware submission, all of which can cause additional instability with this device. Apply with:

sudo update-grub

X11 Driver

Install the Intel DDX driver instead of relying on the generic modesetting driver. It has dedicated LSPCON handling code:

sudo apt install xserver-xorg-video-intel

Create /etc/X11/xorg.conf.d/20-intel.conf:

Section "Device"
    Identifier "Intel"
    Driver "intel"
    Option "AccelMethod" "sna"
    Option "DRI" "3"
EndSection

Boot Workaround — rc.local VT Switch

The workaround exploits the fact that switching virtual terminals forces the LSPCON to retrain its link. By performing a VT switch late in the boot process (after the hardware has settled), then starting the display manager, the modeset succeeds reliably.

Create /etc/rc.local:

#!/bin/bash
sleep 15
/usr/bin/chvt 2
sleep 1
/usr/bin/chvt 1
sleep 2
/bin/systemctl start lightdm
exit 0

Make it executable:

sudo chmod +x /etc/rc.local

Set the boot target to multi-user (text mode) so LightDM doesn't start before the VT switch:

sudo systemctl set-default multi-user.target

Reboot. The system will boot to a text console, rc.local will execute the VT switches after 15 seconds, and LightDM will start with a working display.

Why This Works

The VT switch (chvt 2, then chvt 1) triggers a full display pipeline teardown and re-initialization at the kernel level. This forces the LSPCON to perform a fresh link training sequence. By the time rc.local runs (15+ seconds into boot), the LSPCON hardware is fully powered and ready to negotiate, so the subsequent LightDM startup modeset succeeds.

Notes

• The 15-second sleep may be reducible on faster-booting systems, but err on the side of caution.
• If a future kernel adds 3ea5 to the i915 probe list and fixes LSPCON init timing, this workaround may become unnecessary.
• This issue affects NUC8 models with the i3-8109U / i5-8259U / i7-8559U (Coffee Lake GT3e with eDRAM). NUC models with GT2 GPUs (no LSPCON) are not affected.