windows screen scaling causes dead spots where cursor cannot reach

[coke]

Operating Systems

Server:

ProductName: Mac OS X
ProductVersion: 10.15.3
BuildVersion: 19D76

Client:

Microsoft Windows [Version 10.0.18363.418]

Barrier Version

(be nice if you could cut and paste it off about window on mac)

2.1.0-RELEASE-8b69f9fe

Steps to reproduce bug

Have external monitor on windows client where the two monitors are "positioned" so they are not horizontally lined up.

Windows upper monitor (external) || Windows lower monitor (laptop builtin) | Mac Server

Move cursor from mac left onto the lower monitor. Can't move the cursor into the bottom 10% or so of the screen. Cursor works fine on leftmost monitor.

Other info

if I make the monitors level on the windows display config, no cursor issues at all.

Used to happen occasionally. After a recent windows update on client laptop, now consistent.

[coke]

And now I'm seeing a similar issue where I cannot reach the right 10% of the screen of the "lower" windows client screen; it jumps directly to the server screen - seems to be related to the "scale and layout" option of the screen - it was sent to 125%. setting it to 100% avoids the issue.

TLDR: In fact, that seems to have resolved my original issue; I can have the windows monitors at different heights and the cursor works, no dead spots.

Changed title to match

[github-actions]

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

[coke]

This is still an issue.

[coke]

??

[karalaine]

I have similar issue when my main monitor with 2560px width is set to 125% scaling and second monitor with 1920px width 100% scale. Screen size is reported in debug log as -2400,-115 4960x1555 which causes cursor never reaching the -2400 x coordinate (maximum is -1920 as it should). This seems to be since GetSystemMetrics(SM_XVIRTUALSCREEN) to report that incorrect size, no idea whats logic behind the number it returns.

[JDuchniewicz]

I can confirm the issue persists with the latest release (2.4.0). I have a Windows monitor with 2560x1440 with scaling 125% connected to Linux monitor with 1920x1080 without scaling like this:
2560x1440 <=> 1920x1080

The Windows screen config looks like this:
Main(1920x1080) <=> Secondary(2560x14440) => (Linux boundary) Main(1920x1080) <=> Secondary(2560x14440)

Depending on how I positioned my screen relative to the main windows display I achieved more or less of a dead zone in Windows. When the screens were not adjusted to be even in the Windows Display Manager, I had a deadzone below the meeting point of Windows main and Secondary, if set to be even I just have the deadzone to the far right of the Secondary screen around 1/10 of width.

[alatas]

I had the same problem between two Win 10 computers. The main reason is GetSystemMetrics() does not return the correct screen size. I made a little research about it and found out that this is related to the HighDPI awareness settings of the application. When you are using scaling, Windows needs to know whether the application has an awareness of that DPI settings or not. If the application doesn't use the HighDPI awareness settings, Windows reports the resolution as scaled-down in a ratio of scaling to make the application work as it is.

You can use an app manifest or another API call to set the DPI awareness to an application. Barrier 2.4.0 has an embedded manifest file on both barriers and barrierc. But both of these manifests don't have the correct XML tags to report DPI awareness. I saw a fix on these manifests to handle this issue but it is not released yet.

So until the release happens, we have two workarounds:

1. Download correct manifest files next to the executables and change the windows settings to prefer manifest files instead of the embedded manifest. I tested that solution and fixed the all problems related to display scaling (stuck mouse, jump next monitor in the middle of the screen, etc.). You can download these two manifest files (for barrierc, for barriers) next to the correct executables (to folder C:\Program Files\Barrier). Then change a registry key to use external manifest files instead of the embedded ones. You can see the correct screen sizes in the log when the log level is DEBUG.

2. Download pre-releases' executables from the azure pipeline and change the barrier executables, or make a new install with the pre-release installer. I didn't test this but I saw the correct manifest file embedded in the new releases. So, It will probably work. These are the latest builds artifacts. You can download them with the link right side of the lines.

Actually, this HighDPI problem caused lots of bug reports. I found so many of them. Examples: #1105, #500, #1025, #1444, #1476, #1443, #1423, #1462, #1363, #1415, #1382, #1318, #1220, #1108

(sources: 1 2 3 4 )

[ahoin001]

Yeah this is a very real issue thank goodness for a temporary fix

[josephtesfaye]

Downloading the latest build from https://dev.azure.com/debauchee/Barrier/_build?definitionId=1 helped me. You don't have to change the registry key.

[JaMinsane]

TY @josephtesfaye It works for Win10 as server & Win11 as Client