[GH-ISSUE #107] Keyboard changes language when moving from Windows to Mac #81

New issue

Closed

opened 2026-05-05 05:01:00 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

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

Owner

Originally created by @chrisvltn on GitHub (Aug 2, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/107

Operating Systems

Server: Windows 10 Version 1803

Client: MacOs High Sierra Version 10.13.5

Barrier Version

2.1.0

Steps to reproduce bug

Have two or more different keyboard languages configured in your Windows (in my case I have Portuguese - Portuguese (Brasil) ABNT2 and English (United States) - Portuguese (Brasil) ABNT2
Change the computer using mouse or a configured hotkey
Bug occurs: The keyboard language in Windows is changed

Other info

When did the problem start to occur? When I started using Barrier, actually
Is there a way to work around it? No
Does this bug prevent you from using Barrier entirely? No
Mac has both English and ABNT2 keyboard languages installed, as the default macbook keyboard I have has English keymap, and the Windows keyboard I use has ABNT2.
When I come back to Windows, the language is changed again, but accents stop working
In the Mac the keyboard language doesn't change

Originally created by @chrisvltn on GitHub (Aug 2, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/107 ### Operating Systems ### Server: Windows 10 Version 1803 Client: MacOs High Sierra Version 10.13.5 ### Barrier Version ### 2.1.0 ### Steps to reproduce bug ### 1. Have two or more different keyboard languages configured in your Windows (in my case I have Portuguese - Portuguese (Brasil) ABNT2 and English (United States) - Portuguese (Brasil) ABNT2 2. Change the computer using mouse or a configured hotkey 3. Bug occurs: The keyboard language in Windows is changed ### Other info ### * When did the problem start to occur? When I started using Barrier, actually * Is there a way to work around it? No * Does this bug prevent you from using Barrier entirely? No * Mac has both English and ABNT2 keyboard languages installed, as the default macbook keyboard I have has English keymap, and the Windows keyboard I use has ABNT2. * When I come back to Windows, the language is changed again, but [accents stop working](https://github.com/debauchee/barrier/issues/108) * In the Mac the keyboard language doesn't change

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

@walker0643 commented on GitHub (Sep 8, 2018):

Hi @chrisvltn -

I have a similar situation. I use EN on my main Windows screen and INTL on my secondary Linux screen. The root of this problem is not Barrier but the host's keyboard driver (or w/e in the OS interprets and remaps keystrokes like dead keys) not acting in a way that the client's keyboard driver can understand.

Keyboards themselves don't have a "language", they send signals based on which switch (key) was depressed. It's up to the software to determine which symbol that signal represents. That determination is made before Barrier is notified of the keystroke, but it wouldn't matter anyway because Barrier just relays keystrokes across the network with very little interpretation.

The good news, however, is that I've been able to get both of my machines to function predictably, but with each multi-layout session it takes some trial-and-error to get it into this state. I hope you're able to find the same balance that I have found, though I'm not sure what I can offer to help you with this. Try to think of each window as having its own layout setting (because it does) and also think of your secondary screens as being a window on the primary screen and therefore have a layout setting of their own (again, because they do). Maybe it will help you to understand what is happening when the layouts change and give you a hint as to what it needed in your specific situation to predict and control these changes.

Closing this issue since it's not a Barrier bug, but please do respond with any followup you have. Best of luck!

@walker0643 commented on GitHub (Sep 8, 2018): Hi @chrisvltn - I have a similar situation. I use EN on my main Windows screen and INTL on my secondary Linux screen. The root of this problem is not Barrier but the host's keyboard driver (or w/e in the OS interprets and remaps keystrokes like dead keys) not acting in a way that the client's keyboard driver can understand. Keyboards themselves don't have a "language", they send signals based on which switch (key) was depressed. It's up to the software to determine which symbol that signal represents. That determination is made before Barrier is notified of the keystroke, but it wouldn't matter anyway because Barrier just relays keystrokes across the network with very little interpretation. The good news, however, is that I've been able to get both of my machines to function predictably, but with each multi-layout session it takes some trial-and-error to get it into this state. I hope you're able to find the same balance that I have found, though I'm not sure what I can offer to help you with this. Try to think of each window as having its own layout setting (because it does) and also think of your secondary screens as being a window on the primary screen and therefore have a layout setting of their own (again, because they do). Maybe it will help you to understand what is happening when the layouts change and give you a hint as to what it needed in your specific situation to predict and control these changes. Closing this issue since it's not a Barrier bug, but please do respond with any followup you have. Best of luck!

gitea-mirror referenced this issue

2026-05-05 07:56:25 -06:00

[PR #91] [CLOSED] [TEST ME!] Smarter Zeroconf Address #1563