Cursor "sticks" to screen edge

retnikt commented 5 years ago

Operating Systems

Server: Ubuntu 1804

Client: Windows 10 1809

Barrier Version

2.2.0

Steps to reproduce bug

Move mouse cursor to edge of client screen using server mouse
"Push" against edge
Move away from edge again
Observe that it takes a while until it moves from the edge.

Video: https://youtu.be/9FAjEFUGU5M (between 0:01 and 0:05 I am slowly moving my mouse left and immediately back right again)

Other info

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

It seems to stick more if you move the cursor slower.

It only happens on one specific edge of my screen, which is a second monitor on the client. (setup diagram) the sticking occurs on the highlighted red side.

dregimbal commented 5 years ago

This happens to me with an ubuntu barrier server + a Windows Client, while I'm running VirtualBox on the Ubuntu host/server (Windows 10 VM), where VirtualBox has mouse integration enabled. Clicking on my Ubuntu desktop or using my host keys to "release" my mouse from VirtualBox seems to fix it. Configuring the server so that the barrier client is above the host/server prevents the cursor from getting stuck to the edge, but it still doesn't pass through until I've released my mouse from my VM

p12tic commented 5 years ago

I think this problem could be very hard to solve, because the VM taking the ownership of the pointer will break many assumptions made internally by Barrier.

dregimbal commented 5 years ago

I found that disabling "Auto Capture Keyboard" in VirtualBox fixes the issue :+1:

I turned logging to "DEBUG2" and captured this

[2019-07-08T09:47:38] DEBUG2: waiting to grab keyboard
    /home/user/git-repos/barrier/src/lib/platform/XWindowsScreen.cpp,1972
[2019-07-08T09:47:38] DEBUG2: grab keyboard timed out
    /home/user/git-repos/barrier/src/lib/platform/XWindowsScreen.cpp,1975
[2019-07-08T09:47:38] WARNING: can't leave screen
    /home/user/git-repos/barrier/src/lib/server/Server.cpp,483

@p12tic is there anything further I can do to help debug?

MasterJubei commented 5 years ago

I am having a similar issue, if my pen tablet touches the border of the screen to where the guest is, the cursor gets stuck at the border. Additionally if playing a game in fullscreen like a RTS, when the mouse touches the border it will interfere with keyboard inputs.

Host: Manjaro Deepin Guest: WIndows 10

ssaanncchheezz commented 5 years ago

I was just facing this problem and manage to fix it!

So I have 2 monitors one for a Windows server and one for a Mac laptop, the problem started happening after I unplugged the monitor from the laptop. The monitor was running in 1920*1080 an the laptop was 1440*900, so for some reason the resolution changed fix it, probably barrier still believes that the cursor is in a non-existent location therefore causing it to stick to the border.

revanmj commented 5 years ago

I have similar issue when Android Studio window is in focus on the server (Ubuntu)

phuein commented 4 years ago

Same issue on Win10 with server macOS. Different resolutions too, with scaling in Win10. Looks like Barrier needs to be able to track different resolutions for the cursor position?

mbach04 commented 4 years ago

I'm seeing this issue when using any Gnome environment. For example, take a single window and snap it to one half of the desktop environment. Leave the other half empty. This prevents the mouse from leaving the barrier server host. Now full size that one window (snap it to the top) and barrier can slide right into your guest.

zerovertex commented 3 years ago

I've run into this same issue when running itopia Remote Desktop Client in full screen on the "server" running Linux Mint 20. I was able to work around it to some degree by disabling clipboard sharing and setting use relative mouse movements in the server advanced options. It still happens often. The server log on Debug 2 level says the following

[2020-12-06T18:15:14] INFO: leaving screen [2020-12-06T18:15:15] WARNING: can't leave screen [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0 [2020-12-06T18:15:15] DEBUG: locked by mouse buttonID: 0

At this point I'm click the middle mouse and the Windows key.

The client says NOTE: server is dead. Looks like it reconnects and releases the mouse back to the server.

[2020-12-06T18:15:15] NOTE: client "ws-****" has disconnected [2020-12-06T18:15:15] DEBUG: Closing socket: 53947830 [2020-12-06T18:15:15] DEBUG: Opening new socket: 539EC690 [2020-12-06T18:15:15] INFO: OpenSSL 1.1.1g 21 Apr 2020

I should note the client is a Dell laptop on wireless with 2880x1920 screen and the server is a desktop on a wired network connection with dual 1920x1080 screens. Client is to the right of the server.

Again, no issues if the itopia Remote Desktop Client application is minimized.

umisef commented 3 years ago

As far as I can tell, this happens when the edge of the physical screen is different from the edge of the overall monitor area.

For example, imagine you have two screens, one landscape 1920x1080, and another in portrait mode, so 1080x1920. If the portrait screen is to the right of the landscape one, with the lower edges aligned, then the overall enclosing rectangle for the screen area is 3000x1920 pixels (3000=1920+1080).

It appears that as far as Barrier's switching between screens is concerned, the enclosing rectangle is all that matters; It has no concept of individual monitors filling that rectangle, possibly incompletely. So as far as Barrier is concerned, the upper edge of that computer's "screen" is 1920 pixels above the lower edge.

Now if the mouse happens to be on the landscape monitor, it will hit the physical upper edge of the individual monitor 1080 pixels above the lower edge, and moving further up will get the mouse pointer "stuck" on that physical edge. But in the background, Barrier is still tracking the mouse moving further and further towards the 1920 pixel logical edge, and once it reaches that edge, whatever other computer is configured to lie beyond it gets the mouse.

If one doesn't go all the way to the logical edge, but instead starts moving the mouse back down again after reaching, say, a height of 1600 pixels, the logical mouse position will still be above the physical limit of the monitor for some time, so the mouse pointer won't move away from that physical edge. Only once the logical position drops below 1080 pixels will it be reflected in movement of the actual mouse pointer.

As best as I can tell, this effect only happens on screen edges that have links to other machines configured.

debauchee / barrier