Multi layout issues

[Ashark]

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.

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

[Ashark]

Reserved place for future comments

[Ashark]

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.

[eugenegff]

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 #910 and Windows clients with this fix now works properly with windows hosts. Current issue probably has more problems...

[darkdragon-001]

Might this help? #134

[yakoder]

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]

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.