Keyboard issues with FreeDRP

Hello Martin,

Thank you for reporting the issues.

I was able to reproduce the alt gr + 4 that makes RDM crash, we actually use the same shortcut with a French keyboard for $. I will open an internal ticket regarding this.

As for the no input from the keyboard, I was not able to reproduce it. Is it only happening the first time you change the property of an entry to use "Dynamic resolution"?

Best regards,

Hello Martin

Thanks for your patience, and I apologize for the inconvenience.

I've found the issue with AltGr causing RDM to crash - this was a regression in a native dependency (actually; the issue is that FreeRDP is now more strictly validating certain inputs and the AltGr key is a very special case in terms of Windows keyboard input that we didn't properly account for). That fix will be in an upcoming release of RDM and we'll endeavour to post back here once it is available.

The same as my colleague, I've not been able to reproduce the issue where keyboard input is sometimes not working. We create a keyboard hook to receive input events, and that hook needs to be enabled or disabled appropriately as the focussed session changes - my feeling is that there is a certain case or scenario where we're not properly following the focus, preventing the hook from being enabled.

I'll keep trying to reproduce that issue, but in the interim I'll add some more diagnostic output to the relevant code that should help us troubleshoot the bug more effectively.

Please don't hesitate if you have further questions or concerns

Thanks and kind regards,

Hello Martin

My apologies for the delayed response (I missed this in our issue tracker), but the fix for the crash when typing key combinations with AltGr should have been fixed in RDM 2022.2.18.0. Can you let me know if you are still experiencing issues after that version?

Thanks and kind regards,

Hi,

Well, it doesn't crash now, but instead do a [CTRL] lock . No special charater, but everything after I try to use the [ALT GR]-key is [CTRL]+the key pressed for some time - Select all, Find, Cut, Paste and so on.

Have tried RDP (FreeRDP 7.0) and RDP (FreeRDP Latest) - but same result.

Kind regards
Martin Jensen

Hi Martin

I'm sorry to hear that's still not working quite right. I'll look into this ASAP and get back to you in this thread.

My apologies for the inconvenience

Thanks and kind regards

Hello again Martin

I've done some further investigation here, and I wasn't able to reproduce the problem you describe (the "ctrl-lock" effect). Although I *do* see things not working quite right - as far as I can tell, our embedded control matches the behaviour of FreeRDPs own Windows client but in both cases, pressing AltGr seems to cause the remote Ctrl key to be held only. So things are definitely still not quite right.

Can you confirm for me, if you're able to type special characters using Ctrl + Alt in place of AltGr? For example, to get a '$' on your Danish keyboard, can you achieve that with [Ctrl] + [Alt] + 4?

Thanks and kind regards,

Hi again,

New strange behavior with 2022.2.20.0, but to the questions:

Alt Gr: Still does a "CTRL Lock" for some time after the press of Alt Gr. So and A is a select all and V is paste.
Ctrl+Atl: Does nothing alt all - no $, no CTRL Lock,...

And now for something new I haven't seen before:
We use another brand PAM system where the username is [domain]\[username]+[domain]\[managedAccount]+[system] and the PAM-server as Host and with a blank domain and we have "Always ask for password" option enabled.
When using non-FreeRDP does it work fine, but with the two FreeRDP options does it reprompt for password and move the first [domain] to the domain field - you can add the [domain] back to the username and get past, but sadly doesn't the PAM system accept this :/

Lucky is the workaround easy - dont use the FreeRDP option and dont get the Dynamic Resolution option

Kind regards
Martin Jensen

Hi Martin

Thanks for the continued feedback. There's a few things to unpack here so I apologize in advance for my lengthy response.

Firstly, as you see, we have a lot of different options for RDP integration (and the list of options recently got bigger). The different configurations and settings form a huge matrix and while we do work hard on it, it's hard to get every feature correct for each option (and for each platform). Sadly FreeRDP is mainly implemented to support our non-Windows platforms (where it's the only choice for embedded RDP); while we provide it for consistency on Windows and try to keep up with issues, it naturally takes a back seat to the other RDP engines which are far more widely used.

That being said - you have a very good use-case for using FreeRDP (dynamic resolution). MS RDC also supports dynamic resolutions, you'll first need to install the RDC client then set "MSRDC" as the RDP application. In testing this, I realize it only works in "External" mode and you must manually toggle the setting in the RDC session. We already have a ticket open to automatically enable this based on your connection settings, and to enable it in embedded mode. I plan to circle back to these tickets, but the blocker is that RDC doesn't have much of a public or documented API for us to talk to. I'd suggest keeping an eye on the RDM release notes for improvement here, as this has potential to be a more effective workaround than using FreeRDP.

Regarding the issue with your new PAM system: I'm not entirely sure I follow the description. Are you saying: when you use MS RDP, the credentials prompt is shown with everything properly laid out - you simply enter the password and go? And with FreeRDP, the first domain string is moved and you must manually move it back, but then after entering your password the connection doesn't work? Possibly there is a bug with parsing the credentials, and it happens again after you dismiss the credential prompt - leading to the wrong username format getting passed to the PAM system. It doesn't get any further than that? (The RDP connection is not attempted?). I'm surprised that this works differently between MS and FreeRDP, so that's why I want to be really sure I understand. Can I know what is the PAM system (you could send me a PM if you don't want to write it here)>

With regard to the keyboard issue, I'm still looking into this (and had another ticket raised recently for something very similar).

Can you try one more thing for me? In the connection settings; under Local Resources > Keyboard, change the "Apply Windows key combinations..." setting to "On the remote computer". Does it now work if you strike [Ctrl] + [Alt] + 4 to get a $?

(I'm certainly assuming in all of this that you have a Danish layout both locally *and* remotely, and that the AltGr functions as expected with the MS RDP application option?)

Thanks for your continued troubleshooting and patience. I am eager to get this working for you and apologies for the inconvenience.

Kind regards,

Hi again Martin

Actually - if you toggle the setting I mentioned in my above post ("Apply Windows key combinations"), does AltGr now work as expected?

My feeling is that the default value for this setting ("On the local computer") traps the "Alt" key locally when it's pressed in conjunction with other keys (and internally, AltGr is just a mapping for "Ctrl" and "Alt" together).

Please let me know,

Thanks and kind regards

Hi,

I have tested and seen MSRDC works with external - can always hope M$ makes an API for it.

Regarding FreeRDP and "Apply Windows Key combination", then does it makes ALT GR+4 and CTRL+ALT+4 work to get a $ on the remote computer (Danish layout on both). Diont know if it gives any issues in day to day use - but time will tell when I test over a longer time.

Will send a PM about the PAM issue.

Kind regards

Martin Jensen

Hi Martin

Thanks a lot for the extra detail in your PM. Your application log file seems quite irregular; if you have time can you reproduce the issue with some more verbose logging enabled? Under Options > Types > Remote Desktop, there's a setting "Enable Logging", and you can provide a path to a text log file (the file will be created if needed). After you "OK" out of the options you'll need to relaunch RDM for the setting to take effect; but afterwards you should get a detailed debug log from FreeRDP in the given file, which you can send to me by PM or to service@devolutions.net (noting this forum thread in the email).

We *should* be able to unblock the "dynamic resolution" setting in embedded MSRDC; there's a ticket open for that and I encourage you to keep an eye on the RDM release notes for that in the future.

For the key combinations in FreeRDP, the downside of having that setting enabled is that the RDP session might capture some key combinations intended for the host (for example, Alt+Tab). The implementation of this setting broadly blocks sending the 'Alt' key in certain cases, whereas it should be based on a heuristic depending on the exact key combination(s) you're using. I'll enter a bug for this on our side, and update this forum thread once I have some progress on that.

As always, if you have any further questions or comments, please don't hesitate to ask

Kind regards,

Hi Martin

A small follow up for you.

The "Dynamic Resolution" screen sizing option was added to the UI to serve our needs on RDM macOS; and it's available when using FreeRDP on Windows too.

However; if you use MS RDP ("RDP (8.1)" or "Latest" under "RDP Version") **and** the server supports RDP 8.1; you can choose the "Smart Reconnect" display option. Under these conditions, when you resize the display, the client **won't** reconnect - it will perform a resolution change on the server.

If the client or server versions are not RDP 8.1 (or newer), it will fallback on reconnecting.

As a first step to tidying this up, I'll make sure the "Dynamic Resolution" option when using MS RDP on Windows gets the proper behaviour. But for now - try choosing "Smart Reconnect" instead.

Let me know if you have any questions or something is not clear,