[GH-ISSUE #550] Server does not understand relative screen geometry #430

Open
opened 2026-05-05 06:22:30 -06:00 by gitea-mirror · 5 comments
Owner

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

  • When did the problem start to occur? Since install
  • Is there a way to work around it? Yes, exiting server monitors 1 & 3 to client
  • Does this bug prevent you from using Barrier entirely? No

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.

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 ### * When did the problem start to occur? Since install * Is there a way to work around it? Yes, exiting server monitors 1 & 3 to client * Does this bug prevent you from using Barrier entirely? No 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.
gitea-mirror added the
enhancement
label 2026-05-05 06:22:30 -06:00
Author
Owner

@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:

xrandr --output $EXTDP --primary --mode 3840x2160 --pos 4480x0 --output $OUTDP --mode 1920x1920 --pos 2560x240 --output $INTDP --mode 2560x1440 --pos 0x720
<!-- gh-comment-id:583812014 --> @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: ``` xrandr --output $EXTDP --primary --mode 3840x2160 --pos 4480x0 --output $OUTDP --mode 1920x1920 --pos 2560x240 --output $INTDP --mode 2560x1440 --pos 0x720 ```
Author
Owner

@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?

<!-- gh-comment-id:583899826 --> @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?
Author
Owner

@tattsan commented on GitHub (Feb 10, 2020):

Panning the central monitor?

<!-- gh-comment-id:583951415 --> @tattsan commented on GitHub (Feb 10, 2020): Panning the central monitor?
Author
Owner

@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.

<!-- gh-comment-id:593876581 --> @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.
Author
Owner

@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.

<!-- gh-comment-id:701108198 --> @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.
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#430
No description provided.