Bug Report

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.

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

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.

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

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.

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.

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.

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 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]

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]

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.

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)

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, Zorin OS here. I have this behavior when I open several tabs with distinct SSH sessions and when I try to type special characters like ' or ", i cannot see what iḿ typing in the active tab but when i switch to another tab, those characters were written there. Regards

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

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

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

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