[GH-ISSUE #698] windows screen scaling causes dead spots where cursor cannot reach

gitea-mirror commented

2026-05-05 06:40:10 -06:00

Owner

Originally created by @coke on GitHub (May 27, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/698

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.

Originally created by @coke on GitHub (May 27, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/698 ### 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.

gitea-mirror commented

2026-05-05 06:40:15 -06:00

Author

Owner

@coke commented on GitHub (May 27, 2020):

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

@coke commented on GitHub (May 27, 2020): 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

gitea-mirror commented

2026-05-05 06:40:19 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 21, 2020):

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.

@github-actions[bot] commented on GitHub (Sep 21, 2020): 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.

gitea-mirror commented

2026-05-05 06:40:22 -06:00

Author

Owner

@coke commented on GitHub (Sep 21, 2020):

This is still an issue.

@coke commented on GitHub (Sep 21, 2020): This is still an issue.

gitea-mirror commented

2026-05-05 06:40:23 -06:00

Author

Owner

@coke commented on GitHub (Sep 29, 2020):

??

@coke commented on GitHub (Sep 29, 2020): ??

gitea-mirror commented

2026-05-05 06:40:25 -06:00

Author

Owner

@karalaine commented on GitHub (Oct 21, 2020):

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.

@karalaine commented on GitHub (Oct 21, 2020): 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.

gitea-mirror commented

2026-05-05 06:40:27 -06:00

Author

Owner

@JDuchniewicz commented on GitHub (Dec 2, 2021):

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.

@JDuchniewicz commented on GitHub (Dec 2, 2021): 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.

gitea-mirror commented

2026-05-05 06:40:30 -06:00

Author

Owner

@alatas commented on GitHub (Feb 15, 2022):

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:

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.
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 )

@alatas commented on GitHub (Feb 15, 2022): 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](https://github.com/debauchee/barrier/commit/00a57ea972e106a21af6ea5b849e21013685a0e5) 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`](https://raw.githubusercontent.com/debauchee/barrier/master/src/cmd/barrierc/barrierc.exe.manifest), [for `barriers`](https://raw.githubusercontent.com/debauchee/barrier/master/src/cmd/barriers/barriers.exe.manifest)) next to the correct executables (to folder `C:\Program Files\Barrier`). Then [change a registry key](https://stackoverflow.com/a/18905977) 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. 1. 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.](https://dev.azure.com/debauchee/Barrier/_build/results?buildId=770&view=artifacts&pathAsName=false&type=publishedArtifacts) 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](http://msdn.microsoft.com/en-us/library/ms633543%28VS.85%29.aspx) [2](https://stackoverflow.com/questions/2630392/getsystemmetrics-returns-wrong-value-for-sm-cxscreen) [3](https://docs.microsoft.com/en-us/windows/win32/direct2d/how-to--size-a-window-properly-for-high-dpi-displays) [4](https://stackoverflow.com/questions/52373528/how-to-use-my-own-manifest-file-and-embed-it-into-executable-using-visual-studio) )

gitea-mirror commented

2026-05-05 06:40:33 -06:00

Author

Owner

@ahoin001 commented on GitHub (Jan 10, 2023):

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

@ahoin001 commented on GitHub (Jan 10, 2023): Yeah this is a very real issue thank goodness for a temporary fix

gitea-mirror commented

2026-05-05 06:40:37 -06:00

Author

Owner

@josephtesfaye commented on GitHub (Jan 26, 2023):

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.

@josephtesfaye commented on GitHub (Jan 26, 2023): 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.

gitea-mirror commented

2026-05-05 06:40:39 -06:00

Author

Owner

@JaMinsane commented on GitHub (Jun 29, 2023):

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

@JaMinsane commented on GitHub (Jun 29, 2023): TY @josephtesfaye It works for Win10 as server & Win11 as Client

gitea-mirror commented

2026-05-05 06:40:41 -06:00

Author

Owner

@leepenkman commented on GitHub (Feb 24, 2025):

i had some powertoys related dead zone fixed by ununstalling powertoys fyi

@leepenkman commented on GitHub (Feb 24, 2025): i had some powertoys related dead zone fixed by ununstalling powertoys fyi

gitea-mirror commented

2026-05-05 06:40:43 -06:00

Author

Owner

@nbolton commented on GitHub (Feb 26, 2025):

Please try Deskflow or Input Leap as Barrier is no longer in development.

https://github.com/deskflow/deskflow
https://github.com/input-leap/input-leap

Both are compatible with Barrier client/server so you can try on one of your computers.

If this is still an issue in those projects, we would appreciate a cross-post of this issue.

@nbolton commented on GitHub (Feb 26, 2025): Please try Deskflow or Input Leap as Barrier is no longer in development. https://github.com/deskflow/deskflow https://github.com/input-leap/input-leap Both are compatible with Barrier client/server so you can try on one of your computers. If this is still an issue in those projects, we would appreciate a cross-post of this issue.

Rows
Columns

[GH-ISSUE #698] windows screen scaling causes dead spots where cursor cannot reach #555

Operating Systems

Barrier Version

Steps to reproduce bug

Other info