KVM Mode – Display Artifacts

Those vertical streaks in your screenshot are stale regions that never got repainted, trailing down from the windows that changed. That reads as a frame encoding problem rather than something wrong on the Latitude's own display.

The lever we have on that is per connection. Open the KVM connection's settings, go to the gear icon and Advanced KVM settings, and flip "Force video encoding mode (quality will be lower for text)". Whichever way it is set now, set it the other way. Those labels are from the Multiplicity 3 docs and 4 moved some things around, so the wording may not match exactly on 4.07.

The part that catches people out: changing Multiplicity settings while a KVM session is open does nothing until you disconnect that session. Change it, disconnect, reconnect, then judge it. Testing it without the reconnect is how this ends up looking like the setting did nothing.

There is precedent for the encoder doing this. 4.0.0.4 fixed an issue where low compression mode in KVM and seamless display showed visual corruption. That specific one is long since fixed and you are well past it on 4.07, but it is the same subsystem, which is why I would start there.

On drivers, the frame is captured on the machine you are controlling, so it is the Latitude's Intel graphics driver that matters here and not the RTX 5080. Worth checking whether that laptop is still on Dell's OEM display driver rather than Intel's current one for that part.

On versions, 4.08 shipped but the only thing in it is a KVM memory leak fix on long-running connections, so it will not touch this. There is a 4.2 beta with more KVM display work in it, but the display fixes named there are an AMD contrast problem on Windows Insider builds and HDR clipping. Neither matches your hardware, so I would not move to a beta expecting this to clear up.

If the encoding toggle changes nothing, the detail that would actually help is whether the artifacts show up on a completely static remote desktop, or only after something on the Latitude moves or redraws. That splits the problem in half.

@Haalee, thanks for that. I may have a comprehension disability here, but in version 4.07 I can’t seem to find anything close to Advanced KVM Settings or Force video encoding mode (quality will be lower for text).

I’m not saying it isn’t there; I’m just not finding it. Then again, I usually can’t find the mustard in the fridge when it’s sitting right in front of me.

Just to establish a baseline: the Latitude’s local display does not show any artifacts at all. The artifacts only appear when I connect to the Latitude from the primary PC through Multiplicity KVM, so while using KVM with the virtual desktop.

If you can point me toward where that encoding setting moved in 4.07, I’ll toggle it, fully disconnect/reconnect the KVM session, and test again.

Not a comprehension problem. The gear is not in the main Multiplicity settings window, it sits on the configuration screen for one specific KVM connection.

On the Primary, open the KVM tab and double-click the Latitude's entry in the connections list, or select it and click Edit. That opens the per-connection config with the passcode, display name and KVM mode display fields on it. The gear on that screen is Advanced KVM settings.

Advanced only ever held the one option in what we have written down. If the gear panel on 4.07 shows you something different, tell me what is in it and I will stop sending you after a setting that moved.

One trap worth knowing while you are in there. The stretch-to-fit option in the general KVM settings sets a default for new connections only, and it will not override a preference recorded during your last successful connection to that machine. Change things on the connection itself rather than on the defaults, otherwise it looks like nothing happened.

Your baseline is the useful part of that post. Latitude's own display clean, artifacts only through KVM, puts this in the capture and encode path rather than in its graphics output.

I've tried a few option on the Primary PC, no change.

And here is where I arrived following your directions - I think the setting you recall has moved. 

You are right, it moved and it changed shape. What was one checkbox is now a three way selector in that panel: Low, Standard and High compression. You are sitting on Standard, which is the recommended one, so there was nothing there for you to switch on and nothing you missed.

Worth knowing what that rules out. The corruption bug this subsystem has actually had was in low compression mode, fixed back in 4.0.0.4. Low also wants a 2.5GbE link, which that panel says itself. You are not on it, so do not spend a test going there.

The thing in your screenshot you have not moved is at the bottom of it. Global KVM display scaling, set to 75% of original size. That puts a scaling stage in between the frame being captured on the Latitude and it being drawn on your screen.

You can test that without touching settings at all. In a live KVM session bring the toolbar up and use the 1:1 toggle, which swaps between 1:1 and stretch or shrink to fit. If the streaking stops in 1:1, this lives in the scaling path rather than the encoder. If it looks identical both ways, scaling is out and we are back to encode.

One caveat so the result means something. 1:1 only gives you full detail when the Latitude's resolution is lower than your local one. If it is higher you will be panning around a larger desktop, which is awkward, but it still answers the question.

Haalee - I appreciate the continued troubleshooting.

On the scaling side, I’ve actually done quite a bit of poking around already trying to shake something loose. I originally had the display at 125%, then tested at 100%, and as you can see in the screenshot, I’ve even gone down to 75%.

I’ve also toggled between 1:1 and stretch/shrink-to-fit during the KVM sessions. I’ve actually gone so far as to restart each Multiplicity instance between changes, just to make sure I wasn’t testing against a setting or session that hadn’t fully refreshed. Unfortunately, the artifacting has persisted through all of those combinations.

I don’t want that to come across as “already tried it, next,” because I genuinely appreciate you continuing to troubleshoot this with me. I just feel like I’ve done a pretty substantial amount of poking around at this point without finding a setting that changes the behavior.

The thing that keeps sticking with me is that I didn’t have this problem back around 2024 with essentially the same setup. That makes me wonder if something changed along the way with a Multiplicity update, Windows/graphics update, or how KVM is now handling the display.

Would be nice if an engineer would hop on or reach out

You ruled scaling out properly, restarts between changes included, so it is off the table rather than merely untested. Three resolutions and both 1:1 and shrink-to-fit is more than most people do before reporting.

The 2024 detail is the most useful thing in your post, and it may not be the setup that changed. Multiplicity 4.0 went out on 8 October 2024. If your clean stretch was before roughly then, you were on 3.x, and the 3.x KVM display path is not the one you are running now.

The changes there were not cosmetic. Across 4.0 and 4.01 the KVM display side got performance and memory work, reduced idle bandwidth, a fix for an initial connection crash, and the compression corruption fix in 4.0.0.4. Your Latitude is being captured and encoded by different code than it was in 2024.

So the thing worth pinning down is which version you were on when it was clean, and roughly when you came off it. If that lands either side of October 2024, this stops being a settings hunt and becomes a regression with a date on it.

Two questions from earlier are still open, and both move this further than scaling did.

Does the corruption show up on a completely static remote desktop, left alone a minute with nothing redrawing, or only once something on the Latitude moves? That splits capture from encode.

Is the Latitude on Dell's OEM Intel display driver or on Intel's own current one for that part? The frame is captured on the Latitude, so that driver sits in the path and the 5080 does not.

On getting an engineer onto it, I am not going to promise you one. What I can tell you is what makes a thread like this get picked up: a version boundary, a clean baseline, and the static versus motion answer. You already have the middle one.