mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #1291] mouse not switching screens #1032
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#1032
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 @digitao on GitHub (Sep 18, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1291
What happened?
with archlinux server and win10 client, when running gnome on wayland (currently this is the default for gnome) when the desktop is shown or there is a gnome application (ie gedit , nautilus or gnome-terminal) fullscreen the mouse cursor will refuse to switch screens, when another application is fullscreen (ie chrome or firefox) it switches as expected.
from the testing I have done it appears as if whenever a gnome has control of the right edge of the screen (my windows client is to the right) barrier does not see the mouse being at that edge whereas when the cursor is over some other application when it reaches the trigger edge (ie one of the barrier windows or chrome)it sees it just fine.
behaviour only manifests on wayland, Xorg behaves fine.
also turned up logging to debug2 nothing logged when it fails...
Version
v2.3.3
Git commit hash (if applicable)
No response
If applicable, where did you install Barrier from?
archlinux - aur
windows - installer
What OSes are you seeing the problem on? (Check all that apply)
Linux, Windows
What OS versions are you using?
archlinux
windows 10
Relevant log output
No response
Any other information
No response
@luizfelipelaviola commented on GitHub (Oct 5, 2021):
In my case, Barrier only work if the window (on server) is active.
@luizfelipelaviola commented on GitHub (Oct 5, 2021):
UPDATE: I just downgraded to 2.3.2 and it works!
@mirh commented on GitHub (Oct 7, 2021):
Downgrading to 2.3.3 (not git, the original release) should have been already enough #1241
@ellisgl commented on GitHub (Oct 10, 2021):
You might want to make sure you didn't have scroll lock (ScrLk) on. That will lock the mouse to the system you were on when you hit that key.
@piemanny commented on GitHub (Oct 16, 2021):
Yes, I have the issue where OSX is server and windows is client it works, but when windows is server and osx is client i get Cursor may not be visible
@delcake commented on GitHub (Nov 20, 2021):
I've just started testing out Barrier and noticed this issue too. I'm on Barrier version 2.4.0 using EndeavourOS with Gnome on Wayland attempting to interact with a Windows 10 client and I believe I've narrowed down this behavior to the Dash-To-Panel Gnome extension.
Any time that I set up a screen layout where Dash-to-Panel isn't on the same border of the monitor that I want to use to change screens, Barrier works as expected. Barrier will also work if another application is fullscreen above Dash-to-Panel as it isn't able to intercept the attempt to cross over to the client.
During my testing I also found it's possible to cause some odd behavior by toggling on Dash-to-Panel's Panel Intellihide feature. If the panel is fully hidden, you can force the mouse over to your remote client if you're quick enough but the panel beginning to unhide usually snaps me back to the server if I'm too slow.