Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

jstamerj
Copy link

@jstamerj jstamerj commented Jan 29, 2022

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:
#94
#273
#1363
#1405
#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)

@jstamerj jstamerj changed the title Jstamerj/win high dpi fix Fix issues on windows with high DPI monitors (scaling set higher than 100%) Jan 29, 2022
@eugenegff
Copy link

eugenegff commented Feb 8, 2022

I have the same issue with 4K monitor with 150% scale on Barrier server PC - mouse cursor work on left 2/3 of screen width, and disappear when moved to right 1/3.

I can confirm that marking Barrier binaries as "DPI aware" fixes situation - I did it by modifying RT_MANIFEST directly inside the binaries using Visual Studio as editor. Not sure which exactly binary from barrier.exe, barrierd.exe, barriers.exe need such modification, I did it for all three of them.

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0' xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

@Taknok
Copy link

Taknok commented Feb 10, 2022

Probably, already done in this commit (8 jan): 00a57ea

@ghost
Copy link

ghost commented Sep 20, 2022

Any updates on this being merged with the main branch? Seems like it should be as I still have the issue persisting with 2.4

@Tahiaji
Copy link

Tahiaji commented Nov 16, 2022

For a long time, I could not understand why the connection works in one direction, but not in the other. Well, yes, if you change it to 100%, it starts working. But alas, it's too small :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants