*Update: tested with bookworm's 6.1.0-50-amd64 kernel on Debian 13*
I installed |linux-image-6.1.0-50-amd64| from bookworm alongside the
Trixie system and booted into it via GRUB (|uname -r| confirms
|6.1.0-50-amd64|).
Result: the external monitor works correctly with a single direct
USB-C-to-USB-C cable, with the laptop on its own charger — i.e. it
reproduces the Debian 12 behavior, not the Debian 13 (6.12) regression.
No secondary USB-B cable is needed.
Note: on this kernel, |/sys/class/typec/| is empty even though
|ucsi_acpi|, |typec_ucsi|, and |typec| are all loaded (confirmed via
|lsmod|). So I can't provide the
svid/power_role/number_of_alternate_modes comparison here.
dmesg shows:
|[ 6.478666] ucsi_acpi USBC000:00: PPM init failed (-110)|
This may or may not be related to the ACPI/WMI method failures I noted
in the original report (|AE_AML_BUFFER_LIMIT| errors on |\_SB.WMID.WQBE|
and |\HWMC|, and |hp_bioscfg| error |0x300a|) .
With the kernel 6.12.96+deb13-amd64 I get this:
dmesg | grep -i -E "ucsi|typec"
[ 1.330833] typecport0: bound usb3-port2 (ops connector_ops [usbcore])
[ 1.330859] typecport0: bound usb2-port1 (ops connector_ops [usbcore])
[ 1.916979] typecport1: bound usb3-port3 (ops connector_ops [usbcore])
[ 1.917021] typecport1: bound usb2-port2 (ops connector_ops [usbcore])
And the monitor is back to not working without an additional USB cable
for power. (Although, when I first rebooted with the 6.12, it worked,
until I disconnected it and connected it back again, so it seems the
problem is right at the negotiation stage, and once that's been done the
monitor is happy to go on working).
I couldn't find any kernels between 6.1 and 6.12 in apt. Claude AI
suggests using an Ubuntu repository. To me that sounds odd at least, but
I'm way out of my depth here. If you send me more instructions, I'll be
happy to help.
On 29/07/2026 16:42, Salvatore Bonaccorso wrote:
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
