Control: tags -1 + moreinfo Hi,
On Sat, Jul 11, 2026 at 11:56:09PM +0100, Wenceslao Grillo wrote: > Package: src:linux > Version: 6.12.95-1 > Severity: normal > X-Debbugs-Cc: [email protected] > > > Summary: > DisplayPort Alt Mode over USB-C fails to negotiate reliably with an external > portable USB-C monitor on an HP Spectre x360 13-aw0xxx. The exact same > hardware (laptop, cable, monitor, USB-C port) worked without any special > configuration under Debian 12. After upgrading to Debian 13 (kernel > 6.12.95+deb13-amd64), the same setup intermittently fails, and the failure > mode is inconsistent across attempts. > > Hardware: > - Laptop: HP Spectre x360 Convertible 13-aw0xxx > - USB-C controller: ucsi_acpi (confirmed via > /sys/class/typec/port0/device/driver) > - External monitor: portable USB-C monitor (Brand: iProda Model: PD152KPNM) > - Same cable and same physical USB-C port used throughout testing > > Software: > - Debian 13 (Trixie) > - Kernel: 6.12.95+deb13-amd64 > - Working previously on Debian 12 (kernel version unknown/not recorded at the > time) > > Observed behaviour: > 1. Connecting the monitor via a direct USB-C to USB-C cable, with the laptop > plugged into its own charger, results in "No signal" on the monitor, which > then goes to sleep. > > 2. /sys/class/typec/port0-partner/port0-partner.0/svid reports "000a" in > this state, rather than "ff01" (the standard DisplayPort Alt Mode SVID). > /sys/class/typec/port0/power_role shows the laptop's port as [source]. > > 3. Attempting to manually force a power role swap fails: > # echo sink | sudo tee /sys/class/typec/port0/power_role > tee: /sys/class/typec/port0/power_role: Invalid argument > > 4. Using a USB-C to HDMI adapter instead of a direct USB-C-to-USB-C cable, > with the monitor powered externally (not from the laptop), reliably > produces a working video signal. > > 5. Using a direct USB-C-to-USB-C cable while powering the monitor from a > separate charger (making the monitor the power source and the laptop the > sink, confirmed via power_role showing "source [sink]") intermittently > works and intermittently does not, with no reliably reproducible trigger > found. In one state where the laptop was the sink, video was NOT working, > and /sys/class/typec/port0-partner/number_of_alternate_modes reported 0. > > 6. A working configuration was eventually found: laptop connected to its own > charger, PLUS a direct USB-C-to-USB-C cable to the monitor for video, > PLUS an additional USB-B-to-USB-C cable from the laptop to a secondary > port on the monitor. In this three-cable configuration, video works > reliably, and disconnecting the USB-B cable immediately causes the video > to stop. Note that even in this working state, > /sys/class/typec/port0-partner/port0-partner.0/svid still reports "000a", > not "ff01" -- suggesting this sysfs value may not reliably reflect > whether DisplayPort Alt Mode video is actually active for this hardware. > > 7. No relevant firmware updates are available (checked via fwupdmgr; > only Secure Boot dbx/UEFI revocation list updates were offered, no > System Firmware/EC update). > > 8. lsusb shows no separate enumeration for the monitor as a USB device > (consistent with a true DisplayPort Alt Mode device rather than a > DisplayLink-type monitor). > > Expected behaviour: > The monitor should negotiate DisplayPort Alt Mode and display video > consistently via a single USB-C cable, as it did under Debian 12 on the > same hardware, without requiring a secondary USB-B data cable or specific > power-source arrangement. > > Additional notes: > - Unrelated ACPI firmware errors are also present in dmesg > (AE_AML_BUFFER_LIMIT errors aborting \_SB.WMID.WQBE and \HWMC methods, > and hp_bioscfg reporting error 0x300a). These may or may not be related > to the USB-C PD/Alt-Mode negotiation issue, since some HP laptops route > USB-C role/mode logic partly through WMI-based EC calls, but this has not > been confirmed. > > Please let me know what additional debugging output (e.g. dynamic debug > logs from the ucsi/typec modules during a fresh connection) would be useful. Assuming it works under Debian 13 but with the 6.1.177-1 kernel from Debian bookworm, and given you have a reliable way to determine the issue exists, could you please bisect the problem so we can get an idea on the commit which is causing the problem? I agree it is a wide range of kernel versions, so you might want to first narrow down closer the upstream version which introduces the behaviour change and bug, and then bisect the closer upstream versions. If that is not feasible then start directly with testing 6.12 and 6.1. Can you report back? Regards, Salvatore
