github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #1479] Ubuntu 20 server, Windows 10 client, barrier fails unless chrome is fullscreen #1124

New issue

Open

opened 2026-05-05 07:30:39 -06:00 by gitea-mirror · 11 comments

gitea-mirror commented

2026-05-05 07:30:39 -06:00

Owner

Originally created by @gclayburg on GitHub (Dec 12, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1479

What happened?

I installed barrier 2.4.0-release-ac5a1bfb on Ubuntu 20.04. I run it as a server without using SSL.
I installed barrier 2.4.0-release-3e0d758b on Windows 10. This one runs as a client.

What I find is that barrier works to share the mouse and keyboard, but only when there is an application like chrome running full screen on the server. If there is not app in full screen, the mouse will never leave the server to travel to the client. As soon as the app is maximized to full screen again, the mouse can move to the client. I've noticed this with the chrome app, but others may trigger this behavior as well.

What is also interesting is that this little trick does not work for all apps. Running the file manager in full screen for example does not "trick" barrier to start working.

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

Barrier on the server is running from the latest stable snap.

What OSes are you seeing the problem on? (Check all that apply)

Linux

What OS versions are you using?

Ubuntu 20.04

Relevant log output

No response

Any other information

No response

Originally created by @gclayburg on GitHub (Dec 12, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1479 ### What happened? I installed barrier 2.4.0-release-ac5a1bfb on Ubuntu 20.04. I run it as a server without using SSL. I installed barrier 2.4.0-release-3e0d758b on Windows 10. This one runs as a client. What I find is that barrier works to share the mouse and keyboard, but only when there is an application like chrome running full screen on the server. If there is not app in full screen, the mouse will never leave the server to travel to the client. As soon as the app is maximized to full screen again, the mouse can move to the client. I've noticed this with the chrome app, but others may trigger this behavior as well. What is also interesting is that this little trick does not work for all apps. Running the file manager in full screen for example does not "trick" barrier to start working. ### Version v2.4.0 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? Barrier on the server is running from the latest stable snap. ### What OSes are you seeing the problem on? (Check all that apply) Linux ### What OS versions are you using? Ubuntu 20.04 ### Relevant log output _No response_ ### Any other information _No response_

gitea-mirror commented

2026-05-05 07:30:42 -06:00

Author

Owner

@alexemilberg commented on GitHub (Dec 26, 2021):

Do you use wayland?

@alexemilberg commented on GitHub (Dec 26, 2021): Do you use wayland?

gitea-mirror commented

2026-05-05 07:30:44 -06:00

Author

Owner

@raffraffraff commented on GitHub (Dec 27, 2021):

Hi Gary.

Wild guess: something on the desktop (screenlets? plasma widgets?) is "taking over" when the mouse hovers over the edge, but when you've got an application in full-screen mode it can't do this.

Some of these might help you diagnose:

Which edge is supposed to trigger Barrier to move focus from Ubuntu to the Windows (eg: top, bottom, left or right)? Have you tried temporarily using a different edge to trigger it?
Which desktop environment are you using on Ubuntu (eg: KDE, Gnome, Mate, XFCE)? Have you tried temporarily using another to see if the problem is specific to the one you're using?
Are you using any edge-activated widgets, docks, menus or panels?
(should be first really...) please confirm if it's just Chrome, or if indeed any fullscreen app makes Barrier work

[Disclaimer: I don't actually use Barrier, I'm just browsing issues to see if it's worth my while installing it!]

@raffraffraff commented on GitHub (Dec 27, 2021): Hi Gary. Wild guess: something on the desktop (screenlets? plasma widgets?) is "taking over" when the mouse hovers over the edge, but when you've got an application in full-screen mode it can't do this. Some of these *might* help you diagnose: 1. Which edge is supposed to trigger Barrier to move focus from Ubuntu to the Windows (eg: top, bottom, left or right)? Have you tried temporarily using a different edge to trigger it? 2. Which desktop environment are you using on Ubuntu (eg: KDE, Gnome, Mate, XFCE)? Have you tried temporarily using another to see if the problem is specific to the one you're using? 3. Are you using any edge-activated widgets, docks, menus or panels? 4. (should be first really...) *please* confirm if it's just Chrome, or if indeed *any* fullscreen app makes Barrier work [Disclaimer: I don't actually use Barrier, I'm just browsing issues to see if it's worth my while installing it!]

gitea-mirror commented

2026-05-05 07:30:45 -06:00

Author

Owner

@raffraffraff commented on GitHub (Dec 27, 2021):

If nothing above helps, perhaps you can use xev to show some Xorg debugging information for your desktop.

Open a terminal (not fullscreen and not near the Barrier edge!)
Run xwininfo, and click on your desktop. It'll show a bunch of information including window ID
Run xev -id <window_ID>

At this point, xev will show debug information whenever you type or click the mouse. It also shows information LeaveNotify event and EnterNotify event any time the mouse leaves or enters the desktop (eg: activating a dock or panel, or over an open application window). See if it triggers Leave/Enter events on the edge of the desktop when no applications are open.

@raffraffraff commented on GitHub (Dec 27, 2021): If nothing above helps, perhaps you can use `xev` to show some Xorg debugging information for your desktop. 1. Open a terminal (not fullscreen and not near the Barrier edge!) 2. Run `xwininfo`, and click on your desktop. It'll show a bunch of information including window ID 3. Run `xev -id <window_ID>` At this point, xev will show debug information whenever you type or click the mouse. It also shows information `LeaveNotify event` and `EnterNotify event` any time the mouse leaves or enters the desktop (eg: activating a dock or panel, or over an open application window). See if it triggers Leave/Enter events on the edge of the desktop when no applications are open.

gitea-mirror commented

2026-05-05 07:30:48 -06:00

Author

Owner

@raffraffraff commented on GitHub (Dec 27, 2021):

Also, see https://github.com/symless/synergy-core/issues/4524 (it's an old issue from Synergy, which Barrier was forked from). It appears to confirm that launchers and docks can indeed affect or be affected by edge activated software.

@raffraffraff commented on GitHub (Dec 27, 2021): Also, see https://github.com/symless/synergy-core/issues/4524 (it's an old issue from Synergy, which Barrier was forked from). It appears to confirm that launchers and docks can indeed affect or be affected by edge activated software.

gitea-mirror commented

2026-05-05 07:30:49 -06:00

Author

Owner

@gclayburg commented on GitHub (Dec 28, 2021):

Yes, I use wayland and gnome 3.36.8. I should be able to try some of these ideas later tonight.

@gclayburg commented on GitHub (Dec 28, 2021): Yes, I use wayland and gnome 3.36.8. I should be able to try some of these ideas later tonight.

gitea-mirror commented

2026-05-05 07:30:50 -06:00

Author

Owner

@alexemilberg commented on GitHub (Dec 29, 2021):

Wayland is not really supported right now, try switching to xorg session
and see if it works better.

@alexemilberg commented on GitHub (Dec 29, 2021): Wayland is not really supported right now, try switching to xorg session and see if it works better.

gitea-mirror commented

2026-05-05 07:30:52 -06:00

Author

Owner

@darylliney1406 commented on GitHub (Jan 30, 2022):

I have this same issue. When Chrome is full screen or at the edge configured in the server I am able to move my mouse to another machine, as soon as it is minimised you are stopped from moving to another machine.
I have found that this behaviour disappears whilst using xfce.

@darylliney1406 commented on GitHub (Jan 30, 2022): I have this same issue. When Chrome is full screen or at the edge configured in the server I am able to move my mouse to another machine, as soon as it is minimised you are stopped from moving to another machine. I have found that this behaviour disappears whilst using xfce.

gitea-mirror commented

2026-05-05 07:30:53 -06:00

Author

Owner

@raffraffraff commented on GitHub (Feb 1, 2022):

^ XFCE doesn't support Wayland at all right now. If you prefer to use Gnome or KDE then see if your login manager has an option to run them without Wayland.

@raffraffraff commented on GitHub (Feb 1, 2022): ^ XFCE doesn't support Wayland at all right now. If you prefer to use Gnome or KDE then see if your login manager has an option to run them without Wayland.

gitea-mirror commented

2026-05-05 07:30:55 -06:00

Author

Owner

@dgentry commented on GitHub (Feb 17, 2022):

I hit this too.

First, I hit the issue where if you run the server on Windows and the client on Ubuntu 20.04/Gnome/Wayland, the cursor disappears as it moves onto the Ubuntu screen, and works, except for cursor visiblity. (I can click on stuff, type into dialog boxes, etc., I just can't see where the cursor is.)

So I switched the Ubuntu machine to be the server and Windows the client, and astonishingly, it does work as long as there's a full screen Chrome on the monitor next to the Windows monitor. It doesn't work with full screen File Manager, Terminal, AisleRiot, or a couple of other programs I tried.

I will now switch to running Gnome on Xorg instead of Wayland, but I will lose some Gnome features I had been using. Are there any plans to ever support Wayland? It seems like it's not far from working, but I haven't dug through the barrier source.

@dgentry commented on GitHub (Feb 17, 2022): I hit this too. First, I hit the issue where if you run the server on Windows and the client on Ubuntu 20.04/Gnome/Wayland, the cursor disappears as it moves onto the Ubuntu screen, and works, except for cursor visiblity. (I can click on stuff, type into dialog boxes, etc., I just can't see where the cursor is.) So I switched the Ubuntu machine to be the server and Windows the client, and astonishingly, it does work as long as there's a full screen Chrome on the monitor next to the Windows monitor. It doesn't work with full screen File Manager, Terminal, AisleRiot, or a couple of other programs I tried. I will now switch to running Gnome on Xorg instead of Wayland, but I will lose some Gnome features I had been using. Are there any plans to ever support Wayland? It seems like it's not far from working, but I haven't dug through the barrier source.

gitea-mirror commented

2026-05-05 07:30:57 -06:00

Author

Owner

@alexemilberg commented on GitHub (Mar 8, 2022):

@dgentry I think this issue tracks wayland progress https://github.com/debauchee/barrier/issues/109

@alexemilberg commented on GitHub (Mar 8, 2022): @dgentry I think this issue tracks wayland progress https://github.com/debauchee/barrier/issues/109

gitea-mirror commented

2026-05-05 07:30:58 -06:00

Author

Owner

@themaskedcrusader commented on GitHub (Apr 10, 2024):

This is still happening in Ubuntu 22.04. If Chrome is fullscreen, I can switch to other desktops, When windowed the cursor is locked to my screen. It appears to only be chrome. Fullscreen Firefox doesn't let me switch. Full screen calculator doesn't let me switch. I've checked a lot of other apps (terminal, gedit, solitare, etc) and all don't let the cursor move to the other screens.

Chrome doesn't even have to be full screen. If I have the chrome window off the side of the desktop, I can switch as long as my cursor goes from chrome to the edge of the screen. Nothing else will work. Tis very strange.

Edit: So it looks totally related to Wayland. I switched to X11 and it works fine without a full-screen chrome. and What is it about Chrome that it overrides whatever Wayland is doing? that's weird too.

@themaskedcrusader commented on GitHub (Apr 10, 2024): This is still happening in Ubuntu 22.04. If Chrome is fullscreen, I can switch to other desktops, When windowed the cursor is locked to my screen. It appears to only be chrome. Fullscreen Firefox doesn't let me switch. Full screen calculator doesn't let me switch. I've checked a lot of other apps (terminal, gedit, solitare, etc) and all don't let the cursor move to the other screens. Chrome doesn't even have to be full screen. If I have the chrome window off the side of the desktop, I can switch as long as my cursor goes from chrome to the edge of the screen. Nothing else will work. Tis very strange. Edit: So it looks totally related to Wayland. I switched to X11 and it works fine without a full-screen chrome. and What is it about Chrome that it overrides whatever Wayland is doing? that's weird too.