I beg your pardon, since keymap is a server feature, I should have phrased my suggestion the following:
1. Extend the keymap file format to support physical-to-scancode mapping, either from JS keyCode strings or from other (better) physical codes. 2. For each keypress, have Guacamole client send standard keysym-translated value along with the physical value (whenever there exists a physical value) 3. When Guacamole server interprets a key stoke, if physical value was passed on from the client + if a physical mapping (the new feature) was defined in the keymap file, favor the physical mapping. Otherwise, go on the standard keysym mapping. Then, our keymap example could look as follows (no need to couple physical with shift/caps in our case; and punctuation marks are back in the keysym section in order to support on screen keyboards): # Standard (fallback) keysym mapping map -caps -shift 0x29 0x02..0x0D ~ "`1234567890-=" map -caps -shift 0x10..0x1B 0x2B ~ "qwertyuiop[]\" map -caps -shift 0x1E..0x28 ~ "asdfghjkl;'" map -caps -shift 0x2C..0x35 ~ "zxcvbnm,./" … # Physical mapping map +physical 0x10..0x1B 0x2B ~ "KeyQ,KeyW,KeyE,KeyR,KeyT,KeyY,KeyU,KeyI,KeyO,KeyP,BracketLeft,BracketRight,Backslash" map +physical 0x1E..0x28 ~ "KeyA,KeyS,KeyD,KeyF,KeyG,KeyH,KeyJ,KeyK,KeyL,Semicolon,Quote" map +physical 0x2C..0x35 ~ "KeyZ,KeyX,KeyC,KeyV,KeyB,KeyN,KeyM,Comma,Period,Slash" Thanks, Uri From: אורי ענבר Sent: Friday, May 10, 2024 1:15 PM To: [email protected] Subject: RE: Hebrew/English keyboard layout challenges I fully agree, that’s why I what is suggest is the following general solution, which does not favor any specific layout: Extend the keymap file format to support physical-to-scancode mapping, either from JS keyCode strings or from other (better) physical codes, and treat this mapping with higher priority than the standard keysym-to-scancode definitions. Then, if Guacamole client receives a physical key press which has a physical mapping – take it. Otherwise, fallback to the standard keysym-to-scancode definition. For our US based layouts the mapping file could look like this (note that I intentionally omitted the problematic punctuation marks from the keysym mapping for our use case): # Standard (fallback) keysym mapping map -caps -shift 0x29 0x02..0x0D ~ "`1234567890-=" map -caps -shift 0x10..0x1B 0x2B ~ "qwertyuiop[]\" map -caps -shift 0x1E..0x26 ~ "asdfghjkl" map -caps -shift 0x2C..0x32 ~ "zxcvbnm" # Physical mapping map -caps -shift +physical 0x10..0x1B 0x2B ~ "KeyQ,KeyW,KeyE,KeyR,KeyT,KeyY,KeyU,KeyI,KeyO,KeyP,BracketLeft,BracketRight,Backslash" map -caps -shift +physical 0x1E..0x28 ~ "KeyA,KeyS,KeyD,KeyF,KeyG,KeyH,KeyJ,KeyK,KeyL,Semicolon,Quote" map -caps -shift +physical 0x2C..0x35 ~ "KeyZ,KeyX,KeyC,KeyV,KeyB,KeyN,KeyM,Comma,Period,Slash" Uri From: Nick Couchman <[email protected]<mailto:[email protected]>> Sent: Tuesday, May 7, 2024 4:42 PM To: [email protected]<mailto:[email protected]> Subject: Re: Hebrew/English keyboard layout challenges On Tue, May 7, 2024 at 6:05 AM <[email protected]<mailto:[email protected]>> wrote: 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: When you say "currently selected Windows keyboard language," it sounds like you mean the client-side, not the remote side. I think I assumed in my original response that you meant the layout selected on the remote side, but the above statement clarifies that you just mean on the client-side, where the user is accessing Guacamole. It doesn't sound like it matters much, though - there does not currently appear to be a way for the browser to access the currently-selected keyboard layout. # 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. Ideally, whatever solution is defined should scale beyond a single use-case. There may be RTL or other non-Latin languages that would benefit from something like this, but that aren't based off the US 102/105 key 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.
