Editing Openai/69676758-d944-8003-a3d4-835e33b4e372 (section)

=== Assistant: That depends on what you mean by “above” in the stack. ===
That depends on what you mean by “above” in the stack. DisplayPort itself sits relatively low. Conceptually, what comes above it is not another single protocol, but several layers of abstraction.

From lowest to highest:
# DisplayPort (you already know this layer)
* Physical signaling, link training, packet transport
* Carries pixel streams, audio samples, and control data
# Video timing / pixel formats
These define what the pixel stream represents, independent of the wire:
* Resolution (e.g., 2560×1440)
* Refresh rate (e.g., 144 Hz)
* Color format (RGB, YCbCr)
* Bit depth (8-bit, 10-bit, etc.) Examples: VESA timing standards like CVT / CVT-RB
# Display protocol usage modes
Logical uses of DisplayPort:
* Single Stream Transport (SST)
* Multi-Stream Transport (MST) These determine how many displays and streams are carried, but still no “content meaning”.
# GPU display engine / OS graphics subsystem
This is where “display content” starts to exist:
* Linux: DRM/KMS, Wayland/X11
* Windows: WDDM + Desktop Window Manager
* The OS compositor decides what pixels should appear on each display and hands framebuffers to the GPU
# Applications and rendering APIs
Applications generate the visuals:
* OpenGL, Vulkan, DirectX, Metal
* Game engines, video players, browsers They never “talk DisplayPort”; they render frames into buffers.

Important distinction
DisplayPort does not carry:
* Video codecs (H.264, AV1, etc.)
* Files, windows, or UI concepts
* Application data

By the time data reaches DisplayPort, it is already fully rendered pixels (plus audio).

In short
Above DisplayPort is:

: 

If you want, I can draw a strict layered diagram or compare this to how USB-C tunnels DisplayPort alongside PCIe and USB.