mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #775] Large windows clipboard entries cause barrier to lock up on screen change #612
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#612
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eldorel on GitHub (Jun 28, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/775
Operating Systems
Server: Windows 8.1 Pro
Client1: Windows 8.1 Pro
Client2: Windows 10 Pro
Client3: Windows 10 Home
Barrier Version
2.3.2-Snapshot-210c2b70
Steps to reproduce bug
Result:
Barrier stops passing mouse and keyboard input to any device and requires killing barriers.exe to restore input. Changing screens via hotkey is also disabled.
Other info
When did the problem start to occur? As far as I know, it's been present since the first time I installed barrier.
Is there a way to work around it? Disable clipboard sharing.
Does this bug prevent you from using Barrier entirely? No
Put anything else you can think of here.
Notes:
I have 3x 4k displays, with 2 in portrait mode.
This means that my desktop screenshots from Printscreen are large enough to trigger this bug...
I have not (yet) tested to see if this occurs with other types of files/data, as I'm on-call and can't risk not being able to use the computer if the phone rings.
@natesubra commented on GitHub (Jun 29, 2020):
I've encountered this as well. I didn't realize that it was related to size. I have 2x 3440x1440 and 2x 1080p displays and accidently hitting print screen would cause the the issue (using sharex which dumps the screenshot to a jpg and loads it into the clipboard).
Bug aside, it would be nice if there was a way to control what types of content barrier tried to share. Being able to limit barrier to text only clipboard sharing etc.
@clort81 commented on GitHub (Jul 22, 2020):
Clipboards were originally designed for text. Then some 'genius' decided they should be abused for all kinds of object data.
if your clipboard contains multi-megabytes of data, it's going to take some time to send it to an adjacent computer on screen change.
My problem with clipboard enabled occurs even with small clipboard data (text only) or an empty clipboard. Right now the only solution for me is to disable clipboard sharing.
There's something weird happening with linux and clipboard. Sometimes it works without delay, sometimes not. Sometiems it even takes me a couple of seconds to paste a small url.
@github-actions[bot] commented on GitHub (Sep 21, 2020):
This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.
@eldorel commented on GitHub (Sep 21, 2020):
So, this is still an issue.
But since the bot wants to close the ticket, I get to make a useless comment here.
@eldorel commented on GitHub (Sep 21, 2020):
As an additional note: the wiki refers to a config option "clipboardSharingSize" that is apparently not implemented in barrier.
That feature would probably provide a reasonable work around to this issue, but it's apparently not in this fork.
https://github.com/debauchee/barrier/wiki/Command-Line#text_config
@eldorel commented on GitHub (Oct 9, 2020):
@p12tic Is there a particular reason why the bot is automatically closing issues without them ever being reviewed, even after people are updating them to add more detail and confirm that it's still a problem?
@p12tic commented on GitHub (Jan 10, 2021):
@eldorel This is bad bot, I've spent whole evening reviewing closed issues and reopening issues which were closed by error.
@wznazir commented on GitHub (Feb 4, 2021):
I have the same problem with clipboard sharing enabled. \
I noticed if you move the cursor from the server (Windows 10) to the client (Xubuntu in my case) very slowly it works 100% of the time, but when the cursor is moved faster then the problem occurs.
The faster the cursor the more likely it goes back and forth between the 2 screens and get
DEBUG: dropped bogus delta motion:on the server@thibaut2hd commented on GitHub (Aug 24, 2021):
Same issue here between two Macs (Intel server and M1 client).
I understand that copying large non-textual content between machines takes time.
Maybe there could be a setting that triggers this copying over the network only when a pasting action is triggered on the remote client? This way we could avoid locking the mouse whenever we enter a new screen and still allow large clipboard objects to be shared?
But this is probably more complicated than I imagine it...
@vinnymac commented on GitHub (Aug 24, 2021):
I have this issue. Curious if we could just have a user-defined limit for how much data we want to transfer between systems. For example, under no circumstance am I interested in triggering this, if the data is great than say 100 KBs.
With a configuration, I imagine users will also find what works best for their setup, and be able to tweak it until it isn't annoying to use. The default could even be infinite, so that the current behavior doesn't change.
Additionally, it would be nice if their was a way to easily cancel the copy operation that occurs with a keyboard shortcut. Does such a thing exist?
Sometimes when moving between systems I find that the prompt that a data transfer is happening comes up on the screen. Then my mouse disappears, and I am unable to stop it from sitting their and transferring a huge amount of data that won't be used. Seems less than ideal from a user experience perspective.
@thibaut2hd commented on GitHub (Aug 25, 2021):
As @eldorel mentioned above, that settings exists but is somehow not implemented:
clipboardSharingSize sets a limit of N Kb of data when clipboard sharing is enabled
@xfinityandbeyond commented on GitHub (Sep 9, 2021):
I can confirm that this issue occurs with a Linux server and Windows client. Trying to move from the Linux host machine to a Windows client while there's a 4K screenshot on the clipboard locks up Barrier on the host and all I can do is switch TTY and login and kill barrier.