On Tue, May 7, 2024 at 6:05 AM <u...@alyn.org> wrote: > On 5/6/24 9:06 AM, Nick Couchman wrote: > > > On Mon, May 6, 2024 at 10:31 AM <u...@alyn.org <mailto:u...@alyn.org>> > 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 >
