Monitor Randomly Disconnects

[oyasuna]

This is related to this thread, but I thought the tone of the message was inappropriate, so I've opened this thread.

We, the user base, definitely need a fix, but we need to be respectful of the engineers who have spend countless hours developing this wonderful software and hardware. Poor tone or unjustified claims of fault will not solve this problem.

I too experience the same issue.

Background:

I have a 2021 16" MacBook Pro. I have two monitors attached via a Plugable Docking Station. Oddly enough, only one of the monitors (2nd) is listed in the DisplayLink Manager tool window (VX3267U-4K).

On 5-22-25 at 12:13pm, I upgraded from macOS 14.7.2 to 15.5 (and am certain this is the exact time because I checked with $system_profiler SPInstallHistoryDataType | grep -A 4 "macOS"$. At the time, I was on DisplayLink Manager Graphics Connectivity 1.12.2.

Since then, I have uninstalled via Homebrew and installed version 1.12.4 from the DisplayLink website.

What I've tried:

1. Restarted my computer.
2. Uninstalled DisplayLink via the tool and reinstalled it.
3. Completely wiped and reinstalled macOS.

The issue persists.

I decided to observe the issue to attempt to find a pattern.

Observation:

1. ~20:26:45 - My 2nd monitor disconnected.
2. ~20:27:10 - I enabled my 2nd monitor.
3. ~20:33:25 - My 2nd monitor randomly disconnected.
4. ~20:34:07 - I enabled my 2nd monitor.
5. ~20:38:58 - My 2nd monitor disconnected.
6. ~20:39:15 - I enabled my 2nd monitor. I then stepped away from my computer.
7. ~21:05:50 - I returned to my computer. At some point, my 2nd monitor disconnected.
8. ~21:06:20 - I enabled my 2nd monitor.
9. ~21:10:36 - My 2nd monitor disconnected.
10. ~21:11:00 - I enabled my 2nd monitor.
11. ~21:11:12 - My 2nd monitor disconnected.
12. ~21:11:33 - I enabled my 2nd monitor.
13. ~21:18:53 - My 2nd monitor disconnected.
14. ~21:19:09 - I enabled my 2nd monitor.
15. ~21:25:13 - My 2nd monitor disconnected. Taking a break.
16. ~21:52:42 - I enabled my 2nd monitor.
17. ~21:54:30 - My 2nd monitor disconnected.
18. ~21:54:45 - I enabled my 2nd monitor.
19. ~21:55:15 - I watched a funny video on YouTube.
20. ~22:00:52 - My 2nd monitor disconnected.
21. ~22:04:02 - I enabled my 2nd monitor.
22. ~22:07:05 - My 2nd monitor disconnected.

During this observation, I also monitored the two DisplayLink processes' CPU and memory usage. I did this via $htop -p $(pgrep -d, -f "DisplayLink")$. When my 2nd monitor is connected, $DisplayLinkUserAgent$ uses ~152MB of memory and fluctuates between 0% and 5% CPU usage, and $DisplayLinkXpcService$ uses ~6400K of memory and stays around 0% CPU usage. When my 2nd monitor is disconnected, $DisplayLinkUserAgent$ uses ~151MB of memory and fluctuates between 0% and 1% CPU usage, and $DisplayLinkXpcService$ uses ~6400K of memory and stays around 0% CPU usage.

I also monitored $DisplayLinkUserAgent$'s file system activity. I did this via $sudo fs_usage -f pathname <pid>$. For the most part, it just accesses its log file stored in $/Users/<username>/Library/Group Containers/73YQY62QM3.com.displaylink.DisplayLinkShared/Library/Application Support/Logs/DisplayLink Manager.log$. It will access other things if you interact with the DisplayLink Manager tool window. Unfortunately, the log file isn't useful for users. Each log message is encrypted then base64 encoded. Not sure why this is necessary...? If someone knows, please let me know.

I also monitored the DisplayLink processes' network usage. I did this via $sudo lsof -i -r 1 | grep "DisplayLink"$. There was no network activity at all during this observation. (After the observation, I checked if DisplayLink Manager sends any network requests if I quit and restart it. It did not. Props to the developers for designing this to work completely offline.)

Random Notes:

1. I noticed that the CPU usage percent of DisplayLinkUserAgent spikes when you click on a window in a different monitor than the focused window, or drag a window to a different monitor. The developers could probably optimize behavior this by prefetching information based on the location of the mouse cursor.
2. Note to DisplayLink developers: I found your AES encryption/decryption function at 0x1000b0f5c and your AES key derivation function at 0x1003467d8. As far as I can tell, you derive the key from hardcoded constants, a seed, and a hash computation. You use a fixed seed in multiple places, which is definitely unsafe. I decided to stop here, but I doubt it'd be hard to decipher your key derivation algorithm and compute the key. To fix this, you should add some randomness and maybe add a derivation based on some unique system value.

Extra:

Output of $system_profiler SPDisplaysDataType$ (when all monitors are connected):

Graphics/Displays:

    Apple M1 Pro:

      Chipset Model: Apple M1 Pro
      Type: GPU
      Bus: Built-In
      Total Number of Cores: 16
      Vendor: Apple (0x106b)
      Metal Support: Metal 3
      Displays:
        LG HDR 4K:
          Resolution: 3840 x 2160 (2160p/4K UHD 1 - Ultra High Definition)
          UI Looks like: 3840 x 2160 @ 60.00Hz
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Rotation: Supported
        Color LCD:
          Display Type: Built-in Liquid Retina XDR Display
          Resolution: 3456 x 2234 Retina
          Mirror: Off
          Online: Yes
          Automatically Adjust Brightness: No
          Connection Type: Internal
        VX3267U-4K:
          Resolution: 3840 x 2160 (2160p/4K UHD 1 - Ultra High Definition)
          UI Looks like: 3840 x 2160 @ 60.00Hz
          Mirror: Off
          Online: Yes
          Rotation: Supported

I noticed that the $DisplayLinkUserAgent$ binary contains both x86_64 and arm64 builds ($lipo -detailed_info /Applications/DisplayLink\ Manager.app/Contents/MacOS/DisplayLinkUserAgent$). Props to the developers for spending the time to do this.

Conclusion:

Based on the things I attempted to fix this, the observation, and this thread, I think the issue is macOS. At some point, a macOS update caused the issue.

Bottom line: Regardless of the source of the issue, it is a problem that needs to be fixed. We cannot expect Apple to fix it. Until a fix is applied from the DisplayLink developers, the products we've paid for are rendered useless.