Support for DisplayLink solutions

[MrModest]

At my work, we started using Dell DisplayLink instead of direct Thunderbolt cables (so people with M1 can use 2 monitors as well).
But for me, with a M2 Pro, the RDM doesn't work properly any more since there are no HiDPI options any more when I connect the laptop via this DisplayLink :(

I'm asking without any hope, but would it be possible to find a workaround or make HiDPI work again?

I use 2 monitors with 2K resolution. When I connect then via Thunderbolt, I can see 1080p HiDPI option, but when I connect the same monitors via DisplayLink I can see only non-HiDPI options

[MrModest]

I did some digging with Claude Code Opus 4.6 myself, and no success. Here's what he's got so far if someone is interested. Below is Claude's generated report.

---

Deep Investigation: Why HiDPI Doesn't Work with DisplayLink on macOS Sequoia (and likely won't)

System tested:

• MacBook Pro M2 Pro,
• macOS Sequoia 15.7.4 (Build 24G517),
• two Dell U2722DE (2560x1440) monitors connected via Dell Universal Hybrid Video Dock (DisplayLink).

TL;DR

DisplayLink on macOS uses a user-space virtual display driver that captures screen content via the Screen Capture API and sends it over USB. This architecture fundamentally bypasses the GPU-backed framebuffer pipeline that makes HiDPI work on native (Thunderbolt/USB-C) connections. All approaches to force HiDPI — display override plists, virtual display creation with mirroring, private API manipulation — fail because the DisplayLink driver captures frames at the logical resolution (1x), not the backing store resolution (2x), regardless of what the mode descriptor claims.

---

How HiDPI works on native displays (Thunderbolt/USB-C)

For a 2560x1440 monitor connected via Thunderbolt:

1. macOS reads the monitor's EDID via the GPU driver
2. The GPU driver registers the display through IOKit (IODisplayConnect / IOFramebuffer)
3. macOS generates HiDPI modes (e.g., 1920x1080 HiDPI = 3840x2160 backing store, scaled to 2560x1440)
4. When a HiDPI mode is selected, macOS renders at 2x in GPU memory → GPU downscales to panel resolution → sends over DisplayPort/HDMI
5. Result: sharp text at the logical resolution

How DisplayLink works differently (macOS 10.15.6+)

Since Apple deprecated kernel extensions, DisplayLink uses:

1. A user-space agent (DisplayLinkUserAgent) that creates virtual framebuffers
2. The Screen Capture API (CGDisplayStream / ScreenCaptureKit) to capture rendered content
3. USB data packets to send compressed frames to the dock, which outputs to the monitor

Key differences:

• No IOKit display registration: CGDisplayIOServicePort() returns 0x0 for DisplayLink displays (confirmed)
• No GPU-backed framebuffer: The display is a software virtual display, not backed by the GPU
• No EDID passthrough to IOKit: macOS doesn't see the display in the IODisplay hierarchy (confirmed via ioreg -r -c IODisplayConnect returning nothing for external displays)
• The DisplayLink driver decides which modes to expose, and it only exposes density=1.0 (non-HiDPI) modes

What we confirmed via diagnostics

We built diagnostic tools using both private (CGSGetNumberOfDisplayModes, CGSGetDisplayModeDescriptionOfLength) and public (CGDisplayCopyAllDisplayModes) APIs.

Built-in Retina display: 132 modes, 72 HiDPI (density=2.0) — working perfectly.

Both Dell U2722DE via DisplayLink: 47 modes each, 0 HiDPI across ALL APIs:

• Private CGS API: 0 HiDPI
• Public API with kCGDisplayShowDuplicateLowResolutionModes: 0 HiDPI
• Public API with NULL options: 0 HiDPI

All 47 modes have density=1.0. The maximum resolution is 2560x1440@60Hz (mode index 32, flags 0x2000007).

The DisplayLink Manager app's "Additional HiDPI modes" toggle was enabled — no effect on the mode list.

Approach 1: Display Override Plist (FAILED)

Theory: macOS reads display override plists from /Library/Displays/Contents/Resources/Overrides/DisplayVendorID-XXXX/DisplayProductID-YYYY to add custom scaled resolutions. These plists use a scale-resolutions key with binary data entries containing resolution + HiDPI flags (kFlagHiDPI = 0x0000000100000000).

What we did:

• Identified the DisplayLink displays' vendor/product IDs: vendor 0x10ac (Dell), product 0x4233
• Created a proper override plist with HiDPI entries (1920x1080 HiDPI, 1280x720 HiDPI, etc.)
• Installed to /Library/Displays/Contents/Resources/Overrides/DisplayVendorID-10ac/DisplayProductID-4233
• Rebooted

Result: No change. Still 47 modes, 0 HiDPI.

Why it failed: The override plist mechanism works through IOKit's IODisplayConnect matching. Since DisplayLink displays have CGDisplayIOServicePort() == 0x0 and don't appear in the IOKit display hierarchy, the plist is never loaded. This was confirmed by Gemini/GPT analysis and verified experimentally.

Approach 2: Virtual Display with HiDPI + macOS Mirroring (PARTIALLY WORKED, BUT NO VISUAL IMPROVEMENT)

Theory: Create a virtual display using the private SLVirtualDisplay API (SkyLight framework) with HiDPI modes, then use macOS display mirroring to stream the HiDPI content to the DisplayLink display.

What we did:

We reverse-engineered the SkyLight framework's virtual display API by introspecting the Objective-C runtime:

SLVirtualDisplay (initWithConfiguration:error:, displayID, destroy, applySettings:error:)
SLVirtualDisplayConfiguration (initWithName:vendorID:productID:serialNumber:sizeInMillimeters:maximumSizeInPixels:chromaticities:error:)
SLVirtualDisplayMode (initWithSizeInPixels:sizeInPoints:refreshRate:error:)
SLVirtualDisplaySettings (initWithNativeMode:preferredMode:optionalModes:rotations:error:)

Critical discovery: Whether macOS generates HiDPI modes for a virtual display depends on the physical size parameter. A large physical size (610x356mm, matching the real monitor) produces 0 HiDPI modes. A small physical size (286x179mm, simulating a Retina-class DPI) produces 11+ HiDPI modes. The threshold is around ~200 DPI.

We successfully:

1. Created a virtual display with small physical size → 11 HiDPI modes generated including 1920x1080 HiDPI
2. Set the virtual display to 1920x1080 HiDPI mode → confirmed 3840x2160 backing store via screenshot (CGDisplayCreateImage returned a 3840x2160 image)
3. Configured mirroring: DisplayLink display mirrors the virtual display → mode descriptor on DL display shows density=2.0
4. Force-set the HiDPI mode on the DisplayLink display via CGSConfigureDisplayMode

Result: The mode descriptor says density=2.0 and the API reports the current mode as HiDPI. But fonts remain blurry — identical to non-HiDPI 1920x1080. System Settings labels these modes as "(low resolution)", not HiDPI/Retina.

Why it failed: The DisplayLink driver captures screen content at the logical resolution (1920x1080), not the backing store resolution (3840x2160). Even though macOS renders the virtual display at 3840x2160 (confirmed), the mirroring pipeline sends the logical-resolution content to the DisplayLink display. The density=2.0 flag in the mode descriptor is essentially cosmetic — the actual pixel data reaching the monitor is 1x.

Approach 3: Custom Capture Pipeline (IMPRACTICAL)

Theory: Bypass macOS mirroring entirely. Capture the virtual display's 3840x2160 content using CGDisplayStreamCreateWithDispatchQueue, then render it into a fullscreen window on the DisplayLink display via Core Animation.

What we did:

• Created a CGDisplayStream capturing the virtual display at 3840x2160
• Successfully received IOSurfaces at 3840x2160 (confirmed: the capture API DOES deliver full-resolution frames)
• Rendered captured frames into a fullscreen NSWindow on the DisplayLink display

Result: Technically captured at full resolution (~7.4 FPS), but fundamentally impractical:

• The user must move all windows to an invisible virtual display (no physical monitor) and interact with them there
• The fullscreen rendering window on the DL display conflicts with normal display operation
• The approach essentially requires building a complete display management system from scratch (input routing, cursor handling, window management)
• This is what BetterDisplay attempts to do, and even BetterDisplay couldn't make it work properly on this setup

Approach 4: DisplayLink Manager HiDPI Toggle (FAILED)

The DisplayLink Manager app has "Additional HiDPI modes" setting. It was enabled — no effect. The mode list remained at 47 non-HiDPI modes.

Approach 5: BetterDisplay (FAILED, per user report)

The user tried BetterDisplay's virtual display + mirror approach. It also did not produce actual HiDPI rendering on the DisplayLink displays.

Root Cause Analysis

The fundamental issue is architectural:

Native Thunderbolt:  App → macOS Renderer (2x) → GPU Framebuffer (3840x2160) → GPU Scaler → DisplayPort (2560x1440)
                     ↑ GPU handles everything in hardware, HiDPI just works

DisplayLink:         App → macOS Renderer (?) → Virtual Framebuffer → Screen Capture API (logical res) → USB → Monitor
                     ↑ DisplayLink captures at logical resolution, 2x rendering is discarded

For HiDPI to work with DisplayLink, the driver would need to:

1. Create its virtual framebuffer at 2x the logical resolution
2. Capture/receive the 3840x2160 backing store content
3. Downscale to 2560x1440 before sending over USB

This is a DisplayLink driver change, not something that can be fixed from the application side (RDM, BetterDisplay, or otherwise).

Summary of Private APIs Explored

API	Purpose	Result
CGSGetNumberOfDisplayModes / CGSGetDisplayModeDescriptionOfLength	Enumerate display modes	0 HiDPI for DisplayLink
CGDisplayCopyAllDisplayModes (with all option variants)	Public mode enumeration	Same result
SLVirtualDisplay / SLVirtualDisplayConfiguration / SLVirtualDisplayMode / SLVirtualDisplaySettings	Create virtual displays with HiDPI	Works, but mirroring doesn't preserve HiDPI quality
CGConfigureDisplayMirrorOfDisplay	System display mirroring	Mirroring succeeds but DisplayLink captures at 1x
CGSConfigureDisplayMode	Set display mode	Can set modes, but HiDPI flag is cosmetic for DisplayLink
SLSConfigureDisplayEnabled	Enable/disable displays	Works for removing orphaned virtual displays
CGDisplayStreamCreateWithDispatchQueue	Screen capture	Successfully captures at 3840x2160, but impractical for full pipeline
CGDisplayIOServicePort	Get IOKit service	Returns 0x0 for DisplayLink (no IOKit representation)

Tools Built During Investigation

All source code is in the repo as diag_modes.m, diag_full.m, diag_vdisplay.m, poc_virtual_hidpi.m, poc_virtual_v2.m, poc_v3.m, poc_verify.m, poc_stream.m, cleanup.m.

Conclusion

HiDPI on DisplayLink-connected monitors is a driver-level limitation that cannot be worked around from the application level on macOS Sequoia. The DisplayLink macOS driver would need to be updated to support 2x density framebuffers and capture the full backing store resolution. Until DisplayLink addresses this in their driver, no macOS tool (RDM, BetterDisplay, or otherwise) can provide true HiDPI rendering for DisplayLink-connected monitors.