You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue has been migrated from old Barrier Github repository debauchee/barrier#194
Issue created on: 2018-12-09 by @egomolka
Issue last updated on: 2021-03-18
Operating Systems
Server: Windows 10 (Version 1803 - Build 17134.407)
Client: Ubunutu-Mate 18.04 (LTS)
Linux version 4.15.0-42-generic
Barrier Version
On Windows server - 2.1.0-Release-0b2dfd80 (downloaded installer)
On Linux client - 2.2.0-snapshot-14a7ca08 (built locally)
Steps to reproduce bug
My problem arose when I went from using HDMI cables on both my client and server machines, to using a DisplayPort cable with a new 4K monitor that I bought for my server machine.
Connect server machine monitor with a DisplayPort cable
Connect client machine monitor with an HDMI cable (no DisplayPort connection available on my client machine).
Power up the two machines.
Start Barrier on the server
Start Barrier on the client
Move the mouse from the server screen to the client screen, It appears to pop up on the client screen for a split second, but then disappears, never to be seen again on either monitor.
Recover by shutting down Barrier on the client machine, at which point the mouse reappears on the server machine's monitor.
Other info
My workaround is to stick to HDMI on both machines, so this is not an urgent thing, but I would love to be able to use DisplayPort on my new 4K monitor.
Thanks for providing a great piece of software. I have been happily using it for a couple of months now for 10+ hours a day, with remarkably few issues.
I can confirm this issue, with Windows 10 acting as a server with a 4K monitor connected via DisplayPort, and Arch Linux running as a client on a laptop with a small 1366x768 screen.
I can get it working if I change the server's scale factor to 100% - normally I use it in 150% mode - this of course makes things look too small on my Windows desktop, so as an alternative, setting it to 1080p/100% scaling is another option.
Therefore, I think this is a problem with Windows 10's DPI scaling rather than a monitor cable issue.
I experimented with changing compatibility settings for barrier.exe, and barriers.exe to force DPI modes, but this didn't work for me.
However, exporting my config to a file and writing the following batch file to start barriers.exe directly with a compatibility environment variable set does allow it to work albeit with some occasional minor glitching as the mouse crosses screens:
set __COMPAT_LAYER=HIGHDPIAWARE
@echo off
"C:\Program Files\Barrier\barriers.exe" --enable-crypto -c config.sgc
I think it's a case of seeing what's new in Windows 10 DPI scaling APIs and fixing Barrier so that it's aware somehow. Hope this helps with the debugging!
Thanks @dwhinham, that was helpful! I was able to get this working by running it normally as a service (without the batch file) with compatibility settings: barriers.exe Properties > Compatibility > Change settings for all users > Change high DPI settings > Check 'Override high DPI scaling behavior', and set Scaling performed by: Application
In my humble opinion no, as the above are workarounds that the user should not have to worry about rather than concrete solutions.
I think the fix is to somehow bake the High DPI awareness flag into the executable, maybe with some kind of manifest? I'm not that familiar with Windows GUI programming but I am happy to take a look when I get some free time :)
I have this issue when I change my monitor to a different one. The first time I resolve this issue is by completely reset windows to start fresh.
Then I change to a different monitor the following day and the issue come back. Interestingly, if I put the client to different side (originally right, then put it to left) it would work.
At the end, I use AngelJA's solution and it works again.
Glad that I found this issue!
I am using version 2.3.3 but still have this problem.
The text was updated successfully, but these errors were encountered:
Operating Systems
Server: Windows 10 (Version 1803 - Build 17134.407)
Client: Ubunutu-Mate 18.04 (LTS)
Linux version 4.15.0-42-generic
Barrier Version
On Windows server - 2.1.0-Release-0b2dfd80 (downloaded installer)
On Linux client - 2.2.0-snapshot-14a7ca08 (built locally)
Steps to reproduce bug
My problem arose when I went from using HDMI cables on both my client and server machines, to using a DisplayPort cable with a new 4K monitor that I bought for my server machine.
Other info
My workaround is to stick to HDMI on both machines, so this is not an urgent thing, but I would love to be able to use DisplayPort on my new 4K monitor.
Thanks for providing a great piece of software. I have been happily using it for a couple of months now for 10+ hours a day, with remarkably few issues.
I can confirm this issue, with Windows 10 acting as a server with a 4K monitor connected via DisplayPort, and Arch Linux running as a client on a laptop with a small 1366x768 screen.
I can get it working if I change the server's scale factor to 100% - normally I use it in 150% mode - this of course makes things look too small on my Windows desktop, so as an alternative, setting it to 1080p/100% scaling is another option.
Therefore, I think this is a problem with Windows 10's DPI scaling rather than a monitor cable issue.
I found these issues on Synergy's issues tracker:
deskflow/deskflow#4041
deskflow/deskflow#6070
I experimented with changing compatibility settings for
barrier.exe
, andbarriers.exe
to force DPI modes, but this didn't work for me.However, exporting my config to a file and writing the following batch file to start
barriers.exe
directly with a compatibility environment variable set does allow it to work albeit with some occasional minor glitching as the mouse crosses screens:I think it's a case of seeing what's new in Windows 10 DPI scaling APIs and fixing Barrier so that it's aware somehow. Hope this helps with the debugging!
Thanks @dwhinham, that was helpful! I was able to get this working by running it normally as a service (without the batch file) with compatibility settings: barriers.exe Properties > Compatibility > Change settings for all users > Change high DPI settings > Check 'Override high DPI scaling behavior', and set Scaling performed by: Application
Is this issue solved? Can it be closed?
In my humble opinion no, as the above are workarounds that the user should not have to worry about rather than concrete solutions.
I think the fix is to somehow bake the High DPI awareness flag into the executable, maybe with some kind of manifest? I'm not that familiar with Windows GUI programming but I am happy to take a look when I get some free time :)
That'd be very appreciated.
I have this issue when I change my monitor to a different one. The first time I resolve this issue is by completely reset windows to start fresh.
Then I change to a different monitor the following day and the issue come back. Interestingly, if I put the client to different side (originally right, then put it to left) it would work.
At the end, I use AngelJA's solution and it works again.
Glad that I found this issue!
I am using version 2.3.3 but still have this problem.
The text was updated successfully, but these errors were encountered: