github-starred/barrier

Fork 0

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

[GH-ISSUE #888] Lockscreen temporarily disconnects Windows 10 client #707

New issue

Closed

opened 2026-05-05 06:58:32 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 06:58:32 -06:00

Owner

Originally created by @PatienceAllergy on GitHub (Sep 28, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/888

Barrier version on both: 2.3.3
Server: Ubuntu 20.04.1 LTS
Client: Windows 10 Pro Version 2004

After enabling lock screen/screensaver (manually or from automatic inactive timeout) on Windows 10, the mouse control does 2 frustrating things:

A) Switches back to Ubuntu.
B) Then gets locked in Ubuntu for about 4 seconds, despite furious bumping of the mouse pointer at the edge of screen.

As you can see from the log below, the lock screen seems to cause Barrier to disconnect for a bit. Perhaps there is a way to stop that behavior?

Simplified Log:
[18:42:19] NOTE: client "windows" has disconnected
[18:42:19] INFO: jump from "windows" to "ubuntu" at 960,540
// snip
[18:42:23] NOTE: accepted client connection
[18:42:23] NOTE: client "windows" has connected

Troubleshooting already tried:
I've tried a host of different config options, which mostly do nothing at all, good or bad. Even config that is unrelated, like hot corners, and hot-key switching seem to do nothing. So this lack of effect might indicate a solution to someone?

I have only 1 option in config enabled at the moment: "Enable Clipboard Sharing" (which works great btw).

Thanks to all the devs who make this app work. It really has been a net productivity boost, despite any issues I'm experiencing :)

Originally created by @PatienceAllergy on GitHub (Sep 28, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/888 Barrier version on both: 2.3.3 Server: Ubuntu 20.04.1 LTS Client: Windows 10 Pro Version 2004 After enabling lock screen/screensaver (manually or from automatic inactive timeout) on Windows 10, the mouse control does 2 frustrating things: A) Switches back to Ubuntu. B) Then gets locked in Ubuntu for about 4 seconds, despite furious bumping of the mouse pointer at the edge of screen. As you can see from the log below, the lock screen seems to cause Barrier to disconnect for a bit. Perhaps there is a way to stop that behavior? Simplified Log: [18:42:19] NOTE: client "windows" has disconnected [18:42:19] INFO: jump from "windows" to "ubuntu" at 960,540 // *snip* [18:42:23] NOTE: accepted client connection [18:42:23] NOTE: client "windows" has connected Troubleshooting already tried: I've tried a host of different config options, which mostly do nothing at all, good or bad. Even config that is unrelated, like hot corners, and hot-key switching seem to do nothing. So this lack of effect might indicate a solution to someone? I have only 1 option in config enabled at the moment: "Enable Clipboard Sharing" (which works great btw). Thanks to all the devs who make this app work. It really has been a net productivity boost, despite any issues I'm experiencing :)

gitea-mirror closed this issue

2026-05-05 06:58:35 -06:00

gitea-mirror commented

2026-05-05 06:58:38 -06:00

Author

Owner

@galkinvv commented on GitHub (Sep 30, 2020):

I'm using barrier/synergy for several years, and always observed such behavour on windows clients (both win7 and win10). It is reasoned by the fact that in every new "windows session context" (or something like this) a barrier client need to be relaucnhed to get control over mouse.

So it is a bit annoying, but is an expected behaviour with current design.

@galkinvv commented on GitHub (Sep 30, 2020): I'm using barrier/synergy for several years, and always observed such behavour on windows clients (both win7 and win10). It is reasoned by the fact that in every new "windows session context" (or something like this) a barrier client need to be relaucnhed to get control over mouse. So it is a bit annoying, but is an expected behaviour with current design.

gitea-mirror commented

2026-05-05 06:58:40 -06:00

Author

Owner

@PatienceAllergy commented on GitHub (Oct 1, 2020):

@galkinvv Thanks for the heads-up on the "expected behaviour" 😅

I can't help but wonder if there might be some workaround to this session context thingy tho... I'm all ears if someone has ideas I can look into. Maybe something like an ssh tunnel? So that windows doesn't need to disconnect because the pointer calls are all redirected to appear natively coming from localhost instead of a "scary" other machine on the local net lol. Hmmm... 🤷‍♀️

@PatienceAllergy commented on GitHub (Oct 1, 2020): @galkinvv Thanks for the heads-up on the "expected behaviour" :sweat_smile: I can't help but wonder if there might be some workaround to this session context thingy tho... I'm all ears if someone has ideas I can look into. Maybe something like an ssh tunnel? So that windows doesn't need to disconnect because the pointer calls are all redirected to appear natively coming from localhost instead of a "scary" other machine on the local net lol. Hmmm... :woman_shrugging:

gitea-mirror commented

2026-05-05 06:58:41 -06:00

Author

Owner

@PatienceAllergy commented on GitHub (Oct 4, 2020):

@galkinvv So, I found a solution for this issue.

On Windows 10 client:

Run Barrier as an admin
Barrier Menu > Change Settings > set "elevate" to "always"

Hope this helps someone like me 😌 This runs so well now!

@PatienceAllergy commented on GitHub (Oct 4, 2020): @galkinvv So, I found a **_solution_** for this issue. On Windows 10 client: - Run Barrier as an admin - Barrier Menu > Change Settings > set "elevate" to "always" Hope this helps someone like me :relieved: This runs so well now!

gitea-mirror commented

2026-05-05 06:58:43 -06:00

Author

Owner

@galkinvv commented on GitHub (Oct 4, 2020):

Barrier Menu > Change Settings > set "elevate" to "always"

As far as I remember after turning on this option (with synergy, on windows 7,several years ago) I ran in some another rare but critical issue that was caused by process elevation).
Unfortunately I can't remember the exact problem (maybe something with clipboard). If in current version of barrier and win10 there is no any problems with eleveate=always mode, maybe it should be the default mode.

@galkinvv commented on GitHub (Oct 4, 2020): > * Barrier Menu > Change Settings > set "elevate" to "always" As far as I remember after turning on this option (with synergy, on windows 7,several years ago) I ran in some another rare but critical issue that was caused by process elevation). Unfortunately I can't remember the exact problem (maybe something with clipboard). If in current version of barrier and win10 there is no any problems with eleveate=always mode, maybe it should be the default mode.

No labels

Rows
Columns