mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #550] Server does not understand relative screen geometry #430
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#430
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 @netstat-peanut on GitHub (Feb 4, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/550
Operating Systems
Server: Debian 10 / KDE Plasma 5.14.5
Client: MS Windows 10 1803
Barrier Version
Server: 2.2.0-Release
Client: 2.3.2-snapshot
Steps to reproduce bug
Setup is 3 monitors on Debian (up), 3 monitors on Windows (down). KB & Mouse sharing work fine, as does clipboard. All mouse transitions between Windows client and Debian server work as expected, across all 3 monitors, and with cursor appearing at appropriate part of server display(s). Transition between Debian server and Windows client works on monitors 1 and 3, however monitor 2 does not allow transition.
Other info
I expect this has something to do with configuration of X geometry on the Debian-side, as the log is reflecting negative space for the left-most monitor on Windows client (e.g. "switch from "client" to "server" at -685,0"). However, I'm not sure how to specify appropriate geometry for Barrier.
Edit: This setup works flawlessly in the reverse, with Debian configured as client and Windows configured as server.
@tattsan commented on GitHub (Feb 9, 2020):
Do the three monitors (up) have the same vertical resolution? If they are different, try to align the bottom. I'll show my configuration:
@netstat-peanut commented on GitHub (Feb 9, 2020):
Thanks tattsan, you're definitely on to something. All 3 "up" monitors have the same vertical resolution, however the center monitor causing the problems has been vertically offset to account for its position.
The following line in X config Screen section allows horizontal mouse travel between screens to align properly, however it seems that Barrier does not recognize the logical bottom of the screen.
Option "metamodes" "DP-5: nvidia-auto-select +3840+265, HDMI-0: nvidia-auto-select +0+265, DP-3: nvidia-auto-select +1920+0"
Is it possible to have the best of both worlds here?
@tattsan commented on GitHub (Feb 10, 2020):
Panning the central monitor?
@the-wes commented on GitHub (Mar 3, 2020):
This is not currently possible in Barrier. There is probably a feature request in the list already related to this, but as I don't have the number handy I will leave this open for now.
Barrier does not see individual monitors - it only sees the whole displayable area as a single rectangle shape. So your middle screen having its bottom edge higher than the other two screens' bottom edges is the reason you can't switch there.
It works when Windows is the server because it doesn't know there's a "void" there - if you watch carefully and move the mouse slowly down from the middle screen, you'll note that it hangs for a little while before switching. In this time, Barrier is attempting to move the mouse into that void, which Linux handles by setting the mouse location to the nearest spot that it can.
@github-actions[bot] commented on GitHub (Sep 30, 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.