gitea-mirror commented

Owner

Originally created by @Ashark on GitHub (May 23, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/45

There are many issues when you are using multiple layouts on both client and server side. I have done some testing and publishing results here.
In the table I have marked unexpected behavior with red circle (🔴). Cases that are working as expected I have not marked just because there is still no green circle until unicode 12.0.

What I consider as expected behavior?

When I am typing text in a client, I expect that when I hit switch layout key combination, then I continue typing in client in another language. My main attention is in client's layout indicator, but not server's. Actually, I do not care of server's layout until I return my mouse to server.

Versions

I tested both Linux and Windows in both roles.

Linux: ArchLinux 4.16.9-1-ARCH and Barrier 2.1.0-RELEASE (built from aur)

Windows: windows 10 v1803 (17134.48) and Barrier 2.1.0-RELEASE-0b2dfd80

Linux server and Windows client

Linux server layout	Windows client layout	Button pressed	Typing in text editor	Saving file with ctrl + s	Switching layout with win + space	Switching layout with alt + shift (same shortcut on server and client)
ru	рус	s/ы	ы	🔴Automatically switched to eng Instead of saving file s was typed	🔴does not work	🔴Instead of switching layout on client it was switched on server
ru	eng	s/ы	🔴Automatically switched to rus Instead of typing s it was ы	🔴Instead of saving file s was typed	🔴does not work	🔴Instead of switching layout on client it was switched on server
us	рус	s/ы	🔴Automatically switched to eng Instead of typing ы it was s	🔴file was saved, but client Automatically switched to eng	works normally	🔴Instead of switching layout on client it was switched on server
us	eng	s/ы	s	file was saved	works normally	🔴Instead of switching layout on client it was switched on server

Windows server and Linux client

Windows server layout	Linux client layout	Button pressed	Typing in text editor	Saving file with ctrl + s	Switching layout with ctrl+alt+k	Switching layout with Alt shift (same shortcut on server and client)	Typing comma symbol
рус	ru	s/ы	ы	🔴File was saved, but client Automatically switched to us	🔴Impossible to switch to us, but it should switch between us and ru	🔴Alt+shift works, but Shift+alt does not	🔴Pressing Shift + [?/] button has no effect, but it should act as typing comma while in russian layout
рус	us	s/ы	🔴Instead of typing s it was ы	file was saved	🔴Impossible to switch to us, but it should switch between us and ru	🔴Alt+shift works, but Shift+alt does not	🔴Pressing [<,] should act as comma in english layout, but it was typed б, like client was set in russian layout. And if we assume that barrier had wrongly assigned layout on client, it still bahaves wrong, because pressing shift + [?/] has no effect.
eng	ru	s/ы	ы	file was saved	works normally	🔴Alt+shift works, but Shift+alt does not	Comma was typed as in russian layout
eng	us	s/ы	s	file was saved	works normally	🔴Alt+shift works, but Shift+alt does not	Comma was typed as in english layout

Originally created by @Ashark on GitHub (May 23, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/45 There are many issues when you are using multiple layouts on both client and server side. I have done some testing and publishing results here. In the table I have marked unexpected behavior with red circle (:red_circle:). Cases that are working as expected I have not marked just because there is still no green circle until unicode 12.0. # What I consider as expected behavior? When I am typing text in a client, I expect that when I hit switch layout key combination, then I continue typing in client in another language. My main attention is in client's layout indicator, but not server's. Actually, I do not care of server's layout until I return my mouse to server. # Versions I tested both Linux and Windows in both roles. <br> Linux: ArchLinux 4.16.9-1-ARCH and Barrier 2.1.0-RELEASE (built from aur) <br> Windows: windows 10 v1803 (17134.48) and Barrier 2.1.0-RELEASE-0b2dfd80 <br> # Linux server and Windows client |Linux server layout|Windows client layout|Button pressed|Typing in text editor|Saving file with ctrl + s|Switching layout with win + space |Switching layout with alt + shift (same shortcut on server and client)| | --- | --- | --- | --- | --- | --- | --- | |ru|рус|s/ы|ы|:red_circle:Automatically switched to eng Instead of saving file s was typed|:red_circle:does not work|:red_circle:Instead of switching layout on client it was switched on server |ru|eng|s/ы|:red_circle:Automatically switched to rus Instead of typing s it was ы|:red_circle:Instead of saving file s was typed|:red_circle:does not work|:red_circle:Instead of switching layout on client it was switched on server |us|рус|s/ы|:red_circle:Automatically switched to eng Instead of typing ы it was s|:red_circle:file was saved, but client Automatically switched to eng|works normally|:red_circle:Instead of switching layout on client it was switched on server |us|eng|s/ы|s|file was saved|works normally|:red_circle:Instead of switching layout on client it was switched on server # Windows server and Linux client |Windows server layout|Linux client layout|Button pressed|Typing in text editor|Saving file with ctrl + s|Switching layout with ctrl+alt+k |Switching layout with Alt shift (same shortcut on server and client)|Typing comma symbol | --- | --- | --- | --- | --- | --- | --- | --- | |рус|ru|s/ы|ы|:red_circle:File was saved, but client Automatically switched to us|:red_circle:Impossible to switch to us, but it should switch between us and ru|:red_circle:Alt+shift works, but Shift+alt does not|:red_circle:Pressing Shift + [?/] button has no effect, but it should act as typing comma while in russian layout |рус|us|s/ы|:red_circle:Instead of typing s it was ы|file was saved|:red_circle:Impossible to switch to us, but it should switch between us and ru|:red_circle:Alt+shift works, but Shift+alt does not|:red_circle:Pressing [<,] should act as comma in english layout, but it was typed б, like client was set in russian layout. And if we assume that barrier had wrongly assigned layout on client, it still bahaves wrong, because pressing shift + [?/] has no effect. |eng|ru|s/ы|ы|file was saved|works normally|:red_circle:Alt+shift works, but Shift+alt does not|Comma was typed as in russian layout |eng|us|s/ы|s|file was saved|works normally|:red_circle:Alt+shift works, but Shift+alt does not|Comma was typed as in english layout

gitea-mirror added the

bug

meta

labels 2026-05-05 04:49:27 -06:00

gitea-mirror commented

2026-05-05 04:49:32 -06:00

Author

Owner

@Ashark commented on GitHub (May 23, 2018):

Reserved place for future comments

@Ashark commented on GitHub (May 23, 2018): Reserved place for future comments

gitea-mirror commented

2026-05-05 04:49:36 -06:00

Author

Owner

@Ashark commented on GitHub (Nov 30, 2018):

I have found a very quirky way to change linux client's layout while the same shortcut on a server (Alt+Shift).

Run setxkbmap -option on server. After that client will not switch layout with alt+shift or shift+alt, in despite of kde system settings were not changed.
Run xmodmap -e "keycode 64 = Alt_L" on server. This will prevent Alt + Shift to become Meta.
Move mouse to client and press alt+shift. Layout will be switched. For some reason, shift+alt still do not switch layout on client.
To be able to switch layout again on server, go to system settings -> input devices -> keyboard -> advanced -> Switching to another layout -> uncheck and then check again Alt+Shift, then press Apply.

@Ashark commented on GitHub (Nov 30, 2018): I have found a very quirky way to change linux client's layout while the same shortcut on a server (Alt+Shift). 1) Run `setxkbmap -option` on server. After that client will not switch layout with alt+shift or shift+alt, in despite of kde system settings were not changed. 2) Run `xmodmap -e "keycode 64 = Alt_L"` on server. This will prevent Alt + Shift to become Meta. 3) Move mouse to client and press alt+shift. Layout will be switched. For some reason, shift+alt still do not switch layout on client. 4) To be able to switch layout again on server, go to system settings -> input devices -> keyboard -> advanced -> Switching to another layout -> uncheck and then check again Alt+Shift, then press Apply.

gitea-mirror commented

2026-05-05 04:49:39 -06:00

Author

Owner

@eugenegff commented on GitHub (Oct 14, 2020):

Windows server often improperly converts UTF16 char obtained from KB layout to ANSI and then back to UTF16, probably using two different ANSI code pages. This issue was fixed in pull request https://github.com/debauchee/barrier/pull/910 and Windows clients with this fix now works properly with windows hosts. Current issue probably has more problems...

@eugenegff commented on GitHub (Oct 14, 2020): Windows server often improperly converts UTF16 char obtained from KB layout to ANSI and then back to UTF16, probably using two different ANSI code pages. This issue was fixed in pull request https://github.com/debauchee/barrier/pull/910 and Windows clients with this fix now works properly with windows hosts. Current issue probably has more problems...

gitea-mirror commented

2026-05-05 04:49:42 -06:00

Author

Owner

@darkdragon-001 commented on GitHub (Dec 20, 2020):

Might this help? #134

@darkdragon-001 commented on GitHub (Dec 20, 2020): Might this help? #134

gitea-mirror commented

2026-05-05 04:49:44 -06:00

Author

Owner

@yakoder commented on GitHub (Aug 17, 2021):

red circle (🔴). ...just because there is still no green circle until unicode 12.0.
Probably a good thing (red-green colorblindness is a very real thing.

Since this seems to be a catch-all type issue.
RE: Alt-Shift for switching lang layout. On my Win installs (from about 95 to 10) it's specifically the Left-Alt + Shift, not just "Alt" as others keep stating. (Diff keys, diff keycodes, we're techies, we're supposed to be specific).

Not seen mention: (Possibly pasting into cmd/cygwin/wsl terminal related.) The language layout seems to change on its own for me. I'll be moving back and forth between 2 computers (both win10 21h1 w/ en & ru layouts) and at some point I'll go to type on the client & get ????? instead of whatever I wanted to type (or something like Ctrl-S will do nothing).
Client shows ENG; Server shows PYC
Steps after that: switch back to server. Win_Key+Space (since we can't disable that shortcut) now shows ENG. Move back to client, as soon as client becomes active, server shows PYC again. Move back to server. Change layout back to ENG. Click on something (background, a term window, another program). Change back to client. Yay! We're still on ENG on both.

I've not quite worked out the exact steps, as it seems to not happen frequently enough to work out a pattern/cause. And I wind up trying to just switch several times. It's either that it needs to switch PYC->ENG & auto-switch back to (unwanted... I didn't hit that shortcut) PYC, three separate times, or it's that after changing the server back to ENG, making a click on something is needed.

Disabling the older shortcut (that Left-Alt+Shift combo) does seem to help some, but it still happens, almost as if a phantom "change keyboard layout" shortcut sequence gets sent during frequent (like every minute or less) moves between computers. Possibly a dropped/errant packet?

@yakoder commented on GitHub (Aug 17, 2021): > red circle (🔴). ...just because there is still no green circle until unicode 12.0. Probably a good thing (red-green colorblindness _is_ a very real thing. Since this seems to be a catch-all type issue. RE: Alt-Shift for switching lang layout. On my Win installs (from about 95 to 10) it's specifically the Left-Alt + Shift, not just "Alt" as others keep stating. (Diff keys, diff keycodes, we're techies, we're supposed to be specific). Not seen mention: (Possibly pasting into cmd/cygwin/wsl terminal related.) The language layout seems to change on its own for me. I'll be moving back and forth between 2 computers (both win10 21h1 w/ en & ru layouts) and at some point I'll go to type on the client & get ????? instead of whatever I wanted to type (or something like Ctrl-S will do nothing). Client shows ENG; Server shows PYC Steps after that: switch back to server. Win_Key+Space (since we can't disable _that_ shortcut) now shows ENG. Move back to client, as soon as client becomes active, server shows PYC again. Move back to server. Change layout back to ENG. Click on something (background, a term window, another program). Change back to client. Yay! We're still on ENG on both. I've not quite worked out the _exact_ steps, as it seems to not happen frequently enough to work out a pattern/cause. And I wind up trying to just switch several times. It's _either_ that it needs to switch PYC->ENG & auto-switch back to (unwanted... _I_ didn't hit that shortcut) PYC, _three_ separate times, or it's that after changing the server back to ENG, making a click on something is needed. Disabling the older shortcut (that Left-Alt+Shift combo) does seem to help some, but it still happens, almost as if a phantom "change keyboard layout" shortcut sequence gets sent during frequent (like every minute or less) moves between computers. Possibly a dropped/errant packet?

gitea-mirror commented

2026-05-05 04:49:46 -06:00

Author

Owner

@yakoder commented on GitHub (Sep 4, 2021):

Additional info: this does seem to be related to having a Windows command prompt open (be it cmd.exe, mintty.exe, or similar), hereafter called "terminal".
Without any terminal open, am able to switch back-and-forth between computers without any change of server's keyboard layout language.

Open a terminal on the server (either start->command prompt or win-x->c) and as soon as the client is given focus, the server's keyboard layout language is changed to (in my case) Russian. Switch back to server. Close terminal. Switch back to English. Click on another program, so it has focus. Then switching back to client does not change server's keyboard language.

Open a terminal on the client and changing between client and server does not change either machine's keyboard layout language.

Currently, for both of my boxes, barrier is set to run as a service. No further testing (of disabling service & running manually; or of reversing server-client assignments) is planned.

Just checked: this is with "latest release" (for windows) of 2.3.3.

@yakoder commented on GitHub (Sep 4, 2021): Additional info: this does seem to be related to having a Windows command prompt open (be it cmd.exe, mintty.exe, or similar), hereafter called "terminal". Without any terminal open, am able to switch back-and-forth between computers without any change of server's keyboard layout language. Open a terminal on the _server_ (either start->command prompt or win-x->c) and as soon as the client is given focus, the server's keyboard layout language is changed to (in my case) Russian. Switch back to server. Close terminal. Switch back to English. _Click_ on another program, so it has focus. Then switching back to client does not change server's keyboard language. Open a terminal on the _client_ and changing between client and server does not change either machine's keyboard layout language. Currently, for both of my boxes, barrier is set to run as a service. No further testing (of disabling service & running manually; or of reversing server-client assignments) is planned. Just checked: this is with "latest release" (for windows) of 2.3.3.

gitea-mirror referenced this issue

2026-05-05 06:16:36 -06:00

[GH-ISSUE #508] Automatically start Barrier on boot in Raspbian Buster #395

gitea-mirror referenced this issue

2026-05-05 07:59:14 -06:00

[PR #694] Add systemd services (resolves #36, resolves #508) #1675

Rows
Columns

[GH-ISSUE #45] Multi layout issues #36

What I consider as expected behavior?

Versions

Linux server and Windows client

Windows server and Linux client