github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 22:01:23 -06:00

[GH-ISSUE #58] Linux client pauses #47

New issue

Closed

opened 2026-05-05 04:51:43 -06:00 by gitea-mirror · 10 comments

gitea-mirror commented

2026-05-05 04:51:43 -06:00

Owner

Originally created by @Bryce-Dixon on GitHub (Jun 10, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/58

Operating Systems

Server: Windows 10 build 1803

Client: Linux Mint 18.3 Cinnamon

Barrier Version

2.1.0-RELEASE

Steps to reproduce bug

Run the server on Windows
Connect with a client on Linux
Moving the mouse from Windows to Linux works, but if the mouse stops moving, it won't move for a few seconds when on the client. The same occurs with the keyboard (there's a noticeable delay when beginning to type)

This does not occur when Linux is hosting the server and Windows connects as the client.

Originally created by @Bryce-Dixon on GitHub (Jun 10, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/58 ### Operating Systems ### Server: Windows 10 build 1803 Client: Linux Mint 18.3 Cinnamon ### Barrier Version ### 2.1.0-RELEASE ### Steps to reproduce bug ### 1. Run the server on Windows 2. Connect with a client on Linux 3. Moving the mouse from Windows to Linux works, but if the mouse stops moving, it won't move for a few seconds when on the client. The same occurs with the keyboard (there's a noticeable delay when beginning to type) This does not occur when Linux is hosting the server and Windows connects as the client.

gitea-mirror

2026-05-05 04:51:43 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 04:51:49 -06:00

Author

Owner

@walker0643 commented on GitHub (Sep 8, 2018):

I have a Win10/arch setup here but I can't reproduce your issue. Can you provide anything that might help me bring out the bug? Can anyone else confirm similar behavior?

@walker0643 commented on GitHub (Sep 8, 2018): I have a Win10/arch setup here but I can't reproduce your issue. Can you provide anything that might help me bring out the bug? Can anyone else confirm similar behavior?

gitea-mirror commented

2026-05-05 04:51:52 -06:00

Author

Owner

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

I know this is late, but I just had a similar issue, except instead of pausing for a few seconds it was only like a half second. If I moved the mouse continuously it seemed fine, but if I paused, then the first time I moved the mouse or typed there'd be a noticeable, annoying lag. (Also Windows server, Linux Client)

For me it turned out to be because my Linux Client was on wifi; using ethernet gave me super smooth performance. So for anyone else having issues I'd consider looking at your network setup.

@AngelJA commented on GitHub (Dec 9, 2018): I know this is late, but I just had a similar issue, except instead of pausing for a few seconds it was only like a half second. If I moved the mouse continuously it seemed fine, but if I paused, then the first time I moved the mouse or typed there'd be a noticeable, annoying lag. (Also Windows server, Linux Client) For me it turned out to be because my Linux Client was on wifi; using ethernet gave me super smooth performance. So for anyone else having issues I'd consider looking at your network setup.

gitea-mirror commented

2026-05-05 04:51:54 -06:00

Author

Owner

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

Followup to my last post: I did a bit more research and found that the reason ethernet was so much better was because wifi powersave was on. I won't list the steps to fix that since it may vary, but you should be able to google it. :)

@AngelJA commented on GitHub (Dec 9, 2018): Followup to my last post: I did a bit more research and found that the reason ethernet was so much better was because wifi powersave was on. I won't list the steps to fix that since it may vary, but you should be able to google it. :)

gitea-mirror commented

2026-05-05 04:51:56 -06:00

Author

Owner

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

Can this issue be closed?

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

gitea-mirror commented

2026-05-05 04:51:58 -06:00

Author

Owner

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

I think barrier could issue a warning when excessive network latency is present. At least users would know that it's something on their side instead of thinking that the software is crap.

@p12tic commented on GitHub (Dec 13, 2018): I think barrier could issue a warning when excessive network latency is present. At least users would know that it's something on their side instead of thinking that the software is crap.

gitea-mirror commented

2026-05-05 04:52:00 -06:00

Author

Owner

@mirh commented on GitHub (Sep 14, 2019):

At least users would know that it's something on their side instead of thinking that the software is crap.

This, a hundred times.

Though, couldn't barrier also took care of handling powersave? It would be much more user-friendly, and it could even allow still some nice power saving (e.g. if the mouse is on the host, no need to keep it disabled)
I know wifi.powersave should be an actual hook for snaps then..
but NM can only set them via cfgs, and the kernel dropped long ago the api specifically crafted for that..
So, I think the only option would be calling iw? With some caveats.

@mirh commented on GitHub (Sep 14, 2019): > At least users would know that it's something on their side instead of thinking that the software is crap. This, a hundred times. Though, couldn't barrier also took care of handling powersave? It would be much more user-friendly, and it could even allow still some nice power saving (e.g. if the mouse is on the host, no need to keep it disabled) I know `wifi.powersave` should be an actual hook for [snaps](https://ubuntu.com/core/docs/networkmanager/snap-configuration/wifi-powersave) then.. but NM can only set [them](https://bugzilla.gnome.org/show_bug.cgi?id=739084) via cfgs, and the kernel dropped [long ago](https://patchwork.kernel.org/patch/7396631/) the api specifically crafted for that.. So, I think the only option would be calling iw? With some [caveats](https://www.ctrl.blog/entry/linux-wifi-dpm-latency.html).

gitea-mirror commented

2026-05-05 04:52:02 -06:00

Author

Owner

@Jieiku commented on GitHub (Apr 6, 2020):

In my Case I am running Windows 8.1 in QEMU KVM with GPU passthrough for gaming, its the only thing the windows VM gets used for.

Windows 8.1 is the Server and Linux is the client. My linux client occasionally hangs/pauses for what seems to be about 5 seconds. This only happens occasionally.

I would not think latency could be the issue when it happens on the same machine between the VM and Host.

Is there any way for me to debug what might be causing this? It only occurs when I have the input moved over to the linux client.

I notice it often if I am opening a right click menu of the mouse, but that's not the only time, its just one of the times I seem to notice it happen the most. During this time I can use the secondary mouse or keyboard that are connected directly to Linux, its just the ones being used through Barrier that appear to freeze/lock up.

Also sometimes I type things On the linux client, and the freeze up will happen, after a few seconds when it goes back to working the things that I was trying to type will finally show up, as if there was a massive delay but it still received the characters I was trying to type.

I have been dealing with this for about the last 8 months, and every time I silently grumble and just deal with it, but i have been using windows more lately.

@Jieiku commented on GitHub (Apr 6, 2020): In my Case I am running Windows 8.1 in QEMU KVM with GPU passthrough for gaming, its the only thing the windows VM gets used for. Windows 8.1 is the Server and Linux is the client. My linux client occasionally hangs/pauses for what seems to be about 5 seconds. This only happens occasionally. I would not think latency could be the issue when it happens on the same machine between the VM and Host. Is there any way for me to debug what might be causing this? It only occurs when I have the input moved over to the linux client. I notice it often if I am opening a right click menu of the mouse, but that's not the only time, its just one of the times I seem to notice it happen the most. During this time I can use the secondary mouse or keyboard that are connected directly to Linux, its just the ones being used through Barrier that appear to freeze/lock up. Also sometimes I type things On the linux client, and the freeze up will happen, after a few seconds when it goes back to working the things that I was trying to type will finally show up, as if there was a massive delay but it still received the characters I was trying to type. I have been dealing with this for about the last 8 months, and every time I silently grumble and just deal with it, but i have been using windows more lately.

gitea-mirror commented

2026-05-05 04:52:03 -06:00

Author

Owner

@axtux commented on GitHub (May 19, 2020):

May be related to #617

@axtux commented on GitHub (May 19, 2020): May be related to #617

gitea-mirror commented

2026-05-05 04:52:06 -06:00

Author

Owner

@Jieiku commented on GitHub (May 19, 2020):

I ended up opening my own issue: https://github.com/debauchee/barrier/issues/645

I had issues with barrier the entire time I was using it which was under ubuntu 18.04.
Once I did a clean install of Ubuntu 20.04 and a clean install of my windows 8.1 vm, the issue was magically gone so I closed the issue I had open.

I suspect the issue was somehow with Ubuntu 18.04 because I used the exact same install media for the windows VM, and all it gets is a few games installed.

@Jieiku commented on GitHub (May 19, 2020): I ended up opening my own issue: https://github.com/debauchee/barrier/issues/645 I had issues with barrier the entire time I was using it which was under ubuntu 18.04. Once I did a clean install of Ubuntu 20.04 and a clean install of my windows 8.1 vm, the issue was magically gone so I closed the issue I had open. I suspect the issue was somehow with Ubuntu 18.04 because I used the exact same install media for the windows VM, and all it gets is a few games installed.

gitea-mirror commented

2026-05-05 04:52:08 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

This has been fixed in #679.

@p12tic commented on GitHub (Jan 10, 2021): This has been fixed in #679.