github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #194] Mouse disappears with DisplayPort cable on server and HDMI on client #157

New issue

Open

opened 2026-05-05 05:27:08 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 05:27:08 -06:00

Owner

Originally created by @egomolka on GitHub (Dec 9, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/194

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.

Originally created by @egomolka on GitHub (Dec 9, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/194 ### 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. 1. Connect server machine monitor with a DisplayPort cable 1. Connect client machine monitor with an HDMI cable (no DisplayPort connection available on my client machine). 1. Power up the two machines. 1. Start Barrier on the server 1. Start Barrier on the client 1. 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. 1. 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.

gitea-mirror added the

bug

label 2026-05-05 05:27:08 -06:00

gitea-mirror commented

2026-05-05 05:27:13 -06:00

Author

Owner

@dwhinham commented on GitHub (Dec 11, 2018):

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:
https://github.com/symless/synergy-core/issues/4041
https://github.com/symless/synergy-core/issues/6070

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!

@dwhinham commented on GitHub (Dec 11, 2018): 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: https://github.com/symless/synergy-core/issues/4041 https://github.com/symless/synergy-core/issues/6070 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!

gitea-mirror commented

2026-05-05 05:27:15 -06:00

Author

Owner

@AngelJA commented on GitHub (Dec 12, 2018):

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

@AngelJA commented on GitHub (Dec 12, 2018): 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

gitea-mirror commented

2026-05-05 05:27:17 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 12, 2018):

Is this issue solved? Can it be closed?

@AdrianKoshka commented on GitHub (Dec 12, 2018): Is this issue solved? Can it be closed?

gitea-mirror commented

2026-05-05 05:27:20 -06:00

Author

Owner

@dwhinham commented on GitHub (Dec 12, 2018):

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

@dwhinham commented on GitHub (Dec 12, 2018): 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 :)

gitea-mirror commented

2026-05-05 05:27:22 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 13, 2018):

That'd be very appreciated.

@AdrianKoshka commented on GitHub (Dec 13, 2018): That'd be very appreciated.

gitea-mirror commented

2026-05-05 05:27:25 -06:00

Author

Owner

@ryoplasmic commented on GitHub (Mar 18, 2021):

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.

@ryoplasmic commented on GitHub (Mar 18, 2021): 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.

gitea-mirror commented

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

Author

Owner

@kentsin commented on GitHub (Jun 25, 2022):

The server is win11 4K the client is win11 3K the mouse pointer disappear when it cross into the client after disconnect the client, it appear on the server screen again.

@kentsin commented on GitHub (Jun 25, 2022): The server is win11 4K the client is win11 3K the mouse pointer disappear when it cross into the client after disconnect the client, it appear on the server screen again.

gitea-mirror referenced this issue

2026-05-05 07:56:38 -06:00

[PR #157] [MERGED] Build full installer via clean_build.sh #1571