On 5/6/24 9:06 AM, Nick Couchman wrote:
On Mon, May 6, 2024 at 10:31 AM <[email protected] <mailto:[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.
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).
* 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.
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 - Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
