[PR #1543] Fix issues on windows with high DPI monitors (scaling set higher than 100%) #1815

New issue

Open

opened 2026-05-05 08:02:33 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 08:02:33 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/debauchee/barrier/pull/1543
Author: @jstamerj
Created: 1/29/2022
Status: 🔄 Open

Base: master ← Head: jstamerj/WinHighDPIFix

📝 Commits (6)

367beb5 Call SetProcessDPIAware
726258f Fix whitespace
5c1527c remove unnecessary calls
31acdd2 remove extra whitespace
4ee8913 add newsfragments
9b57c5b add comment to code

📊 Changes

2 files changed (+6 additions, -0 deletions)

View changed files

➕ doc/newsfragments/fix-windows-high-dpi.bugfix (+2 -0)
📝 src/lib/barrier/win32/AppUtilWindows.cpp (+4 -0)

📄 Description

When a windows monitor is scaled to > 100%, GetSystemMetrics() returns a correspondingly reduced size. But, barrier still reads/writes the mouse position in terms of raw pixels. This causes these problems:
https://github.com/debauchee/barrier/issues/94
https://github.com/debauchee/barrier/issues/273
https://github.com/debauchee/barrier/issues/1363
https://github.com/debauchee/barrier/issues/1405
https://github.com/debauchee/barrier/issues/1462

Adding a call to SetProcessDPIAware() changes the behavior of GetSystemMetrics() to return the sizes in pixels (as if all monitors were scaled at 100%). This fixes the problems above. I debugged and verified this fix on my setup (windows barrier server to the left of a linux client). I don't have the capability to try this on all possible setups, but I believe it will fix all of the above issues.

barrier/src/lib/platform/MSWindowsScreen.cpp:

 MSWindowsScreen::updateScreenShape() 
 { 
     // get shape and center 
     m_w = GetSystemMetrics(SM_CXVIRTUALSCREEN); 
     m_h = GetSystemMetrics(SM_CYVIRTUALSCREEN); 
     m_x = GetSystemMetrics(SM_XVIRTUALSCREEN); 
     m_y = GetSystemMetrics(SM_YVIRTUALSCREEN);

When windows is the server, and the mouse pointer scrolls offscreen (to a barrier client), barrier hides the mouse cursor on the server and sets the mouse position back to the center of the screen. However, because of the above mixup between scaled/unscalled pixels, the position the mouse gets set to isn't actually the center of the screen. The barrier server then sees that the mouse position is not centered and interprets this as the user moving the mouse (even when the user has not). Barrier then movies the mouse on the client and sets the mouse back to the false center on the server again. This results in an infinite loop always moving the mouse one way. The effective position gets pinned in one corner of a client screen.

Another effect of the bug is that the mouse cursor appears to jump from the server to the client prematurely (because the barrier server thought the server's screen was smaller than it actually is).

Contributor Checklist:

I have created a file in the doc/newsfragments directory IF it is a
user-visible change (and make sure to read the README.md in that directory)

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/debauchee/barrier/pull/1543 **Author:** [@jstamerj](https://github.com/jstamerj) **Created:** 1/29/2022 **Status:** 🔄 Open **Base:** `master` ← **Head:** `jstamerj/WinHighDPIFix` --- ### 📝 Commits (6) - [`367beb5`](https://github.com/debauchee/barrier/commit/367beb52cd86a56e868ff2f8d62642b1a6da4748) Call SetProcessDPIAware - [`726258f`](https://github.com/debauchee/barrier/commit/726258ff718fc1cfd4243daee7cf3ff3a3b29a38) Fix whitespace - [`5c1527c`](https://github.com/debauchee/barrier/commit/5c1527c665ca87f8c8d3172e8f91c065ee823f1b) remove unnecessary calls - [`31acdd2`](https://github.com/debauchee/barrier/commit/31acdd23fd8bfcf273460ebb6e5fce348a17cad9) remove extra whitespace - [`4ee8913`](https://github.com/debauchee/barrier/commit/4ee8913284b9b1a992a0acce020d0b9b34243de5) add newsfragments - [`9b57c5b`](https://github.com/debauchee/barrier/commit/9b57c5b227f955c529f6b6b72ad240a757addf16) add comment to code ### 📊 Changes **2 files changed** (+6 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `doc/newsfragments/fix-windows-high-dpi.bugfix` (+2 -0) 📝 `src/lib/barrier/win32/AppUtilWindows.cpp` (+4 -0) </details> ### 📄 Description When a windows monitor is scaled to > 100%, GetSystemMetrics() returns a correspondingly reduced size. But, barrier still reads/writes the mouse position in terms of raw pixels. This causes these problems: https://github.com/debauchee/barrier/issues/94 https://github.com/debauchee/barrier/issues/273 https://github.com/debauchee/barrier/issues/1363 https://github.com/debauchee/barrier/issues/1405 https://github.com/debauchee/barrier/issues/1462 Adding a call to SetProcessDPIAware() changes the behavior of GetSystemMetrics() to return the sizes in pixels (as if all monitors were scaled at 100%). This fixes the problems above. I debugged and verified this fix on my setup (windows barrier server to the left of a linux client). I don't have the capability to try this on all possible setups, but I believe it will fix all of the above issues. ``` barrier/src/lib/platform/MSWindowsScreen.cpp: MSWindowsScreen::updateScreenShape() { // get shape and center m_w = GetSystemMetrics(SM_CXVIRTUALSCREEN); m_h = GetSystemMetrics(SM_CYVIRTUALSCREEN); m_x = GetSystemMetrics(SM_XVIRTUALSCREEN); m_y = GetSystemMetrics(SM_YVIRTUALSCREEN); ``` When windows is the server, and the mouse pointer scrolls offscreen (to a barrier client), barrier hides the mouse cursor on the server and sets the mouse position back to the center of the screen. However, because of the above mixup between scaled/unscalled pixels, the position the mouse gets set to isn't actually the center of the screen. The barrier server then sees that the mouse position is not centered and interprets this as the user moving the mouse (even when the user has not). Barrier then movies the mouse on the client and sets the mouse back to the false center on the server again. This results in an infinite loop always moving the mouse one way. The effective position gets pinned in one corner of a client screen. Another effect of the bug is that the mouse cursor appears to jump from the server to the client prematurely (because the barrier server thought the server's screen was smaller than it actually is). ## Contributor Checklist: * [x] I have created a file in the `doc/newsfragments` directory *IF* it is a user-visible change (and make sure to read the `README.md` in that directory) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>