github-starred/barrier

Fork 0

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

[GH-ISSUE #315] barrier(1) locks up WM on CentOS 7/XFCE4 #252

New issue

Closed

opened 2026-05-05 05:51:13 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 05:51:13 -06:00

Owner

Originally created by @ElvishArtisan on GitHub (May 23, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/315

Operating Systems

CentOS Linux release 7.6.1810
XFCE 4.12.1
XOrg Nouveau 1.0.15
Qt 5.9.2

Barrier Version

Cloned Git checkout [a3804c4]

Steps to reproduce bug

From an unprivileged shell, type 'barrier'. The 'Barrier' dialog opens.
Tick the 'Server (share this computer's mouse and keyboard):' box, select 'Configure interactively:', then click 'Configure Server...'. The 'Server Configuration' dialog opens.
Attempt to drag the monitor icon in the upper right-hand corner. The window manager instantly locks up. The mouse cursor still moves, but does not update when moved into other windows, nor will other windows take focus. Clicks on Barrier's 'Server Configuration' dialog have no effect either.
Press SHIFT-F2 to switch to a different virtual terminal (CLI mode), login and enter 'killall barrier'. Press SHIFT-F1 to switch back to X11 session. Barrier is shutdown, WM operation is back to normal.

Other info

Problem also exists in v2.1.2.

Originally created by @ElvishArtisan on GitHub (May 23, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/315 ### Operating Systems ### CentOS Linux release 7.6.1810 XFCE 4.12.1 XOrg Nouveau 1.0.15 Qt 5.9.2 ### Barrier Version ### Cloned Git checkout [a3804c4] ### Steps to reproduce bug ### 1) From an unprivileged shell, type 'barrier'. The 'Barrier' dialog opens. 2) Tick the 'Server (share this computer's mouse and keyboard):' box, select 'Configure interactively:', then click 'Configure Server...'. The 'Server Configuration' dialog opens. 3) Attempt to drag the monitor icon in the upper right-hand corner. The window manager instantly locks up. The mouse cursor still moves, but does not update when moved into other windows, nor will other windows take focus. Clicks on Barrier's 'Server Configuration' dialog have no effect either. 4) Press SHIFT-F2 to switch to a different virtual terminal (CLI mode), login and enter 'killall barrier'. Press SHIFT-F1 to switch back to X11 session. Barrier is shutdown, WM operation is back to normal. ### Other info ### Problem also exists in v2.1.2.

gitea-mirror

2026-05-05 05:51:13 -06:00

closed this issue
added the
bug

linux
labels

gitea-mirror commented

2026-05-05 05:51:22 -06:00

Author

Owner

@ElvishArtisan commented on GitHub (May 23, 2019):

Also, FWIW, synergy-1.6.2 works as expected.

@ElvishArtisan commented on GitHub (May 23, 2019): Also, FWIW, synergy-1.6.2 works as expected.

gitea-mirror commented

2026-05-05 05:51:25 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 24, 2019):

Why did you checkout from master? Just curious.

@AdrianKoshka commented on GitHub (May 24, 2019): Why did you checkout from master? Just curious.

gitea-mirror commented

2026-05-05 05:51:28 -06:00

Author

Owner

@ElvishArtisan commented on GitHub (May 24, 2019):

I initially tried v2.1.2, which exhibited the bug. Before submitting a report, I wanted to test the 'bleeding edge' development version to see if the problem had perhaps been swatted already [it hadn't].

Is there a more appropriate branch that I should be testing with?

@ElvishArtisan commented on GitHub (May 24, 2019): I initially tried v2.1.2, which exhibited the bug. Before submitting a report, I wanted to test the 'bleeding edge' development version to see if the problem had perhaps been swatted already [it hadn't]. Is there a more appropriate branch that I should be testing with?

gitea-mirror commented

2026-05-05 05:51:30 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 24, 2019):

Not really. Development is slow, and mostly comes from PRs people make to fix things. I just try to keep the lights on for this project. (Original developers is really busy with life, so they haven't had much time to dedicate to the project).

@AdrianKoshka commented on GitHub (May 24, 2019): Not really. Development is slow, and mostly comes from PRs people make to fix things. I just try to keep the lights on for this project. (Original developers is really busy with life, so they haven't had much time to dedicate to the project).

gitea-mirror commented

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

Author

Owner

@thre-raritan commented on GitHub (Jun 11, 2019):

By the way, the same bug is also in synergy-core 1.10.2. Didn't try older synergy releases.

@thre-raritan commented on GitHub (Jun 11, 2019): By the way, the same bug is also in synergy-core 1.10.2. Didn't try older synergy releases.

gitea-mirror commented

2026-05-05 05:51:37 -06:00

Author

Owner

@truatpasteurdotfr commented on GitHub (Sep 22, 2019):

no issue for 2.3.1-git 0ed18c6b version on CentOS-7 running the default gnome window manager, are you using xfce4 from epel?

@truatpasteurdotfr commented on GitHub (Sep 22, 2019): no issue for 2.3.1-git 0ed18c6b version on CentOS-7 running the default gnome window manager, are you using xfce4 from epel?

gitea-mirror commented

2026-05-05 05:51:39 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

Since there was no activity, I'm assuming this bug no longer happens. Please reopen the github issue if this is not the case.

@p12tic commented on GitHub (Jan 10, 2021): Since there was no activity, I'm assuming this bug no longer happens. Please reopen the github issue if this is not the case.

gitea-mirror referenced this issue

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

[PR #252] [MERGED] Fire screen switch event on client disconnect #1589