On Mon, May 6, 2024 at 10:31 AM <[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 >
