Bug Report

I'm running Zorin OS 18.1 Pro on a Framework 13.   I have to edit my connections to optimize for HiDPI connections as shown below. [image] And as you can see, everything looks great. [image] However when I do a quick connect I get this: [image] Everything is huge.  I cannot seem to find the same HiDPI setting in the preferences. Thanks again for fixing the cursor not changing when trying to resize windows in an rdp session! Thanks for looking into this as well. Mat

Hi, it’s me again. I’ve updated to Fedora 45 and even tried reinstalling the latest version of the RPM available on the website, but it won’t launch. Here is the error I’m getting.: Unhandled exception. System.TypeInitializationException: The type initializer for 'Avalonia.Controls.Documents.RichTextElement' threw an exception. ---> ei: An unexpected error occurred while processing the AvaloniaUI license key. Please verify the license key is correct or copy a fresh key from the Avalonia Portal. ---> System.PlatformNotSupportedException: OpenSSL is required for algorithm 'RSAOpenSsl' but could not be found or loaded. at System.Security.Cryptography.RSAOpenSsl.ThrowIfNotSupported() at System.Security.Cryptography.RSAOpenSsl..ctor(Int32 keySize) at System.Security.Cryptography.RSA.Create() at em.b(Byte[] a, Byte[] b, String c) at em.a(String a, String b) --- End of inner exception stack trace --- at em.a(String a, String b) at ef.n(String a) at Avalonia.Controls.Documents.RichTextElement..cctor() --- End of inner exception stack trace --- at CompiledAvaloniaXaml.!AvaloniaResources.Populate:/Themes/Default.axaml(IServiceProvider, Styles) at CompiledAvaloniaXaml.!AvaloniaResources.Build:/Themes/Default.axaml(IServiceProvider) at CompiledAvaloniaXaml.!AvaloniaResources.Populate:/Assets/EntryPoint/Styles.EntryPoint.axaml(IServiceProvider, Styles) at Devolutions.AvaloniaUI.AvaloniaApp.!XamlIlPopulate(IServiceProvider, AvaloniaApp) at Devolutions.AvaloniaUI.AvaloniaApp.Initialize() at Avalonia.AppBuilder.SetupUnsafe() at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.SetupWithClassicDesktopLifetime(AppBuilder builder, String[] args, Action`1 lifetimeBuilder) at Devolutions.RemoteDesktopManager.AvaloniaProgram.Initialize() at Devolutions.RemoteDesktopManager.Program.Main(String[] args) Annullato (core dump creato) remotedesktopmanager OpenSSL 4.0.3 29 Sep 2026 (Library: OpenSSL 4.0.3 29 Sep 2026)

I just upgraded to 2026.3.0.5 64-bit and have since not been able to use the Special key as it brings up my host OS's Application Menu. It used to be that I could press Right Ctrl to toggle between the host OS and remote RDP session if this occurred but that is not working. I ran through various options in the application and wasn't able to find anything to address this. Standard keyboard input is fine, but even combinations like Alt+Tab are kept on the local host OS. Your team has been pretty awesome in continuing to develop this software on Linux so I hope this is a helpful bug report!

Version 2026.3.0.5 via normal deb package. Since update to this version my keyboard shortcut for Reconnect (CTRL+R) is no longer working. When connection to host is active this shrotcut does "(reverse-i-search)`':" on host instead of reconnect. When host is disconnected nothing is happening. Another thing with duplicating tab. I have 5 tabs opened. 4 saved and 1 opened via this field on the bottom (all ssh). Duplicating saved tab works ok. Duplicating this not saved tab works but it works differently. It creates new tab, activates last active tab, then asks for username, password. New duplicated tab is not activated (as it is when saved tab is duplicated). Clicking on SFTP button while connected to linux host via ssh does nothing.

Greetings, I tried out the Devolutions Flakpak repo, after some months of using the DNF repo on Fedora, mostly without issue. In the flatpak version, using Fedora 44, Plasma 6.8.2, I'm experiencing a crash to desktop when I attempt to close an open SSH session via: A reboot command on the VM (ie. doas/sudo reboot) Clicking the X on the connection window Right clicking the connection in the nav bar > Close Aborting the SSH key import process This behavior was not present on the standard repo version of the application. I tried launching RDM from the cli - flatpak run, and the only output I get is when I connect to an SSH session - no further output: (RemoteDesktopManager:2): GLib-GObject-CRITICAL **: 09:50:22.027: ../gobject/gsignal.c:2437: signal 'response' is invalid for instance '0x7fa048017360' of type 'GtkWindow' I have also discovered a couple other irregularities: ~/.ssh directory override is still required to save SSH keys. Shouldn't this be a default override in the flatpak? Not having it as default inhibits a standard security practice and user experience. Theming seems to retain my system theme, everywhere except right clicking an in open SSH session reveals the light theme context menu as opposed to the dark version, which the rest of the application is using. I do not recall from previous tickets how to provide additional logs, any assistance would be appreciated.

Before 2026.3, the default when using a HiDPI display with for example 200% scaling (my external screen) or 166% scaling (my laptop screen) and connecting to a remote desktop machine (RDP), was that it would render the remote machine with 100% scaling, but upscale that according to my clients scaling settings. That would lead to the display being somewhat blurry, but showing all content with the correct size and rendering really fast as it didn't need to fetch 4 times the amount of data to be able to render it pixel perfect on my screen with 200% scaling. In practically all my usage, this is the perfect balance between speed and quality (mostly preferring speed I guess, but still), so I was quite disappointed when it now can't do that any more. In 2026.3.0.5, it renders the remote machine with the same scaling as my client by default (even though the settings are set to the same values as before: 100%), which looks quite good but is much slower, and no matter what I set the settings in General->Display->Scaling to, it seems to be impossible to make it behave like it did by default in 2026.2. I'm using Ubuntu 26.04 with Gnome/Wayland

Hello, when pressing Ctrl+D to exit the terminal, in this version it suddenly started to open a duplicate session dialog instead of logging off the ssh session. Tested on Linux MInt 22.3 and Fedora 44.

Environment OS: Fedora Linux 44 Desktop environment: KDE Plasma Remote Desktop Manager: 2026.3.0.5 Connection type: SSH Remote host: Linux RDM terminal: built-in SSH terminal While using an SSH session in RDM, the terminal works normally for some time and then suddenly starts behaving as if the Alt/Meta key is still pressed . Normal keyboard input is replaced by sequences such as: ^[i ^[n ^[d ^[j ^[s ^[kFor example, typing normal characters results in ESC + character being sent to the remote shell. At the same time, Ctrl+C stops working correctly . The remote shell continues to behave abnormally and pressing Ctrl+C does not interrupt the current input/process as expected. Workaround Pressing the Alt key once immediately restores normal keyboard input. After pressing Alt, the SSH terminal works normally again without reconnecting the session. Reproduction / observed behavior Open an SSH session in RDM. Use the terminal normally. After some time, the keyboard input may become corrupted. The terminal starts receiving ESC + character sequences (^[x). Ctrl+C no longer works correctly. Pressing Alt once immediately fixes the problem. This seems to indicate that RDM is incorrectly retaining or restoring the Alt/Meta modifier state in the SSH terminal. Please investigate whether this is a regression or a known issue in the 2026.3.x terminal/keyboard handling on Linux.

When I batch edit more than a couple entries, RDM completely hangs for multiple minutes usually ending in a crash, "unable to validate entry via server", or "unable to connect to the server. Connection timed out." (System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.). Single entry editing is fine. I just edited 4 entries and it took a couple minutes but it worked. Things changed in the batch edit : tags or credentials. Edit: Tested on flatpak and rpm release 2026.3.05 (wayland and x11) and rpm 2026.2.2.2

Hello Devolutions Support, Remote Desktop Manager for Linux terminates with SIGSEGV when I close an active SSH session. I have also observed a crash while leaving RDM running without interaction. Two captured crashes have the same native stack signature in g_object_remove_toggle_ref. The session-closing crash also occurred with X11 explicitly forced and the Wayland socket disabled for RDM. Impact The whole RDM process exits, interrupting my remote-session workflow. Environment - RDM version: 2026.3.1.1, x86_64 - Installation: system-wide Flatpak, origin "devolutions", branch "current" - App ID: com.devolutions.remotedesktopmanager - App ref: app/com.devolutions.remotedesktopmanager/x86_64/current - App commit: 6a30b972e332f8fb3b5f4f073da55ebbc1ffe85d2e26aa6ae973340b21f78235 - App build date: 2026-10-02 22:02:45 UTC - Desktop: KDE; session type: Wayland - Runtime: org.gnome.Platform/x86_64/49, origin "flathub", system installation - Runtime commit: 2bb946ea4ebb050f6a32f90e979feb975b08280d1ff1aac881dec3d1361ad84d - Runtime build subject: Build of the GNOME Runtime from: 49.10-1-g75d7cf116 - Runtime build date: 2026-10-03 06:00:39 UTC - libgobject/libglib reported in the crash: 2.86.5 (libgobject-2.0.so.0.8600.5) - NVIDIA library present in the first core: libnvidia-glcore.so.615.71.09 - Host distribution, kernel, Flatpak version and KDE version: not yet collected Steps observed to trigger the crash 1. Launch RDM. 2. Open and use an SSH session in RDM. 3. Close the active SSH session. 4. RDM can terminate with SIGSEGV instead of only closing the session. Expected: The SSH session closes and RDM remains running. Actual: The entire RDM process crashes and systemd records a core dump. Frequency: Observed more than once, but not established to happen on every session closure. An additional idle crash was observed. I have not established whether this began with the October 2 update. Crash evidence Both cores identify this executable: /app/lib/devolutions/RemoteDesktopManager/RemoteDesktopManager First captured crash: 2026-10-07 14:14:33 CEST, host PID 26701, SIGSEGV. Its symbolized native stack begins: #0 g_type_check_instance_is_fundamentally_a (...) at ../gobject/gtype.c:3917 #1 g_object_remove_toggle_ref (object=0x55798d1c8360, ...) at ../gobject/gobject.c:4561 #2 0x00007f336174438f in ??? () Second captured crash: 2026-10-07 15:32:00 CEST, host PID 32109, SIGSEGV, on closing an active SSH session during the forced-X11 test. Its symbolized native stack begins: #0 g_type_check_instance_is_fundamentally_a (type_instance=0x56015b1aba30, fundamental_type=0x50 [GObject]) at ../gobject/gtype.c:3917 #1 g_object_remove_toggle_ref (object=0x56015b1aba30, notify=0x7f27fbc19b90, data=0x7f17a1c145b0) at ../gobject/gobject.c:4561 #2 0x00007f27ff713f7f in ??? () #3 0x00007f185acae7a0 in ??? () #4 0x0000000000000001 in ??? () #5 0x00007ffd332abad0 in ??? () #6 0x0000000000000000 in ??? () The faulting source line reported by GDB in both cases is: node = lookup_type_node_I (type_instance->g_class->g_type); The managed caller is not resolved by these native GDB traces. An invalid or already freed GObject is a hypothesis, not a confirmed root cause. Troubleshooting completed - Installed the GNOME 49 SDK and debug symbols to inspect the cores. - Disabled GDB debuginfod retrieval and successfully obtained backtraces. - Tested this launch command: flatpak run --socket=x11 --nosocket=wayland --env=GDK_BACKEND=x11 com.devolutions.remotedesktopmanager - RDM still crashed when closing an active SSH session under that launch configuration, with the same native stack signature. - Queried the Devolutions remote using flatpak remote-info --system --log devolutions com.devolutions.remotedesktopmanager//current. It returned an empty History section, so no application rollback was tested. - No native .deb/.rpm installation or runtime rollback has been tested. Additional terminal messages during the forced-X11 run (RemoteDesktopManager:2): Gtk-WARNING **: 14:30:37.594: Locale not supported by C library. Using the fallback 'C' locale. (RemoteDesktopManager:2): GLib-GObject-CRITICAL **: 14:30:53.233: ../gobject/gsignal.c:2437: signal 'response' is invalid for instance '0x7f17a80089b0' of type 'GtkWindow' That warning occurred earlier in the run; a causal relationship with the later crash has not been established. Flatpak also reported reserved /etc certificate paths not being shared. GDB reported unavailable file-backed mappings and deleted memfd mappings, but successfully loaded the cores and resolved the two GObject frames. Available diagnostic files - rdm-backtrace.txt: first core, bt full and all-thread backtraces - rdm-32109-backtrace.txt: second core, top 15 frames requested - rdm-x11-test.txt: terminal output from the forced-X11 run Please confirm whether this is a known RDM/GTK binding object-lifetime issue or a GNOME 49 runtime compatibility issue. Is there a fixed build or recommended workaround? If a managed stack trace is required, please provide the appropriate SOS/runtime-symbol collection steps for this exact Flatpak build.

CTRL+a d shortcut for session detaching (in 'screen' app) opens rdm machine properties instead of detaching the screen in terminal (in ssh session) it doesn't work in rdm-2026.3.1.1 it works in rdm-2026.2.2.2 ----- RDM installed on Debian 13.7

In the latest version the new filter field is broken, when I filter for a connection, open the ssh connection and click back into the filter, I can't type anything. I can click on the X, which removes the content but clicking again in the field and try to type, it doesn't work. After alt+tab and going back it's working again. Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 327 MB

SUMMARY When an embedded RDP session tab is closed in Remote Desktop Manager for Linux, RDM does not close the TCP connection to the server. The socket stays ESTABLISHED and RDM stops reading it. The server therefore never sees a disconnect: the session remains "Active". A few minutes later every process in that session stops running until the session is really disconnected. For us this pauses a 24/7 application that runs in the interactive session on the server. ENVIRONMENT - Remote Desktop Manager for Linux 2026.3.0.5 (deb, amd64) - Ubuntu 24.04.5 LTS, GNOME on Wayland, kernel 7.0.0-28-generic - Session type: RDP, display mode: Embedded (tabbed) - Server: Windows Server 2016 Standard (10.0.14393), direct connection to port 3389, no gateway - Version 2025.3.0.8 was installed until 25 Sep 2026; we suspect the same behaviour there (similar incidents, not measured) STEPS TO REPRODUCE 1. Open an RDP session to a Windows server in an embedded tab and log on. 2. Close the tab (do not log off, do not use Start > Disconnect). 3. On the client: ss -tnpi '( dport = :3389 )' 4. On the server, from another session: quser ACTUAL RESULT Client: - The socket is still owned by RemoteDesktopManager and stays in ESTAB. - Recv-Q only grows, so RDM no longer reads it. One connection sampled after the tab was closed: Recv-Q 0 -> 2322 -> 2475 -> 2577 -> 2730 -> ... -> 5025 -> 7983 -> 8136, state ESTAB all the time. - When the server side is disconnected later, the socket goes to CLOSE-WAIT and stays there: RDM never closes its end. Server: - quser keeps showing the session as Active, not Disc. No disconnect is logged. - 2 to 4.5 minutes after the tab was closed (2:00, about 2:30, 3:25 and 4:27 in four runs; in a fifth run nothing happened within 5:47) all processes of that session stop: their CPU time no longer increases, GUI and console processes alike. About every 2 minutes they run for a moment and stop again. Processes in session 0 are not affected. - It also happens in a freshly created session. - The stall ends within a second when the session is really disconnected: "tsdiscon <id>" from another session, or the "time limit for active but idle sessions" policy, or a reconnect. The same processes simply continue. EXPECTED RESULT Closing the tab disconnects the RDP session and closes the TCP connection, as closing the window of mstsc or xfreerdp does. The server then shows the session as Disc. IMPACT After an administrator closes an RDM tab, the application running in that server session is frozen for minutes, until somebody reconnects. On servers where that application must run around the clock this is an outage. WORKAROUNDS WE USE - Start > Disconnect inside the session before closing the tab. - Server side: the idle-session limit policy, which disconnects the stuck session after the limit. QUESTIONS 1. Is this a known issue in RDM for Linux? 2. Is closing an embedded RDP tab meant to disconnect the session and close the socket? 3. Is there a setting that influences this? 4. Which logs would help? We can provide full "ss -tnpi" snapshots over time, the server-side session events, and RDM logs if you tell us how to enable the relevant ones.

2026.2.1.4 64-bit on Fedora 44 w/KDE Plasma Hi all, when i edit a connection i need to switch tabs to find out update (or cancel) button to save.: [image] Same behavior with ssh sessions.

RDM 2026.3.1.2, Devolutions.ProtocolsSharp 2026.9.28.2 fails with: SSH session: Failed to initiate PKCS11 ECDSA signing Provider: /usr/lib/x86_64-linux-gnu/libykcs11.so Explicit PKCS#11 certificate method also fails. The YubiKey starts blinking. OpenSSH with ssh -vvv -I /usr/lib/x86_64-linux-gnu/libykcs11.so user@host prompts for PIN and authenticates successfully. The same setup worked in an older RDM version. Linux distribution: Ubuntu 24.04.5 LTS

Why will all this function keys get capture in a "remote desktop client" software? Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 284 MB

Hi, since the upgrade on the latest version SSH has a kind of annoying feature, it create a rename dialog for the connection while you are in an ssh session. Pretty sure nobody needs a short cut to rename a connection ever, even it's common shortcut in file explorers... can this be disabled or removed or if it can be configured point me where an disable it per default for other frustrated future users? Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 107 MB

Did anyone testing ssh before releasing new features? Open an SSH session and press ctrl+d to logout, instead the settings screen opens... who needs a shortcut for the settings screen? This version is so broken that I downgrade soon... Remote Desktop Manager 2026.3.1.2 64-bit Runtime: .NET 10.0.13 Platform: Debian GNU/Linux 13 (trixie) Allocated memory: 284 MB

Dear Support Team, Thank you for your excellent product. I am already using it on Windows and now I am trying to use it on Ubuntu Linux as a replacement for Remmina. I would like to report a very small bug. It is not a major issue, but it can be a little annoying for non-English users who need to type accented characters in their daily work. Product: Remote Desktop Manager for Linux Version: 2026.3.1.1 64-bit, .NET 10.0.12 OS: Ubuntu 26.04.1 LTS, Wayland session [GNOME ?] Keyboard: Swiss French QWERTZ physical keyboard, layout "French (Switzerland)" Description In an embedded RDP session, dead keys are not taken into account. Pressing a dead key followed by a letter outputs only the letter, without the accent: ^ then e gives "e", not "ê". Pressing a dead key followed by Space outputs only a space, not the accent character itself. The dead key press itself produces nothing, so it is impossible to type ^, ~ or ¨ [exact key combination to confirm], or any accented letter built with them. This affects every dead key I tested: ^, ~ (AltGr + ^) and ¨ [to confirm]. Regular keys and other modified characters work normally: Shift + 2 gives ", AltGr + 2 gives @. Expected behavior The dead key is forwarded or composed correctly, so that ^ then e gives "ê", and ^ then Space gives "^", as with other RDP clients. What works Dead keys work normally in RDM's own interface (e.g. the search bar), including ^ then e giving "ê". With the same server, the same user and the same keyboard layout, both xfreerdp and wlfreerdp handle dead keys correctly and give "ê". What I tried without success RDP entry keyboard layout set to French (Switzerland) and to French (France) "Send Unicode" set to true and to false Launching RDM with GTK_IM_MODULE set to ibus and to none [and the AVALONIA_IM_MODULE / XMODIFIERS variants] Steps to reproduce Open an RDP session to a Windows machine from RDM on Ubuntu (Wayland), with a Swiss French keyboard. Click in a text field in the remote session (e.g. Notepad). Press ^, then e: only "e" appears. Press ^, then Space: only a space appears. Repeat with ~ (AltGr + ^) and ¨: same result. Analysis The dead key event seems to be lost between the local keyboard handling and the RDP layer on Wayland: the following key arrives as a plain key without any accent. This is my interpretation, not a confirmed diagnosis. I can provide logs or run additional tests if needed. Thanks in advance for your attention.

Hello, In Remote Desktop Manager for Linux, clicking Open on a remote file downloads it successfully, but no editor opens and no error is displayed. Environment: RDM 2026.3.1.1, 64-bit, DEB installation Ubuntu 26.04.1 LTS GNOME / Wayland Default PHP file editor: VS Code Steps to reproduce: Connect to a Linux server over SSH and open the SFTP pane. Navigate to a file such as /home/ubuntu/example/config/Config.php. Right-click the file and select Open . The file is downloaded to: /tmp/RDM/edit_<hash>/Config.php However, the debug log reports the following (paths anonymized): OpenEdit - Failed to find file at location: /tmp/RDM/edit_<hash>//home/ubuntu/example/config/Config.php It appears that the full remote path is appended to the temporary directory where only the filename should be appended. Additional checks: Opening a local PHP file with xdg-open successfully launches VS Code. An execve trace showed no editor or xdg-open process being launched during the failed Open action. Creating a temporary directory symlink so the incorrect path resolves to the downloaded file made Open work immediately. Automatic upload after editing has not been tested. Updating from 2026.3.0.5 to 2026.3.1.1 fixed the separate issue where the SFTP pane would not open from the SSH toolbar, but this file-opening issue remains. Could you investigate the local path construction in the SFTP Open action?

Hi, I am having a scaling issue with Remote Desktop Manager for Linux 2026.2.0.4 on Ubuntu 26.04 / GNOME Wayland . The remote session content itself is readable, for example SSH terminal text is fine, but the RDM interface around it is extremely small: top menus; toolbar icons; filter bar; small UI controls. This makes RDM difficult to use on my setup. Environment Ubuntu 26.04 GNOME Wayland session Remote Desktop Manager 2026.2.0.4 5-monitor HiDPI / mixed scaling setup RDM version: apt policy remotedesktopmanager remotedesktopmanager: Installed: 2026.2.0.4 Candidate: 2026.2.0.4 Monitor layout: Monitors: 5 0: +*HDMI-4 6144/700x3456/390+2160+2880 HDMI-4 1: +DP-5 2160/600x3840/340+8304+2880 DP-5 2: +DP-6 2160/600x3840/340+0+2880 DP-6 3: +DVI-D-1 3840/600x2160/340+7280+720 DVI-D-1 4: +HDMI-5 5120/610x2880/350+2160+0 HDMI-5 RDM process environment: XDG_SESSION_TYPE=wayland WAYLAND_DISPLAY=wayland-0 DISPLAY=:0 GDK_BACKEND=x11 XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth... So RDM appears to run under XWayland , while the desktop session is Wayland. What I tried I already tried the following without success: AVALONIA_GLOBAL_SCALE_FACTOR=1.5 remotedesktopmanager AVALONIA_GLOBAL_SCALE_FACTOR=2 remotedesktopmanager AVALONIA_GLOBAL_SCALE_FACTOR=4 remotedesktopmanager Also tried per-monitor scaling: AVALONIA_SCREEN_SCALE_FACTORS='HDMI-4=1.5;DP-5=1.5;DP-6=1.5;DVI-D-1=1.5;HDMI-5=1.5' remotedesktopmanager and also with scale factor 4. The variable is visible inside the RDM process environment, but it has no visible effect. I also tried: printf 'Xft.dpi: 144\n' | xrdb -merge printf 'Xft.dpi: 192\n' | xrdb -merge No effect. I tested with a clean RDM profile by moving ~/.rdm, but even the initial setup wizard starts extremely small, so it does not seem to be caused by my profile or saved layout. I also tried gamescope. It can make the whole window larger, but it causes mouse/input and resize issues, so it is not usable as a real workaround. Strange behavior A couple of times RDM seemed to start with normal scaling by itself, but I could not reproduce why. Most of the time it starts with the UI extremely small. This makes me suspect a DPI/scaling detection issue related to XWayland, monitor ordering, startup timing or initial window placement. Questions Is this a known issue with RDM Linux 2026.2.0.4 on Wayland/XWayland with HiDPI/fractional scaling? Is there an official way to force RDM UI scaling on Linux? Does RDM read any specific config file, command line option or environment variable for UI scaling? Thanks.

Hi, I prefer to open RDP Sessions in undocked mode. However, when configure the Undocked mode to be the default in the settings I'm missing the tabs on the window. This makes it also impossible to group the connections in undocked mode. Tested on version 2026.3.1.1 Best regards, Christoph Fink

Hi all, Firt issue: Since the last update, switching between shells while working on multiple simultaneous SSH sessions takes two seconds . Second issue: I constantly use Ctrl+D to close the session (which is the standard behavior on Linux), but the function has been changed; now, it edits the active connection instead. Would it be possible to restore the previous behavior? Thanks again.

Hi, the Update from 2026.2.2.2 to 2026.3.0.5 introduced a strange bug. Im Using Kubuntu 24.04. LTS with EN_US locale but DE_DE keyboard layount and a keyboard with german alyout. After the update to 3.0.5 my keypresses are not submitted correctly to an RDP connection. It seems they are submitted with the rdpmanager thinking I'm using EN_US keyboard layout. Downgrading to 2026.2.2.2 fixed the problem.

The option "Display the connection bar when in full screen mode" (Connection Properties -> General -> Display) doesn't seem to do anything at the moment. I expected that unchecking it would turn the connection bar off entirely when viewing a connection in full screen, but the connection bar is showing the same way independent of what this option is set to. The connection bar is probably quite useful depending on how someone uses remote desktops, but for me personally I really only use the close button and there are other ways to close the connection, so it's more in the way then being useful for me and it would be perfect if this option would function as it sounds like it's intended to do, so that I can disable the connection bar entirely for a connection.