[GH-ISSUE #229] on dual head, moving mouse to another screen warps it back

gitea-mirror commented

2026-05-05 05:33:29 -06:00

Owner

Originally created by @brianjmurrell on GitHub (Jan 17, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/229

Operating Systems

Server: Linux

Client: Linux

Barrier Version

2.1.2

Steps to reproduce bug

Set up dual displays on the server with display 1 on the left and display 2 on the right and set the right display to Primary Display
On the server: barriers -f --config synergy.conf (see configuration below)
On the client: barrierc -f 10.75.22.1
Move mouse from the right of the Primary display (the right-hand of the dual displays) off of the right edge to laptop
Observe as the mouse warps back to the centre of the Primary display.

Other info

This was a problem in synergy also, but I am currently using synergys 1.8.6, protocol version 1.6 and this problem does not exist there, so it must be fixed prior to that.
Does this bug prevent you from using Barrier entirely? Yes

Put anything else you can think of here.
synergy.conf:

section: screens
	server.example.com:
	laptop.example.com:
end
section: links
	server.example.com:
		right = laptop.example.com
	laptop.example.com:
		left = server.example.com
end

barriers.log
barrierc.log

Originally created by @brianjmurrell on GitHub (Jan 17, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/229 ### Operating Systems ### Server: Linux Client: Linux ### Barrier Version ### 2.1.2 ### Steps to reproduce bug ### 1. Set up dual displays on the server with display 1 on the left and display 2 on the right and set the right display to Primary Display 1. On the server: `barriers -f --config synergy.conf` (see configuration below) 1. On the client: `barrierc -f 10.75.22.1` 1. Move mouse from the right of the Primary display (the right-hand of the dual displays) off of the right edge to _laptop_ 1. Observe as the mouse warps back to the centre of the Primary display. ### Other info ### * This was a problem in synergy also, but I am currently using **synergys 1.8.6, protocol version 1.6** and this problem does not exist there, so it must be fixed prior to that. * Does this bug prevent you from using Barrier entirely? Yes Put anything else you can think of here. `synergy.conf`: ``` section: screens server.example.com: laptop.example.com: end section: links server.example.com: right = laptop.example.com laptop.example.com: left = server.example.com end ``` [barriers.log](https://github.com/debauchee/barrier/files/2767169/barriers.log) [barrierc.log](https://github.com/debauchee/barrier/files/2767170/barrierc.log)

gitea-mirror

2026-05-05 05:33:29 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 05:33:33 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 17, 2019):

I have/had the same issue. I've been using the following patch to work around it.

--- a/src/lib/platform/XWindowsScreen.cpp
+++ b/src/lib/platform/XWindowsScreen.cpp
@@ -1548,6 +1548,9 @@ XWindowsScreen::onMouseMove(const XMotionEvent& xmotion)
 {
        LOG((CLOG_DEBUG2 "event: MotionNotify %d,%d", xmotion.x_root, xmotion.y_root));
 
+       if (!xmotion.same_screen)
+               return;
+
        // compute motion delta (relative to the last known
        // mouse position)
        SInt32 x = xmotion.x_root - m_xCursor;

This makes barrier/synergy ignore mouse movements if its not on the same DISPLAY=:0.x as the one you started barrier/synergy on.

@jwestfall69 commented on GitHub (Jan 17, 2019): I have/had the same issue. I've been using the following patch to work around it. ``` --- a/src/lib/platform/XWindowsScreen.cpp +++ b/src/lib/platform/XWindowsScreen.cpp @@ -1548,6 +1548,9 @@ XWindowsScreen::onMouseMove(const XMotionEvent& xmotion) { LOG((CLOG_DEBUG2 "event: MotionNotify %d,%d", xmotion.x_root, xmotion.y_root)); + if (!xmotion.same_screen) + return; + // compute motion delta (relative to the last known // mouse position) SInt32 x = xmotion.x_root - m_xCursor; ``` This makes barrier/synergy ignore mouse movements if its not on the same DISPLAY=:0.x as the one you started barrier/synergy on.

gitea-mirror commented

2026-05-05 05:33:36 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jan 17, 2019):

Could a PR be made to integrate this patch?

@AdrianKoshka commented on GitHub (Jan 17, 2019): Could a PR be made to integrate this patch?

gitea-mirror commented

2026-05-05 05:33:38 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 17, 2019):

Something else that might be relevant, which I notice I failed to mention in my original description is that my Primary display is rotated 90 degrees counter-clockwise.

@brianjmurrell commented on GitHub (Jan 17, 2019): Something else that might be relevant, which I notice I failed to mention in my original description is that my Primary display is rotated 90 degrees counter-clockwise.

gitea-mirror commented

2026-05-05 05:33:41 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 17, 2019):

With the patch, barrier will only consider mouse movement from one of the X Displays. If you want to have remote clients on each side of the dual head X setup, it will cause the mouse to jump to the remote client when you hit the shared monitor edge between the 2 X displays.

Example:
remote1 | X1 | X2 | remote2

If X2 is the X barrier is watching for mouse movement, when the mouse nears the left edge of X2 it would trigger a jump to remote1.

One thing I haven't tried with this patch is to see if its viable to run barriers on one X display and an barrierc on the other X display. I think if that worked then it maybe worth adding the patch. I will give it a try this weekend, but suspect the mouse it going to disappear.

@jwestfall69 commented on GitHub (Jan 17, 2019): With the patch, barrier will only consider mouse movement from one of the X Displays. If you want to have remote clients on each side of the dual head X setup, it will cause the mouse to jump to the remote client when you hit the shared monitor edge between the 2 X displays. Example: ```remote1 | X1 | X2 | remote2``` If X2 is the X barrier is watching for mouse movement, when the mouse nears the left edge of X2 it would trigger a jump to remote1. One thing I haven't tried with this patch is to see if its viable to run barriers on one X display and an barrierc on the other X display. I think if that worked then it maybe worth adding the patch. I will give it a try this weekend, but suspect the mouse it going to disappear.

gitea-mirror commented

2026-05-05 05:33:43 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 17, 2019):

One thing I haven't tried with this patch is to see if its viable to run barriers on one X display and an barrierc on the other X display. I think if that worked then it maybe worth adding the patch. I will give it a try this weekend, but suspect the mouse it going to disappear.

Is this some kind of debugging step you are suggesting or are you trying to suggest that the working configuration for a dual-head display is to run both a barriers and a barrierc, one for each display?

Please also note, that my dual-head displays are "joined" into a single :0.0 where I can drag windows from one display to the other. They are not configured as discreet :0.0 and :0.1 displays.

@brianjmurrell commented on GitHub (Jan 17, 2019): > One thing I haven't tried with this patch is to see if its viable to run barriers on one X display and an barrierc on the other X display. I think if that worked then it maybe worth adding the patch. I will give it a try this weekend, but suspect the mouse it going to disappear. Is this some kind of debugging step you are suggesting or are you trying to suggest that the working configuration for a dual-head display is to run both a `barriers` and a `barrierc`, one for each display? Please also note, that my dual-head displays are "joined" into a single :0.0 where I can drag windows from one display to the other. They are not configured as discreet :0.0 and :0.1 displays.

gitea-mirror commented

2026-05-05 05:33:45 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 17, 2019):

Can you provide your X config.

@jwestfall69 commented on GitHub (Jan 17, 2019): Can you provide your X config.

gitea-mirror commented

2026-05-05 05:33:47 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 17, 2019):

In what manner? xdpyinfo?

I don't have an xorg.conf file. I let Xorg and GNOME autoconfigure/manage the configuration.

@brianjmurrell commented on GitHub (Jan 17, 2019): In what manner? `xdpyinfo`? I don't have an `xorg.conf` file. I let Xorg and GNOME autoconfigure/manage the configuration.

gitea-mirror commented

2026-05-05 05:33:48 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 17, 2019):

In theory the ServerLayout section from /var/log/Xorg.0.log should be good enough to see your setup. For example mine has

[   376.696] (==) ServerLayout "Layout0"
[   376.696] (**) |-->Screen "Screen0" (0)
[   376.696] (**) |   |-->Monitor "Monitor0"
[   376.697] (**) |   |-->Device "Device0"
[   376.697] (**) |-->Screen "Screen1" (1)
[   376.697] (**) |   |-->Monitor "Monitor1"
[   376.697] (**) |   |-->Device "Device1"
[   376.697] (**) |-->Input Device "Keyboard0"
[   376.697] (**) |-->Input Device "Mouse0"
[   376.697] (**) Option "Xinerama" "0"

@jwestfall69 commented on GitHub (Jan 17, 2019): In theory the ServerLayout section from /var/log/Xorg.0.log should be good enough to see your setup. For example mine has ``` [ 376.696] (==) ServerLayout "Layout0" [ 376.696] (**) |-->Screen "Screen0" (0) [ 376.696] (**) | |-->Monitor "Monitor0" [ 376.697] (**) | |-->Device "Device0" [ 376.697] (**) |-->Screen "Screen1" (1) [ 376.697] (**) | |-->Monitor "Monitor1" [ 376.697] (**) | |-->Device "Device1" [ 376.697] (**) |-->Input Device "Keyboard0" [ 376.697] (**) |-->Input Device "Mouse0" [ 376.697] (**) Option "Xinerama" "0" ```

gitea-mirror commented

2026-05-05 05:33:49 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 17, 2019):

I thought about that but looking at it it didn't seem very useful:

[832443.889] (==) No Layout section.  Using the first Screen section.
[832443.889] (==) No screen section available. Using defaults.
[832443.889] (**) |-->Screen "Default Screen Section" (0)
[832443.889] (**) |   |-->Monitor "<default monitor>"
[832443.889] (==) No monitor specified for screen "Default Screen Section".
        Using a default monitor configuration.

Perhaps the screen-joining is being done by GNOME with xrandr. It is in the GNOME control panel Display Settings where I set up a joined display.

@brianjmurrell commented on GitHub (Jan 17, 2019): I thought about that but looking at it it didn't seem very useful: ``` [832443.889] (==) No Layout section. Using the first Screen section. [832443.889] (==) No screen section available. Using defaults. [832443.889] (**) |-->Screen "Default Screen Section" (0) [832443.889] (**) | |-->Monitor "<default monitor>" [832443.889] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. ``` Perhaps the screen-joining is being done by GNOME with `xrandr`. It is in the GNOME control panel Display Settings where I set up a joined display.

gitea-mirror commented

2026-05-05 05:33:50 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 18, 2019):

I was able to reproduce the issue mimicking your setup. The issue appears to be some weirdness with xinerama and warping the mouse pointer. Can you try the attached patch and see if it fixes the issue for you? Please also be sure you have your distro's xinerama devel package installed.

229-v1.txt

@jwestfall69 commented on GitHub (Jan 18, 2019): I was able to reproduce the issue mimicking your setup. The issue appears to be some weirdness with xinerama and warping the mouse pointer. Can you try the attached patch and see if it fixes the issue for you? Please also be sure you have your distro's xinerama devel package installed. [229-v1.txt](https://github.com/debauchee/barrier/files/2771625/229-v1.txt)

gitea-mirror commented

2026-05-05 05:33:51 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 18, 2019):

Doesn't seem to fix it. Now warps from the display on the right to the display on the left when I try move the mouse off of the right side of the right-hand display.

barriers.log
barrierc.log

I think it's worth taking a step back and pondering why synergy 1.8.6 doesn't have this problem but barrier, taken from a later commit does. No?

@brianjmurrell commented on GitHub (Jan 18, 2019): Doesn't seem to fix it. Now warps from the display on the right to the display on the left when I try move the mouse off of the right side of the right-hand display. [barriers.log](https://github.com/debauchee/barrier/files/2774161/barriers.log) [barrierc.log](https://github.com/debauchee/barrier/files/2774162/barrierc.log) I think it's worth taking a step back and pondering why synergy 1.8.6 doesn't have this problem but barrier, taken from a later commit does. No?

gitea-mirror commented

2026-05-05 05:33:53 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 18, 2019):

You will probably need to bitsect to find the commit the caused the issue. However looking at the commits logs I would suspect its the removal of this code.

https://github.com/symless/synergy-core/pull/5832/commits/fee00440eb0826d5bc01bea0bb0ee65f361d1f8b

You might trying adding it back and see if it helps

@jwestfall69 commented on GitHub (Jan 18, 2019): You will probably need to bitsect to find the commit the caused the issue. However looking at the commits logs I would suspect its the removal of this code. https://github.com/symless/synergy-core/pull/5832/commits/fee00440eb0826d5bc01bea0bb0ee65f361d1f8b You might trying adding it back and see if it helps

gitea-mirror commented

2026-05-05 05:33:55 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 18, 2019):

Putting that back is warping the mouse in weird ways without even trying to leave the screen. barriers also winds up STBing with:

barriers: /net/server/src/barrier/src/lib/server/Server.cpp:458: void Server::switchScreen(BaseClientProxy*, SInt32, SInt32, bool): Assertion `x >= dx && y >= dy && x < dx + dw && y < dy + dh' failed.

@brianjmurrell commented on GitHub (Jan 18, 2019): Putting that back is warping the mouse in weird ways without even trying to leave the screen. `barriers` also winds up STBing with: ``` barriers: /net/server/src/barrier/src/lib/server/Server.cpp:458: void Server::switchScreen(BaseClientProxy*, SInt32, SInt32, bool): Assertion `x >= dx && y >= dy && x < dx + dw && y < dy + dh' failed. ```

gitea-mirror commented

2026-05-05 05:33:56 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 18, 2019):

Can you try the below patch and provide the output. It adds some debug info to my original patch. The patch assumes a fresh master checkout.

229-v2.txt

What I was seeing when I was able to reproduce the issue was the barrier server not being able to warp the mouse cursor to the picked center of the screen. When you leave the server for a remote client, barrier server will warp the (invisible) cursor to the center of the servers screen. As you move the mouse it tracks the movements and those deltas get pushed to the client to control the mouse on it. If you get to far away from the center it will warp you back again.

When I was able to reproduce the issue, my setup was xinerama with 2 monitors (3840x2160 and 1920x1200) and barrier would pick 1920x1080 as the center of the screen. However when it warped there it always ended up at 1919x1080. This caused barrier to think I moved the mouse to the left. So soon as I entered the remote right screen, barrier would think I wanted to move back to the server.

The debugging will log the warp target and where we actually ended up to see if you are seeing the same issue.

Could you also provide the screen resolutions of each of your monitors on the server?

@jwestfall69 commented on GitHub (Jan 18, 2019): Can you try the below patch and provide the output. It adds some debug info to my original patch. The patch assumes a fresh master checkout. [229-v2.txt](https://github.com/debauchee/barrier/files/2774587/229-v2.txt) What I was seeing when I was able to reproduce the issue was the barrier server not being able to warp the mouse cursor to the picked center of the screen. When you leave the server for a remote client, barrier server will warp the (invisible) cursor to the center of the servers screen. As you move the mouse it tracks the movements and those deltas get pushed to the client to control the mouse on it. If you get to far away from the center it will warp you back again. When I was able to reproduce the issue, my setup was xinerama with 2 monitors (3840x2160 and 1920x1200) and barrier would pick 1920x1080 as the center of the screen. However when it warped there it always ended up at 1919x1080. This caused barrier to think I moved the mouse to the left. So soon as I entered the remote right screen, barrier would think I wanted to move back to the server. The debugging will log the warp target and where we actually ended up to see if you are seeing the same issue. Could you also provide the screen resolutions of each of your monitors on the server?

gitea-mirror commented

2026-05-05 05:33:57 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 21, 2019):

Can you try the below patch and provide the output. It adds some debug info to my original patch. The patch assumes a fresh master checkout.

barriers.log

I seemed to have failed at getting the barrierc log but suspect you don't need that. Let me know if you do and I will repro and get both logs.

FWIW, I tried 3-4 times to move the mouse off of the right edge of the display on the right to the barrierc computer.

Could you also provide the screen resolutions of each of your monitors on the server?

            +--------+
            |        |
+----------+|        |
|          ||        |
|          ||        |
+----------+|        |
            +--------+

Left: 1600x1200
Right: 1080x1920 (i.e. 1080p rotated 90 degrees CCW), Primary

@brianjmurrell commented on GitHub (Jan 21, 2019): > Can you try the below patch and provide the output. It adds some debug info to my original patch. The patch assumes a fresh master checkout. [barriers.log](https://github.com/debauchee/barrier/files/2778006/barriers.log) I seemed to have failed at getting the `barrierc` log but suspect you don't need that. Let me know if you do and I will repro and get both logs. FWIW, I tried 3-4 times to move the mouse off of the right edge of the display on the right to the `barrierc` computer. > Could you also provide the screen resolutions of each of your monitors on the server? ``` +--------+ | | +----------+| | | || | | || | +----------+| | +--------+ ``` Left: 1600x1200 Right: 1080x1920 (i.e. 1080p rotated 90 degrees CCW), Primary

gitea-mirror commented

2026-05-05 05:34:01 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 22, 2019):

The logs show something funky going on.

[2019-01-21T03:04:37] INFO: warped to 540,600
[2019-01-21T03:04:37] INFO: trying to warp to 540,600
[2019-01-21T03:04:37] INFO: warped to 540,600
[2019-01-21T03:04:37] INFO: trying to warp to 540,600
[2019-01-21T03:04:37] INFO: warped to 540,600
[2019-01-21T03:04:37] INFO: trying to warp to 540,600
[2019-01-21T03:04:37] INFO: warped to 540,600
[2019-01-21T03:04:37] INFO: trying to warp to 540,600
[2019-01-21T03:04:37] INFO: warped to 0,1183

Most of the time it properly warps your cursor back to 540,600 as expect but as you can see that last warp ended up at 0,1183. This would trigger a large leftward motion causing barrier to want to leave your laptop and go back to your desktop.

Can you run this patch on your the server, it add some more debugging. It will be a bit spammy as its going to log all mouse movements.

229-v3.txt

Can you tell me what distro/version you are running? Wondering if there could end up being a bug in the version of X it has.

thanks

@jwestfall69 commented on GitHub (Jan 22, 2019): The logs show something funky going on. ``` [2019-01-21T03:04:37] INFO: warped to 540,600 [2019-01-21T03:04:37] INFO: trying to warp to 540,600 [2019-01-21T03:04:37] INFO: warped to 540,600 [2019-01-21T03:04:37] INFO: trying to warp to 540,600 [2019-01-21T03:04:37] INFO: warped to 540,600 [2019-01-21T03:04:37] INFO: trying to warp to 540,600 [2019-01-21T03:04:37] INFO: warped to 540,600 [2019-01-21T03:04:37] INFO: trying to warp to 540,600 [2019-01-21T03:04:37] INFO: warped to 0,1183 ``` Most of the time it properly warps your cursor back to 540,600 as expect but as you can see that last warp ended up at 0,1183. This would trigger a large leftward motion causing barrier to want to leave your laptop and go back to your desktop. Can you run this patch on your the server, it add some more debugging. It will be a bit spammy as its going to log all mouse movements. [229-v3.txt](https://github.com/debauchee/barrier/files/2781401/229-v3.txt) Can you tell me what distro/version you are running? Wondering if there could end up being a bug in the version of X it has. thanks

gitea-mirror commented

2026-05-05 05:34:03 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 22, 2019):

I was thinking about this a bit more last night wondering where that 0,xxxx location came from. The one thing that came to mind is it possibility being the warp location we would have asked the client to move to when switching to it. When you test with this new patch can you do the following.

Have the cursor at the top of your server screen when you try to go to your laptop, when that fails move to the middle and try, then finally from the very bottom.

@jwestfall69 commented on GitHub (Jan 22, 2019): I was thinking about this a bit more last night wondering where that 0,xxxx location came from. The one thing that came to mind is it possibility being the warp location we would have asked the client to move to when switching to it. When you test with this new patch can you do the following. Have the cursor at the top of your server screen when you try to go to your laptop, when that fails move to the middle and try, then finally from the very bottom.

gitea-mirror commented

2026-05-05 05:34:04 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 23, 2019):

Have the cursor at the top of your server screen when you try to go to your laptop, when that fails move to the middle and try, then finally from the very bottom.

Done. I ended up doing the last one (bottom of the screen) twice as I wasn't sure about the data for it the first time.

barriers.log

@brianjmurrell commented on GitHub (Jan 23, 2019): > Have the cursor at the top of your server screen when you try to go to your laptop, when that fails move to the middle and try, then finally from the very bottom. Done. I ended up doing the last one (bottom of the screen) twice as I wasn't sure about the data for it the first time. [barriers.log](https://github.com/debauchee/barrier/files/2785302/barriers.log)

gitea-mirror commented

2026-05-05 05:34:07 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Jan 23, 2019):

The newest log shows the mouse pointer on the server jump to near the same location as the server told the client to move. But there is nothing in the server logs to indicate it was telling the local X to do that.

Re-reviewing your original client/laptop log it has this

[2019-01-16T23:44:04] DEBUG: XOpenDisplay("localhost:10.0")
[2019-01-16T23:44:09] DEBUG: screen shape: 0,0 2680x1920 (xinerama)

It seems very unlikely your laptop has the same exact weird resolution as your server. 2ndly the localhost:10.0 is an indication of X being forwarded over ssh. So I suspect whats going on is that you are ssh'ing from your server to your laptop with X forwarding enabled to start barrierc. This is causing barrierc to run against your server's X instance instead of your laptops.

Try adding --display :0.0 to you barrierc command line to force it to use your laptop's X instance.

@jwestfall69 commented on GitHub (Jan 23, 2019): The newest log shows the mouse pointer on the server jump to near the same location as the server told the client to move. But there is nothing in the server logs to indicate it was telling the local X to do that. Re-reviewing your original client/laptop log it has this ``` [2019-01-16T23:44:04] DEBUG: XOpenDisplay("localhost:10.0") [2019-01-16T23:44:09] DEBUG: screen shape: 0,0 2680x1920 (xinerama) ``` It seems very unlikely your laptop has the same exact weird resolution as your server. 2ndly the localhost:10.0 is an indication of X being forwarded over ssh. So I suspect whats going on is that you are ssh'ing from your server to your laptop with X forwarding enabled to start barrierc. This is causing barrierc to run against your server's X instance instead of your laptops. Try adding ``` --display :0.0 ``` to you barrierc command line to force it to use your laptop's X instance.

gitea-mirror commented

2026-05-05 05:34:08 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 23, 2019):

~~smacks forehead~~ Doh!

Yes, of course. Stupid mistake by me. I should have realised. Once I stopped using the X-forwarded display it works just fine.

So, this ticket should in fact be titled: Detect if being run on an SSH X-forwarded display and refuse to start if so. :-)

Seriously though, it should. barrier[cs] should detect if it's being run on an X11 forwarded display and not start, or at least give the user a big warning, if it's found.

How could this be determined? Heuristically is one way. Is DISPLAY # >= 10? Is resolution of server and client the same? Are other SSH environment variables set?

Or one could look for a more unique property of an X display and see if they are == on both client and server. One could set an X property on the server and see if it's set on the client.

There are probably other ways.

@brianjmurrell commented on GitHub (Jan 23, 2019): ~smacks forehead~ Doh! Yes, of course. Stupid mistake by me. I should have realised. Once I stopped using the X-forwarded display it works just fine. So, this ticket should in fact be titled: _Detect if being run on an SSH X-forwarded display and refuse to start if so_. :-) Seriously though, it should. barrier[cs] should detect if it's being run on an X11 forwarded display and not start, or at least give the user a big warning, if it's found. How could this be determined? Heuristically is one way. Is DISPLAY # >= 10? Is resolution of server and client the same? Are other SSH environment variables set? Or one could look for a more unique property of an X display and see if they are == on both client and server. One could set an X property on the server and see if it's set on the client. There are probably other ways.

gitea-mirror commented

2026-05-05 05:34:11 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jan 23, 2019):

@brianjmurrell I'm going to close this issue seeing as it's fixed. Though I encourage you to open a new issue describing that there should be a X11 forwarding warning.

@AdrianKoshka commented on GitHub (Jan 23, 2019): @brianjmurrell I'm going to close this issue seeing as it's fixed. Though I encourage you to open a new issue describing that there should be a X11 forwarding warning.

gitea-mirror referenced this issue

2026-05-05 05:46:14 -06:00

[GH-ISSUE #297] Unable to run Linux barrier client during startup using systemd #238

Rows
Columns

[GH-ISSUE #229] on dual head, moving mouse to another screen warps it back #185

Operating Systems

Barrier Version

Steps to reproduce bug

Other info