github-starred/barrier

Fork 0

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

[GH-ISSUE #1073] When configuring keystrokes in the hotkeys gui, the windows/super key is not captured. #853

New issue

Open

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

gitea-mirror commented

2026-05-05 07:13:10 -06:00

Owner

Originally created by @dlobue on GitHub (Feb 20, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1073

Describe the bug

When configuring keystrokes in the hotkeys gui, the windows/super key is not captured.
This happens when defining the initiating hotkey, as well as when defining keystrokes for the resulting action.

To Reproduce

Steps to reproduce the behavior:

Go to Hotkeys tab in the Server Configuration
Click on New to create a new hotkey
Click on keystroke input
Press the key combination Super+v
Observe that the captured value in the input equals keystroke(v)

Expected behavior

I expect the captured keystroke to read keystroke(Super+v)

Desktop (please complete the following information):

OS: Arch Linux
Barrier version 2.3.3

Additional context

I am not running Wayland. I'm running kde/plasma 5 on x11.
I discovered this issue when I was creating a hotkey to map ctrl+v to super+v for my mac client.

Originally created by @dlobue on GitHub (Feb 20, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1073 **Describe the bug** When configuring keystrokes in the hotkeys gui, the windows/super key is not captured. This happens when defining the initiating hotkey, as well as when defining keystrokes for the resulting action. **To Reproduce** Steps to reproduce the behavior: 1. Go to Hotkeys tab in the Server Configuration 2. Click on `New` to create a new hotkey 3. Click on keystroke input 4. Press the key combination `Super+v` 5. Observe that the captured value in the input equals `keystroke(v)` **Expected behavior** I expect the captured keystroke to read `keystroke(Super+v)` **Desktop (please complete the following information):** - OS: Arch Linux - Barrier version 2.3.3 **Additional context** I am not running Wayland. I'm running kde/plasma 5 on x11. I discovered this issue when I was creating a hotkey to map ctrl+v to super+v for my mac client.

gitea-mirror commented

2026-05-05 07:13:12 -06:00

Author

Owner

@matiferrigno commented on GitHub (Mar 31, 2021):

Did you solve it? Today I read your issue because I was looking the same solution and decided to look on KDE configuration after I notice you use too. Actually I notice that (my) problem** was on KDE and is not a bug on barrier.

@matiferrigno commented on GitHub (Mar 31, 2021): Did you solve it? Today I read your issue because I was looking the same solution and decided to look on KDE configuration after I notice you use too. Actually I notice that (my) problem** was on KDE and is not a bug on barrier.

gitea-mirror commented

2026-05-05 07:13:13 -06:00

Author

Owner

@duhow commented on GitHub (Jul 6, 2021):

Same for me. Debian 11 bullseye x86_64 Linux 5.10.0-6-amd64, KDE 5.78.0 / Plasma 5.20.5. Using last Barrier release 2.3.3 .

@duhow commented on GitHub (Jul 6, 2021): Same for me. Debian 11 bullseye x86_64 Linux 5.10.0-6-amd64, KDE 5.78.0 / Plasma 5.20.5. Using last Barrier release 2.3.3 .

gitea-mirror commented

2026-05-05 07:13:15 -06:00

Author

Owner

@edanaher commented on GitHub (Sep 12, 2021):

I'm also seeing this on NixOS using FVWM, which definitely doesn't eat the keypress. It was easy enough to work around by exporting the config to a text file and adding it there, but it's inconvenient.

@edanaher commented on GitHub (Sep 12, 2021): I'm also seeing this on NixOS using FVWM, which definitely doesn't eat the keypress. It was easy enough to work around by exporting the config to a text file and adding it there, but it's inconvenient.

gitea-mirror commented

2026-05-05 07:13:16 -06:00

Author

Owner

@matiferrigno commented on GitHub (Sep 13, 2021):

I had this issue but I haven't it any more. Try add this config to your screen.

                meta = altgr
                altgr = shift

@matiferrigno commented on GitHub (Sep 13, 2021): I had this issue but I haven't it any more. Try add this config to your screen. ``` meta = altgr altgr = shift ```

gitea-mirror commented

2026-05-05 07:13:17 -06:00

Author

Owner

@PhilCS commented on GitHub (Nov 5, 2021):

~~I tried adding these to my config, but neither works. It's quite unfortunate.~~

keystroke(Control+y) = keystroke(Super+Shift+z,Phils-MacBook-Pro.local)

keystroke(Control+y) = keystroke(Meta+Shift+z,Phils-MacBook-Pro.local)

~~Without Shift, both work, which is really weird. With just Shift+z, Shift is not sent at all.~~

EDIT: For some reason, Z has to be uppercase! This works okay-ish (although far from perfect, you gotta release Ctrl to press Ctrl-Z after)

keystroke(Control+y) = keystroke(Meta+Shift+Z,Phils-MacBook-Pro.local)

Which also works alongside

ctrl = super
super = ctrl

@PhilCS commented on GitHub (Nov 5, 2021): ~~I tried adding these to my config, but neither works. It's quite unfortunate.~~ keystroke(Control+y) = keystroke(Super+Shift+z,Phils-MacBook-Pro.local) keystroke(Control+y) = keystroke(Meta+Shift+z,Phils-MacBook-Pro.local) ~~Without Shift, both work, which is really weird. With just `Shift+z`, Shift is not sent at all.~~ EDIT: For some reason, `Z` has to be uppercase! This works okay-ish (although far from perfect, you gotta release Ctrl to press Ctrl-Z after) keystroke(Control+y) = keystroke(Meta+Shift+Z,Phils-MacBook-Pro.local) Which also works alongside ctrl = super super = ctrl

gitea-mirror commented

2026-05-05 07:13:19 -06:00

Author

Owner

@mhagnumdw commented on GitHub (Aug 16, 2022):

Has anyone found a workaround yet?

@mhagnumdw commented on GitHub (Aug 16, 2022): Has anyone found a workaround yet?

gitea-mirror commented

2026-05-05 07:13:21 -06:00

Author

Owner

@edanaher commented on GitHub (Aug 16, 2022):

Regarding a workaround, as I said above (emphasis added):

I'm also seeing this on NixOS using FVWM, which definitely doesn't eat the keypress. It was easy enough to work around by exporting the config to a text file and adding it there, but it's inconvenient.

More explicitly:

Set up a placeholder key binding without Super.
In the Barrier Menu, select "Save configuration". Save this to a file.
Open up the file in any text editor, and edit the key binding to include Super, similar to how PhilCS did. Mine looks like
keystroke(Alt+Super+Control+j) = switchToScreen(other). Note also his issues with shift; apparently if you want to do something with the Shift modifier, you need to capitalize the key.
Back in Barrier, select "Use existing configuration" and point it at the file you just set up.

Sadly, AFAICT there's no way to import the config back, so you have to either make further updates in the text file (which honestly, I prefer anyway), or else re-export and fix Super every time you update your configuration.

@edanaher commented on GitHub (Aug 16, 2022): Regarding a workaround, as I said above (emphasis added): > I'm also seeing this on NixOS using FVWM, which definitely doesn't eat the keypress. **It was easy enough to work around by exporting the config to a text file and adding it there**, but it's inconvenient. More explicitly: 1. Set up a placeholder key binding without Super. 2. In the Barrier Menu, select "Save configuration". Save this to a file. 3. Open up the file in any text editor, and edit the key binding to include Super, similar to how PhilCS did. Mine looks like `keystroke(Alt+Super+Control+j) = switchToScreen(other)`. Note also his issues with shift; apparently if you want to do something with the Shift modifier, you need to capitalize the key. 4. Back in Barrier, select "Use existing configuration" and point it at the file you just set up. Sadly, AFAICT there's no way to import the config back, so you have to either make further updates in the text file (which honestly, I prefer anyway), or else re-export and fix Super every time you update your configuration.

No labels

Rows
Columns