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.

Hello, I am experiencing a keyboard-related issue in Remote Desktop Manager for Linux. My current version is: Remote Desktop Manager Free 2026.2.2.2 The issue happens when I enable Caps Lock inside a remote session. After pressing Caps Lock, there is a noticeable delay before it becomes active. If I start typing immediately after pressing Caps Lock, the first characters may still be entered in lowercase, and only after a short delay the following characters are entered in uppercase. Example: I press Caps Lock and immediately type: aaaaAAAAAA instead of: AAAAAAAAAA This behavior is very noticeable during normal use and makes typing difficult. The issue appears to be related specifically to keyboard input handling inside Remote Desktop Manager. I have attached a screenshot showing the issue and my current RDM version. Could you please confirm if this is a known issue or regression in the Linux version? If needed, I can also provide information about: Linux distribution and version X11 or Wayland session Desktop environment Keyboard configuration Remote connection type Thank you. Eu acrescentaria também esta frase, porque ajuda bastante o suporte a entender a gravidade: The Caps Lock state seems to take approximately 1–2 seconds to synchronize with the remote session.

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

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

After upgrading RDM from 2026.2.2.2 to 2026.3.0.5, two problems appeared inside remote desktop sessions: • Pressing the Spanish acute-accent key followed by a produces a instead of á. • Each mouse-wheel notch scrolls approximately 10 lines, much farther than before. Environment: CachyOS Linux, KDE Plasma on Wayland, RDM installed through the AUR package remote-desktop-manager. Both the local keyboard and RDM are configured for Spanish. Steps to reproduce on the affected setup: 1. Upgrade RDM from 2026.2.2.2 to 2026.3.0.5 and open an RDP session. 2. In a text field in the remote session, press the acute-accent key followed by a. 3. In a scrollable remote application, turn the mouse wheel one notch at a time. Expected: á is entered, and scrolling moves the normal amount per notch. Actual: only a is entered, and scrolling moves approximately 10 lines per notch. Downgrading only RDM to 2026.2.2.2 resolved both problems, without changing connection settings or downgrading system dependencies. The package versions were 2026.2.2.2-2 (working) and 2026.3.0.5-1 (affected). Comparing the packages showed Avalonia changed from 11.3.17 to 12.1.2, while the bundled libDevolutionsRdp.so was byte-for-byte identical. This may help narrow the investigation, although it does not establish the root cause. Please let me know whether this is a known regression and which release will contain a fix.

Hi, I ran the official Linux build of RDM on FreeBSD's Linux compatibility layer (Linuxulator) and got surprisingly far, but hit two issues that look like they are on the RDM side rather than the platform side. I am not asking for FreeBSD support, and I understand this is an unsupported configuration. I am posting because the findings isolate the failure fairly precisely and might be useful to you, and because a few of them would improve the packaging on lean Linux installs as well. Environment FreeBSD 15.1-RELEASE amd64, Linuxulator with a Rocky Linux 9 userland (linux_base-rl9 9.7) RDM Linux 2026.3.0.5, the official DEB, unpacked into the Linux root. SHA256 matches the one pinned in your own Flatpak manifest (7a08f8af70f2...) webkit2gtk3 2.52.5 (EL9, API 4.0), vte291 0.64.2, GTK 3.24 from EL9 Xvfb at 1600x1000x24, software rendering via llvmpipe, tested both with and without a window manager Launched as the packaged wrapper does: GDK_BACKEND=x11 DOTNET_EnableWriteXorExecute=0 What works The application itself runs well. Full Avalonia UI, fonts, dialogs, settings, session history, all responsive. More importantly: VNC sessions work completely , including the live framebuffer. I connected to a local x11vnc and got a correct, continuously updating image. The RDP protocol handshake completes against xrdp: TLS, licensing, capability exchange, finalization, gdi_init_ex with PIXEL_FORMAT_BGRX32, and the rdpdr, rdpsnd, cliprdr and drdynvc channels all connect. The web view actually loads pages . My local test server logs GET / HTTP/1.1 200 coming from the RDM tab. So the .NET runtime, Avalonia, Skia, the VNC stack and the FreeRDP stack are all functional here. Issue 1: embedded GTK widgets get a window but never a usable surface This affects both the SSH terminal (VTE) and the web view (WebKitGTK). The X window tree during an open web session: 0x20000e "Remote Desktop Manager" 1024x768+10+10 (Avalonia toplevel) └─ 0x200017 676x661+339+73 (session area) └─ 0xc0002a "RemoteDesktopManager" 676x661+0+0 (GTK window, correctly reparented) └─ 0xc0002b 1x1+-1+-1 (content, never allocated) The GTK window is embedded at the right size, but its child stays at 1x1. Accompanying messages on stderr: (RemoteDesktopManager:11387): Gdk-CRITICAL **: gdk_window_move_resize_internal: assertion 'GDK_IS_WINDOW (window)' failed (RemoteDesktopManager:13951): Gtk-CRITICAL **: gtk_widget_get_parent: assertion 'GTK_IS_WIDGET (widget)' failed (RemoteDesktopManager:13951): GLib-GObject-CRITICAL **: g_object_remove_toggle_ref: assertion 'G_IS_OBJECT (object)' failed Consequences: SSH sessions abort. The tab opens, the host key prompt appears (so libssh is talking to the server), the username dialog appears, and then the session closes. The server side logs Connection closed by 127.0.0.1 port 47691 [preauth], and the GTK assertions above appear at exactly that moment. Web view stays blank even though the page was fetched successfully. Things I ruled out, in this order: Missing libraries. ldd on libEmbeddedTerminal.so and libWebView-4.0.so resolves everything. VTE API mismatch. All 11 vte_* symbols referenced by libEmbeddedTerminal.so are exported by vte291 0.64.2. Window manager. Same result with twm running and with no WM at all. WEBKIT_DISABLE_COMPOSITING_MODE=1, LIBGL_ALWAYS_SOFTWARE=1, GDK_SYNCHRONIZE=1, and forcing resize events on the embedded window from outside. Missing Xwayland, which is a hard dependency of your DEB. Installed it, no change. GTK itself. This is the key data point: a plain GTK3 application (zenity --info) from the same EL9 userland, on the same X server, renders perfectly, icon, text, button and all. So GTK, GDK, cairo and pango are fine on this platform. Only the widgets RDM embeds into the Avalonia window fail. Issue 2: RDP session stalls right after gdi_init_ex With WLOG_LEVEL=DEBUG, the connection completes and then stops. Last lines: [INFO][com.freerdp.gdi] - [gdi_init_ex]: Local framebuffer format PIXEL_FORMAT_BGRX32 [INFO][com.freerdp.gdi] - [gdi_init_ex]: Remote framebuffer format PIXEL_FORMAT_BGRA32 [DEBUG][Devolutions.Rdp] - [_OnChannelConnected]: OnChannelConnected (rdpdr) [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [static] Loaded alsa backend [DEBUG][Devolutions.Rdp] - [_OnChannelConnected]: OnChannelConnected (rdpsnd) [DEBUG][Devolutions.Rdp] - [_OnChannelConnected]: OnChannelConnected (cliprdr) [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading DVC nowproto [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading DVC ainput [WARN][com.winpr.thread] - [SetThreadPriority]: pthread_setschedprio(0) not implemented Nothing after that, even at WLOG_LEVEL=TRACE. The UI keeps showing "Connecting to 127.0.0.1:3389", and the socket confirms the client stopped reading: tcp4 839 0 127.0.0.1.24404 127.0.0.1.3389 ESTABLISHED 839 bytes sit unread in the receive queue indefinitely, which are presumably the server's finalization PDUs. The pthread_setschedprio warning is a compile time fallback in WinPR, not the cause. I confirmed that by shimming the symbol via LD_PRELOAD, which changes nothing. Packaging observations that apply to Linux generally libusb-1.0.so.0 is not in the DEB's Depends, but libDevolutionsRdp.so links against it. When it is missing, the library fails to load and RDM reports a generic "Unable to connect to host", which points the user at the network instead of at a missing dependency. Adding libusb-1.0-0 to Depends, or surfacing the dlopen error, would save people a lot of guessing. If /etc/resolv.conf is absent, the web view fails silently with a blank page and no visible error, because only the WebKitNetworkProcess is affected while the rest of the application keeps working. WebKit logs "Failed to get the memory usage" in a tight loop when /proc/meminfo has no MemAvailable line. That is a platform gap on my side and I patched it locally, but a rate limit on that message would be kind. Questions How does RDM embed the VTE and WebKitGTK widgets into the Avalonia window? GtkPlug/GtkSocket with XEmbed, or a manually reparented X child window? Knowing which handshake is expected would tell me what to instrument next. Is there a way to raise the log level for the session hosting layer, the way WLOG_LEVEL works for the RDP stack? The GTK assertions are all I currently get. Is libusb required, or optional for smart card and USB redirection only? Happy to run further tests, gather traces or try patched builds. The setup is a throwaway VM, so I can break it freely. Thanks.

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, 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.

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!

Hi, in RDM version 2026.3.0.5 on Linux with Gnome on Wayland the setting Application - Application Startup - Startup window state "minimized" "to the system tray" doesn't work right. When RDM is started, the system tray icon appears and after a few seconds, also the application window comes up. I tried "To the system tray", "To the taskbar" and "Both" with no difference in regards of the application window coming up instead of being minimized. Great work guys, RDM as improved a lot with the new surface. Best regards Markus

Hi. I have 3 tabs opened. First one is correctly "Disconnected". Second one is disconnected but "Disconnected" on tab is missing. Third tab is connected but "Disconnected" on tab is shown. Noticed that on previous version, newest one still has this 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.

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.

I see a few other topics about this, but keypresses are definitely broken for me. I think I figured out what triggers it, along with a workaround. It's annoying for sure, and it's not just RDP. I'm seeing the same thing with SSH connections too. I grabbed a video showing it, I just don't want to upload it here publicly. Basically, I connect and everything works fine. Then I switch to another app for a little while and come back to RDM. Boom, keyboard input is broken. I can't type anything. The up and down arrows sort of work, but not really. The workaround I've found is to click on another connection in the RDM connection list. It doesn't even need to actually be connected. Then I click back to the session I was using, and keyboard input starts working again. Super annoying. This only started happening for me with the latest version. Remote Desktop Manager 2026.3.0.5 64-bit Platform: CachyOS (KDE)

Subject: Devolutions Password Manager on Ubuntu 26.04 hangs when switching tabs Version: 2026.2.2.2 OS: Ubuntu 26.04 Description: Devolutions Password Manager occasionally hangs/freezes when switching between tabs. on wayland

Linux Kubuntu 24.04 , RDM 2026.3.0.5 64-bit In this version, sorting for folders based on "Sort Priority" does not work. In the screenshot, folders 1-2 have priority 0, while folder 3 has priority 10. For the connection list, sorting works correctly — server-3 with priority 10 is placed first. [image]

In the Linux version of RDM (I'm currently using 2026.2.2.2) there is always a thin frame around the content in the fullscreen view. This doesn't look particularly good, but the bigger problem is that because this frame makes the actual view slightly smaller than the screen size, and I'm using the scrollbar screen sizing mode, there is always a scrollbar, as the content never fits perfectly because of the rendering area always being slightly smaller than the screen size. On macOS, there is no frame around the fullscreen content in RDM, which both looks much better and prevents this issue. Could this be changed on Linux too, so that it follows the way it behaves on macOS?

I've encountered another issue (I can open a separate case if necessary). I can't use any keyboard shortcuts, particularly the ones for executing predefined commands, macros, or scripts in an SSH session. [image]

Environment: Product: Remote Desktop Manager (Linux), latest version OS: Ubuntu 24.04 LTS Display server: X11 Installation: .deb Connection scenario: RDP session reached through an SSH tunnel (target accessed via 127.0.0.1:<local_port>) Summary: RDM consistently crashes when establishing an RDP connection through an SSH tunnel. The application terminates with either SIGABRT (GTK text buffer assertion) or SIGSEGV, depending on conditions. The crash appears to originate in the bundled FreeRDP layer, with a secondary crash in the GTK text widget used to render the connection log/console. Crash signatures observed: GTK text iterator assertion (SIGABRT): Gtk:ERROR:../../../gtk/gtktextiter.c:1940:forward_char: assertion failed: (real->segment->type == &gtk_text_char_type) GTK text btree assertion (SIGABRT): Gtk:ERROR:../../../gtk/gtktextbtree.c:2204:_gtk_text_btree_get_line_at_char: assertion failed: (line != NULL) Segmentation fault during FreeRDP init when run with G_DEBUG=fatal-warnings (SIGSEGV). Relevant FreeRDP build warnings emitted before the crash: This build is using [experimental] build options: * 'WITH_MBEDTLS=ON' [experimental] build options might crash the application This build is using [runtime-check] build options: * 'WITH_VERBOSE_WINPR_ASSERT=ON' The bundled FreeRDP is built with mbedTLS (flagged experimental) rather than OpenSSL, and the build itself warns it "might crash the application." Last FreeRDP error before the SIGABRT in the most recent run: [ERROR][com.freerdp.core] - [transport_default_connect_tls]: ERRCONNECT_TLS_CONNECT_FAILED [0x00020008] Steps to reproduce: Establish an SSH tunnel forwarding a local port to a remote RDP host. In RDM, configure an RDP entry pointing at 127.0.0.1:<local_port>. Initiate the connection. RDM crashes (SIGABRT or SIGSEGV) instead of either connecting or failing gracefully. Expected behavior: RDM should either complete the connection or fail with a clean error message, without crashing the entire application. Actual behavior: The whole application terminates with a core dump.

Product: Remote Desktop Manager (Linux), RDP connections via bundled FreeRDP. Note: an earlier forum reply (Simon Duguay Létourneau, https://forum.devolutions.net/topics/9648/wrong-keyboard-layout) stated RDM bundles FreeRDP 3.11.0 - we've since confirmed the actual version shipped is 3.16.0, so that reply may be outdated. Setup: RDM runs inside a browser-based Linux desktop (KasmVNC/KDE Plasma), German ("de") keyboard layout configured both client- and server-side, RDP connection's Keyboard Layout explicitly set to German (0x00000407). ### Symptom - With "Send as Unicode" enabled: pressing AltGr+ß (backslash on a German layout) inserts a garbage/incorrect character immediately before the backslash. - With "Send as Unicode" disabled: pressing AltGr alone is interpreted as "@" instead of being recognized as a modifier. - The RDP connection's Advanced tab no longer has a "Disable sandboxing" option (present in RDM ~2 years ago per the forum thread above), so that earlier troubleshooting step is no longer available to test. ### Root cause we were able to trace Our browser-based desktop's VNC layer (KasmVNC) delivers the physical AltGr key as X11 keycode 92 (a dynamically-allocated "spare" keycode) instead of keycode 108 (the standard position for AltGr on a German XKB layout) - confirmed via xev. We could not get KasmVNC to deliver the correct/expected keycode without breaking AltGr composition entirely (a separate, unresolved upstream VNC-side limitation we're pursuing with the KasmVNC project directly). Given that, it looks like FreeRDP's internal X11-keycode-to-VK table doesn't recognize keycode 92 as any known key, resulting in VK_NONE, and falls back to transmitting the composed character via Unicode input instead of a proper AltGr-modified keypress - which is what produces both symptoms above. ### Ask Since the incoming X11 keycode from the display server can genuinely vary (not every VNC/X setup delivers AltGr on the "textbook" keycode), could the AltGr/Level3 handling be made more robust to non-standard keycodes - e.g. by trusting the keysym (ISO_Level3_Shift) directly when the keycode lookup fails, rather than only falling back to a raw Unicode character transmission?

I've installed RDM on the following Linux installs which were all bare metal. Bazzite (newest) Debian 12.10 Archlinux 2025.01 [image] Ubuntu 24.04 POP_OS! 22.04 I've attached a screenshot that I cut my data out of but you can see which parts accept dark mode and which do not. Most of my work is done at night. It would excellent to have this working. Thank you.

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.

Environment: Remote Desktop Manager: 2026.2.1.4, official APT package Avalonia: 11.3.17 OS: Ubuntu 24.04.4 LTS Kernel: 7.0.0-28-generic Desktop: GNOME Shell 46.0 Session: Wayland; RDM runs through XWayland with GDK_BACKEND=x11 GPU: Intel Iris Xe (i915) plus NVIDIA RTX 2000 Ada (nvidia) Display scaling: 100%, no fractional scaling Three monitors: 1920×1200 and two 2560×1440 displays Description: After RDM has been running for some time, the application intermittently stops accepting keyboard input and meaningful left-click actions. Right-click still opens context menus. Left-clicking different tabs changes the File/Home/Edit/View/Administration ribbon contents, showing that pointer events and UI repainting still occur, but buttons and normal commands/terminal changes do not propagate. Embedded SSH terminals also stop accepting keyboard input. Restarting RDM temporarily restores normal operation. Tests performed: Confirmed xdg-desktop-portal and GNOME portal services are healthy. Confirmed XWayland keyboard and pointer devices remain present. Disabled IBus only for RDM: no improvement. Toggled “Grab Keyboard Input”/magnet: no improvement. Forced X11 input focus to the main RDM window: no improvement. Sent Escape events to dismiss a possible hidden modal: no improvement. Verified there was no mapped hidden/modal top-level RDM window. Minimized/restored and forcibly remapped the main window: no improvement. Tested the Flatpak build with GNOME Platform 49: same issue. Downgraded to RDM 2026.1.2.4 / Avalonia 11.3.12: same issue. Restored 2026.2.1.4 afterward. Observed X11 state during failure: Main RDM window remained mapped, responsive, and declared WM_HINTS input=True. X11 input focus could successfully be assigned to the main RDM window. The process remained alive and responsive. Therefore the failure appears internal to RDM/Avalonia input or command routing rather than loss of XWayland devices or compositor focus. Expected behavior: RDM should continue accepting keyboard and left-click input without requiring the application and all open sessions to be restarted.

Hi Everyone. I'm facing a new behavior in the 2026.2.0.6. I'm not allowed to do anything into the root of a vault. I can't see properties, more or add new entries... On Windows client, connected with the same user, I have the permissions. [image] [image] It seems like the system permissions aren't applied correctly. Thank you in advanve.

Environment Remote Desktop Manager version: 2026.2.1.4 (Linux, installed via official APT repo dl.cloudsmith.io/public/devolutions/rdm, package remotedesktopmanager) OS: Ubuntu 22.04 (Jammy), inside a Docker container based on kasmweb/core-ubuntu-jammy:1.18.0-rolling-weekly Window Manager: xfwm4 (Xfce), no compositing/panel changes relevant to reproduction Access method: VNC (noVNC/Kasm) into the container's X11 display Launch command: remotedesktopmanager --no-sandbox Reproduced consistently; a second container running the identical RDM version under KDE Plasma (kwin as window manager) does not exhibit the problem. Description Keyboard input is not accepted in the connection editor's RDP-specific settings tab (the tab shown when creating/editing a connection of type RDP). All other tabs/menus of the same connection editor window accept keyboard input normally. Mouse clicks into text fields on the RDP tab appear to register (cursor/focus indicator), but no characters are entered when typing. Steps to Reproduce Start Remote Desktop Manager (2026.2.1.4) in a container using xfwm4 as window manager, connected via VNC. Create a new connection or edit an existing one, selecting RDP as the connection type. Open the RDP-specific settings tab within the connection editor. Click into any text input field on that tab and try to type. Expected behavior Keyboard input is entered into the focused field, as it is on every other tab of the same dialog and as it is under KDE/KWin. Actual behavior No keystrokes reach the input field on the RDP tab. The field visually appears focused (cursor caret shown), but typed characters are dropped. Technical investigation (X11 level) We debugged this at the X11 protocol level from inside the container: The connection editor's dialog top-level window (WM_CLASS = "RemoteDesktopManager") is correctly marked as _NET_WM_STATE_MODAL / _NET_WM_STATE_FOCUSED by the window manager, and correctly declares WM_HINTS.input = True plus WM_PROTOCOLS including WM_TAKE_FOCUS. However, the actual input-receiving widget is a window nested three levels deep below that top-level window (top-level → intermediate window → innermost WM_CLASS = "RemoteDesktopManager" window). This innermost window has no WM_HINTS and does not implement WM_TAKE_FOCUS itself — it relies entirely on the application to forward real X11 input focus (XSetInputFocus) to it once the top-level receives focus. Using xev, we confirmed focus NO on both the top-level and intermediate windows at all times during interaction — i.e., true X11 input focus never actually lands there via normal click interaction. Manually forcing focus onto the innermost window from outside the application (xdotool windowfocus --sync <innermost-window-id>) immediately fixes the issue: subsequent keystrokes from the VNC session are received correctly by the field, confirming the window and toolkit are otherwise fully capable of receiving input once focused. This also rules out any VNC/X-server input delivery problem. We independently ruled out window-manager focus-model differences (tested with both click-to-focus and focus-follows-mouse in xfwm4, and with /general/synchronous_client enabled) — none of these changed the behavior, since none of them can make the WM aware of the deeper application-owned child window that needs focus. The launch command includes --no-sandbox, suggesting the affected UI is rendered via an embedded Chromium/Electron surface; if the RDP-specific tab is implemented as a separately embedded renderer/view (unlike the other tabs), this would be consistent with our finding that only this specific sub-window fails to receive delegated input focus. Conclusion This appears to be an application-side issue in how Remote Desktop Manager forwards X11 input focus from its managed top-level window down to the embedded/nested widget used specifically by the RDP connection settings tab, triggered by xfwm4's focus-assignment behavior differing from KWin's in a way that this delegation does not handle. We're happy to provide the exact xwininfo -tree / xprop output and xev traces if useful. [image]