Dvorak/Colemak Keyboard Layouts

Hello,

Now just to be sure we understand the issue well.
In local, you have a Dvorak keyboard layout, but the remote system joined through RDP have a QWERTY layout and it doesn't allow you to use Dvorak.

Do we understand well the issue?
Best regards,

Hello! Yes, local system keyboard layout is Dvorak, RDP sessions results in QWERTY layout that cannot be changed in RDM and incorrect keystrokes being sent. Thank you

Hello

From a superficial look at the problem, this looks like a combination of two bugs:

• Our implementation of RDP defaults to an `en-US` keyboard layout, if the keyboard layout is not overridden by the user. This isn't correct: Microsoft RDP will try to use the client (local) keyboard layout in this case, and our implementation should be the same.
• In the section of RDM that allows you to override the keyboard layout, we're showing a list of cultures, not keyboard layouts. That partially works for different international layouts, but it also means that certain layouts which are not culture dependent are not available. So you cannot currently manually select a Dvorak layout.

I'm going to look into both these problems and I'll get back to you soon with an update. In the meantime, thanks for your patience and I apologize for the inconvenience.

Kind regards,

Hello

Just to give an update here; I've provided the RDM Mac team with an updated RDP library that should allow them to fix the keyboard layout selection (to include missing layouts like Dvorak) and also enable automatic keyboard layout detection based on your local layout.

I've created a ticket for those changes to be integrated, so someone on the RDM Mac team will post back here once there is progress on that.

Thanks for your patience

Kind regards,

Hello--Any update on when this might be targeted for release? I just updated to 2025.2.12.2 and the bugfix does not appear to be included. Is there anyway I could apply the fix locally?

Hello,

The feature was tagged to be released in the next major version, which is still in a while.
I will look if we can release it in the next minor version or if we can make a patch version to add it.
I will come back with an answer very soon.

Best regards,

Just checking in to see if there's a target for this request in a minor release?

Hi,

This should already be available. In the settings of the RDP go to "Local resources" and set "Keyboard layout" to Default.
For the keyboard layout to change in the remote system, either log out first or reboot the machine. The effect is the same. It’s a limitation of RDP.
After that, the remote session should use your system’s keyboard layout.

Best regards,

I have updated to 2025.3.6.9 and this behavior still persists. Using "Default" as the Keyboard Layout does not pass through the system keyboard layout. Locales are still present and not keyboard layouts for selecting alternatives. This is not a limitation of RDP as all other RDP clients do not have this limitation. Please review. Thank you.

Hi,

I reproduced the issue and applied a fix. After testing, everything is now working correctly. I’ll try to fast-track the release process for this ticket.
Sorry for the inconvenience.

Best regards,

Hey @Jesse Galarneau! -- As of 2025.3.9.2, this issue appears to persist. Any idea what release we might be able to expect this in? Thank you!

Hi,

Please note that for the keyboard layout change to take effect on the VM, you will need to either restart the virtual machine or log off and log back in to your user session.
If you continue to experience any issues after these steps, please feel free to reply and we will be happy to investigate further.

Best regards,

Hi,

Please note that for the keyboard layout change to take effect on the VM, you will need to either restart the virtual machine or log off and log back in to your user session.
If you continue to experience any issues after these steps, please feel free to reply and we will be happy to investigate further.

Best regards,

@Samuel Oliveira Martel Please see earlier in this thread where that is not the case. RDP allows for keymap translations. Jesse claimed a fix was completed... I'm just curious when it will be released or if I can get a patch ahead of that. This is a very frustrating bug.

Hello

There's nothing in the RDP protocol to translate between keyboard layouts. Any such feature would be very complex, and handled by the client. It's not something we support.

When you start an RDP session, the protocol allows us to specify what keyboard layout should be used on the remote system. If the keyboard layout is different to what is currently used in the remote session, it won't be applied,. That is an RDP limitation. So: if you connect to an already logged in session by RDP and ask for a different keyboard layout than is currently in use, it won't take effect. That is an RDP limitation that applies to all clients. It's necessary to log off the remote system and log back on for the change to be applied.

On my side, I've configured a Dvorak (DV) layout and specified that RDM should use "Default" for the keyboard layout. I've connected to my already logged in Windows session over RDP where previously I was using an English US layout. The server keyboard layout is not updated. I've logged off the system and reconnected, and now the remote keyboard layout is En Dv. To switch back to English US using just RDP, it's necessary to log out and back in again.

This is all expected and if you can identify an RDP client that supports a different workflow I would be interested to know which one that is.

If the feature is not working as I've written above (and I tested on RDM 2025.3.9.2) please let us know because it would indicate a bug.

Otherwise, if you have more questions or comments please don't hesitate to post back.

Thanks and kind regards,

I was able to recreate your observations with other clients. (Logging in with one key layout, disconnecting, and logging in with RDM appears to assume that layout) However, upon initial login -- all other RDM clients that I have used for MacOS appear to properly signal or set the proper keyboard layout upon login, including Microsoft's official client and FreeRDP-based clients. I started to dig into how these clients work and compare them to Devolutions RDP. The key difference for MacOS client appears to send keycodes rather than scancodes to the server. When configured in this manner, the remote system appears to correctly apply the requested layout on initial login.

In Devolutions RDP, this behavior appears to be enabled by selecting "Send Input as Unicode->Yes" (Default here appears to send scancodes? Is that correct?) and leaving Keyboard layout as "Default" This appears to resolve the initial login key layout issue. I'll keep testing and see if anything else is affected by this change, but this configuration looks promising.

Hello

Thanks for the follow up. The keyboard layout requested on the server should be totally independent of whether we send unicode or scan code for key events (I would have to double-check that in the code, but this is two completely different parts of the protocol - connection bootstrapping versus actual input).

How are you verifying the layout on the server? By typing and seeing the results? Can you confirm first of all that (with the above constraints about needing to logoff for the server to register a new keyboard layout from the client) that the keyboard layout is being properly set on the server? Most typically I do this by checking the notification tray which by default shows the current keyboard layout. I think you can also find that in Settings > Time & Language > Language & region.

Thanks and kind regards,

@Richard Markiewicz I agree with your statement. That said, changing to Unicode->Yes appears to have allowed all servers to correctly identify the requested keymap (indicated by the EN-DV icon at login and in the tray) However, several days now since I mass edited and replaced the settings across all servers and no matter how I configure the entry, I am unable to recreate the original failure.

Could it possibly have been some previous saved config carried forward from upgrades that was wiped out with the mass edit? Either way, happy to report that keymaps are working properly now. Thank you all for your help!

Hello

First, I'm glad you have things working well. I can't understand why recreating an entry would have solved your problem.

A little background explanation might go some way to help understand the behaviours you see on your side.

First, as we've already discussed, at connection time the RDP client tells the server what keyboard layout it wants to be used. If your user is already logged in to that server (i.e. you connect to an existing session) and that keyboard layout is not the one currently being used, RDP (on the server side) cannot change it. That can only be achieved by logging out and back in again - or, of course, by the user manually changing the layout in Windows. RDM lets you choose a specific keyboard layout or leave it at "Default" which will try to suggest the keyboard layout you're using locally (perhaps imperfectly in some cases, because there is not a strict 1-1 mapping between macOS and Windows keyboard layouts).

Second, for the keyboard input mode. If you choose to send scan codes, this is like "raw" key input and sends the physical key that was pressed. So, on my US English keyboard if I press the key marked "t" the protocol sends a scan code that effectively points to "the fifth key in the first row". Then the server injects that scan code into the session and it's interpreted by regular Windows keyboard handling. So, in this case, it's of high importance that the keyboard layouts on the client and the server are in sync. Otherwise, in this example, if I had Dvorak locally that same key is marked with a "y" but if the server is using US English we will obviously get a "t". The mapping of scan code to character is done entirely server side and is strictly dependent on the active keyboard layout.

Now, if you choose "Unicode" for the keyboard input mode it's different. Instead of sending a physical key location, symbolic characters are sent. In the above example we actually send the unicode symbol for "t". For the most part, this takes the keyboard layout on the server out of the loop, as the majority of Windows applications can interpret unicode input and will simply take the character as entered. Even an application that only understands scan code input, and tries to map that character back to physical keypresses will likely get it right based on the current keyboard layout, even if that layout does not match the client. This normally gives a more seamless experience but there can be edge cases - for example, we've seen problems with certain versions of PowerShell falling over on Unicode input.

I hope that this explains things well, but if you have any further questions or comments please don't hesitate to write back

Kind regards,