T480s → Anker 556 → LG 32UK50T: 4K@60 Diagnostics

Report 2 of 2 · 12/3/2025

T480s → Anker 556 → LG 32UK50T: 4K@60 Diagnostics

12/3/2025

This report finished before verdicts existed. Its conclusions are in the full report.

Files17

output.pngImage · 63.7 KBImage · 63.7 KB
output2.pngImage · 54.3 KBImage · 54.3 KB
plot.pngImage · 36.1 KBImage · 36.1 KB
generated_image.pngImage · 1010 KBImage · 1010 KB
plot.pngImage · 51.1 KBImage · 51.1 KB
plot.pngImage · 51.7 KBImage · 51.7 KB
plot.pngImage · 97.9 KBImage · 97.9 KB
generated_image.pngImage · 901.7 KBImage · 901.7 KB
generated_image.pngImage · 1 MBImage · 1 MB
generated_image.pngImage · 982.6 KBImage · 982.6 KB
output.pngImage · 83.1 KBImage · 83.1 KB
output2.pngImage · 89.7 KBImage · 89.7 KB
output.pngImage · 57.6 KBImage · 57.6 KB
output2.pngImage · 135.7 KBImage · 135.7 KB
output3.pngImage · 64.6 KBImage · 64.6 KB
generated_image.pngImage · 898.6 KBImage · 898.6 KB
generated_image.pngImage · 956.1 KBImage · 956.1 KB

Banner for T480s → Anker 556 → LG 32UK50T: 4K@60 Diagnostics

Diagnostics of 4K@60Hz Output Failure: Lenovo ThinkPad T480s (UHD 620) → Anker 556 Dock → LG 32UK50T on Fedora 43

Introduction

Research question

Why does a Lenovo ThinkPad T480s (Intel UHD Graphics 620) running Fedora Workstation 43 (GNOME on Wayland) fail to deliver 3840×2160 at 60 Hz (4K@60) through an Anker 556 USB‑C (USB4) dock while the same dock, cable, and monitor achieve 4K@60 with a MacBook?

Scope

Investigate whether the limitation is (a) T480s hardware (USB‑C / Thunderbolt controller, GPU DisplayPort capability), (b) dock/cable/monitor constraints or firmware, (c) Linux kernel/driver/compositor negotiation (i915, DRM, Mesa, Wayland), or (d) DisplayPort link parameters (link rate, lane count, DP version, DSC/MST) and bandwidth constraints.

Concise summary of key evidence-based findings

The T480s platform includes a Thunderbolt‑capable USB‑C port implemented with Intel’s Alpine Ridge (JHL6240) family controller; Alpine Ridge is historically limited to DisplayPort 1.2 (HBR2) capabilities, not DP 1.4/HBR3.
Intel UHD Graphics 620 (Gen9.5) advertises DisplayPort 1.2 support (DP1.2/HBR2) and is therefore consistent with a maximum native DP link payload of DP1.2-level bandwidth (HBR2).
The Anker 556 (A83A8H11) advertises USB4/USB‑C 40Gbps host interface and dual‑display support up to dual 4K@60 (single 8K@30), but its published documentation does not explicitly state whether the dock’s internal DP tunneling/translator supports DP1.4/HBR3 or DSC. Anker’s product pages list supported output resolutions and dual‑4K capability but do not explicitly state DSC or DP version.
DisplayPort link rates and payloads: HBR2 = 5.4 Gbps/lane -> usable payload ~17.28 Gbps (4 lanes); HBR3 = 8.1 Gbps/lane -> usable payload ~25.92 Gbps (4 lanes). DP1.2 (HBR2) payload is therefore significantly lower than DP1.4 (HBR3) payload.
Bandwidth calculation using CVT‑RB timings for 3840×2160@60 yields pixel clocks in the ≈533 MHz–594 MHz window depending on timing standard; the resulting video payload for RGB 8bpc 4:4:4 typically exceeds DP1.2/HBR2 payload capacity without chroma subsampling or color depth reduction.

These evidence points suggest the most likely root cause: the combination of Intel UHD 620 + Alpine Ridge (JHL6240) implementation limits the exposed DisplayPort link to DP1.2/HBR2 (or to fewer active lanes) so that across the dock (which may expect a DP1.4-capable host or tunnel) the negotiated link cannot achieve the payload required by full‑bandwidth 4K@60 in RGB 4:4:4/10bpc, and therefore the system falls back to 4K@30 or 4K@60 with subsampling/color reduction only when the source (MacBook) provides DP1.4/HBR3 support. Evidence and a detailed step‑by‑step diagnostic and verification plan follow.

Methodology (applied and recommended)

The investigative methodology combines: (1) hardware and firmware audit, (2) controlled experiments with cable/dock/monitor swaps, (3) software diagnostics (kernel/DRM logs, i915 debug data, EDID extraction), (4) configuration trials (Wayland vs X11, kernel/i915/Mesa upgrades, i915 parameters), and (5) quantitative bandwidth analysis using DP link rates, pixel clock and chroma/depth profiles. Experimentation and logs to collect are enumerated in the sections below.

Note: all claims and numerical values in this report are drawn from public product specifications, kernel/i915 documentation, vendor product pages, and technical references gathered and cited below.

Detailed analysis

1) Hardware and firmware audit

Summary table (key hardware components and observed/published capabilities)

Component	Observed / Published capability	Source
Lenovo ThinkPad T480s — ports listing	One USB 3.1 Type‑C Gen 1 (PD + DP) and one USB 3.1 Type‑C Gen 2 / Thunderbolt 3 port (PD + DP). PSREF lists USB‑C 3.1 Gen 2 / Thunderbolt 3 port with max external resolution via USB‑C 4096×2304@60.
T480s — TB3 controller (platform probes)	Device IDs and hardware probes on T480/T480s indicate Intel JHL6240 (Alpine Ridge LP) Thunderbolt controller present on TB3-capable port(s).
Intel JHL6240 (Alpine Ridge LP) — DP capability	JHL6x40/Alpine Ridge family predates Titan Ridge and is understood to provide DP 1.2 (HBR2) capabilities; Titan Ridge controllers added DP 1.4 support. Documents and reviews state Alpine Ridge supports two DP 1.2 streams, while Titan Ridge adds DP 1.4.
Intel UHD Graphics 620 (Gen9.5) — DP support	Intel UHD 620 is documented as supporting DisplayPort 1.2 (DP1.2) external outputs, consistent with Gen9.5 integrated GPU capabilities.
Anker 556 (A83A8H11) — dock published resolutions	Anker lists USB4/40Gbps hub with DisplayPort and HDMI outputs, advertising single‑display up to 8K@30 or dual displays up to 4K@60; the product pages do not explicitly specify DP version (1.4 vs 1.2) or DSC support in published specs.
LG 32UK50T — DisplayPort version and 4K@60 support	Monitor listings indicate DisplayPort 1.2 interface and native 3840×2160 support up to ~60 Hz (56–61 Hz in spec listings); DP1.2 suffices for 4K@60 with reduced‑blanking timings and/or chroma subsampling.

Discussion of these entries and implications

The T480s hardware specification confirms presence of a Thunderbolt‑capable USB‑C port and a second USB‑C port; platform probes and published PCI device IDs indicate the Thunderbolt controller present is an Alpine Ridge (JHL6240) variant rather than the newer Titan Ridge family. The Alpine Ridge family is historically associated with DP1.2 feature parity for DisplayPort tunneling over the Thunderbolt link; product announcements for Titan Ridge explicitly list DP1.4 as a new capability relative to Alpine Ridge.
From the GPU side, Intel UHD Graphics 620 is part of the Gen9.5 family and is documented to provide DP1.2 external display support; it lacks documented DP1.4/HBR3 native capability on the integrated display pipe. This constrains the maximum native DP link rate the GPU can request via the Thunderbolt controller or DP Alt Mode.
The dock (Anker 556) advertises modern USB4 features and high supported resolutions on its product page (8K@30 single, dual 4K@60), but vendor pages do not disclose whether internal tunneling/translator microcontrollers accept HBR3/DP1.4 or whether they rely on host DP version negotiation. In the absence of explicit DP1.4/DSC claims, one must not assume DP1.4 behavior.

Collectively, the hardware audit shows a plausible hardware ceiling: the host GPU + TB3 controller combination (UHD 620 + Alpine Ridge) is consistent with DP1.2/HBR2‑level capability, while the dock and monitor may be DP1.4/DP1.2 compatible in different ways; when the host (MacBook) provides higher DP version/UB/DSC-capable signaling the dock/monitor can reach 4K@60 in full color, but the T480s host may not be able to expose the required DP1.4/HBR3/DSC pipeline.

2) Controlled experiments (protocol and logs to collect)

Planned controlled experiments (ranked by diagnostic value):

Direct native path: Connect T480s directly to LG 32UK50T using the highest‑quality direct USB‑C ↔ DisplayPort or USB‑C ↔ DP adapter available (prefer a TB3‑certified cable or a passive DP1.4‑capable cable if the monitor supports it). Observe whether the T480s GPU can negotiate 4K@60 directly without the dock in the chain. Collect: EDID, xrandr mode list, kernel dmesg drm link training lines, and i915 debug output. Commands: sudo dmesg | grep -i drm|displayport|i915, xrandr --verbose, sudo cat /sys/kernel/debug/dri/*/i915_display_info and EDID extraction via modetest/get-edid/edid-decode. Example diagnostics lines for link rates/lane counts to watch for in the kernel log include entries like "DP lane count 2 clock 540000 bpp 24" or DP link training success/failure lines; these examples are shown in publicly available kernel logs.
Docked path (baseline): With the same cable used to connect to the dock (the Anker 556 upstream cable), connect T480s → Anker 556 → LG 32UK50T and record the same set of logs and the mode negotiated. Repeat using the same dock/cable/monitor with a MacBook to confirm the dock/cable/monitor can provide 4K@60 when the host supports more modern DP features (to reproduce user observation). Collect screenshots of xrandr --verbose or Wayland compositor mode list as proof. Cross‑compare the negotiated DP link parameters.
Cable variation: Try TB3‑certified USB‑C cable vs DP1.4 certified cable vs the original cable. Record negotiated link rates. Many hosts/docks will cap link rate when using cables not rated for requisite bandwidth; ensure cables are full‑featured (SuperSpeed/USB4 / TB3 rated). Vendor pages often specify that included cables are certified; the Anker product page suggests a provided USB4 cable.
Alternative host comparison: Reproduce the same dock/cable/monitor setup with a MacBook known to negotiate DP1.4/HBR3 or higher. Capture logs and mode lists from that host to contrast with T480s outputs. This will demonstrate whether the dock/monitor chain can carry DP1.4 signals when the host provides them. (User already reports MacBook success; collecting the MacBook’s negotiated link provides definitive evidence.)
Software/OS variations: Test (a) Fedora 43 default Wayland session vs an X11 session if possible (or XWayland fallbacks), and (b) newer kernels (e.g., kernels 6.3+ or later where DP1.4/DSC i915 improvements landed), and (c) alternative Mesa versions if relevant for mode negotiation reporting. Collect uname -a, rpm -q kernel-core mesa (or distro package versions), and modinfo i915 with kernel logs and dmesg | grep -i drm|i915|displayport|thunderbolt.
i915 debug and dc lx settings: Enable drm.debug=0xe kernel parameter or i915-specific debugfs nodes where applicable to capture extended link training logs. Inspect /sys/kernel/debug/dri/*/i915_* debugfs nodes for i915_display_info, dsc nodes, and connector capabilities. Kernel log lines to watch for include intel_dp_compute_config, intel_dp_start_link_train, and intel_dp_link_training_* lines which explicitly show link rates and lane counts. Example log patterns showing link rate and lane count are published as representative examples in upstream issue trackers and forum posts.
Firmware/BIOS updates: Verify T480s BIOS/UEFI, Thunderbolt firmware, and dock firmware versions and upgrade to vendor-provided updates where available. These updates sometimes modify tunnel behavior or DP Alt Mode exposure by the Thunderbolt controller. Check Lenovo’s support pages for T480s BIOS and Thunderbolt controller firmware. (Caveat: vendor downloads are not listed here as an evidence source in this report; BIOS updates must be obtained by the operator.)

Each experiment should collect: lspci -k, lsusb -t, sudo modinfo i915, xrandr --verbose or weston-info/wayland-info (for Wayland), journalctl -k and journalctl -b | grep drm entries, and EDID via DDC/edid-decode. Recommended shell commands are provided in the Diagnostics section.

3) Software diagnostics: what to collect and how to interpret

Essential commands and expected evidence items

lspci -k — confirm PCI device IDs (e.g., Intel GPU 8086:5917 / TB controller 8086:15c0) and driver bindings. Use these to confirm Alpine Ridge/TB and which kernel driver is bound.
lsusb and lsusb -t — show USB devices and whether the dock enumerates on the USB bus; helpful to verify USB4 tunneling and device class assignments.
modinfo i915 — display i915 kernel module version and parameters. Document the module version and export date (to map to kernel and i915 features). (When DPI/DSC features were merged into kernel/i915, references show Gen≥10 was required for DSC in older patches; kernel 6.3 added MST‑DSC i915 features.)
xrandr --verbose (or wf-recorder/Wayland compositor debug output) — list modes and whether the monitor is reporting the expected 3840x2160@60 mode. When Wayland is used, compositor logs and journalctl may reveal the selected final mode. Fedora 43’s default GNOME session is Wayland only, so capturing compositor logs (journalctl for GNOME/Wayland) is necessary.
Kernel logs for DRM/i915/DP link training — sudo journalctl -k | grep -i drm and dmesg | grep -i drm — look for lines indicating DP link parameters (e.g., DP lane count X clock Y bpp Z, clock recovery OK, Channel EQ done. DP Training successful, or errors like too many voltage retries, give up or failed to train DP). Example kernel debug outputs demonstrating link counts and clock values are available in public issue threads and kernel discussions. These lines directly indicate negotiated DP link rate and lane count (e.g., clock 540000 → 5.4 Gbps/lane, HBR2/HBR3 determination based on value).
EDID extraction — capture with get-edid or ddcutil or via debugfs exposed EDID and run through edid-decode to learn the monitor’s supported link capabilities and preferred timings. A monitor may advertise DP1.2 in its EDID descriptor or list CTA‑861 timing blocks; some public monitor specs list DP1.2 explicitly for LG 32UK50T.
cat /sys/kernel/debug/dri/*/i915_display_info — yields the i915 view of connectors and is useful for seeing whether DSC is available or whether the port reports only HBR2 rates. The i915 driver added DSC debugfs nodes for supported connectors in earlier kernels with Gen≥10 gating; check for existence and values.

Representative kernel log snippets (examples to search your logs for)

Successful link training (example):

[drm:intel_dp_compute_config] DP link bw 06 rate select 00 lane count 2 clock 162000 bpp 24
[drm:intel_dp_link_training_clock_recovery] clock recovery OK
[drm:intel_dp_link_training_channel_equalization] Channel EQ done. DP Training successful

These lines indicate successful training and negotiated link rate entries (rates in kHz correspond to familiar DP rates).

Failed link training (example):

[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_dp_link_training_channel_equalization [i915]] *ERROR* failed to train DP, aborting

These indicate physical link problems or negotiation mismatches (cable/dock/controller).

Interpreting link rates and lane counts

DP link rate numbers in kernel logs are usually expressed as clock in kHz; common values include 162000 (RBR 1.62 Gbps/lane), 270000 (HBR 2.7 Gbps/lane), 540000 (HBR2 5.4 Gbps/lane), 810000 (HBR3 8.1 Gbps/lane). Look for DP lane count X clock Y bpp Z lines to see what was actually negotiated.

4) Bandwidth analysis (quantitative)

Fundamental numeric facts (sources)

DP link raw rates and payloads:
- HBR2: 5.4 Gbps per lane → 21.6 Gbps raw (4 lanes) → ~17.28 Gbps usable payload after 8b/10b overhead.
- HBR3: 8.1 Gbps per lane → 32.4 Gbps raw (4 lanes) → ~25.92 Gbps usable payload after 8b/10b overhead.
CVT‑RB pixel clock for 3840×2160@60 (reduced blanking) is commonly cited around 533.25 MHz (variations appear in practical tables and tool outputs). Other timing references (full HDTV/CTA standards) list values up to ≈594 MHz depending on timing standard. Use of reduced blanking reduces required bandwidth.
Chroma subsampling reduces bandwidth demand: YCbCr 4:2:0 uses ~50% of the color channel bandwidth compared to 4:4:4; 4:2:2 ≈ 2/3 of 4:4:4. These ratios significantly affect whether a DP1.2 link can carry a particular 4K@60 encoded format.

Visual evidence (embedded charts)

Figure 1: Required video bandwidth for 3840×2160@60 (CVT‑RB) across common color/bit‑depth formats, plotted against DP1.2 (HBR2) and DP1.4 (HBR3) usable payloads. This chart illustrates which format combinations fit within HBR2 vs which require HBR3 or DSC. ![Required Bandwidth vs DP Payloads] (https://storage.googleapis.com/scholarly-research-files/research/692fc4b010ca1c41e5127729/ac68da8b-6fb3-4318-90ab-a2327e018c4c_output.png)
Figure 2: Ratio chart showing required / DP payload for HBR2 and HBR3 for the same formats.

Interpretation of the charts (evidence‑based):

RGB 8bpc (4:4:4) 4K@60 requires a high payload that approaches or exceeds HBR2 payload capacity (17.28 Gbps) when standard CVT‑RB timings with a ≈533 MHz pixel clock are used; the precise required payload depends on timing and blanking assumptions. If the host/dock chain limits link rate to HBR2 (or to 2 lanes at HBR3-equivalent per lane), the result is that full‑bandwidth 4K@60 at 4:4:4 8bpc may not fit and the system will either fall back to a lower refresh rate (e.g., 30 Hz) or use chroma subsampling (4:2:2/4:2:0) or color depth reduction to fit within the available payload.
The existence of DSC (Display Stream Compression) on a host/dock/display path can dramatically reduce required link payload by lossy compression, enabling higher resolutions and refresh rates even when raw link payload is insufficient; however, DSC support requires the source GPU, the tunneling controller, and driver stack to enable and agree on DSC. i915 driver DSC support historically required Gen≥10 hardware for native DSC acceleration in i915, and kernel-level MST‑DSC work continued into recent kernels (e.g., references to Phoronix on Linux 6.3 adding DP MST DSC support in i915). This suggests that older Gen9/Gen9.5 platforms like UHD 620 may not present full DSC capability even if dock/display support it.

5) Protocol and driver considerations

Key protocol points and how they relate to the observed symptom

USB‑C DP Alt Mode and Thunderbolt encapsulation: USB‑C ports either expose DP Alt Mode lanes directly or tunnel DisplayPort over Thunderbolt/USB4 pipes. Actual DP version/lane/quality exposed depends on the host controller (Thunderbolt chip), the physical port wiring, the cable capabilities, and the dock’s internal translator/firmware. In practice, older TB3 controller families (Alpine Ridge/JHL6x40) were typically implemented with DP1.2 capability; Titan Ridge controllers were announced to add DP 1.4 support. Consequently, a host platform using Alpine Ridge may not be able to request an HBR3/DP1.4 link even if the dock supports it.
i915 / Intel DRM stack: Historical patches show DSC enabling in i915 targeted at Gen≥10, with later kernel versions adding MST‑DSC capability; therefore, the i915 driver on Gen9.5 hardware may not advertise or accept DSC even if downstream components would benefit from it. Kernel versions matter: Fedora 43 ships with kernel 6.17 which includes many display improvements, but Gen‑targeted DSC enablement still depends on GPU generation. Check modinfo i915/kernel release notes and i915 debugfs nodes for dsc exposure.
User space/compositor negotiation (Wayland): On Wayland, the compositor (GNOME/Wayland) negotiates modes via DRM; the kernel ultimately performs link training and sets the pipe configuration. Wayland vs X11 generally does not change the physical link’s negotiated rate, but compositor behavior (whether it forces color-depth reduction or relies on kernel/probe info) can affect the final mode selection and what is exposed in user-visible tools. Fedora 43’s Wayland default means more reliance on kernel/compositor interactions; carefully captured kernel logs are therefore essential.

6) Synthesis & root‑cause argument (evidence chain)

T480s hardware detail: T480s uses an Intel JHL6240 (Alpine Ridge LP) Thunderbolt family controller on its TB3-capable USB‑C port as indicated by PCI device IDs and hardware probes.
Alpine Ridge limitations: Alpine Ridge family (JHL6x40) launched before Titan Ridge and is commonly documented or observed to be limited to DP 1.2 (HBR2) capability for DisplayPort tunneling; Titan Ridge controllers were introduced to add DP1.4 capability. These public vendor/industry analyses and product announcements are explicit about the DP1.4 addition in the JHL7xxx family and therefore imply that Alpine Ridge is DP1.2-limited.
Intel iGPU DP support: Intel UHD 620 is officially documented to provide DP1.2 external display support (Gen9.5), indicating that the source GPU does not provide native DP1.4/HBR3 signaling. Thus the host cannot request HBR3 unless intermediate components (Thunderbolt controller) can perform tunneling/translation beyond what the GPU advertises.
Dock/monitor capability: The Anker 556 advertises dual‑4K@60 and single 8K@30 capability via USB4, and the LG 32UK50T advertises DP1.2 and 4K@~60 capability. The MacBook success implies the dock/monitor/cable can support 4K@60 when the host provides suitable DP version/lanes (e.g., a MacBook that exposes DP1.4 / higher link rates). However, Anker’s published specs do not confirm internal DP1.4 or DSC behavior; in situations where the host is DP1.2‑limited, the dock will only receive DP1.2 bandwidth from the host.
Bandwidth mismatch: 4K@60 RGB 8bpc/4:4:4 requires payload near or above DP1.2/HBR2 usable payload for the common CVT‑RB timings, while DP1.4/HBR3 or DSC would provide sufficient payload headroom. Consequently, the host+controller+dock chain that is limited to DP1.2 cannot transport 4K@60 in full color at normal timing, leading to fallback behaviors (subsampling or lower refresh).
Driver/OS role: On Linux, the i915 driver controls what the GPU and connector advertise and negotiate; DSC support in i915 was gated by GPU generation and required more recent kernel support for MST‑DSC. Given UHD 620’s Gen9.5 status, i915 is unlikely to advertise or enable DSC to force higher effective bandwidth on older hardware. Thus even kernel updates might not allow DSC on this platform.

Combining items (1)–(6) the most parsimonious evidence‑based root cause is: the host side (Intel UHD 620 combined with the Alpine Ridge JHL6240 Thunderbolt controller in the T480s) is limited to DP1.2/HBR2 (or to reduced lane counts), and therefore the dock (or the whole tunnel) cannot present the DP1.4/HBR3 payload that a MacBook is able to provide. This leads to the observed failure to obtain full‑bandwidth 4K@60 over the Anker 556 when sourced by the T480s, despite the same dock/cable/monitor working with a MacBook that provides a DP1.4/HBR3 link.

7) Recommended remediation options (ordered by likelihood of success and invasiveness)

Direct‑connect if possible: Prefer direct USB‑C ↔ DisplayPort or native DisplayPort/HDMI output from the T480s to the monitor (bypassing the dock). If a direct cable yields 4K@60, this confirms the dock/controller path is the bottleneck. Commands and logs: collect the same dmesg/i915 outputs and xrandr --verbose after direct connection.
Replace the Thunderbolt controller/Dock/Cable layer with DP1.4-capable hardware:
- Use a dock or adapter that explicitly documents Titan Ridge or later TB3/TB4 controllers (JHL7xxx/Titan Ridge or newer) that advertise DP1.4/HBR3 support and/or DSC capability. Titan Ridge controllers were introduced to add DP1.4 capabilities relative to Alpine Ridge.
- Use a USB‑C cable certified for full USB4/TB3/TB4 or a passive DP‑rated cable (DP1.4 certified) if the dock/monitor path requires it. Cable limitations will appear as a lowered negotiated link rate.
Evaluate color/depth/subsampling workarounds: If DP1.4 hardware replacement is not possible, accept 4K@60 with chroma subsampling (YCbCr 4:2:0 or 4:2:2) or lower color depth to fit in HBR2. The display/compositor typically indicates these modes when negotiated; the user may prefer subsampled 4K@60 visually to 30 Hz. Chroma subsampling reduces bandwidth (4:2:0 ≈ 50% of 4:4:4 for color channels).
Firmware/BIOS updates: Ensure the T480s BIOS and Thunderbolt firmware are up to date; occasionally vendors release controller firmware updates that improve tunnel behavior. However, an Alpine Ridge TB3 controller’s hardware logic for DP version is not generally upgradable to DP1.4 in firmware—Titan Ridge added different silicon. Document BIOS/fw versions before upgrading. (Vendor update pages should be consulted directly.)
Kernel / i915 / Mesa upgrades and force options: Test with the newest kernels (6.3+ and beyond), enable i915 debug and force DSC only where hardware supports it (i915 DSC debugfs nodes are Gen‑gated), and test whether the driver advertises DSC. However, Gen9.5 hardware is unlikely to add DSC hardware capability via software alone.
Replace laptop/platform with DP1.4 capable host: If 4K@60 at full RGB/color depth is a hard requirement via the dock, the only certain fix without replacing the dock is using a host that exposes DP1.4/HBR3 or supports DSC (e.g., modern MacBooks or newer Intel/AMD/NVIDIA platforms with DP1.4/TB4 capabilities). The MacBook comparison in the controlled experiment already demonstrates an alternate host achieves the required mode.

8) Verification procedures and expected signals/logs for successful fixes

After a hardware replacement (Titan Ridge TB3/TB4 dock or a DP1.4-capable host), kernel logs should show negotiated link rates of 810000 (kHz) or clock 810000 and lane count consistent with the negotiated mode (e.g., 4 lanes at HBR3). Example success log pattern: DP lane count 4 clock 810000 bpp 24 followed by clock recovery OK and Channel EQ done. DP Training successful.
If DSC is used, the driver/debugfs nodes may report a dsc capability and a negotiated compression PPS; i915 debug commits and kernel features describe DSC node presence for Gen10+ devices.
When the link is successful, xrandr --verbose (or compositor mode lists) should include 3840x2160 at 60.00 Hz as the active mode and the monitor EDID preferred timing. If the dock/host uses subsampling to obtain 4K@60, xrandr --verbose or the compositor logs may show YCbCr 4:2:0 or 4:2:2 in the reported pixel format.

Tables and concise reference data

Table 1: DisplayPort link rates and usable payload (after 8b/10b overhead)

DP mode	Per‑lane raw rate (Gbps)	4‑lane raw (Gbps)	Usable payload (Gbps)	Typical capability
HBR2 (DP1.2)	5.40	21.6	17.28	Common for DP1.2 devices (e.g., Alpine Ridge / older GPUs)
HBR3 (DP1.3/1.4)	8.10	32.4	25.92	DP1.4/HBR3 devices (Titan Ridge, modern GPUs)

Table 2: Representative hardware capability mapping (source, controller, DP version)

Device / component	Published DP version / claim	Evidence
Lenovo ThinkPad T480s (port spec)	TB3 / USB‑C with DP support (PSREF mentions external display up to 4096×2304@60 via USB‑C)
TB3 controller on many T480/T480s probes	Intel JHL6240 (Alpine Ridge LP)
Intel UHD Graphics 620	DP1.2 (external) / Gen9.5
Anker 556 (A83A8H11)	USB4/TB capability; advertises single 8K@30 or dual 4K@60; DP version/DSC not explicitly listed in spec page
LG 32UK50T	DisplayPort 1.2 listed; supports 3840×2160 at ~60Hz

Step‑by‑step experimental log capture recipe (for reproducibility)

Record system environment

uname -a (kernel version)
rpm -q kernel-core mesa (or equivalent distro package query)
modinfo i915 (driver version/compile)

Capture hardware enumeration

lspci -nnk (capture GPU, Thunderbolt controller IDs)
lsusb -t (clusters and speeds)

With the target connection active, capture kernel logs and DRM/i915 lines

sudo journalctl -k -b 0 | grep -iE 'drm|i915|thunderbolt|displayport|dp|link' (search for DP link training lines)
dmesg | grep -iE 'drm|i915|thunderbolt|displayport|dp|link'

Capture connector and display info

xrandr --verbose (for X or XWayland output) or compositor logs for Wayland (journalctl for GNOME/Wayland) to list modes and pixel formats
sudo cat /sys/class/drm/*/edid > edid.bin then edid-decode edid.bin (or edid-decode < edid.bin) to parse monitor capabilities
sudo cat /sys/kernel/debug/dri/*/i915_display_info (i915 view of display pipelines and debug nodes)

Repeat for direct‑attached cable, docked cable, and for the MacBook host (collect the same logs). Use identical cabling where possible to isolate host differences.
Document cable part numbers and any dock firmware versions (if retrievable via vendor utilities or the dock’s firmware update pages).

Conclusion

Synthesis of evidence

The Lenovo ThinkPad T480s platform examined is consistent with a hardware stack comprising Intel UHD Graphics 620 (Gen9.5) and an Intel Alpine Ridge (JHL6240 family) TB3/USB‑C controller. Public product documentation, platform probes, and industry descriptions indicate that Alpine Ridge was designed with DP1.2 (HBR2) DisplayPort capability, while DP1.4/HBR3 was introduced in the subsequent Titan Ridge family.
Intel UHD Graphics 620 is documented as supporting DisplayPort 1.2 as its external DP capability, aligning with a host-limited link rate that is compatible with HBR2 payloads rather than HBR3.
The Anker 556 dock documents dual 4K@60 support and single 8K@30 support; however, its published spec does not explicitly confirm it performs DP1.4/HBR3/DSC translation if the host cannot request it. The MacBook working with the same dock/cable/monitor constitutes an important comparative datum: when the host exposes DP1.4/HBR3 (or more flexible tunnel capabilities), the dock+monitor can attain 4K@60. When the T480s host appears to offer only DP1.2/HBR2 through Alpine Ridge/JHL6240, the chain lacks the required usable payload and therefore cannot produce native 4K@60 in full RGB 4:4:4 or high bit depths; the system falls back to subsampling, lower color depth, or lower refresh rate.

Final root‑cause statement (evidence‑based)

The T480s hardware combination (Intel UHD 620 + Intel JHL6240 Alpine Ridge TB3 controller) is limited to DisplayPort 1.2/HBR2 capabilities in practical operation; once the dock is inserted in the chain, the negotiated DP link cannot reach the HBR3/DP1.4 payload required for 4K@60 at full color-depth without DSC or chroma/dither reductions. Therefore the inability to achieve 4K@60 is primarily a host/hardware limitation rather than a Linux kernel or Anker dock defect per se.

Limitations

Lack of hands‑on logs from the specific T480s/Anker 556 monitor chain under test. The argument relies on published hardware specs, platform probes found in public hardware probe databases, product announcements, and kernel/i915 commit history and public forums as the evidence base. For an airtight conclusion, reproduce the controlled experiments (direct attach vs docked attach) with the T480s machine and collect the specific kernel dmesg/journalctl logs and i915_display_info debugfs outputs; the report presents the precise commands and expected log patterns to collect.
Vendor pages for the Anker 556 do not disclose precise internal DP version translation or DSC capability; absence of explicit vendor confirmation in published specs requires cautious interpretation rather than definitive assertion about the dock firmware internals.
i915/DSC kernel support is complex and GPU generation dependent; while kernel patches for DSC presence are documented, actual active DSC negotiation is gated by hardware generation; precise runtime behavior requires the exact kernel and driver logs from the tested machine.

TLDR

The T480s’s TB3 port is driven by an Alpine Ridge (JHL6240) controller and the integrated GPU is Intel UHD Graphics 620 (Gen9.5). Alpine Ridge and many Gen9.5 iGPU implementations are effectively limited to DisplayPort 1.2 (HBR2) bandwidth.
DP1.2 (HBR2) payload is typically ≈17.28 Gbps (after overhead), while DP1.4 (HBR3) payload is ≈25.92 Gbps. Full 4K@60 4:4:4 RGB 8bpc pixel streams often require payload beyond DP1.2 depending on timing; DP1.4/HBR3 or DSC is therefore necessary for guaranteed full‑bandwidth 4K@60 with full color depth.
Practical remediation: use a direct DP connection or a DP1.4/Titan Ridge (or newer TB4) host/dock or accept 4K@60 with chroma subsampling or lower color depth. Test kernel/i915 debug logs to confirm link rate/lane negotiation.

Appendix: Key references and artifacts cited in this report

Lenovo ThinkPad T480s product specifications (PSREF) — ports and external display claims.
Linux hardware probe evidence identifying JHL6240 Alpine Ridge on T480/T480s devices.
Intel product/driver pages for Intel UHD Graphics 620 (external DP1.2 support).
AnandTech coverage of Titan Ridge vs Alpine Ridge differences (DP1.4 addition in Titan Ridge).
Anker 556 product page showing advertised resolutions (USB4 hub A83A8H11).
LG 32UK50T specifications listing DP1.2 and 4K@~60 capability.
DP link rate / HBR2 vs HBR3 payload references.
Timing/pixel clock references for 3840×2160@60 CVT‑RB.
i915 DSC commit and kernel work (DSC enablement, Gen gating) and Phoronix reporting for Linux kernel display features.
Representative kernel log examples for DP link training messages (for interpretation guidance).

Embedded visuals (figures cited in text)

Figure 1 — Required Bandwidth for 3840×2160@60 (CVT‑RB) by color format vs DP payloads (HBR2, HBR3).
Figure 2 — Ratio (Required Bandwidth / DP Payload) for the same formats vs HBR2 and HBR3.
Conceptual diagram: Host (T480s) → Alpine Ridge TB3 → Anker 556 USB4 dock → LG monitor (paths labeled DP Alt Mode direct vs tunneled DP) (generated).
Negotiation flowchart (Linux compositor → i915/DRM → DP link training → failure points annotated) (generated).

End of report.

T480s → Anker 556 → LG 32UK50T: 4K@60 Diagnostics

T480s → Anker 556 → LG 32UK50T: 4K@60 Diagnostics

Files17

Diagnostics of 4K@60Hz Output Failure: Lenovo ThinkPad T480s (UHD 620) → Anker 556 Dock → LG 32UK50T on Fedora 43

Introduction

Methodology (applied and recommended)

Detailed analysis

1) Hardware and firmware audit

2) Controlled experiments (protocol and logs to collect)

3) Software diagnostics: what to collect and how to interpret

4) Bandwidth analysis (quantitative)

5) Protocol and driver considerations

6) Synthesis & root‑cause argument (evidence chain)

7) Recommended remediation options (ordered by likelihood of success and invasiveness)

8) Verification procedures and expected signals/logs for successful fixes

Tables and concise reference data

Step‑by‑step experimental log capture recipe (for reproducibility)

Conclusion

Limitations

TLDR

Cited sources20