Some apps do not scale correctly when reconnecting with different display scaling

mike__a — Thu, 19 Oct 2023 02:05:11 GMT

I use to connect to Windows 10 VDI from two computers in full screen mode. Both have the same updated Horizon clients (8.10.0 for now).

1. Linux Mint, display 1920x1200 (16:10) scaling 100%

2. Windows 11, display 2560x1600 (16:10) scaling 200%

When connecting for the first time after VDI reset and reconnecting from the same computer everything is just fine.

The problem is when reconnecting from different computer. Say we

Reset desktop
Connect from Linux with 100% scaling
Disconnect without logging off
Connect from Windows with 200% scaling

Than almost all apps like Firefox, Google Chrome, MS Teams look normal. But some apps have extra small font in menus.

Winaero Tweaker showed that Windows registry system font size values became two times smaller. When connecting from Linux with 100% host display scaling it was 10 but after reconnecting from Windows with 200% host display scaling it became 5.

It is also strange that in both connections display scaling of VDI desktop itself is 200% and read only. Admins say they did not block this parameter. So I think it is set by VDI client itself. E.g. switching to 640x480 windowed mode changes VDI desktop scaling to 100%

It seams that at reconnect VDI client tries to adjust system font size according to new and previous VDI and client host display scaling.

So I think the problem is VDI display scaling does not match client host display scaling than connecting from Linux computer. Am I right? And if so, is there a way to make them match each other?

VMware App Volumes file name too long error

mike__a — Wed, 27 Apr 2022 09:39:29 GMT

Hi.

I use git with a custom precommit tool in Windows 10 VDI. Local git root is located in user profile. On some repos precommit tool fails with System.IO.PathTooLongException. I noticed that file names processed by precommit tool contain \SnapVolumesTemp\MountPoints\{<GUID>}\{<GUID>}\SVROOT in between C: and \Userprofile. This is obviously too long.

Since the tool is opensource I made it to extract that long App Volume part before file IO operations and it made the trick.

Now the question is, will IO to C:\SnapVolumesTemp\MountPoints\{<GUID>}\{<GUID>}\SVROOT\Users\username\file.txt have the same effect as to C:\Users\username\file.txt? Or maybe there is a better way to prevent this path too long exception?

mike__a Tracker

Some apps do not scale correctly when reconnecting with different display scaling

VMware App Volumes file name too long error