[GH-ISSUE #671] Enhancement: Ignore keyboard input until the first mouse click after screen change

gitea-mirror commented

2026-05-05 06:36:43 -06:00

Owner

Originally created by @rebroad on GitHub (May 17, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/671

This is happening on Linux and on Windows, on the client and on the server.

What should happen (as with all extended desktops) is that the focus should remain on the last window clicked on, and only change to another window when it is clicked on. (At least, this is the default functionality in Windows, and in Ubuntu).

Although some may want the focus to change, this would be the rarer preference, and in this situation the focus ought to change to whichever window the mouse is over (which it doesn't do currently).

Originally created by @rebroad on GitHub (May 17, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/671 This is happening on Linux and on Windows, on the client and on the server. What should happen (as with all extended desktops) is that the focus should remain on the last window clicked on, and only change to another window when it is clicked on. (At least, this is the default functionality in Windows, and in Ubuntu). Although some may want the focus to change, this would be the rarer preference, and in this situation the focus ought to change to whichever window the mouse is over (which it doesn't do currently).

gitea-mirror added the

enhancement

label 2026-05-05 06:36:43 -06:00

gitea-mirror commented

2026-05-05 06:36:47 -06:00

Author

Owner

@simons-public commented on GitHub (May 17, 2020):

@rebroad There is a preference for preserving focus that you can check on the screen settings for each host. It is in Server Configuration > Screens and links > Double-click on the screen. On the Screen Settings dialog at the bottom right in the "Fixes" section is the "Fix Preserve Focus" setting.

The Synergy Wiki has a pretty decent article that covers all the configuration options if you're curious.

Although I prefer to keep focus on the windows of other machines like you describe (#178), I wouldn't venture to say it should be the default. I think most people would expect focus to stay with just the application on the screen they are currently controlling.

@simons-public commented on GitHub (May 17, 2020): @rebroad There is a preference for preserving focus that you can check on the screen settings for each host. It is in Server Configuration > Screens and links > Double-click on the screen. On the Screen Settings dialog at the bottom right in the "Fixes" section is the "Fix Preserve Focus" setting. The [Synergy Wiki](https://github.com/symless/synergy-core/wiki/Text-Config) has a pretty decent article that covers all the configuration options if you're curious. Although I prefer to keep focus on the windows of other machines like you describe (#178), I wouldn't venture to say it should be the default. I think most people would expect focus to stay with just the application on the screen they are currently controlling.

gitea-mirror commented

2026-05-05 06:36:50 -06:00

Author

Owner

@rebroad commented on GitHub (May 18, 2020):

@simons-public I tried what you suggested but it didn't fix the issue. The focus is still lost when the mouse leaves the desktop. I even tried reloading, and stopping and starting the server, but the issue remains.

To clarify, I do expect the focus to stay with the application I am currently controlling, as you mention, but I do not expect the focus to change just because the mouse moves into the other display - I expect it to change when I click on something else to change the focus.

@rebroad commented on GitHub (May 18, 2020): @simons-public I tried what you suggested but it didn't fix the issue. The focus is still lost when the mouse leaves the desktop. I even tried reloading, and stopping and starting the server, but the issue remains. To clarify, I do expect the focus to stay with the application I am currently controlling, as you mention, but I do not expect the focus to change just because the mouse moves into the other display - I expect it to change when I click on something else to change the focus.

gitea-mirror commented

2026-05-05 06:36:52 -06:00

Author

Owner

@hiuwo commented on GitHub (May 23, 2020):

Hey Rebroad, sorry to reply so late, but you can also try Configure Server > Advanced Settings (Tab) > Dont take foreground window on Windows Server, I dont know what that really means if I am honest, but it works for me for several apps for other window focus issues.

@hiuwo commented on GitHub (May 23, 2020): Hey Rebroad, sorry to reply so late, but you can also try Configure Server > Advanced Settings (Tab) > Dont take foreground window on Windows Server, I dont know what that really means if I am honest, but it works for me for several apps for other window focus issues.

gitea-mirror commented

2026-05-05 06:36:53 -06:00

Author

Owner

@rebroad commented on GitHub (May 29, 2020):

@hiuwo I tried, that but still the same problem - as soon as I move the mouse to another display, the text I am typing no longer is received by the last window clicked on.

@rebroad commented on GitHub (May 29, 2020): @hiuwo I tried, that but still the same problem - as soon as I move the mouse to another display, the text I am typing no longer is received by the last window clicked on.

gitea-mirror commented

2026-05-05 06:36:57 -06:00

Author

Owner

@simons-public commented on GitHub (May 29, 2020):

@rebroad I thought you were just talking about focus before, but I think I might get what you're saying. When you move the mouse to another screen barrier changes the mouse and keyboard to that new screen. If that's what you mean, I believe that's the expected behavior and in line with what a hardware KVM would do as well.

@simons-public commented on GitHub (May 29, 2020): @rebroad I thought you were just talking about focus before, but I think I might get what you're saying. When you move the mouse to another screen barrier changes the mouse *and* keyboard to that new screen. If that's what you mean, I believe that's the expected behavior and in line with what a hardware KVM would do as well.

gitea-mirror commented

2026-05-05 06:37:01 -06:00

Author

Owner

@hiuwo commented on GitHub (May 29, 2020):

@hiuwo I tried, that but still the same problem - as soon as I move the mouse to another display, the text I am typing no longer is received by the last window clicked on.

That is an intended outcome. Back when you need to do hardware KVM as Simin mentioned, a button click on that little box would detach your connected mouse and keyboard from one computer and reroute them to another. Software KVM does exactly that by hotkey or cursor crossing border.

At the moment there is no option for what you want, you have to move your cursor back to the OS in which you want your mouse and keyboard active.

@hiuwo commented on GitHub (May 29, 2020): > @hiuwo I tried, that but still the same problem - as soon as I move the mouse to another display, the text I am typing no longer is received by the last window clicked on. That is an intended outcome. Back when you need to do hardware KVM as Simin mentioned, a button click on that little box would detach your connected mouse and keyboard from one computer and reroute them to another. Software KVM does exactly that by hotkey or cursor crossing border. At the moment there is no option for what you want, you have to move your cursor back to the OS in which you want your mouse and keyboard active.

gitea-mirror commented

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

Author

Owner

@rebroad commented on GitHub (May 29, 2020):

@hiuwo why is this the intended outcome? it's not the default behavior when one has 2 monitors attached to the same OS, so why would this be chosen as the default? it causes more problems than benefit. e.g. if I click on start and then accidentally the mouse moves too far left, it closes the start menu... this is not useful functionality, IMHO.

So, maybe consider this issue a feature request. I do plan to implement this feature at some point when the time to set up a development environment (for windows and Linux), and I strongly suspect that most people would want this to be the default behavior, given this is what most people will be familiar with.

@rebroad commented on GitHub (May 29, 2020): @hiuwo why is this the intended outcome? it's not the default behavior when one has 2 monitors attached to the same OS, so why would this be chosen as the default? it causes more problems than benefit. e.g. if I click on start and then accidentally the mouse moves too far left, it closes the start menu... this is not useful functionality, IMHO. So, maybe consider this issue a feature request. I do plan to implement this feature at some point when the time to set up a development environment (for windows and Linux), and I strongly suspect that most people would want this to be the default behavior, given this is what most people will be familiar with.

gitea-mirror commented

2026-05-05 06:37:08 -06:00

Author

Owner

@hiuwo commented on GitHub (May 29, 2020):

@hiuwo why is this the intended outcome? it's not the default behavior when one has 2 monitors attached to the same OS, so why would this be chosen as the default? it causes more problems than benefit. e.g. if I click on start and then accidentally the mouse moves too far left, it closes the start menu... this is not useful functionality, IMHO.

So, maybe consider this issue a feature request. I do plan to implement this feature at some point when the time to set up a development environment (for windows and Linux), and I strongly suspect that most people would want this to be the default behavior, given this is what most people will be familiar with.

When I say it is intended, I mean a software KVM is meant to replace what a Hardware KVM can do, in a simple efficient way. And a Hardware KVM switch would have never been able to do what you described. Therefore I just wanted to state that your scenario is not a bug.

It is not a choice that the program runs this way. The biggest challange is that in order to make happen what you propose, it is - lot more complicated than that the devs can choose to pertain which window from which OS to control, because they are not monitors of the same OS but two completely different OSes, and there is no existing way of focus window information communicating across over the OSes. In my humble opinion, this “quality of life” improvement may even require a kernel level snoop unless screen capturing and machine learning is involved, which, either way, is extremely out of portion. Synergy/Barrier cannot have this function without almost having the devs writing half a new app for just that purpose.

Having said the above, I am not for nor against your proposal. I just wanted to chip in about the actual meaning of a KVM switch. And while I think it is a very niche demand and more higher priority fixes are due before such, I, as a user, can imagine a few/ some users can be benefited by it. So I do hope you can come up with a good / smart way to code and implement this :)!!
As for your problem about moving too far left, I assume you mean this is in case of your other OS being placed on the left, and crossing the cursor over the border by accident is problematic. Well, the software KVM currently allows you to set delays, double-click confirmation, safety corners, hotkeys for border locking and transfer, etc. Use them for now.

@hiuwo commented on GitHub (May 29, 2020): > @hiuwo why is this the intended outcome? it's not the default behavior when one has 2 monitors attached to the same OS, so why would this be chosen as the default? it causes more problems than benefit. e.g. if I click on start and then accidentally the mouse moves too far left, it closes the start menu... this is not useful functionality, IMHO. > > So, maybe consider this issue a feature request. I do plan to implement this feature at some point when the time to set up a development environment (for windows and Linux), and I strongly suspect that most people would want this to be the default behavior, given this is what most people will be familiar with. When I say it is intended, I mean a software KVM is meant to replace what a Hardware KVM can do, in a simple efficient way. And a Hardware KVM switch would have never been able to do what you described. Therefore I just wanted to state that your scenario is not a bug. It is not a choice that the program runs this way. The biggest challange is that in order to make happen what you propose, it is - lot more complicated than that the devs can choose to pertain which window from which OS to control, because they are not monitors of the same OS but two completely different OSes, and there is no existing way of focus window information communicating across over the OSes. In my humble opinion, this “quality of life” improvement may even require a kernel level snoop unless screen capturing and machine learning is involved, which, either way, is extremely out of portion. Synergy/Barrier cannot have this function without almost having the devs writing half a new app for just that purpose. Having said the above, I am not for nor against your proposal. I just wanted to chip in about the actual meaning of a KVM switch. And while I think it is a very niche demand and more higher priority fixes are due before such, I, as a user, can imagine a few/ some users can be benefited by it. So I do hope you can come up with a good / smart way to code and implement this :)!! As for your problem about moving too far left, I assume you mean this is in case of your other OS being placed on the left, and crossing the cursor over the border by accident is problematic. Well, the software KVM currently allows you to set delays, double-click confirmation, safety corners, hotkeys for border locking and transfer, etc. Use them for now.

gitea-mirror commented

2026-05-05 06:37:10 -06:00

Author

Owner

@jalbert-dev commented on GitHub (Jun 13, 2020):

I've had similar issues with window focus using Barrier. My own setup is a Ubuntu 19.04 host with a Windows 10 client (both single-monitor), so the "Don't take foreground window on Windows hosts" setting doesn't (or shouldn't!) have any effect. As an example of what issues crop up:

If the host's foreground application is one that pauses, mutes audio, etc. when losing focus, that action will occur when moving the mouse across to the client screen
Related, if the host's foreground application is fullscreen (such as with games or media players!), moving the mouse to the client screen will cause that application to minimize as if the user alt-tabbed out of it

I'll admit I've not personally used a hardware KVM before, and I don't have much experience with window systems, so I could be wrong about this, but I don't feel like this behavior makes sense. I would expect mouse and keyboard events to be sent to the screen containing the mouse cursor, yes, but I don't see any reason why the host machine should lose window focus here; there shouldn't be any issue with each OS having its own foreground window. As-is, it's impossible to play a fullscreen movie on the host while browsing the web on the client.

I ran into both of those problems I mentioned and found them to be unacceptable usability issues, so I went digging around in the source and managed to "fix" the issue in my case by removing an m_isPrimary check from XWindowsScreen::leave()'s implementation.

From what I can tell, for XWindowsScreens m_isPrimary is always true for servers/hosts, and always false for clients, meaning in the current master it's impossible for XWindows hosts to preserve window focus when the cursor leaves the screen, regardless of settings. (Which is not me saying that's wrong or something; like I said, my knowledge of window systems is limited!)

After removing the check I've been running for at least a month now with no issues and with expected behavior (both host and client have their own foreground windows, but input events sent only to one of the two; perfect!). Still, I don't know if my dumb one-line hack would cause issues on other setups. I'd like to hear some feedback regardless, though, because this definitely seems like an issue to me.

(Hopefully this is what OP was talking about. If not, I can open a separate issue.)

EDIT: Double-checking things leads me to believe this hack doesn't change any behavior for clients, since primary is never true, and for hosts, 'breaks' window focus for the capture window, which... doesn't actually appear to interfere with its ability to capture user input. Not sure what to make of that; I don't know enough about XWindows or the input capturing method used by Barrier.

@jalbert-dev commented on GitHub (Jun 13, 2020): I've had similar issues with window focus using Barrier. My own setup is a Ubuntu 19.04 host with a Windows 10 client (both single-monitor), so the "Don't take foreground window on Windows hosts" setting doesn't (or _shouldn't!_) have any effect. As an example of what issues crop up: * If the host's foreground application is one that pauses, mutes audio, etc. when losing focus, that action will occur when moving the mouse across to the client screen * Related, if the host's foreground application is fullscreen (such as with games or media players!), moving the mouse to the client screen will cause that application to minimize as if the user alt-tabbed out of it I'll admit I've not personally used a hardware KVM before, and I don't have much experience with window systems, so I could be wrong about this, but I don't feel like this behavior makes sense. I would expect mouse and keyboard events to be sent to the screen containing the mouse cursor, yes, but I don't see any reason why the host machine should lose window focus here; there shouldn't be any issue with each OS having its own foreground window. As-is, it's impossible to play a fullscreen movie on the host while browsing the web on the client. I ran into both of those problems I mentioned and found them to be unacceptable usability issues, so I went digging around in the source and managed to "fix" the issue in my case by removing [an `m_isPrimary` check](https://github.com/debauchee/barrier/blob/965cd70ba272e765bfa77c4dcce84ab7bfd011ce/src/lib/platform/XWindowsScreen.cpp#L327-L329) from `XWindowsScreen::leave()`'s implementation. From what I can tell, for `XWindowsScreen`s `m_isPrimary` is [always `true` for servers/hosts](https://github.com/debauchee/barrier/blob/965cd70ba272e765bfa77c4dcce84ab7bfd011ce/src/lib/barrier/ServerApp.cpp#L602), and [always `false` for clients](https://github.com/debauchee/barrier/blob/965cd70ba272e765bfa77c4dcce84ab7bfd011ce/src/lib/barrier/ClientApp.cpp#L171), meaning in the current `master` it's impossible for XWindows hosts to preserve window focus when the cursor leaves the screen, regardless of settings. (Which is _not_ me saying that's wrong or something; like I said, my knowledge of window systems is limited!) After removing the check I've been running for at least a month now with no issues and with expected behavior (both host and client have their own foreground windows, but input events sent only to one of the two; perfect!). Still, I don't know if my dumb one-line hack would cause issues on other setups. I'd like to hear some feedback regardless, though, because this definitely seems like an issue to me. (Hopefully this is what OP was talking about. If not, I can open a separate issue.) EDIT: Double-checking things leads me to believe this hack doesn't change any behavior for clients, since primary is never true, and for hosts, 'breaks' window focus for the capture window, which... doesn't actually appear to interfere with its ability to capture user input. Not sure what to make of that; I don't know enough about XWindows or the input capturing method used by Barrier.

gitea-mirror commented

2026-05-05 06:37:11 -06:00

Author

Owner

@rebroad commented on GitHub (Jun 14, 2020):

@hiuwo You seem to not be understanding the functionality I am proposing. What I propose is extremely simple. The host already receives the mouse and keyboard info, and it either forwards this to the clients or it does not.

I am therefore proposing that when the mouse moves out of the host's screen, that it carries on forwarding the mouse movements to the clients as it already does. However, it does NOT start forwarding the keyboard activity until the mouse is clicked. This is the only change I am proposing.

@jalbert-dev change also sounds useful as they are correct in that someone additional happens when the mouse leaves a screen, which does not need to happen, so I also think this is a change worth making.

@rebroad commented on GitHub (Jun 14, 2020): @hiuwo You seem to not be understanding the functionality I am proposing. What I propose is extremely simple. The host already receives the mouse and keyboard info, and it either forwards this to the clients or it does not. I am therefore proposing that when the mouse moves out of the host's screen, that it carries on forwarding the mouse movements to the clients as it already does. However, it does NOT start forwarding the keyboard activity until the mouse is clicked. This is the only change I am proposing. @jalbert-dev change also sounds useful as they are correct in that someone additional happens when the mouse leaves a screen, which does not need to happen, so I also think this is a change worth making.

gitea-mirror commented

2026-05-05 06:37:13 -06:00

Author

Owner

@jalbert-dev commented on GitHub (Jun 14, 2020):

@rebroad

That does sound quite different from what I thought. It does sound like what you're looking for is for an option to have client computers act as a secondary monitors for the host computer, rather than as KVM switch targets. If I'm understanding, you'd prefer the server computer's event loop to behave something like:

On receiving mouse click event:
- If event is for a client, mark them as the active keyboard event target
On receiving keyboard event:
- If "require mouse click to send keyboard event" option is set, always forward to active keyboard event target

On its face it doesn't sound impossible by any means (EDIT: is what I would say had I not forgotten that window events are indeed... sent to windows and not broadcasted), but I'm sure there are a lot of ugly edge cases to deal with. I'll take a look and see if I can implement it as a proof of concept.

My own post is definitely talking about something a bit different, so I'll make a separate issue at some point.

EDIT: Yeah so the main issue with what you're suggesting, as far as I can tell, is that the host Barrier instance doesn't receive keydown/keyup events at all unless the mouse is "off-screen" due to the way events are sent to the helper window. Dunno if this is something that could be worked around; not familiar enough with the code.

@jalbert-dev commented on GitHub (Jun 14, 2020): @rebroad That does sound quite different from what I thought. It does sound like what you're looking for is for an option to have client computers act as a secondary monitors for the host computer, rather than as KVM switch targets. If I'm understanding, you'd prefer the server computer's event loop to behave something like: * On receiving mouse click event: - If event is for a client, mark them as the active keyboard event target * On receiving keyboard event: - If "require mouse click to send keyboard event" option is set, always forward to active keyboard event target On its face it doesn't sound impossible by any means (EDIT: is what I would say had I not forgotten that window events are indeed... sent to windows and not broadcasted), but I'm sure there are a lot of ugly edge cases to deal with. I'll take a look and see if I can implement it as a proof of concept. My own post is definitely talking about something a bit different, so I'll make a separate issue at some point. EDIT: Yeah so the main issue with what you're suggesting, as far as I can tell, is that the host Barrier instance doesn't receive keydown/keyup events at all unless the mouse is "off-screen" due to the way events are sent to the helper window. Dunno if this is something that could be worked around; not familiar enough with the code.

gitea-mirror commented

2026-05-05 06:37:14 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 22, 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 22, 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:37:15 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

Let's not close feature requests for no reason.

@p12tic commented on GitHub (Jan 10, 2021): Let's not close feature requests for no reason.

gitea-mirror commented

2026-05-05 06:37:16 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

@hiuwo You seem to not be understanding the functionality I am proposing. What I propose is extremely simple. The host already receives the mouse and keyboard info, and it either forwards this to the clients or it does not.

I am therefore proposing that when the mouse moves out of the host's screen, that it carries on forwarding the mouse movements to the clients as it already does. However, it does NOT start forwarding the keyboard activity until the mouse is clicked. This is the only change I am proposing.

@jalbert-dev change also sounds useful as they are correct in that someone additional happens when the mouse leaves a screen, which does not need to happen, so I also think this is a change worth making.

I think ignoring keyboard events until the first click after changing screens is a valid feature and wouldn't be too hard to implement. Thanks @rebroad for being persistent in explaining your thoughts.

@p12tic commented on GitHub (Jan 10, 2021): > @hiuwo You seem to not be understanding the functionality I am proposing. What I propose is extremely simple. The host already receives the mouse and keyboard info, and it either forwards this to the clients or it does not. > I am therefore proposing that when the mouse moves out of the host's screen, that it carries on forwarding the mouse movements to the clients as it already does. However, it does NOT start forwarding the keyboard activity until the mouse is clicked. This is the only change I am proposing. > @jalbert-dev change also sounds useful as they are correct in that someone additional happens when the mouse leaves a screen, which does not need to happen, so I also think this is a change worth making. I think ignoring keyboard events until the first click after changing screens is a valid feature and wouldn't be too hard to implement. Thanks @rebroad for being persistent in explaining your thoughts.

Rows
Columns

[GH-ISSUE #671] Enhancement: Ignore keyboard input until the first mouse click after screen change #531