github-starred/barrier

Fork 0

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

[GH-ISSUE #836] Barrier can't automatically switch to avaiable screen when another machine shutdown #666

New issue

Open

opened 2026-05-05 06:52:15 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 06:52:15 -06:00

Owner

Originally created by @stardiviner on GitHub (Aug 16, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/836

Operating Systems

Server: Manjaro Linux (using 5.6.4 kernel)

Client: Windows 10, 1905

Barrier Version

2.3.2

Steps to reproduce bug

Barrier connection is fine. This is great, thanks for this project!!

When I move cursor to the client screen (Win10 machine), then shutdown the Win10 machine, the server screen (Manjaro Linux machine) does not auto re-get focus, I can't move cursor, can't get focus again automatically after the Win10 machine shutdown. I hope the barrier can detect whether client is available, if not available, auto switch back to server machine.

Other info

When did the problem start to occur? When I...
Is there a way to work around it? No
Does this bug prevent you from using Barrier entirely? No

Originally created by @stardiviner on GitHub (Aug 16, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/836 ### Operating Systems ### Server: Manjaro Linux (using 5.6.4 kernel) Client: Windows 10, 1905 ### Barrier Version ### 2.3.2 ### Steps to reproduce bug ### Barrier connection is fine. This is great, thanks for this project!! When I move cursor to the client screen (Win10 machine), then shutdown the Win10 machine, the server screen (Manjaro Linux machine) does not auto re-get focus, I can't move cursor, can't get focus again automatically after the Win10 machine shutdown. I hope the barrier can detect whether client is available, if not available, auto switch back to server machine. ### Other info ### * When did the problem start to occur? When I... * Is there a way to work around it? No * Does this bug prevent you from using Barrier entirely? No

gitea-mirror commented

2026-05-05 06:52:19 -06:00

Author

Owner

@stardiviner commented on GitHub (Nov 7, 2020):

Any update on this issue?
I think Barrier can add an condition detect whether a client machine is still avavilable. If not, put mouse point back to server screen. Currently barrier can get mouse point back if the client shutdown, the mouse point vanished too.

@stardiviner commented on GitHub (Nov 7, 2020): Any update on this issue? I think Barrier can add an condition detect whether a client machine is still avavilable. If not, put mouse point back to server screen. Currently barrier can get mouse point back if the client shutdown, the mouse point vanished too.

gitea-mirror commented

2026-05-05 06:52:21 -06:00

Author

Owner

@Deelight-fr commented on GitHub (Jan 11, 2021):

I'm having the exact same problem, but as my Win10 client is a virtual machine (with a dedicated GPU), I found two workarounds:

Shutting down the Win10 Barrier client and initiating VM shutdown from the host (Ubuntu 20), or
Disconnecting the VM screen and initiating VM shutdown from the host

These workarounds are very specific to my unusual setup, so I guess they won't help much.

@Deelight-fr commented on GitHub (Jan 11, 2021): I'm having the exact same problem, but as my Win10 client is a virtual machine (with a dedicated GPU), I found two workarounds: - Shutting down the Win10 Barrier client and initiating VM shutdown from the host (Ubuntu 20), or - Disconnecting the VM screen and initiating VM shutdown from the host These workarounds are very specific to my unusual setup, so I guess they won't help much.

gitea-mirror commented

2026-05-05 06:52:24 -06:00

Author

Owner

@Thomas131 commented on GitHub (Feb 7, 2021):

Same problem, pretty disrupting ...

My workaround for Linux:
Switch to tty1 which still works (Ctrl+Alt+F1) -> log in -> killall -9 barriers -> Switch back (eg. Ctrl+Alt+F7) -> restart barrier when I need it again

@Thomas131 commented on GitHub (Feb 7, 2021): Same problem, pretty disrupting ... My workaround for Linux: Switch to tty1 which still works (Ctrl+Alt+F1) -> log in -> killall -9 barriers -> Switch back (eg. Ctrl+Alt+F7) -> restart barrier when I need it again

gitea-mirror commented

2026-05-05 06:52:26 -06:00

Author

Owner

@FabienZa commented on GitHub (Jun 10, 2022):

+1 Same problem, thanks for your sharing @Thomas131 !

@FabienZa commented on GitHub (Jun 10, 2022): +1 Same problem, thanks for your sharing @Thomas131 !

gitea-mirror commented

2026-05-05 06:52:28 -06:00

Author

Owner

@Thomas131 commented on GitHub (Jun 10, 2022):

Puh, I don't have this problem anymore ... Do you have the newest barrier versions? I think a update once fixed a lot of problems for me. Which Operating Systems (Server&Client)?

@Thomas131 commented on GitHub (Jun 10, 2022): Puh, I don't have this problem anymore ... Do you have the newest barrier versions? I think a update once fixed a lot of problems for me. Which Operating Systems (Server&Client)?

gitea-mirror commented

2026-05-05 06:52:29 -06:00

Author

Owner

@FabienZa commented on GitHub (Jun 10, 2022):

Damn... I have this configuration :
Server : Version 2.3.2 on Ubuntu 20.04.4
Client : Version 2.4.0 on Windows 10.0.19044

I will try to update the server to 2.4.0 !

@FabienZa commented on GitHub (Jun 10, 2022): Damn... I have this configuration : Server : Version 2.3.2 on Ubuntu 20.04.4 Client : Version 2.4.0 on Windows 10.0.19044 I will try to update the server to 2.4.0 !

No labels

Rows
Columns