[fairydust] M2 Air: DP Alt Mode link repeatedly bounces with VIA Labs hub adapter (PS186); stable with UGREEN CM478

[Hegghammer]

fairydust: DP Alt Mode link repeatedly bounces with VIA Labs hub adapter (PS186); stable with simple adapter — M2 MacBook Air

Hardware / software

• Machine: Apple MacBook Air (13-inch, M2, 2022) — apple,j413 / t8112
• Distro: Fedora Asahi Remix 42, i3 on X11
• Kernel: fairydust branch, self-built, uname -r = 7.1.6+ (CONFIG_DRM_ASAHI=m, CONFIG_TYPEC_DP_ALTMODE=m, 16K pages)
• Monitor: Philips 27E2N1500L, 2560x1440@60, connected via HDMI
• Failing adapter: USB-C multiport hub — VIA Labs VL817-family (USB2 hub 2109:2817, USB3 hub 2109:0817, billboard 2109:0103); DCP matches AppleDCPPS186 (Parade DP→HDMI)
• Working adapter: Ugreen CM478

Summary

With the VIA Labs hub adapter, the DP link trains successfully — HPD asserts, full 256-byte EDID is read, 28 modes enumerated — but then drops within seconds and re-trains in a continuous bounce cycle. A modeset attempted during a bounce leaves X half-configured (virtual screen resized, output never activated). With a simple single-purpose USB-C→HDMI adapter on the same port, cable, and monitor, the link is stable and external output works at 2560x1440@60.

Behaviour with the failing adapter

Repeating cycle, observed at multiple uptimes (708s, 760s, 1553s...):

1. dcp_dptx_connect(port=0) → powering nub → DCPDP13Service/DCPDPService version 14 → AppleDCPDP2HDMI matched → AppleDCPPS186 matched
2. HPD asserted, cb_hotplug() connected:1, nr_modes:28, EDID readable from sysfs (256 bytes)
3. Within ~2–60 s: HPD removed → cb_hotplug() connected:0 → dcp_dptx_disconnect(port=0)
4. Loop.

Each cycle also logs:

apple-dcp 271c00000.dcp: AFK[ep:28]: too many enabled services!
apple-dcp 271c00000.dcp: AFK[ep:28]: too many enabled services!
apple-dcp 271c00000.dcp: AFK[ep:28]: expected announce but got 0xc0 on channel <n>
apple-dcp 271c00000.dcp: DPTXPort: acking unhandled call 20
apple-dcp 271c00000.dcp: DPTXPort: acking unhandled call 21
apple-dcp 271c00000.dcp: set_drive_settings: 2:0:1089342832:-1:0:0:0

The too many enabled services! pair repeats on every reconnect, which may be an endpoint/service leak across bounce cycles.

Example excerpt of one bounce (modeset issued at ~1552, link dropped ~2 s later):

[ 1552.176526] apple-dcp 271c00000.dcp: cb_hotplug() connected:1, valid_mode:1
[ 1552.176539] apple-dcp 271c00000.dcp: dcp_hotplug() connected:1 valid_mode:0 nr_modes:28
[ 1553.998528] ... VideoInterfaceIOAV::unplug_gated(...): display HPD removed
[ 1553.999227] apple-dcp 271c00000.dcp: cb_hotplug() connected:0, valid_mode:0
[ 1554.011892] apple-dcp 271c00000.dcp: dcp_dptx_disconnect(port=0)
[ 1555.510421] apple-dcp 271c00000.dcp: dcp_dptx_connect(port=0)

Userspace side effect: xrandr --output DP-1 --mode 1920x1080 during a bounce shrank the X virtual screen to 1920x1080 (cropping the 2560x1600 eDP panel) while DP-1 was never activated (no * mode). Recoverable with xrandr --output eDP-1 --auto --pos 0x0.

Behaviour with the working adapter

Same port, cable, and monitor. Connect sequence completes identically, then the link stays up (no disconnects over 30+ s idle and through modesets). xrandr --output DP-1 --mode 2560x1440 --rate 60 works; external display fully functional.

Steps to reproduce

1. Boot fairydust kernel with typec_displayport loaded, VIA Labs adapter connected.
2. Observe dmesg -w: connect sequence completes (HPD asserted, EDID read, 28 modes), then HPD drops within seconds and the cycle repeats indefinitely.
3. Swap to the UGREEN CM478 on the same port, cable, and monitor: link stays up and xrandr --output DP-1 --mode 2560x1440 --rate 60 works.

Attached logs

• dp-dmesg.log — failing adapter (VIA Labs/PS186): full bounce cycle, including the repeated too many enabled services! / expected announce lines on each reconnect.
• dp-test.log — xrandr and connector status captured around a modeset attempted during a bounce, showing the half-applied result: X virtual screen resized to 1920x1080 (cropping the 2560x1600 eDP panel) while DP-1 was never activated.
• dp2-working-session.log — working adapter (UGREEN CM478): identical connect sequence, then a stable link through successful modesets at 1920x1080 and 2560x1440, no disconnects.

Notes

• Cold plug vs hot plug made no difference for the failing adapter; both bounce.
• The X cropping is recoverable with xrandr --output eDP-1 --auto --pos 0x0.
• Happy to provide full dmesg from boot, an EDID dump of the Philips panel, Type-C identity sysfs state, or to test patches on this hardware.

dp-dmesg.log

dp-test.log

dp2-working-session.log