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). 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? 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? Thanks, Uri הודעת דואר אלקטרוני זו נשלחה אליך מבית החולים אלי"ן. יתכן שבהודעה כלול מידע רפואי רגיש המוגן בחוק הגנת הפרטיות התשמ"ה 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.
