[Laptop 13]

[davidkhanks]

System Model or SKU

Framework Laptop 13 (Intel® Core™ Ultra Series 3)

BIOS Version

03.02 (2026-05-26)

DIY Edition Information

System: Ultra X7 358H
Memory: LPCAMM2 - LPDDR5X - 64GB
Storage: SANDISK 850X PCIe® 4.0 M.2 2280 - 2TB

Port/Peripheral Information

Peripheral vendor and name: [FILL IN hub vendor + model]

The hub presents as a USB 3.x hub chain — VIA Labs VL822/VL815, a Realtek
RTL8153 gigabit ethernet bridge, and a Genesys Logic hub. It is not a
Thunderbolt/USB4 dock; the display path is DisplayPort alt mode.

Expansion cards by bay:

1. USB-C (Back left) (Charger connected here)
2. USB-C (Front left) (USB-C Hub that is having the issue is here)
3. USB-A (Back right)
4. 1 TB Expansion card (Front right)

The failing connector is reported as con3 by ucsi_acpi and as USB-C Port 3 by framework_tool --pdports. A 100 W charger is attached to USB-C Port 2 and is unaffected throughout.

Standalone Operation

Full System, Standalone mode NOT enabled (normal usage)

Describe the Bug

The PD controller reports DisplayPort alt mode as connected with HPD
asserted, while the same controller's UCSI interface returns
UCSI_ERROR_UNDEFINED for the commands the kernel needs to act on it. The
firmware is internally inconsistent, and the external monitor is invisible to
the OS until a full reboot.

USB data through the hub works perfectly — keyboard, mouse, gigabit ethernet
and a webcam all enumerate and function. Only video is dead.

framework_tool --pdports while the monitor is dark:

USB-C Port 3:
  PD Contract:   Yes
  Power Role:    Source
  Data Role:     Dfp
  VCONN:         Off
  Negotiated:    5.000 V, 3000 mA, 15.0 W
  CC Polarity:   CC2
  Port Partner:  Sink
  EPR:           Inactive
  DP Alt Mode:   UFP_D Connected, HPD High (0x82)

So the EC/PD side has the DP link up and hot-plug detect high.

Meanwhile the kernel gets errors from the same controller:

ucsi_acpi USBC000:00: unknown error 256
ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
ucsi_acpi USBC000:00: con3: failed to register partner alt modes (-5)

unknown error 256 is not the kernel failing to decode something. In
drivers/usb/typec/ucsi/ucsi.h, UCSI_ERROR_UNDEFINED is BIT(8) = 256, and
ucsi.c maps it to -EIO. The PPM is literally reporting "undefined error"
for GET_CABLE_PROPERTY and for GET_ALTERNATE_MODES.

Because GET_ALTERNATE_MODES fails, ucsi_register_altmodes() has nothing to
register, the typec layer never publishes a DP alt mode, and the xe display
driver is never told to claim the DP lanes. Every DRM connector reads
disconnected:

/sys/class/drm/card0-DP-1   disconnected
/sys/class/drm/card0-DP-2   disconnected
/sys/class/drm/card0-DP-3   disconnected
/sys/class/drm/card0-DP-4   disconnected
/sys/class/drm/card0-eDP-1  connected

xe logged nothing at all at plug-in time — no hotplug event, no connector
event. The graphics driver is not failing; it is never notified.

Note also that GET_CABLE_PROPERTY failed (-5) first appears at 10:50:29,
immediately after boot and roughly 50 minutes before the hub was attached at
11:41. That connector's UCSI interface is unhealthy from startup, independent
of what is plugged into it.

Steps To Reproduce

1. Boot the laptop with charger and USB-C hub attached. (Note it is working at this point)
2. Close the lid to enter clamshell mode.
3. Open the lid
4. Disconnect the USB-C hub then the charger
5. Plug in the charger and reattach the USB-C hub with DisplayPort alt mode and an external monitor (I'm using the HDMI port in this case)
6. USB devices on the hub enumerate normally; the monitor stays dark.
7. dmesg shows con3: failed to register partner alt modes (-5).
8. framework_tool --pdports shows DP Alt Mode: UFP_D Connected, HPD High for that port.6. /sys/class/drm/card0-DP-*/status all read disconnected.
   Things that do not recover it:

• Unplugging and replugging — fails identically each time.
• echo detect > /sys/class/drm/card0-DP-*/status (force DRM reprobe) — no change.
• Unbinding and rebinding ucsi_acpi
  (/sys/bus/platform/drivers/ucsi_acpi/{unbind,bind}) — reproduces
  GET_CABLE_PROPERTY failed (-5) immediately.

Only a full reboot recovers DisplayPort output, which is consistent with the
PD controller needing a power cycle.

Expected Behavior

When the PD controller has DisplayPort alt mode negotiated and HPD asserted, it
should report those alt modes successfully over UCSI so the kernel can bring up
the external display — rather than returning UCSI_ERROR_UNDEFINED for
GET_ALTERNATE_MODES and GET_CABLE_PROPERTY while its own PD stack shows the
link as up.

The use case for this is that I have my laptop docked and connected to an external monitor and peripherals and then need to leave with it to take a call in another room. When I come back and plug things back in, I cannot get the monitor to work unless I reboot.

Screenshots

N/A — all evidence is textual and included above.

Operating System

Omarchy 4.0.4 (Arch Linux)

Linux Kernel Version

Linux 7.2.5-3-omarchy #1 SMP PREEMPT_DYNAMIC Mon, 14 Sep 2026 19:55:01 +0000 x86_64

Additional Context

framework_tool version 0.6.5.

This looks closely related to
#265
("EC/PD sees the monitor (HPD high), kernel UCSI stack blind until full
reboot"), with the same end state reached on Core Ultra Series 3 hardware.

The same wedged behaviour has also been reported on non-Framework Panther
Lake hardware — omacom/omarchy#11864
is a Dell XPS 16 with the same Core Ultra X7 358H / Arc B390 / xe
combination, where DP alt mode stays wedged until reboot. That report shows a
different UCSI error signature (duplicate partner altmode SVID 0xff01, VDO
mismatch) rather than UNDEFINED, so it may be the same root cause reached by
a different path, or an adjacent platform-level problem. I have commented on
that issue with this data as well.

Happy to collect further traces (drm.debug=0x1e, ucsi dyndbg, or a
framework_tool dump) if that would help narrow it down.

I have included a reference to an Omarchy issue here where other users are experiencing similar issues on Dell Panther lake hardware: omacom/omarchy#11864

[ciryon]

Same failure on an AMD mainboard, so this is not Intel-specific.

Framework Laptop 13 (AMD Ryzen AI 300 Series), BIOS 03.05 (PD1/PD2 v0.21, UCSI 2.0), kernel 7.2.5-3-omarchy.

One difference worth noting: when the symptom appeared, no hub was attached at all — the machine had been undocked the previous day and moved to another location. The residue was created by the undock and survived s2idle, rather than by a redock.

Sep 24 17:12:06 whole dock tree drops at once (bus 7 + bus 8, r8152 NIC, hubs)
Sep 24 17:12:06 ucsi_acpi USBC000:00: unknown error 256
Sep 24 17:12:21 PM: suspend entry (s2idle) <- 15 s after the unplug
Sep 25 08:14:55 PM: suspend exit, other location, no dock
Sep 25 08:58:14 ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-95)
Sep 25 09:04:19 reboot, fixed

Single boot throughout: Wed 08:18 to Fri 09:04, roughly ten s2idle cycles. That also fits the uptime-plus-s2idle trigger in #265, so the undock may be one path in rather than the cause.

Every DRM connector read disconnected with 0 bytes of EDID and no DP hotplug reached the kernel after resume. USB data still worked, but the hub enumerated only as a high-speed USB2.1 Hub with nothing SuperSpeed behind it — so no PD contract and no DP alt mode, not merely a UCSI reporting failure. Replugging both ends and using a rear USB4 slot changed nothing; only a reboot recovered.

Two small notes for anyone triaging:

• I get UCSI_GET_PDOS failed (-95) (-EOPNOTSUPP), where Laptop 12 (13th Gen Intel): DP alt mode wedged after long uptime with s2idle cycles — EC/PD sees the monitor (HPD high), kernel UCSI stack blind until full reboot #265 and [Laptop 13] #267 report -5. It had zero occurrences in that boot until the failure, so it looks like a usable marker. unknown error 256 is not — it is logged on healthy boots too.
• /sys/class/typec/port0-partner/number_of_alternate_modes reads 0 both while broken and after the reboot with the display working, so it is useless as a diagnostic here.

[davidkhanks]

Correction and new data.

I need to retract the main claim in my original report. I pointed at
conN: failed to register partner alt modes (-5) as the cause. It isn't.
I captured a baseline while the display was working normally and those errors
are present there too, on every boot, healthy or not — along with
GET_CABLE_PROPERTY failed (-5) and unknown error 256. No partner alt modes
are ever registered on this machine, working or broken. Sorry for the noise.

I reproduced the failure deliberately and took nine snapshots across two boots,
including one after each recovery attempt. Here is what actually correlates.

The only field that tracks the fault

state	card0-DP-1/status	--pdports port 3 VCONN
working	connected	Off
working, lid open	connected	Off
wedged	disconnected	On
after connector reset (con3)	disconnected	On
after connector reset (con4)	disconnected	On
after hard connector reset	disconnected	On
after --pd-reset 1	disconnected	On
after suspend/resume	disconnected	On
working, after reboot	connected	Off

VCONN is asserted on the hub's port in the failed state and in no healthy
state, and it survives every reset short of a reboot.

The EC and the kernel disagree

In the wedged state framework_tool --pdports reports port 3 as:

PD Contract:   Yes
Data Role:     Dfp
Negotiated:    5.000 V, 3000 mA, 15.0 W
DP Alt Mode:   UFP_D Connected, HPD High (0x82)

That is byte-identical to the working capture. The EC believes DP alt mode
is entered and HPD is high, while every DRM connector reads disconnected and
no video reaches the monitor. USB, audio and the webcam behind the same hub
keep working throughout.

The Type-C sysfs layer agrees with the EC and is equally useless as a signal:
all four ports report svid=ff01 active=yes in both states, including port 0,
which has nothing plugged into it.

Two dmesg lines appear only when wedged:

ucsi_acpi USBC000:00: GET_PDOS failed (-70)                        (-ECOMM)
ucsi_acpi USBC000:00: con4: failed to register partner alt modes (-5)

con4 is port 3 — the hub. (con3 is port 2, the charger, and its identical
error fires in every state.) -ECOMM on GET_PDOS suggests the PPM stops
answering for that connector once it is in this state.

Recovery attempts, all unsuccessful

	attempt	result
1	UCSI_CONNECTOR_RESET con3 (0x30003)	accepted, no change
2	UCSI_CONNECTOR_RESET con4 (0x40003)	accepted, no change
3	hard connector reset (0x840003)	accepted, no change
4	UCSI_PPM_RESET (0x01)	rejected — Operation not supported
5	framework_tool --pd-reset 1	controller reset, no change
6	forced DRM reprobe	no change
7	suspend/resume (s2idle)	no change
8	reboot	recovers

Worth noting that UCSI_PPM_RESET is refused outright — the driver issues one
at probe, so something about the ACPI PPM path appears not to accept it at
runtime here.

A warm reboot is sufficient — no power removal required. Both recovery
reboots were plain systemd-reboot cycles with no power-off, and the display
was healthy on the very next boot (I have one 2.5-minute boot in between that
came up working). So whatever holds the bad state is cleared by normal
firmware re-init rather than needing power to be pulled.

Where I think the state is stuck (hypothesis, not a finding)

Every reset I could reach targets the PD/Type-C layer, and the captures show
that layer reporting correct values throughout — PD contract up, DP alt mode
entered, HPD high. Meanwhile UCSI_CONNECTOR_RESET, which should force a full
re-negotiation from attach, is accepted and changes nothing, and the EC's own
--pd-reset changes nothing either.

The main thing a warm reboot does that neither of those does is re-initialise
the Intel retimers through BIOS. That would put the sticky state downstream
of the PD controller — in the retimer or the display mux — which would also
explain why the PD layer looks perfectly healthy while no lanes carry video.

I want to be clear this is inference from what didn't work, not something I
can observe directly. If there's a way to re-init or read back retimer state at
runtime, I'd be glad to test it.

What I can test next

It now reproduces on demand, so I can run specific tests against a live
failure. Things I'd be happy to try if they'd help:

• any EC or framework_tool command that touches the retimer or DP mux
• a debug BIOS or EC build
• a patched kernel / xe or ucsi_acpi debug parameters
• specific register reads while wedged, before I reboot

Tell me what would be most useful and I'll capture it.

Reproducer

Unplug the hub and the charger, wait ~2 minutes, plug both back in. This has
produced the wedge every time so far.

System

• Framework Laptop 13 Pro, Core Ultra Series 3
• BIOS 03.02, Intel retimers Left/Right both 0xCF (207)
• PD controllers: Left → ports 2,3 · Right → ports 0,1 (CCG, silicon 0x3E81)
• Hub on port 3 (UCSI con4); 100W charger on port 2 (UCSI con3)
• Arc B390 / xe, kernel 7.2.5

I have the nine raw captures and can attach any of them, or add anything else
that would help — happy to run a specific test against the next failure, since
it now reproduces on demand.

One possibly relevant data point: a Dell XPS 16 with the same Core Ultra X7
358H / Arc B390 / xe combination shows the same end state (video dead over a
hub until reboot, USB fine) with a different UCSI signature
(duplicate partner altmode) — omacom/omarchy#11864. Together with the AMD
board reported on this thread, that argues the common factor isn't the PD
controller or the SoC.

[davidkhanks]

Follow-up with instrumented data — and a correction to my previous comment.

I reproduced this on demand and instrumented it properly. Two things to
correct, then the useful part.

Correction 1: the VCONN correlation is withdrawn

My previous comment gave a table showing port 3 VCONN tracking the fault
across nine captures. That was confounded and I no longer believe it. Every
working sample came from a cold boot (BIOS negotiates the port) and every
broken one from an unplug/replug (runtime renegotiation), so VCONN was marking
which path did the last negotiation, not whether the link worked. Two direct
counterexamples since: VCONN: On with a working display after hibernate
resume, and VCONN: Off with a broken one after a driver rebind.

Correction 2: partner alt modes (from my original report) also withdrawn

Already noted last time, restated for completeness: those errors appear in the
working state too.

There is no PD-layer signature. That is itself worth knowing — it says not
to look there.

The actual finding: every DP layer trains successfully, and there is no image

Captured with drm.debug=0x106 during a DPMS cycle against a live wedge:

[LTTPR 1] Clock recovery OK
[LTTPR 1] Channel EQ done. DP Training successful
[LTTPR 1] Link Training passed at link rate = 540000, lane count = 2
[DPRX]    Clock recovery OK
[DPRX]    Channel EQ done. DP Training successful
[DPRX]    Link Training passed at link rate = 540000, lane count = 2

DPRX is the monitor. It received training patterns over the main lanes and
reported success back over AUX. State while wedged:

layer	state
PD / Type-C	PD Contract: Yes, DP Alt Mode: UFP_D Connected, HPD High (0x82)
AUX / SBU	working — full DPCD reads, SINK_COUNT 0x41, EDID 256 bytes
LTTPR (retimer)	detected, OUI 98-4f-ee dev-ID GBR HW-rev 10.0 SW-rev 3.3, trains OK
main lanes	carry training patterns; monitor locks on
link	HBR2 x 2 lanes, required 1032000 / available 1080000
DRM	connected, DPMS On, native 3440x1440@50 set
monitor	blank

Nothing in the DP protocol stack fails. The link is up and the sink
acknowledges it. What is missing is the video stream itself.

Bandwidth is not the explanation. The native mode runs at 96% of available
link bandwidth, so I tested at 32% — 1920x1080@60 with the rate forced to
HBR3 x 2 lanes (required 519000 available 1620000). Training passes at the
higher rate and the monitor is still blank. The stream is not marginal; it is
absent.

Hibernate does not fix it, and a warm reboot does

This is the part I would most like someone's opinion on.

systemctl hibernate performs a genuine S4 here — Waking up from system sleep state S4, usb usbN: root hub lost power or was reset, boot_id preserved.
The platform fully powers down and firmware POSTs on the way back. It does
not clear the wedge. A warm reboot always does.

Since firmware re-initialises in both cases, firmware or retimer init cannot be
what fixes it. The main thing a reboot does that an S4 resume does not is start
every driver fresh rather than restoring saved state from the hibernation
image. That points at stuck kernel driver state — plausibly the xe display
engine — rather than at the cable, mux, PD controller or retimer.

Full recovery ladder, all tested against live failures

attempt	result
UCSI_CONNECTOR_RESET con3 / con4 / hard	no change
UCSI_PPM_RESET	rejected, Operation not supported
framework_tool --pd-reset 1	no change
ucsi_acpi unbind/rebind	no change
i915_dp_force_link_retrain	no change
force connector on (echo on > .../status)	AUX recovers, EDID returns — still no image
forced low link rate (RBR)	no change
1920x1080@60 forced to HBR3 x 2 (32% bandwidth)	no change
suspend/resume (s2idle)	no change
hibernate (real S4 power-off)	no change
warm reboot	works

One incidental result: unbinding ucsi_acpi entirely, leaving zero typec ports
registered, does not disturb a working display. The DP link is held up
independently of the kernel's UCSI representation.

Reproducer

Unplug the hub and the charger, wait ~2 minutes, plug both back in. Reproduces
every time here.

System

• Framework Laptop 13 Pro, Core Ultra Series 3, BIOS 03.02
• Arc B390 / xe, kernel 7.2.5
• Intel retimers Left/Right both 0xCF (207)
• PD controllers: Left → ports 2,3 · Right → ports 0,1 (CCG, silicon 0x3E81)
• Hub on port 3 (UCSI con4); 100 W charger on port 2 (UCSI con3)

What I can test next

It reproduces on demand and I can instrument it further. Happy to try anything
specific — a debug BIOS/EC build, a patched kernel, xe unbind/rebind with the
session stopped, or register dumps of the display pipe/transcoder while wedged.
Tell me what would be most useful.

[davidkhanks]

Resolved — this is not a Framework hardware issue. Closing, with details for
anyone who lands here with the same symptoms.

Root cause

An aquamarine regression, not the laptop, the hub, the PD controller or the
cable.

• 0.15.0 regression: CRTC of a removed connector is never disabled in the kernel; re-plugged outputs then fail every modeset with EINVAL and stay at 0x0 hyprwm/aquamarine#386 — "0.15.0 regression: CRTC of a removed connector
  is never disabled in the kernel; re-plugged outputs then fail every modeset
  with EINVAL and stay at 0x0"
• Introduced by commit 9d6fed9, which added a guard rejecting commits on
  connectors already marked disconnected. The compositor's disable commit
  therefore never reaches the kernel, and the CRTC is orphaned.
• Fixed by drm: release output on disconnect manually hyprwm/aquamarine#410 ("drm: release output on disconnect
  manually"), merged 15 Sept, released in aquamarine v0.15.1 on 17 Sept.

Corrections to my earlier reports in this thread

Both of my previous diagnoses were wrong and should be disregarded:

1. conN: failed to register partner alt modes (-5) is not the cause. A
   baseline captured while the display was working shows those errors present
   on every boot, healthy or not.
2. The port 3 VCONN correlation I posted is withdrawn. It was confounded:
   every working sample came from a cold boot (BIOS negotiates the port) and
   every broken one from a replug (runtime renegotiation). Counterexamples in
   both directions have since turned up.

There is no PD-layer signature at all. The PD/Type-C stack is byte-identical
between working and broken states, which is why this looked like a hardware
problem for so long.

How to recognise it

While wedged, with drm.debug=0x106, every DisplayPort layer trains
successfully and no image appears:

[LTTPR 1] Link Training passed at link rate = 540000, lane count = 2
[DPRX]    Link Training passed at link rate = 540000, lane count = 2

AUX works, EDID reads, the retimer trains, the monitor locks on. The tell is a
stale CRTC: the connector reads enabled=enabled, dpms=On while
status=disconnected and the compositor has already dropped it. Nothing in
userspace can release it.

Why nothing "fixes" it

Everything below was tested against live failures and failed, because all of it
operates above the orphaned CRTC:

UCSI connector reset (incl. the hub's own connector and a hard reset),
UCSI_PPM_RESET (rejected outright), framework_tool --pd-reset, ucsi_acpi
unbind/rebind, forced DP link retrain, forcing the connector on, forcing a low
link rate, suspend/resume, and a full S4 hibernate — which genuinely powers
the platform off and still does not help, because it restores the same stale
userspace DRM state. Only a warm reboot works, because it rebuilds it.

Workarounds if you are stuck on aquamarine 0.15.0

Both prevent the fault entirely by releasing the output before the hardware
disappears, so the disable commit happens while the connector is still
CONNECTED and the guard does not block it:

• VT switch — Ctrl+Alt+F2, unplug, Ctrl+Alt+F1. Needs no tooling; fbcon
  disables the orphaned CRTC.
• Disable the output first — e.g. under Hyprland,
  hyprctl eval 'hl.monitor({ output = "DP-1", disabled = true })', then
  unplug. Re-enable after replugging.

Neither recovers an already-wedged session; they only prevent it.

If you are on Omarchy specifically

Omarchy pins a tested package snapshot via stable-mirror.omarchy.org, so
aquamarine 0.15.1 may not be available to you yet even though Arch extra
has shipped it. Check with pacman -Q aquamarine; 0.15.0 is affected, 0.15.1
contains the fix.

Affected environment (for matching)

• Framework Laptop 13 Pro, Core Ultra Series 3, BIOS 03.02
• Arc B390 / xe, kernel 7.2.5
• aquamarine 0.15.0-2, hyprland 0.56.2-2, hyprtoolkit 0.5.4-5
• External display on a USB-C hub; USB, audio and webcam keep working, video does not

The AMD-board report earlier in this thread is consistent with this being a
compositor regression rather than anything platform-specific.

Thanks to everyone who looked at this. Apologies for the two incorrect
hardware diagnoses along the way.