github-starred/barrier

Fork 0

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

[GH-ISSUE #647] Switching key stops working, registered as group 0 key after some time or event #516

New issue

Open

opened 2026-05-05 06:34:32 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

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

Owner

Originally created by @sim590 on GitHub (May 2, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/647

Switching from client to server will not work using keystrokes, but this does work the other way around, i.e from the server to the client. This is not always the case and I'm not sure how it occurs.

Operating Systems

Server: GNU/Linux (distro: Debian)

Client: GNU/Linux (distro: Archlinux)

Barrier Version

I compiled both client and server myself on b6a1b574.

barriers 2.3.2-snapshot
Protocol version 1.6
Copyright (C) 2018 Debauchee Open Source Group
Copyright (C) 2012-2016 Symless Ltd.
Copyright (C) 2008-2014 Nick Bolton
Copyright (C) 2002-2014 Chris Schoeneman

Steps to reproduce bug

Not sure for now.

Other info

When did the problem start to occur? Recently, but it is also occuring on synergy's master branch (0b3068b5).
Is there a way to work around it? You have to restart X. Simply restarting either client or server won't do it.
Does this bug prevent you from using Barrier entirely? No.... but it's irritating to use the mouse personally. I always use the keyboard for doing everything including moving windows with the Awesome window manager so I kind of abandon the idea of using it when it happens and I have lots of windows opened and on-going work that I don't want to put on pause just to restart X...

Here I'm linking the log that I'm getting on the client:

barrier-bug-hotkey-cant-switch.log

Notice the lines with INFO: found key in group 0. These happen everytime I hit CTRL+ALT+K to switch back to the server but I can't since it is registered as a "group 0" key which I'm guessing is a passthrough or unregistered key.

Over the server, I was getting no output with -d DEBUG flags when hitting the key.

Here is my config file:

barrier_conf.txt

EDIT (2020-05-03)

My two computers are laptops and I regularly configure the screens using xrandr for configuring an extra monitor. Both of my laptops can claim the same monitor as a second monitor at some point.
I use a thinkpad docking station for connecting one of my laptops to the screen, so this means that I regularly connect and disconnect the screen and go from 1 to two monitors and vice versa.
Normally, when I first start barrier (on both client and server) and, then connect the monitor on the server, the boundaries of the screen are not well known by barrier and the mouse behaves weirdly. I have to restart barrier so that it can learn about the new screen settings.
Normally, when connecting my laptop (the server) to the docking station, I also run a script to configure my keyboard that is connected to the docking station (note that the script is making use of this Xmodmap config).
May be a combination of those things could be related to what I'm experiencing or may be it could trigger it, but I'm not sure for now.

Originally created by @sim590 on GitHub (May 2, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/647 Switching from client to server will not work using keystrokes, but this does work the other way around, i.e from the server to the client. This is not always the case and I'm not sure how it occurs. ### Operating Systems ### Server: GNU/Linux (distro: Debian) Client: GNU/Linux (distro: Archlinux) ### Barrier Version ### I compiled both client and server myself on b6a1b574. ``` barriers 2.3.2-snapshot Protocol version 1.6 Copyright (C) 2018 Debauchee Open Source Group Copyright (C) 2012-2016 Symless Ltd. Copyright (C) 2008-2014 Nick Bolton Copyright (C) 2002-2014 Chris Schoeneman ``` ### Steps to reproduce bug ### Not sure for now. ### Other info ### * **When did the problem start to occur?** Recently, but it is also occuring on synergy's master branch (0b3068b5). * **Is there a way to work around it?** You have to restart X. Simply restarting either client or server won't do it. * **Does this bug prevent you from using Barrier entirely?** No.... but it's irritating to use the mouse personally. I always use the keyboard for doing everything including moving windows with the Awesome window manager so I kind of abandon the idea of using it when it happens and I have lots of windows opened and on-going work that I don't want to put on pause just to restart X... Here I'm linking the log that I'm getting on the client: [barrier-bug-hotkey-cant-switch.log](https://github.com/debauchee/barrier/files/4567047/barrier-bug-hotkey-cant-switch.log) Notice the lines with `INFO: found key in group 0`. These happen everytime I hit `CTRL+ALT+K` to switch back to the server but I can't since it is registered as a "group 0" key which I'm guessing is a passthrough or unregistered key. Over the server, I was getting no output with `-d DEBUG` flags when hitting the key. Here is my config file: [barrier_conf.txt](https://github.com/debauchee/barrier/files/4567051/barrier_conf.txt) **EDIT (2020-05-03)** * My two computers are laptops and I regularly configure the screens using `xrandr` for configuring an extra monitor. Both of my laptops can claim the same monitor as a second monitor at some point. * I use a thinkpad docking station for connecting one of my laptops to the screen, so this means that I regularly connect and disconnect the screen and go from 1 to two monitors and vice versa. * Normally, when I first start barrier (on both client and server) and, then connect the monitor on the server, the boundaries of the screen are not well known by barrier and the mouse behaves weirdly. I have to restart barrier so that it can learn about the new screen settings. * Normally, when connecting my laptop (the server) to the docking station, I also run [a script][script] to configure my keyboard that is connected to the docking station (note that the script is making use of [this Xmodmap config][xmodmap]). * May be a combination of those things could be related to what I'm experiencing or may be it could trigger it, but I'm not sure for now. [script]: https://github.com/sim590/dotfiles/blob/master/bin/setkeyboard [xmodmap]: https://github.com/sim590/dotfiles/blob/master/Xmodmap

gitea-mirror commented

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

Author

Owner

@Miradden commented on GitHub (May 3, 2020):

bump. I have the exact same problem, started happening today. I can't switch screens using the keyboard or use scroll lock to keep the cursor on one screen which leads to the mouse not working in some applications. Server is Arch and my client is windows

@Miradden commented on GitHub (May 3, 2020): bump. I have the exact same problem, started happening today. I can't switch screens using the keyboard or use scroll lock to keep the cursor on one screen which leads to the mouse not working in some applications. Server is Arch and my client is windows

gitea-mirror commented

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

Author

Owner

@sim590 commented on GitHub (May 4, 2020):

It happened today and, up to now, it seems to happen concurrently with some other issue I have that I would normally classify as independent, but since they're very similar and they happen at the same time, I'm mentioning it here.

So, at the same time, I also experience that another key combination configured for the Awesome Window Manager stops working. The key combination is ALT+SHIFT+[0-9] where [1-9] is a regular expression here.

On Barrier, the key combination is CTRL+ALT+k (for going to the left).

I found this strange that both happen. Again, it could be orthogonal problems.

@sim590 commented on GitHub (May 4, 2020): It happened today and, up to now, it seems to happen concurrently with some other issue I have that I would normally classify as independent, but since they're very similar and they happen at the same time, I'm mentioning it here. So, at the same time, I also experience that another key combination configured for the [Awesome Window Manager][awesome] stops working. The key combination is `ALT+SHIFT+[0-9]` where `[1-9]` is a regular expression here. On Barrier, the key combination is `CTRL+ALT+k` (for going to the left). I found this strange that both happen. Again, it could be orthogonal problems. [awesome]: https://awesomewm.org/

gitea-mirror commented

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

Author

Owner

@sim590 commented on GitHub (May 4, 2020):

Further information about my setup:

My two computers are laptops and I regularly configure the screens using xrandr for configuring an extra monitor. Both of my laptops can claim the same monitor as a second monitor at some point.
I use a thinkpad docking station for connecting one of my laptops to the screen, so this means that I regularly connect and disconnect the screen and go from 1 to two monitors and vice versa.
Normally, when I first start barrier (on both client and server) and, then connect the monitor on the server, the boundaries of the screen are not well known by barrier and the mouse behaves weirdly. I have to restart barrier so that it can learn about the new screen settings.
Normally, when connecting my laptop (the server) to the docking station, I also run a script to configure my keyboard that is connected to the docking station (note that the script is making use of this Xmodmap config).
May be a combination of those things could be related to what I'm experiencing or may be it could trigger it, but I'm not sure for now.

I will copy/paste this new info in the OP.

@sim590 commented on GitHub (May 4, 2020): Further information about my setup: * My two computers are laptops and I regularly configure the screens using `xrandr` for configuring an extra monitor. Both of my laptops can claim the same monitor as a second monitor at some point. * I use a thinkpad docking station for connecting one of my laptops to the screen, so this means that I regularly connect and disconnect the screen and go from 1 to two monitors and vice versa. * Normally, when I first start barrier (on both client and server) and, then connect the monitor on the server, the boundaries of the screen are not well known by barrier and the mouse behaves weirdly. I have to restart barrier so that it can learn about the new screen settings. * Normally, when connecting my laptop (the server) to the docking station, I also run [a script][script] to configure my keyboard that is connected to the docking station (note that the script is making use of [this Xmodmap config][xmodmap]). * May be a combination of those things could be related to what I'm experiencing or may be it could trigger it, but I'm not sure for now. I will copy/paste this new info in the OP. [script]: https://github.com/sim590/dotfiles/blob/master/bin/setkeyboard [xmodmap]: https://github.com/sim590/dotfiles/blob/master/Xmodmap

gitea-mirror commented

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

Author

Owner

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