EDIT: The issue was my hdmi cord was not fully plugged into the monitor, I guess the first step should always be the simplest checks!
Which Linux distro are you using?
Fedora KDE plasma
Which release version?
44
Which kernel are you using?
6.19 but I also tested on 6.18 with no change
Which BIOS version are you using?
3.19
Which Framework Laptop 13 model are you using?
12th Gen Intel® Core™
Other info:
I had used my framework with ubuntu 22 (and windows 11) for a while and had no issues connecting external monitors. I just installed fedora 44 but can’t get external monitors to work. Fedora recognizes the hdmi expansion card, but when I check `/sys/class/drm/*/status
` the first four are disconnected and the last is connected, despite having hdmi plugged in. I also tried using an external usb to hdmi adapter that I know works.
I used claude code to try to debug, and these are its notes:
Framework 13 (12th Gen Intel) — HDMI expansion card no display output on Fedora 44 / kernel 6.18–6.19
The HDMI expansion card (32ac:0002) enumerates correctly on USB but produces no video output. After extensive diagnostics, the root cause is that the UCSI ACPI device (\_SB.UBTC, HID USBC000/PNP0CA0) is disabled at boot: its _STA method in the UsbCTabl SSDT returns 0 because two BIOS-populated variables (UCMS and USTC) in the GNVS shared memory region are 0. This prevents the ucsi_acpi driver from binding, leaves /sys/class/typec/ empty, and means DP Alt Mode is never negotiated — so the display pipeline never opens. The issue reproduces on both kernels 6.18 and 6.19 with BIOS 3.19 (fully updated). It also existed on BIOS 3.6 with kernel 6.19.
A secondary issue was found and fixed: the xe DRM driver was loading alongside i915 on Alder Lake-P (kernel 6.19 regression), causing a connector Unknown-1 leaked kernel WARNING on every boot. Blacklisting xe via /etc/modprobe.d/blacklist-xe.conf resolves this. A workaround being tested is an SSDT override that patches _STA to unconditionally return 0x0F, which would force ucsi_acpi to bind — but whether the UCSI mailbox base address (UBCB) in GNVS is valid or also zero is unconfirmed, since /dev/mem is blocked by CONFIG_STRICT_DEVMEM. The expected fix is either a BIOS correction to properly initialize UCMS/USTC/UBCB in GNVS, or a kernel patch to handle the Framework’s UCSI implementation.