In this communication, the customer didn’t simply report that “EDID isn’t working.” Instead, they provided a highly complex, cross-platform real-world scenario:
Apple Silicon MacBook Pro (macOS, clamshell mode) + Ubuntu Linux + NVIDIA GPU + Thunderbolt Dock + DP → KVM multi-layer signal chain.
The customer’s initial confusion was:
EDID emulation was enabled, yet when switching back to the MacBook, the system still forced a login; inserting a dummy HDMI resolved the issue.
During multiple rounds of troubleshooting, the customer did not stop at asking “Is this a problem with your product?” Instead, through repeated testing of different connection methods, clamshell/open-lid states, and direct versus docked setups, they gradually derived a key conclusion:
-
The issue was not due to EDID data loss
-
Rather, it was macOS’s clamshell-mode security behavior triggered by display hot-plug detection (HPD changes)
Ultimately, the customer proactively proposed and verified an important insight:
In clamshell mode, even with EDID emulation, if the system detects a display link rebuild, macOS will lock the screen according to its security policy.
This process, in turn, drove our own growth:
-
We moved from focusing on a single-point question of “Does EDID work?”
-
To a systematic understanding of the boundaries between EDID and HPD behavior, and the macOS security model
-
We further realized that our current product documentation leaves a knowledge gap regarding “EDID ≠ DDM” and “HPD not persistently maintained,” which could mislead advanced users
This is a classic case of co-creation:
It wasn’t just that the customer’s problem was “solved,” but that we were compelled to clarify and fully understand a previously fuzzy area.
