github-starred/barrier

Fork 0

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

[GH-ISSUE #815] Hotkeys to capture mouse do not work when mouse is on secondary screen #648

New issue

Open

opened 2026-05-05 06:50:12 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 06:50:12 -06:00

Owner

Originally created by @roothorick on GitHub (Jul 26, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/815

Operating Systems

Server: Ubuntu 20.04 LTS

Client: Windows 10 Version 2004

Barrier Version

2.3.3-release

Steps to reproduce bug

Move mouse to secondary screen
Press hardcoded hotkey (scroll lock) to lock cursor
Move mouse back to primary screen

Manually created hotkeys are affected as well.

I can capture the mouse on the primary screen just fine.

Other info

When did the problem start to occur? Immediately
Is there a way to work around it? Not as far as I've found
Does this bug prevent you from using Barrier entirely? No

As a partial workaround, is there a way to lock the mouse cursor without using a hotkey?

Originally created by @roothorick on GitHub (Jul 26, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/815 ### Operating Systems ### Server: Ubuntu 20.04 LTS Client: Windows 10 Version 2004 ### Barrier Version ### 2.3.3-release ### Steps to reproduce bug ### 1. Move mouse to secondary screen 2. Press hardcoded hotkey (scroll lock) to lock cursor 3. Move mouse back to primary screen Manually created hotkeys are affected as well. I can capture the mouse on the primary screen just fine. ### Other info ### * When did the problem start to occur? Immediately * Is there a way to work around it? Not as far as I've found * Does this bug prevent you from using Barrier entirely? No As a partial workaround, is there a way to lock the mouse cursor without using a hotkey?

gitea-mirror commented

2026-05-05 06:50:16 -06:00

Author

Owner

@roothorick commented on GitHub (Jul 30, 2020):

After noticing it sometimes working and sometimes not working, I narrowed it down (hopefully).

The server has multiple keyboard layouts switched between with Meta+Space. It appears to be:

If the first keyboard layout on the server (US QWERTY) is selected, hotkeys work on all windows.
If the second keyboard layout on the server (US Dvorak) is selected, hotkeys only work on the server.

This includes keys that "do not move", e.g. scroll lock, break.

@roothorick commented on GitHub (Jul 30, 2020): After noticing it sometimes working and sometimes not working, I narrowed it down (hopefully). The server has multiple keyboard layouts switched between with Meta+Space. It *appears* to be: * If the first keyboard layout on the server (US QWERTY) is selected, hotkeys work on all windows. * If the second keyboard layout on the server (US Dvorak) is selected, hotkeys only work on the server. This includes keys that "do not move", e.g. scroll lock, break.

gitea-mirror commented

2026-05-05 06:50:19 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 28, 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.

@github-actions[bot] commented on GitHub (Sep 28, 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.

gitea-mirror commented

2026-05-05 06:50:21 -06:00

Author

Owner

@roothorick commented on GitHub (Sep 28, 2020):

There have been no releases since the issue was filed, no commits since the last release appear relevant at a glance, and there has as yet been no feedback from the developers. This shouldn't be closed yet.

@roothorick commented on GitHub (Sep 28, 2020): There have been no releases since the issue was filed, no commits since the last release appear relevant at a glance, and there has as yet been no feedback from the developers. This shouldn't be closed yet.

gitea-mirror commented

2026-05-05 06:50:24 -06:00

Author

Owner

@Lillecarl commented on GitHub (Oct 15, 2020):

I also have this issue, how do i help troubleshoot? Or is there some way to control barrier via CLI as a workaround?

This only happens to me intermittently, just now because i was using xfreerdp before (i think)

@Lillecarl commented on GitHub (Oct 15, 2020): I also have this issue, how do i help troubleshoot? Or is there some way to control barrier via CLI as a workaround? This only happens to me intermittently, just now because i was using xfreerdp before (i think)

gitea-mirror commented

2026-05-05 06:50:25 -06:00

Author

Owner

@Lillecarl commented on GitHub (Nov 23, 2020):

I can confirm that this happens when the host layout changes. I've been using se and us, and switching back to the right layout on the host fixes the issue.

@Lillecarl commented on GitHub (Nov 23, 2020): I can confirm that this happens when the host layout changes. I've been using se and us, and switching back to the right layout on the host fixes the issue.