On 5/6/24 9:06 AM, Nick Couchman wrote: > On Mon, May 6, 2024 at 10:31 AM <[email protected] > <mailto:[email protected]<mailto:[email protected]%20%3cmailto:[email protected]>>> wrote:
> ... > > 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. > Sadly, this is simply not reported over RDP by the RDP server. I remember implementing the Guacamole side of this and wishing that such a mechanism existed. An RDP client can request a particular layout during the RDP connection process, but receives no information from the server if that layout is changed later after the RDP session has started. => As far as I understand, It doesn’t matter which layout is currently being selected on the remote RDP session. What does matter is the layout which is currently set on the client side, E.g., if the Guacamole client was able to be aware of the currently selected Windows keyboard language and pass it on to the server, it could have been fantastic to be able to extend the keymap file format to support such as the following: # Language independent mapping map -caps -shift 0x29 0x02..0x0D ~ "`1234567890-=" # English layout mapping map +lang:ENG -caps -shift 0x10..0x1B 0x2B ~ "qwertyuiop[]\" map +lang:ENG -caps -shift 0x1E..0x28 ~ "asdfghjkl;'" map +lang:ENG -caps -shift 0x2C..0x35 ~ "zxcvbnm,./" # Hebrew layout mapping map +lang:HEB -caps -shift 0x10..0x1B 0x2B ~ "/'קראטוןםפ[]\" map +lang:HEB -caps -shift 0x1E..0x28 ~ "שדגכעיחלךף," map +lang:HEB -caps -shift 0x2C..0x35 ~ "זסבהנמצתץ." I tried playing around with the experimental Chromium supported navigator.keyboard KeyboardLayoutMap object, which returns key/value pair mapping from US standard JS key names to current keyboard layout keys, but this mapping does not seem to be sensitive to the currently selected (dynamic) keyboard language settings – it rather it always return EN-US keyboard layout mapping in our case, so I’m not optimistic this overall approach is feasible. > 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. > No, the keycode cannot be used for this (more on this below). There is a more recently introduced value that is directly related to the scancode and might be usable for cases where it's not possible to ensure the remote keyboard layout is predictable/correct, but: * Moving in that direction would be a step away from Guacamole's idealistic, layout-independent posture. If we do this, I think we'd best put that behavior behind an option and clearly document why usage of that option is discouraged (users should be able to transparently use whatever keyboard they want locally and not have to worry about making corresponding settings changes inside the remote desktop - that's an admin concern). => Definitely sounds like an optional setting, which would cause Guacamole client to favor scancode-based communication rather than keysym-based with the server. * There will always be cases where there is no scancode, such as characters typed using dead keys, the on-screen keyboards of mobile devices, and IMEs like those used for inputting Chinese characters. Doing this could mean that we'd have the opposite problem and would need to somehow produce usable scancodes for key events that do not have scancodes by their own nature. => For these cases I suggest defining fallback logic, such that whenever a scancode cannot be determined (assuming our above optional setting is turned on), that specific key would be communicated onward using the standard keysym approach (this should dynamically occur within the same session). Fun fact: the JS keycode is actually not a very useful value. It's commonly misunderstood to be a scancode, but the value is only loosely related to the scancode of the key. It's actually defined as the scancode of the key that would be used to type the desired character on a US keyboard. This means: * The value is ambiguous for different keys on non-US keyboards that produce characters that happen to be located on the same key on US keyboards. * The value is not well defined for keys that don't exist on a US keyboard. See: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode => That’s understandable, and for our case (Hebrew layout) this is fine since the Hebrew keyboard is an extension of the ordinary US keyboard. - Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> הודעת דואר אלקטרוני זו נשלחה אליך מבית החולים אלי"ן. יתכן שבהודעה כלול מידע רפואי רגיש המוגן בחוק הגנת הפרטיות התשמ"ה 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.
