[GH-ISSUE #641] CTRL key does not work in client VMs

gitea-mirror commented

2026-05-05 06:33:40 -06:00

Owner

Originally created by @stutopp on GitHub (Apr 28, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/641

Operating Systems

Server: Windows 10 Pro Build# 1903

Client: Ubuntu 18.04 LTS

Barrier Version

2.3.2-snapshot-210c2b70

Steps to reproduce bug

Click into any VMWare Workstation 15 Pro VM on the client (tested with Kali , Win10, Debian, Ubuntu, CentOS images)
Do any CTRL + command
Watch nothing happen

Other info

Problem has occurred since installation
Able to use physical keyboard on client as a workaround.
Does this bug prevent you from using Barrier entirely? No

Standing by to provide more deets upon request.

Originally created by @stutopp on GitHub (Apr 28, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/641 ### Operating Systems ### Server: Windows 10 Pro Build# 1903 Client: Ubuntu 18.04 LTS ### Barrier Version ### 2.3.2-snapshot-210c2b70 ### Steps to reproduce bug ### 1. Click into any VMWare Workstation 15 Pro VM on the client (tested with Kali , Win10, Debian, Ubuntu, CentOS images) 2. Do any CTRL + command 3. Watch nothing happen ### Other info ### * Problem has occurred since installation * Able to use physical keyboard on client as a workaround. * Does this bug prevent you from using Barrier entirely? No Standing by to provide more deets upon request.

gitea-mirror added the

bug

windows

linux

labels 2026-05-05 06:33:40 -06:00

gitea-mirror commented

2026-05-05 06:33:46 -06:00

Author

Owner

@dsyens commented on GitHub (Jun 1, 2020):

I'm experiencing a similar issue. Barrier host is on Windows 10, Client is a POP_OS System76 laptop. CTRL key is recognized on the POP_OS portion of the laptop, but is not recognized by any VMWare Players on the client. Workaround is same as jasonbourne, physical keyboard is still an option.

@dsyens commented on GitHub (Jun 1, 2020): I'm experiencing a similar issue. Barrier host is on Windows 10, Client is a POP_OS System76 laptop. CTRL key is recognized on the POP_OS portion of the laptop, but is not recognized by any VMWare Players on the client. Workaround is same as jasonbourne, physical keyboard is still an option.

gitea-mirror commented

2026-05-05 06:33:49 -06:00

Author

Owner

@sungod808 commented on GitHub (Jul 24, 2020):

Same issue here. Host is Ubuntu, Client= Debian vm and Windows10 vm. All keys are working except for CTRL + anything inside the vm client.

@sungod808 commented on GitHub (Jul 24, 2020): Same issue here. Host is Ubuntu, Client= Debian vm and Windows10 vm. All keys are working except for CTRL + anything inside the vm client.

gitea-mirror commented

2026-05-05 06:33:53 -06:00

Author

Owner

@cameronbraid commented on GitHub (Sep 2, 2020):

I have same issue, server linux client osx, CTRL key doesnt work at all

@cameronbraid commented on GitHub (Sep 2, 2020): I have same issue, server linux client osx, CTRL key doesnt work at all

gitea-mirror commented

2026-05-05 06:33:55 -06:00

Author

Owner

@cameronbraid commented on GitHub (Sep 2, 2020):

CTRL works with switching tabs in chrome.. CTRL+TAB and CTRL+SHIFT+TAB but not CTRL+C for copy, CTRL+N for new tab

@cameronbraid commented on GitHub (Sep 2, 2020): CTRL works with switching tabs in chrome.. CTRL+TAB and CTRL+SHIFT+TAB but not CTRL+C for copy, CTRL+N for new tab

gitea-mirror commented

2026-05-05 06:33:56 -06:00

Author

Owner

@cameronbraid commented on GitHub (Sep 2, 2020):

also in a html textarea CTRL+SHIFT+RIGHT/CTRL+SHIFT+LEFT selects to the end/start of the line as expected, but CTRL+RIGHT/CTRL+LEFT doesn't move cursor to end/start of line as expected

@cameronbraid commented on GitHub (Sep 2, 2020): also in a html textarea CTRL+SHIFT+RIGHT/CTRL+SHIFT+LEFT selects to the end/start of the line as expected, but CTRL+RIGHT/CTRL+LEFT doesn't move cursor to end/start of line as expected

gitea-mirror commented

2026-05-05 06:33:58 -06:00

Author

Owner

@lilws commented on GitHub (Oct 11, 2020):

I use windows 10 as server, and MacOS as client. I think I got similiar issue but with Windows/Cmd key. It works partiatly. In MacOS, the windows key would work as many different function like hold Ctrl key in Windows. So I can't use Cmd key to choose different folders in Finder. In Chrome, I can't hold Cmd to Ctrl+Click.

@lilws commented on GitHub (Oct 11, 2020): I use windows 10 as server, and MacOS as client. I think I got similiar issue but with Windows/Cmd key. It works partiatly. In MacOS, the windows key would work as many different function like hold Ctrl key in Windows. So I can't use Cmd key to choose different folders in Finder. In Chrome, I can't hold Cmd to Ctrl+Click.

gitea-mirror commented

2026-05-05 06:33:59 -06:00

Author

Owner

@krdian commented on GitHub (Apr 1, 2021):

Same setup as @lilws has. I cannot use Ctrl key on remote end. Is there any workaround for that ?

@krdian commented on GitHub (Apr 1, 2021): Same setup as @lilws has. I cannot use Ctrl key on remote end. Is there any workaround for that ?

gitea-mirror commented

2026-05-05 06:34:00 -06:00

Author

Owner

@licentiapoetica commented on GitHub (Jan 11, 2023):

I have a similar issue.
Host is Arch Linux and my Client also runs Arch Linux, in the Client the Control Key works perfectly but when I enter the Horizon VM Client on my Client machine the CTRL Key doesnt get recognized

@licentiapoetica commented on GitHub (Jan 11, 2023): I have a similar issue. Host is Arch Linux and my Client also runs Arch Linux, in the Client the Control Key works perfectly but when I enter the Horizon VM Client on my Client machine the CTRL Key doesnt get recognized

gitea-mirror commented

2026-05-05 06:34:01 -06:00

Author

Owner

@S1L1K0N commented on GitHub (Feb 9, 2023):

I have a similar issue. Barrier server is Windows 10, client is MX Linux 5.10.0-21, VMware guest is Kali Linux 2022.4. CTRL-C works fine in the Barrier client MX Linux, but is not getting passed through to VMware guest.

@S1L1K0N commented on GitHub (Feb 9, 2023): I have a similar issue. Barrier server is Windows 10, client is MX Linux 5.10.0-21, VMware guest is Kali Linux 2022.4. CTRL-C works fine in the Barrier client MX Linux, but is not getting passed through to VMware guest.

gitea-mirror commented

2026-05-05 06:34:04 -06:00

Author

Owner

@saeedbs commented on GitHub (Oct 22, 2025):

I have similiar issue server is ubuntu 22.04 and clients is kubuntu 24.04 , ctrl key or maybe key combination doesn't work work on VMware vm.

@saeedbs commented on GitHub (Oct 22, 2025): I have similiar issue server is ubuntu 22.04 and clients is kubuntu 24.04 , ctrl key or maybe key combination doesn't work work on VMware vm.

gitea-mirror commented

2026-05-05 06:34:06 -06:00

Author

Owner

@nbolton commented on GitHub (Oct 22, 2025):

Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork).

https://github.com/deskflow/deskflow
https://github.com/input-leap/input-leap

If this is still an issue in those projects, we would appreciate a cross-post of this issue.

@nbolton commented on GitHub (Oct 22, 2025): Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork). https://github.com/deskflow/deskflow https://github.com/input-leap/input-leap If this is still an issue in those projects, we would appreciate a cross-post of this issue.

gitea-mirror commented

2026-05-05 06:34:07 -06:00

Author

Owner

@saeedbs commented on GitHub (Oct 27, 2025):

Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork).

https://github.com/deskflow/deskflow https://github.com/input-leap/input-leap

If this is still an issue in those projects, we would appreciate a cross-post of this issue.

sad.... they both look pretty disappointing to me .... deskflow on ubuntu 24.04 (which is most recent LTS version) needs flatpak no deb package release for such a major distro (its seems package is for ubuntu 25 non lts 6 month support release) .... and other one looks even worse ...
barrier was pretty straight forward ... install and done .... no unusual dependency ...or flatpak ...
it seems I should stick to barrier ...

@saeedbs commented on GitHub (Oct 27, 2025): > Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork). > > https://github.com/deskflow/deskflow https://github.com/input-leap/input-leap > > If this is still an issue in those projects, we would appreciate a cross-post of this issue. sad.... they both look pretty disappointing to me .... deskflow on ubuntu 24.04 (which is most recent LTS version) needs flatpak no deb package release for such a major distro (its seems package is for ubuntu 25 non lts 6 month support release) .... and other one looks even worse ... barrier was pretty straight forward ... install and done .... no unusual dependency ...or flatpak ... it seems I should stick to barrier ...

gitea-mirror commented

2026-05-05 06:34:09 -06:00

Author

Owner

@nbolton commented on GitHub (Oct 27, 2025):

I worry this may be getting a bit off topic, but I do have some thoughts on this.

Edit: Should this be moved to a new discussion?

pretty disappointing to me .... deskflow on ubuntu 24.04 (which is most recent LTS version) needs flatpak no deb package release for such a major distro

@sithlord48 Just thinking out loud...

I believe this frustration is fairly representative of a high number of Linux users. I know you're not a big fan of Ubuntu (I believe you said it's not a real distro), but it still represents the largest segment of users (about 1/3). Since Ubuntu 24.04 is still the primary/current download, a large chunk of Ubuntu users will be on that version, and adoption of new versions is generally very slow. Ubuntu Plucky (25.04) was released in April 2025 but it's not the primary download (I guess because it's not an LTS release), so most Ubuntu users won't be using it. I'm guessing the next version they display predominantly will be Ubuntu 26.04.

Flatpak is divisive and often unpopular in the Ubuntu world and their users are conditioned to expect .deb or Snap packages, and the absence of a .deb for 24.04 creates some frustration. It appears that forks succeeded in the past because they delivered a straightforward install inline with what Ubuntu users are used to.

With Deskflow, do we want broad adoption or do we want to stick to our principles of being leading edge and focused on newer distro releases?

@nbolton commented on GitHub (Oct 27, 2025): I worry this may be getting a bit off topic, but I do have some thoughts on this. Edit: Should this be moved to a new discussion? > pretty disappointing to me .... deskflow on ubuntu 24.04 (which is most recent LTS version) needs flatpak no deb package release for such a major distro @sithlord48 Just thinking out loud... I believe this frustration is fairly representative of a high number of Linux users. I know you're not a big fan of Ubuntu (I believe you said it's not a real distro), but it still represents the largest segment of users (about 1/3). Since Ubuntu 24.04 is still the primary/current download, a large chunk of Ubuntu users will be on that version, and adoption of new versions is generally very slow. Ubuntu Plucky (25.04) was released in April 2025 but it's not the primary download (I guess because it's not an LTS release), so most Ubuntu users won't be using it. I'm guessing the next version they display predominantly will be Ubuntu 26.04. Flatpak is divisive and often unpopular in the Ubuntu world and their users are conditioned to expect `.deb` or Snap packages, and the absence of a `.deb` for 24.04 creates some frustration. It appears that forks succeeded in the past because they delivered a straightforward install inline with what Ubuntu users are used to. With Deskflow, do we want broad adoption or do we want to stick to our principles of being leading edge and focused on newer distro releases? <img width="768" height="737" alt="Image" src="https://github.com/user-attachments/assets/494b5030-bcee-4003-b9c7-117703aecd3e" /> <img width="706" height="492" alt="Image" src="https://github.com/user-attachments/assets/286d1bf1-13b7-40cc-a04f-b55b0ebf7c3f" />

gitea-mirror commented

2026-05-05 06:34:10 -06:00

Author

Owner

@sithlord48 commented on GitHub (Oct 27, 2025):

@nbolton We can not package it due to things the distro is missing. If an ubuntu user cared enough they could make a PPA with the additional packages needed for proper support (libei, libportal, portal backends, etc..) or a Snap. The flatpak works fine I use it daily myself on my Kubuntu 24.04 client. If they don't want to use the flatpak for whatever reason then they can use input-leap or barrier. If your distro only packs barrier or input-leap that's fine they will still be able to talk to those with Deskflow installed.

For me It's not about getting everyone to use Deskflow everywhere, It's about fixing the broken stuff and having code that is future ready.

Edit: Canonical chooses to not support flatpaks out of the box and instead only their NIH solution.

@sithlord48 commented on GitHub (Oct 27, 2025): @nbolton We can not package it due to things the distro is missing. If an ubuntu user cared enough they could make a PPA with the additional packages needed for proper support (libei, libportal, portal backends, etc..) or a Snap. The flatpak works fine I use it daily myself on my Kubuntu 24.04 client. If they don't want to use the flatpak for whatever reason then they can use input-leap or barrier. If your distro only packs barrier or input-leap that's fine they will still be able to talk to those with Deskflow installed. For me It's not about getting everyone to use Deskflow everywhere, It's about fixing the broken stuff and having code that is future ready. Edit: Canonical chooses to not support flatpaks out of the box and instead only their NIH solution.

Rows
Columns

[GH-ISSUE #641] CTRL key does not work in client VMs #510

Operating Systems

Barrier Version

Steps to reproduce bug

Other info