Following up because I did buy the SQ5628134 and it does work great switching my AW3423DW and AW3420DW to my windows PC. However, when I switch to my M2 Max (USB-C DisplayPort) macbook only the AW3420DW gets picked up and there’s a flickering/latency with all inputs while it flaps. If I unplug the AW3423DW and replug it everything is detected correctly and works perfectly.
I ran a series of tests
2026-08-29 12:47:32.922: swapping KVM to C1
2026-08-29 12:47:37.969: swapping to C2 with both displays connected
2026-08-29 12:47:48.977: unplugging AW3423DW
2026-08-29 12:47:54.106: plugging in AW3423DW
2026-08-29 12:48:27.761: swapping KVM to C1
2026-08-29 12:48:32.806: swapping to C2 with AW3420DW disconnected
2026-08-29 12:48:53.822: plugging in AW3420DW
2026-08-29 12:49:11.407: swapping KVM to C1
2026-08-29 12:49:16.480: swapping to C2 with AW3423DW disconnected
2026-08-29 12:49:36.277: plugging in AW3423DW
with logs from
log stream --style compact --level debug --predicate 'subsystem CONTAINS[c] "display" OR subsystem CONTAINS[c] "graphics" OR subsystem CONTAINS[c] "iokit"'
captured during all swaps to C2 (macbook) and actions taken while C2 is active. I’m not display/DisplayPort expert, so the logs were evaluated by claude, who sees the following paths forward:
Fixes, in order of expected payoff
1. A DP/USB-C EDID emulator or HPD holder on the AW3423DW leg. If it holds HPD asserted through the switch, the mac never tears that link down and never re-trains it on the fast path. This is the targeted fix for a KVM with no EDID emulation, and it addresses the exact gap you named at the start.
2. AW3423DW firmware. Dell has shipped updates for this panel touching DP link and wake behavior. A receiver that's ready inside 65 ms doesn't have this bug. Check your current version against Dell's latest.
3. Level1Techs firmware / HPD timing. Ask them directly — you now have an unusually clean report: fast-path HPD (65 ms) fails 5/6, slow-path (2.09 s) succeeds 5/5, same cable, same port, same monitor, and Windows is unaffected. That is the kind of data that gets a firmware answer.
#1 “No more hanging wires…”
#2 Is a no go, I’m already running the latest firmware.
#3 I have no idea how accurate this is, but I have, and can generate, extensive logs of failures/recoveries that I can provide. (As a new user I cannot attach them here).
After re-running the tests without predicate filtering claude had these additional insights
Ladder question, answered without re-running it: powering the AW3423DW off and on at its own power button did not clear the fault (13:45:40 off, 13:45:53 on — 30 more interrupts after). It kept flapping through two further phases until the USB-C reseat at 13:46:48. My prediction held, and the practical consequence is that no sink-side HPD trick will work — that rules out the HPD-dongle fix I'd ranked second, and DDC power cycling with it.
The biggest new fact: HPD is never deasserted. All 112 interrupt events on the affected port logged HPD=1; only the DP IRQ_HPD bit pulses. The KVM isn't dropping or bouncing HPD during the failure — the sink is raising short-pulse interrupts about once a second, which in DisplayPort means "my link status changed, read my DPCD". Asymmetry is stark: 112 on the AW3423DW's port, 1 on the AW3420DW's.
That retires my "KVM mistimes HPD" hypothesis as stated, and it means the attribution question is now three-way rather than two-way. Section 6 of the report reflects that: the KVM owns the trigger (perfect correlation with switch-in, never on reseat, identical configuration either side), the monitor is the party actively signalling a problem, and macOS rebuilds the entire pipeline once a second more than twenty times while retrying the identical mode and never falling back. Windows being unaffected on the same hardware is in there as evidence bearing on the third.
Exact failing configuration, now pinned: 3440×1440 @ 174.96 Hz, YCbCr 4:2:2 10-bit, DSC off, HBR3 ×4, pixel clock 987.000 MHz, htot 3600, vtot 1567. And two things I'd previously left open are now positively excluded — bandwidth (20 bpp × 987 MHz = 19.74 Gbps against 25.92 available, 76%) and the mode itself, since clean bring-ups program that identical mode and settle on it.
Each cycle is a full pipeline rebuild, not a retrain: link shutdown, replug, modeset, DCP power cycle, M3 firmware reload, fresh HDCP session, audio restart, USB-C DP reconfiguration — once per second. That's why the user-visible effect is so violent.
Two things I chased and had to drop, both from my own errors: HDCP session churn is a consequence, not a trigger (sessions are created after each modeset), and my "USB-C reconfiguration never runs on the fast path" table was an artifact of a too-narrow time window — it does run, on every cycle.
The top ask of the manufacturer is now a bench measurement rather than a question about their timing: DPCD registers 0x202–0x204 at the moment the sink raises IRQ_HPD. That tells you whether clock recovery, symbol lock or inter-lane alignment is being lost, which is the one thing that would separate a signal-integrity problem in their switch path from a sink link-maintenance problem. It's unreadable from macOS and straightforward on a bench.
I have very little idea what this all means, but perhaps it’s useful to someone else. And for completeness, before any of this investigation, I did test with both monitors set to 60hz on the macbook.
From a connection topology viewpoint:
KVM <=> PC2 (Macbook)
UGREEN Unidirectional USB C to DisplayPort 1.4 Cable 8K@60Hz 4K@240Hz 6.6FT
KVM <=> PC1 (Windows/GPU)
UGREEN 8K@60Hz, 4K@240Hz VESA Certified DisplayPort 1.4 Cable, 6.6FT
KVM <=> Monitors
UGREEN 8K@60Hz, 4K@240Hz VESA Certified DisplayPort 1.4 Cable, 6.6FT
I did try all permutations of cables/ports for KVM => Monitors and PC2 <=> Macbook, as well as all three USB-C ports on the Macbook. Considering the issue is only on KVM switch, is resolved by replugging the AW3423DW, is not impacting the AW3420DW regardless of port/cable combination, and is not impacting PC1/Windows at all, I feel relatively confident it isn’t the cables or individual ports on either the KVM or Macbook.
And one final observation: when closing the Macbook lid the AW3423DW turns off for a moment before returning. The AW3420DW remains on the entire time.