Two keyboard layouts cannot be identical if switching between them produces different results. They may appear similar, but they cannot actually be identical if they behave differently.
- Mike On Tue, Dec 31, 2019, 10:36 Roman <[email protected]> wrote: > This is the screenshot that I have identical layouts > https://i.imgur.com/WIJyaaq.png > > 31.12.2019, 21:29, "Mike Jumper" <[email protected]>: > > If switching between those two layouts within the RDP session yields > different key behavior, then those layouts are definitely not identical. > > You are seeing different behavior for certain characters because the > series of scancodes for typing those characters on an English keyboard is > interpreted differently by Windows if you tell it you have a Russian > keyboard. > > The keyboard layout within the connection parameters must match the > keyboard layout within RDP for scancode translation to work. If your > connection is set to "en-us-qwerty", then you must select the English US > layout in the RDP session. You cannot set the connection to layout X and > the RDP server to layout Y and have that work. It will cause Guacamole to > send the wrong inputs. > > - Mike > > On Tue, Dec 31, 2019, 10:11 Roman <[email protected]> wrote: > > I use Guacamole 1.0 on Ubuntu 16.04, and two Win 10 PCs, with two > absolutely identical layouts: "EN US" and "RU". > > English layout works well, but when I switch to Russian layout almost all > signs work incorrectly, but letters work normally. > > In connection settings I have En -Us (QWERTY) layout > https://i.imgur.com/10oKTI7.png > > > 31.12.2019, 20:34, "Mike Jumper" <[email protected]>: > > The characters typed will be the characters you type locally. Guacamole > will translate as needed, using Unicode only where the remote end lacks a > character (such as "ю"). If you wish to type a period, you will need to > press whichever keys are used to type a period on your local keyboard > layout. Guacamole will automatically turn those keypresses into the > keypresses required by the RDP server. > > You should also make sure that the remote keyboard layout is set to match > the layout chosen in your connection parameters. It doesn't need match your > local layout, but it absolutely must your remote layout so Guacamole knows > how your RDP server will be interpreting scancodes. The scancodes sent will > be incorrect if this is not the case, resulting in behavior like you > describe. > > As long as the connection parameter and your RDP server's layout match, > everything should just be seamless. > > - Mike > > On Mon, Dec 30, 2019, 23:38 Roman <[email protected]> wrote: > > Thanks very much for your answer, yes it works but unfortunately some > signs doesn't match when I use RU layout, for example instead of period > sign I got Russian letter "ю". > All signs match only if I set Unicode layout but in that way I can't send > keyboard shortcuts. > > > 30.12.2019, 21:17, "Mike Jumper" <[email protected]>: > > On Mon, Dec 30, 2019, 00:04 Rom@n <[email protected]> wrote: > > Hello, guys! > > I’m using Unicode layout and can’t break ping process of windows CMD. > > If I switch to English layout, I can do the break. > > But Russian layout isn’t present in Guacamole. > > Is there any workaround ? > > > Yes: set the keyboard layout within the RDP session to one of the > currently-supported layouts and select that layout in the connection > parameters. > > Guacamole will automatically use Unicode events for any characters not > present in the layout, like Russian characters, but will use normal key > events for any characters present in the server layout (Ctrl-C, etc. will > work). > > https://guacamole.apache.org/faq/#does-guacamole-support-my-keyboard-layout > > Don't use the Unicode failsafe layout - all that will do is force > Guacamole to use Unicode events for all keys, which will break keyboard > shortcuts. Selecting any other keyboard layout will allow Guacamole to send > proper key events, resorting to Unicode only for unknown keys, in this case > keys which type Russian characters. > > - Mike > > > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected]
