Field notes / hardware
Not the integrated GPU
Two USB-C sockets on my laptop look identical. A monitor plugged into either one would land on the integrated graphics, or so the assumption went. It landed on the discrete GPU, and the old dock had been holding that same monitor at 60Hz.
Three monitors, one laptop, and one USB dock old enough to be a bottleneck. Two of the three monitors ran through it: a 4K panel and an ultrawide, both sharing one USB link with the keyboard, the mouse, and Ethernet. The third monitor, a second 4K panel, was already wired natively straight to the discrete GPU over HDMI, no dock involved. The dock was doing its job. It just had a lot of job to do for two-thirds of the setup.
The laptop has two USB-C sockets, and the working assumption going in was that a monitor plugged into either one would land on the integrated graphics, the way a lot of thin-and-light laptops route USB-C video. The two ports look identical. They aren't quite: one carries power delivery up to 100W and DisplayPort 2.1, the other tops out at DisplayPort 1.4 with no power delivery at all. Both are wired to the same USB controller underneath, the only one this laptop has. A different configuration of the same chassis swaps one of those ports for Thunderbolt; this one doesn't, and I confirmed that by checking the controller list directly rather than trusting the spec sheet for this exact model.
2 sockets, 1 controllerThe port routes to the discrete GPU, not the integrated one
Moving the ultrawide monitor from the old dock onto the power-delivery USB-C port — native DisplayPort Alt Mode, the mode that carries real DisplayPort video directly over a USB-C connector, no dock in between — settled the assumption by measurement instead of guesswork. The monitor came up attached to the discrete GPU. Not the integrated graphics chip doing double duty on the internal panel and the USB-C port both, which was the original assumption. A separate, dedicated card, the same one already driving one of the 4K monitors over HDMI.
| Display | Was driven by | Now driven by |
|---|---|---|
| Internal panel2560×1600 · 165Hz | integrated GPU | integrated GPU |
| 4K panel, HDMI3840×2160 · 60Hz | discrete GPU | discrete GPU |
| Ultrawide3440×1440 · 60Hz → 100Hz | the dock | discrete GPU |
| 4K panel, dock3840×2160 · 60Hz | the dock | the dockcable ordered |
The other USB-C port hasn't been tested the same way yet. The reasonable guess is that it behaves the same, since both ports sit on the same controller, but a guess is exactly the thing this whole exercise exists to replace with a measurement, so it stays a guess until it's checked.
59.97Hz → 99.90HzFaster the moment the dock was out of the path
With the ultrawide on its own native connection, dxdiag showed it running at 3440×1440. The old
dock connection had topped out at 60Hz for that monitor, full stop. There was no higher option to
select. The panel itself supports 100Hz; the dock's video path never exposed anything past 60,
because it wasn't sending real DisplayPort signal at all — it was compressing the whole desktop into a
video stream and shipping that over USB.
The refresh rate didn't jump to 100Hz on its own, though. Straight after the re-cable, the display
still reported 59.97Hz, because Windows carries a monitor's previous setting forward across a
different physical connection rather than picking the best one available. The Choose a refresh rate dropdown listed nine options, four of them marked with an asterisk meaning the adapter
synthesised them rather than the monitor actually supporting them:
| Refresh rate | Note |
|---|---|
| 99.90 Hz | unmarked |
| 75.03 Hz | adapter-synthesised |
| 72.19 Hz | adapter-synthesised |
| 70.07 Hz | adapter-synthesised |
| 60 Hz | |
| 59.97 Hz | selected |
| 59.94 Hz | |
| 56.25 Hz | adapter-synthesised |
| 50 Hz |
Picking the unmarked 99.90Hz by hand got a 100Hz reading in dxdiag afterward.
A cable upgrade doesn't come with an automatic refresh-rate upgrade attached. Somebody has to go into the settings and pick it.
right numbers, wrong adapterA tool that reported the wrong monitor entirely
One check along the way turned up something worth flagging on its own, separate from the dock:
Win32_VideoController, a common way of asking Windows what resolution and refresh rate a graphics
adapter is currently running, gave a confidently wrong answer in this exact multi-monitor setup. It
reported the
integrated graphics chip as running the ultrawide's resolution at 60Hz. The integrated chip was
never connected to that monitor at all. It was driving the laptop's own internal screen, at a
completely different resolution and refresh rate. dxdiag, read directly, had the real picture:
internal panel on the integrated chip, ultrawide hanging off the old dock. The first tool wasn't
lying about a number — it was reporting the wrong adapter's numbers as if they belonged to a monitor
they'd never touched. I'd check with a second tool before trusting a report like that in any
setup with more than one screen.
Integrated graphics, 3440×1440 at 60Hz. That is the ultrawide's mode, on an adapter that was never wired to it.
Integrated graphics, 2560×1600 at 165Hz, on the laptop's own internal panel, which is what it was actually driving.
~25 Gbps into ~4The bandwidth math the dock was quietly doing
The old dock's USB link carries something like 4 gigabits a second, shared across both monitors, the keyboard and mouse, and the network connection. A single 4K panel at 60Hz, uncompressed, needs roughly 12.8 gigabits a second on its own. Two monitors, both routed through that one dock, meant somewhere around 25 gigabits of raw pixel data getting squeezed into a 4-gigabit pipe, continuously, the entire time both screens were on. Something has to give, and what gave was a real-time compression pass running in software the whole time, on hardware never asked whether it minded.
Native DisplayPort Alt Mode over USB-C, by contrast, has room to spare: the standard this laptop's faster port supports moves tens of gigabits a second, more than enough for one monitor at its native resolution and refresh rate with nothing left to compress. Once the ultrawide moved off the dock, its own share of that math simply stopped being a problem.
1 of 2 movedWhere this actually stands
One monitor is done: natively connected, correctly identified as running off the discrete GPU, and finally at the refresh rate it was always capable of. A cable for the second monitor, DisplayPort this time rather than the general-purpose USB-C to USB-C cable currently in use, has been ordered but not yet installed. Once it lands, the old dock drops out of the video path entirely and keeps one job: charging and networking, which is what a general-purpose USB link is good at.
Nothing here was fixed by buying better hardware. The laptop, the monitors, and the faster port were all already sitting there. The fix was checking which port actually did what, instead of assuming the label on the box.