All Right-To-Left language implementations (Hebrew, Arabic, Farsi, Aramaic, etc.) work this way, with dynamic switching of keyboard layouts, and most use the same key combination for switching between the layouts (either Alt+Shift or LCtrl/RCtrl+Shift).
You should take into account that RTL languages use totally different non-Latin character sets, so there’s no way getting around in a Latin OS without being able to switch back and forth between English characters and Hebrew ones. Also, due to unfortunate historic typewriter layout reasons, punctuation marks are located on different physical keys compared to Latin layouts. Uri From: Nick Couchman <[email protected]> Sent: Monday, May 6, 2024 7:07 PM To: [email protected] Subject: Re: Hebrew/English keyboard layout challenges On Mon, May 6, 2024 at 10:31 AM <[email protected]<mailto:[email protected]>> wrote: Hi there, We are using Guacamole 1.5.4 for Windows RDP, and are faced with a challenging keyboard layout mapping problem. Our clients and servers all use the same Hebrew keyboard layout which is based on standard US-qwerty, and is switchable on the Windows OS level (using a combined Alt+Shift keypress) between English and Hebrew layouts. While connected through Guacamole, as long as the client’s Windows language is set to ENG everything works fine, since the JS key events are translated by the Guacamole client to standard keysyms, which in turn are translated back on the server to the appropriate Windows scancode values. In this scenario it doesn’t matter which language is currently set active within the RDP session (on the target Windows session), since it receives the standard scancodes from Guacamole server and interprets them according to the active session language layout. The mess begins when the client’s selected Windows language is set to HEB (which happens every time the user intuitively presses Alt+Shift during work in the RDP session). In this case, the Guacamole client intercepts unmapped Hebrew key presses, so by default it sends them as Unicode to the server. This is sort of half a problem when both client and remote RDP session languages are set to HEB, but when client machine is set to HEB and RDP session set to ENG, unwanted results occur (Hebrew characters are typed instead of English). Yes, this will be a problem if users are changing the keyboard layout on the remote side without updating the client-side (Guacamole) keyboard layout - you'll get a mis-match and odd character input. The behavior for Unicode characters being sent when the keys are not mapped is completely intentional - it's designed to give a "fail-safe" for Guacamole in situations where the keymap is undefined. I was able to get over most of this effect by adding the following lines to en_us_qwerty.keymap: map -caps -shift 0x12..0x19 ~ "קראטוןםפ" map -caps -shift 0x1E..0x27 ~ "שדגכעיחלךף" map -caps -shift 0x2C..0x34 ~ "זסבהנמצתץ" map +caps +shift 0x12..0x19 ~ "קראטוןםפ" map +caps +shift 0x1E..0x27 ~ "שדגכעיחלךף" map +caps +shift 0x2C..0x34 ~ "זסבהנמצתץ" This maps client Hebrew key presses to their proper physical scancodes, but it only partly reduces the frustration since there are still problematic leftovers: • In Hebrew layout, the Slash (/) sign is located on the KeyQ key, while in English layout it’s on the ordinary Slash key • The Quote (‘) sign is located on the KeyW in Hebrew, and on ordinary Quote key in English • The Comma (,) sign is located on the Quote key in Hebrew, and on ordinary Comma in English • The Period (.) sign is located on the Slash key in Hebrew, and on ordinary Period in English • The Semicolon (;) sign is located on the Backquote key in Hebrew, and on Semicolon in English So at the moment, as you can gather, if client language is set to HEB and server Guacamole RDP session language is set to ENG, pressing ‘q’ will lead to a slash (/) sign pressing ‘w’ will lead to Quote (‘), etc., which really is a problem that our users can’t live with. To sum the long story short, two questions: 1. Is there a way to make the Guacamole client be aware of the currently active Windows language, and define different layouts correlating to their relevant languages? I'll have to look at the FreeRDP source code, but I don't think there's a feedback loop or callback for when the remote side changes the keyboard layout - I think the expectation is that the client-side keyboard is a fixed (physical) keyboard, so it will not dynamically change, and that you'd want that to stay the same for the entire remote session. I can't foresee a lot of situations where you'd want the client-side keymap to change on-the-fly. 2. Alternatively, on Windows machine scenarios (client + servers) the whole back-and-forth conversion from client JS Key code (which is equivalent to scancode) through generic keysym and then back to scancode on server side, seems redundant when clients and servers share the same keyboard layouts. Is there a way to configure the client to avoid it, and hence implement direct mapping from client JS Key code to server scancode? Mike can probably comment more thoroughly on this, but my understanding is that, no, this is not possible. Even in situations where client and server keyboard layouts match, in order to properly interpret the keyboard input, particularly for characters that require modifiers, the key mapping needs to be done from JS to the Windows scancodes. Is there a reason that you would not want to just implement the Hebrew keyboard layout in Guacamole and set both client and server-side to that layout? -Nick הודעת דואר אלקטרוני זו נשלחה אליך מבית החולים אלי"ן. יתכן שבהודעה כלול מידע רפואי רגיש המוגן בחוק הגנת הפרטיות התשמ"ה 1981, מידע שנועד לשימושם הבלעדי של המכותבים הישירים אליהם נשלחה ההודעה במקור. אם ההודעה אינה מיועדת לך, ואף שיתכן שהגיעה אליך בטעות, הרי שחלה עליך חובת שמירת סודיות. במקרה כזה אנא עדכן באופן מיידי את השולח, ומחק/י את כל עותקיה של ההודעה הנמצאים ברשותך. The contents of this email was sent to you by ALYN Hospital. This email might contain confidential medical information, which is legally protected by the 1981 privacy law. This information is intended only for the use of the original addressee/s of the email from the original sender only. If you are not an intended recipient of the original sender, you are hereby notified that any disclosure, copying, and distribution of this information, is strictly prohibited. If you have received this email in error, please immediately notify the sender and delete any copies of this email in your possession.
