[GH-ISSUE #1180] Can't move cursor away from left edge of client #950

Open
opened 2026-05-05 07:19:15 -06:00 by gitea-mirror · 3 comments
Owner

Originally created by @DoktorNik on GitHub (Jun 1, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1180

Describe the bug
"Something happened" resulting in the cursor on the client freezing. Ever since, it is barely possible to move the cursor away from the left edge of the screen. According to the log when the screen is entered, it immediately tries to exit left. This leads me to believe the co-ordinates are being translated incorrectly.

To Reproduce

Steps to reproduce the behavior:
?
Sorry I don't have better steps but I don't know what the original problem was. I'm more interested in getting this working correctly again but I'm out of ideas.

Expected behavior
Ability to move the mouse cursor around the client.

Desktop (please complete the following information):

Server:
Linux fedora 5.12.8-300.fc34.x86_64 #1 SMP Fri May 28 15:20:54 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Gnome 40.1.0 X11
Barrier 2.3.3

Client:
Windows 10 Professional
Barrier 2.3.3-release-3395cca9

Additional
I can't find anything wrong in the logs (as far as I can tell) from either client or server. I've tried re-installing both client and server, as well as trashing and re-creating the screens in the server config but the problem remains. I've also rebooted both client and server several times. However, it seems the un-install doesn't do much because after installing it again it failed to start because the port was already in use, so I doubt it uninstalled properly.

All the major components seem to be working. I can move the mouse, click the buttons, use the keyboard etc. The mouse is just trapped in a very small horizontal area.

I don't know if this is relevant but the window offset from the client seems strange to me, though I don't know how they are supposed to be set.

DEBUG: received client "Windows" info shape=0,0 3840x1080 at 960,540

Originally created by @DoktorNik on GitHub (Jun 1, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1180 **Describe the bug** "Something happened" resulting in the cursor on the client freezing. Ever since, it is barely possible to move the cursor away from the left edge of the screen. According to the log when the screen is entered, it immediately tries to exit left. This leads me to believe the co-ordinates are being translated incorrectly. To Reproduce **Steps to reproduce the behavior:** ? Sorry I don't have better steps but I don't know what the original problem was. I'm more interested in getting this working correctly again but I'm out of ideas. **Expected behavior** Ability to move the mouse cursor around the client. **Desktop (please complete the following information):** Server: Linux fedora 5.12.8-300.fc34.x86_64 #1 SMP Fri May 28 15:20:54 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Gnome 40.1.0 X11 Barrier 2.3.3 Client: Windows 10 Professional Barrier 2.3.3-release-3395cca9 **Additional** I can't find anything wrong in the logs (as far as I can tell) from either client or server. I've tried re-installing both client and server, as well as trashing and re-creating the screens in the server config but the problem remains. I've also rebooted both client and server several times. However, it seems the un-install doesn't do much because after installing it again it failed to start because the port was already in use, so I doubt it uninstalled properly. All the major components seem to be working. I can move the mouse, click the buttons, use the keyboard etc. The mouse is just trapped in a very small horizontal area. I don't know if this is relevant but the window offset from the client seems strange to me, though I don't know how they are supposed to be set. `DEBUG: received client "Windows" info shape=0,0 3840x1080 at 960,540`
Author
Owner

@mmguero commented on GitHub (Jun 2, 2021):

I am having the same problem with Linux server (Linux sgunat 5.10.0-0.bpo.4-amd64 #1 SMP Debian 5.10.19-1bpo10+1 (2021-03-13) x86_64 GNU/Linux, barrier 2.3.3+dfsg-1.1bpo10+1) and macOS (Barrier 2.3.3-release-3395cca9)

<!-- gh-comment-id:853040751 --> @mmguero commented on GitHub (Jun 2, 2021): I am having the same problem with Linux server (Linux sgunat 5.10.0-0.bpo.4-amd64 #1 SMP Debian 5.10.19-1~bpo10+1 (2021-03-13) x86_64 GNU/Linux, barrier 2.3.3+dfsg-1.1~bpo10+1) and macOS (Barrier 2.3.3-release-3395cca9)
Author
Owner

@DoktorNik commented on GitHub (Jun 2, 2021):

Looking at the debug2 logs the event notify never increases for the x coordinate, so there is no detected movement to send to the guest.

For some reason the x coordinate is set very high when entering the client. I think the cursor won't move further to the right because 3840 is the maximum value on the host so it won't go any further past that.

I suspect this is related to my other issue of barrier not being able to detect the right edge of my host set up.

I'm guessing that the root cause of these problems is that barrier doesn't update when my secondary video card is removed from the host based on this being logged:
[2021-06-02T09:31:15] DEBUG1: flagging X error: 3 - BadWindow (invalid Window parameter)

I tested without passing the secondary video card through to the virtual machine and the cursor is no longer stuck.

Perhaps this is an underlying problem with X or even deeper but barrier could certainly handle the problem better.

<!-- gh-comment-id:853061676 --> @DoktorNik commented on GitHub (Jun 2, 2021): Looking at the debug2 logs the event notify never increases for the x coordinate, so there is no detected movement to send to the guest. For some reason the x coordinate is set very high when entering the client. I think the cursor won't move further to the right because 3840 is the maximum value on the host so it won't go any further past that. I suspect this is related to my other issue of barrier not being able to detect the right edge of my host set up. I'm guessing that the root cause of these problems is that barrier doesn't update when my secondary video card is removed from the host based on this being logged: [2021-06-02T09:31:15] DEBUG1: flagging X error: 3 - BadWindow (invalid Window parameter) I tested without passing the secondary video card through to the virtual machine and the cursor is no longer stuck. Perhaps this is an underlying problem with X or even deeper but barrier could certainly handle the problem better.
Author
Owner

@mmguero commented on GitHub (Jun 2, 2021):

I tested it with barrier then tested it with synergy 1 as well with the same problem. After some more experimentation, for me at least, the issue was tied to multiple X screens with xinerama. After removing the second X screen on the server side, I no longer had the problem either.

<!-- gh-comment-id:853068465 --> @mmguero commented on GitHub (Jun 2, 2021): I tested it with barrier then tested it with synergy 1 as well with the same problem. After some more experimentation, for me at least, the issue was tied to multiple X screens with xinerama. After removing the second X screen on the server side, I no longer had the problem either.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#950
No description provided.