Skip to content

Instantly share code, notes, and snippets.

@genedeng-ca

genedeng-ca/G95NC-macOS-HiDPI.md

Last active September 10, 2026 06:51
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save genedeng-ca/d5d3c27a8a0445f1e6d87b95d06b9219 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save genedeng-ca/d5d3c27a8a0445f1e6d87b95d06b9219 to your computer and use it in GitHub Desktop.
Download ZIP
Samsung Odyssey G95NC on macOS: unlocking 1920x1620 HiDPI via USB-C dock — the cable matters, not the HDMI port
Raw
G95NC-macOS-HiDPI.md

Samsung Odyssey G95NC on macOS: unlocking 1920×1620 HiDPI via USB-C dock — the cable matters, not the HDMI port

Short version for people who Google'd their way here at 2am: if your Mac shows the G95NC at 2560×2160 native 1:1 (tiny text) and the Scaled menu has no 1920×1620 option, it's not the dock and not the HDMI port — it's the cable. You need a USB-C → HDMI 2.1 active cable (not DP-to-HDMI, not a generic adapter). Both HDMI-1 and HDMI-2 on the monitor work once the cable is right. Scripts + full wiring below.

The problem

You bought a Samsung Odyssey G95NC 57" Dual UHD (7680×2160, 32:9). You dock your Mac (MacBook Pro M-series) through a Thunderbolt 4/5 hub. You run it in PBP 21:9 mode so the right half is 2560×2160.

Physical pixel density at that half is crazy-high (~111 PPI over 28"). Text is unreadable without HiDPI. The natural choice is macOS's "looks like 1920×1620" scaled mode (integer 2× scaling → crisp). But in System Settings → Displays → Scaled, the option is simply not there. You get 2560×2160 native, some anemic 1080p options, and nothing in between that fills the screen.

Searching gets you:

  • "Use BetterDisplay to force it" → works but a 3rd-party daemon
  • "Plug via DisplayPort" → fine if you have a spare DP off your dock, but most TB docks only offer HDMI
  • "It's an Apple HDMI limitation" → true but unhelpful
  • "You must use HDMI-1, not HDMI-2" → this is wrong. (See below.)

The root cause (concise)

Apple's display driver keeps an internal whitelist of HiDPI modes per aspect ratio, keyed on how the display identifies over the cable. Over HDMI-identified transport, macOS only offers HiDPI for 16:9 / 21:9 / 16:10 — aspect ratios that ship on actual MacBooks, iMacs, Studio Displays, XDR. The G95NC PBP half is 1.185:1 (effectively 11:9) — not on the list, so the matching HiDPI mode (1920×1620 doubled) never appears.

When the display is identified over USB-C (DisplayPort Alt Mode) instead, this whitelist is bypassed and 1920×1620 becomes available.

The trick: a proper USB-C→HDMI 2.1 active cable tells macOS "I'm a USB-C display" even though the downstream physical connector is HDMI. The monitor's EDID is still HDMI, but macOS's decision layer uses the transport, not the EDID, for the whitelist.

The fix

What to buy

A unidirectional USB-C → HDMI 2.1 active cable, 48 Gbps capable. As of 2026-04:

  • Cable Matters 48Gbps USB-C to HDMI 2.1 (Amazon ASIN B0CT6CK72N, 6ft) — widely confirmed working
  • UGREEN equivalent (Amazon ASIN B0BXWBSJ77, 6.6ft) — pairs well with UGREEN docks

What does NOT work:

  • DisplayPort → HDMI adapters (even 4K@120 ones) — macOS still sees HDMI transport
  • Thunderbolt → HDMI passive adapters — same problem
  • HDMI → HDMI cables from the dock's HDMI output — same problem
  • Any cable labeled "4K@60 only" — you need 8K/4K@120 class bandwidth on the USB-C side

Wiring

MacBook Pro ─── TB5/TB4 ─── Dock ─── USB-C→HDMI 2.1 active cable ─── G95NC HDMI (either HDMI-1 or HDMI-2)

Tested configurations:

  • MacBook Pro M4/M5 Max (Apple M4/M5 Max GPU) via UGREEN TBT5 17-in-1 Docking Station (USB4 v2, 80 Gb/s upstream)
  • Both G95NC HDMI-1 and HDMI-2 ports (see "Myth buster" below)
  • macOS Sonoma 14.x, Sequoia 15.x, Tahoe 26.x — all behave identically

Myth buster: "must be HDMI-1"

A common forum answer says HDMI-1 works but HDMI-2 doesn't. Empirically tested 2026-04 on macOS Tahoe 26.4.1: both HDMI ports expose the 1920×1620 HiDPI mode when the cable on the dock end is the right type. The variable is the cable transport (USB-C vs DP vs passive), not the monitor-side port.

What does differ between HDMI-1 and HDMI-2 is nothing HiDPI-related on macOS. One reasonable port split if you share the monitor with another box:

G95NC input Used by Why
HDMI-1 Mac direct (no dock) — full 7680×2160 @ 120Hz Only used when you want the full 32:9 single screen; no HiDPI needed at that resolution
HDMI-2 Mac through dock — 2560×2160 PBP half with HiDPI 1920×1620 Everyday productivity
DP-1 / DP-2 Linux / Windows box 5120×2160 @ 120Hz or full 7680×2160 @ 240Hz with DSC

Verify the mode is really available

Install displayplacer:

brew install displayplacer

Then:

displayplacer list

Scroll to your G95NC block. You want to see a line like:

mode XX: res:1920x1620 hz:60 color_depth:8 scaling:on

If this line is present, you're done — open System Settings → Displays → pick Scaled → "Larger Text" (macOS maps that to 1920×1620 with scaling:on). Or apply via CLI (below), bypassing the Settings app entirely.

If the line is not present, your cable is still being identified as pure HDMI. Swap to a real USB-C→HDMI 2.1 active cable.

Apply the HiDPI mode from the CLI

Grab your monitor's persistent screen id from displayplacer list (looks like 2567A1C1-6F55-4E5B-A774-833F5AFAA4D9). Then save this script:

~/bin/g95nc-dock-hidpi.sh

#!/bin/bash
# Set G95NC (via USB-C→HDMI 2.1 dock cable) to 1920x1620 HiDPI @60Hz.
# Idempotent: re-running won't cycle the display if already in the target mode.
set -eu
DP=/opt/homebrew/bin/displayplacer
G95NC_ID="REPLACE_WITH_YOUR_PERSISTENT_ID"   # from `displayplacer list`
MODE="res:1920x1620 hz:60 color_depth:8 enabled:true scaling:on origin:(0,0) degree:0"

if ! "$DP" list 2>/dev/null | grep -q "$G95NC_ID"; then
  echo "[g95nc-hidpi] G95NC not connected, skipping." >&2
  exit 0
fi

"$DP" "id:$G95NC_ID $MODE"
chmod +x ~/bin/g95nc-dock-hidpi.sh
~/bin/g95nc-dock-hidpi.sh

Auto-restore on login (optional but recommended)

macOS usually remembers per-display mode choices, but after OS updates, dock firmware updates, or swapping cables, it occasionally reverts to 2560×2160 native. Belt-and-suspenders: run the script on every login.

~/Library/LaunchAgents/com.user.g95nc-hidpi.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.g95nc-hidpi</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>-c</string>
        <string>sleep 5; $HOME/bin/g95nc-dock-hidpi.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/tmp/g95nc-hidpi.log</string>
    <key>StandardErrorPath</key>
    <string>/tmp/g95nc-hidpi.log</string>
</dict>
</plist>

Load it:

launchctl load ~/Library/LaunchAgents/com.user.g95nc-hidpi.plist

The 5s sleep lets Thunderbolt enumeration complete before the script polls displayplacer list on login.

Bonus: KVM USB stuck workaround

The G95NC has a built-in USB hub that follows your video input (selected under OSD → Source → USB Source Setup). Occasionally — on firmware 1009.2 as of this writing — the USB hub stops following the video switch: video goes to Mac, USB hub stays on Linux/Windows, your keyboard/mouse disappears from the machine you're looking at.

Fix: toggle the OSD input source to something else, then back. Do NOT crawl under the desk checking cables — it's the monitor's state machine, not your wiring.

CLI fallback if you have ddcutil on Linux and the G95NC on DP:

ddcutil --sleep-multiplier 2 setvcp 0x60 0x12  # switch to HDMI-2
sleep 2
ddcutil --sleep-multiplier 2 setvcp 0x60 0x0f  # switch back to DP

Note: Samsung VCP code 0xE3 (USB Source Setup) is a private/undocumented opcode — you cannot set USB routing directly over DDC/CI. The video-input toggle is the working workaround.

Bonus: Linux side (Ubuntu 24.04 on NVIDIA)

If you're using the G95NC with a Linux workstation too: 240Hz over DisplayPort works, but took until nvidia-driver-580 + kernel 6.11 to get fully stable. The critical missing piece was Display Stream Compression (DSC) handling on NVIDIA — fixed upstream in nvidia issue #816 (closed 2026-02).

Working config (Ubuntu 24.04 + GNOME 46):

xrandr DP-0 mode:   5120x2160  @120Hz    (PBP half)
                 or 7680x2160  @240Hz    (full 32:9, requires DSC)

No xorg.conf tweaks needed on recent drivers. GNOME mutter picks the right mode from ~/.config/monitors.xml at login.

Shopping list recap

Item Why Example
USB-C → HDMI 2.1 active cable Unlocks 1920×1620 HiDPI menu on macOS Cable Matters B0CT6CK72N, UGREEN B0BXWBSJ77
Thunderbolt 4 or TB5 dock with HDMI out Delivers USB-C upstream to Mac UGREEN TBT5 17-in-1, CalDigit TS4, OWC TB4 Hub
displayplacer Verify mode + apply from CLI brew install displayplacer

Why this gist exists

Every 6 months I see another post on r/G9Odyssey, the BetterDisplay issue tracker, or MacRumors asking the same question and getting partially-correct answers. The most common partial answer is "use HDMI-1 not HDMI-2" — that answer happens to work because the person who figured it out was swapping cables at the same time, and attributed success to the port instead of the cable. This gist is the distilled fix: it's the cable transport, not the port.

If this saved you a night of frustration, a star on the gist is nice — but even better, link it in the next forum thread you see asking the same question.

References

Tested 2026-04-20 on: MacBook Pro (M-series) + UGREEN TBT5 Dock + Samsung Odyssey G95NC (fw 1009.2) + macOS Tahoe 26.4.1.

Bonus: controlling the rear Core Lighting from the command line (Linux, DDC/CI)

The G95NC's rear CoreSync+ lighting turns out to be reachable over plain DDC/CI, through three manufacturer-specific VCP codes the monitor never advertises in its capabilities string:

VCP Meaning Range Writable
0xF8 lighting source: 0x00 off, 0x01 manual, 0x03 CoreSync max 17 only 0x00 / 0x01
0xF9 effect mode max 5 yes, in manual
0xFA colour max 51 yes, in colour-capable modes

Effect modes map 1:1 onto the OSD list (Settings → All Settings → Game → Core Lighting, not the Game quick bar):

0 Aurora · 1 Aurora Rotation · 2 Comet* · 3 Static* · 4 Rainbow · 5 Breathing* (* = has a colour option)

The colour palette in the OSD is a 13 × 4 grid, and 0xFA is simply its row-major index:

index = row * 13 + column       (0-based)
top-left 0 · top-right 12 · bottom-left 39 · bottom-right 51

# pink breathing
ddcutil --bus 17 setvcp 0xF9 5
ddcutil --bus 17 setvcp 0xFA 24

Two myths, corrected

"CoreSync only works over HDMI." It does not. CoreSync is greyed out in the OSD unless the effect mode is Static. That, not the cable, is why owners keep finding it unavailable. This panel is on DisplayPort and CoreSync enables fine from Static.

"If the register accepts the write, it works." Not on this panel. Several registers accept writes with no visible effect. Confirm with your eyes.

What you cannot do

CoreSync itself is read-only. setvcp 0xF8 0x03 fails verification, and once CoreSync is active (set from the OSD) all three codes lock read-only until you turn it off there. You can detect CoreSync from software; you cannot set it.

Also worth knowing: the OSD palette only writes 0xFA when you press Done, so arrowing across swatches changes nothing. And the monitor restores your mode and colour by itself after an off/on cycle, so there is no need to save and replay them.

Full method, the register walk, the five-point verification of the palette formula, and a reference script: https://gist.github.com/genedeng-ca/5ac2fb01ed7764c4122e1d2eef354414

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment