[GH-ISSUE #1020] Server cannot be a recipient of it's own hotkey invoked keystrokes. #810

Open
opened 2026-05-05 07:10:27 -06:00 by gitea-mirror · 1 comment
Owner

Originally created by @BLARGoMATIC on GitHub (Jan 11, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1020

Describe the bug
Similar issue to #838 However, using the wildcard * in keystroke(key[,screens]) or even the server only results in a useless hotkey, along with that keystroke being blocked from normal use on the server.

To Reproduce

Steps to reproduce the behavior:

  1. Set a hotkey of any keystroke to point to the server, or use the wildcard for all screens.
  2. Use the Hokey
  3. Monitor for actions of the hotkey on both the server and the client(s) (if using wildcard).
  4. Server machine does receive the keystroke, furthermore, if the keystroke combination had a purpose before the hotkey (OS level, other programs), that purpose no longer detects the keystroke either.

Expected behavior
Using the example from #838:
keystroke(Control+a,server) should be redundant, and have no noticeable effect. (Select-all continuing to work as intended)
keystroke(Control+a,*) should send the keystroke to the client(s) (which it does) in addition to the keystroke being sent to the server, keeping the Select-all command functioning on the server computer (which it doesn't).

Screenshots

section: screens
	Cthulhu: #Client
		halfDuplexCapsLock = false
		halfDuplexNumLock = false
		halfDuplexScrollLock = false
		xtestIsXineramaUnaware = false
		preserveFocus = false
		switchCorners = none 
		switchCornerSize = 0
	Jabberwocky: #Server
		halfDuplexCapsLock = false
		halfDuplexNumLock = false
		halfDuplexScrollLock = false
		xtestIsXineramaUnaware = false
		preserveFocus = true
		switchCorners = none 
		switchCornerSize = 0
end

section: aliases
end

section: links
	Cthulhu:
		right = Jabberwocky
	Jabberwocky:
		left = Cthulhu
end

section: options
	heartbeat = 5000
	relativeMouseMoves = false
	screenSaverSync = false
	win32KeepForeground = false
	clipboardSharing = true
	switchCorners = none 
	switchCornerSize = 0
	keystroke(AudioPlay) = keystroke(AudioPlay,Cthulhu)
	keystroke(AudioNext) = keystroke(AudioNext,Cthulhu)
	keystroke(AudioPrev) = keystroke(AudioPrev,Cthulhu)
	keystroke(Control+a) = keystroke(Control+a,*) # Added for testing, keystroke does not appear to register on Jabberwocky
end

Desktop (please complete the following information):

  • OS: Windows 10 2004 on Server, and Windows 10 20H2 on Client
  • Barrier version 2.3.3-release-3395cca9

Additional context

I haven't looked too far in finding why this is, but I assume it's due to the keystroke being sent by barrier triggering itself on the server.

Originally created by @BLARGoMATIC on GitHub (Jan 11, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1020 **Describe the bug** Similar issue to #838 However, using the wildcard * in `keystroke(key[,screens])` or even the server only results in a useless hotkey, along with that keystroke being blocked from normal use on the server. **To Reproduce** Steps to reproduce the behavior: 1. Set a hotkey of any keystroke to point to the server, or use the wildcard for all screens. 2. Use the Hokey 3. Monitor for actions of the hotkey on both the server and the client(s) (if using wildcard). 4. Server machine does receive the keystroke, furthermore, if the keystroke combination had a purpose before the hotkey (OS level, other programs), that purpose no longer detects the keystroke either. **Expected behavior** Using the example from #838: `keystroke(Control+a,server)` should be redundant, and have no noticeable effect. (Select-all continuing to work as intended) `keystroke(Control+a,*)` should send the keystroke to the client(s) (which it does) in addition to the keystroke being sent to the server, keeping the Select-all command functioning on the server computer (which it doesn't). **Screenshots** ``` section: screens Cthulhu: #Client halfDuplexCapsLock = false halfDuplexNumLock = false halfDuplexScrollLock = false xtestIsXineramaUnaware = false preserveFocus = false switchCorners = none switchCornerSize = 0 Jabberwocky: #Server halfDuplexCapsLock = false halfDuplexNumLock = false halfDuplexScrollLock = false xtestIsXineramaUnaware = false preserveFocus = true switchCorners = none switchCornerSize = 0 end section: aliases end section: links Cthulhu: right = Jabberwocky Jabberwocky: left = Cthulhu end section: options heartbeat = 5000 relativeMouseMoves = false screenSaverSync = false win32KeepForeground = false clipboardSharing = true switchCorners = none switchCornerSize = 0 keystroke(AudioPlay) = keystroke(AudioPlay,Cthulhu) keystroke(AudioNext) = keystroke(AudioNext,Cthulhu) keystroke(AudioPrev) = keystroke(AudioPrev,Cthulhu) keystroke(Control+a) = keystroke(Control+a,*) # Added for testing, keystroke does not appear to register on Jabberwocky end ``` **Desktop (please complete the following information):** - OS: Windows 10 2004 on Server, and Windows 10 20H2 on Client - Barrier version 2.3.3-release-3395cca9 **Additional context** I haven't looked too far in finding why this is, but I assume it's due to the keystroke being sent by barrier triggering itself on the server.
Author
Owner

@BLARGoMATIC commented on GitHub (Jan 11, 2021):

Looks like people are having similar problems with synergy:
https://members.symless.com/forums/topic/6223-hotkey-for-server-and-client/?tab=comments#comment-28839

https://members.symless.com/forums/topic/6088-hotkey-binding-stopping-funtionality-of-keyboard-input/?tab=comments#comment-28202

not much help in fixing it, and it shows it was a problem before barrier was forked.

<!-- gh-comment-id:757614378 --> @BLARGoMATIC commented on GitHub (Jan 11, 2021): Looks like people are having similar problems with synergy: https://members.symless.com/forums/topic/6223-hotkey-for-server-and-client/?tab=comments#comment-28839 https://members.symless.com/forums/topic/6088-hotkey-binding-stopping-funtionality-of-keyboard-input/?tab=comments#comment-28202 not much help in fixing it, and it shows it was a problem before barrier was forked.
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#810
No description provided.