Resolution/workarea regression from 0.9.24-4 to 0.10.x

[alkisg]

xrdp version

0.10.1-3.1

Detailed xrdp version, build options

root@gmgmt:~# xrdp --version
xrdp 0.10.1
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2024 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --enable-ipv6
      --enable-jpeg
      --enable-fuse
      --enable-rfxcodec
      --enable-opus
      --enable-painter
      --enable-pam
      --enable-pam-config=debian
      --enable-vsock
      --build=x86_64-linux-gnu
      --prefix=/usr
      --includedir=${prefix}/include
      --mandir=${prefix}/share/man
      --infodir=${prefix}/share/info
      --sysconfdir=/etc
      --localstatedir=/var
      --disable-silent-rules
      --libdir=${prefix}/lib/x86_64-linux-gnu
      --libexecdir=${prefix}/lib/x86_64-linux-gnu
      --disable-maintainer-mode
      --disable-dependency-tracking
      --with-socketdir=/run/xrdp/sockdir
      build_alias=x86_64-linux-gnu
      CFLAGS=-g -O2 -Werror=implicit-function-declaration -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/xrdp-Ol8grW/xrdp-0.10.1=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/xrdp-Ol8grW/xrdp-0.10.1=/usr/src/xrdp-0.10.1-3.1
      LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -Wl,--as-needed
      CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=3
      CXXFLAGS=-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/xrdp-Ol8grW/xrdp-0.10.1=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/xrdp-Ol8grW/xrdp-0.10.1=/usr/src/xrdp-0.10.1-3.1
      PKG_CONFIG_PATH=/build/xrdp-Ol8grW/xrdp-0.10.1/pkgconfig

  Compiled with OpenSSL 3.0.13 30 Jan 2024

Operating system & version

Ubuntu 24.04

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

xorgxrdp

What desktop environment do you use?

xterm

Environment xrdp running on

Physical, amdgpu

What's your client?

Ubuntu xfreerdp

Area(s) with issue?

Graphic glitches

Steps to reproduce

To reproduce a "wrong resolution or workarea" issue with xrdp 0.10.1-3.1:

• I've installed xrdp from Ubuntu 25.10 on my remote Ubuntu MATE 24.04; one should be able to reproduce it with the Ubuntu MATE 25.10 live CD
• I've set xterm as my session manager: sudo ln -sf /usr/bin/xterm /etc/alternatives/x-session-manager
• I've launched xfreerdp from a local Ubuntu with: xfreerdp /dynamic-resolution /workarea /u:alkisg /v:server
• On xterm inside the xfreerdp session, I've ran xrandr

✔️ Expected Behavior

On my setup, the reported xrandr resolution should be 1920x1008 for a maximized xfreerdp window.

❌ Actual Behavior

• The xrandr output was wrong: 1920x1036
• The xfreerdp window content area was correct: 1920x1008
• There were no scrollbars in the xfreerdp window, so when I'm using a MATE session instead of xterm, the bottom panel is hidden below the visible area, and I can't scroll down to see it

Un-maximizing xfreerdp and then maximizing it again made xfreerdp do a "screen resize" event, which then gave the correct 1920x1008 resolution. So it's like it didn't correctly detect my local workarea initially.

Anything else?

I've tested on a single remote server, but from many local workstations, e.g. Kubuntu 24.04 with freerdp2, Ubuntu GNOME 25.04 with freerdp3. The local freerdp version or Ubuntu OS or resolution doesn't seem to matter.
The 1036-1008=28 pixels difference appears to be a miscalculation involving the xfreerdp window title bar size.

1. If I omit /workarea from xfreerdp to make it default to 1024x768, or if I use any /size: parameter up to 1920x1007, I get a "not maximized" xfreerdp window and I don't see the issue.
2. If I replace /workarea with /size:1920x1008, I get a maximized xfreerdp window and I don't see the issue. This is the best workaround I've found so far for my use case.
3. If I replace /workarea with any /size: parameter greater than 1008, I get a maximized xfreerdp window and I do see the issue.

So it might be possible that xfreerdp is mis-reporting something, and the old XRDP somehow worked around this.

[matt335672]

Hi @alkisg

Thanks for taking the trouble to investigate this. I take it the XDG_DATA_DIRS variable is no longer a problem?

I can see what's happening here. On my system with a 2560x1440 monitor, the 'workarea' size is 2560x1407. The usable size is 2560x1378.

When xfreerdp connects (I'm using 3.16.0), an initial size of 2560x1407 is sent, and then a size of 2560x1378 is sent on the virtual channel Microsoft::Windows::RDS::DisplayControl which is used for dynamic resizing. All RDP virtual channels are multiplexed over the static channel dydynvc.

On xrdp v0.9.x, we don't need any dynamic channels (including the resize channel) until the login stage has completed. Consequently, we don't enable the drdynvc channel until after login has completed. At least I think this is what is happening - there have been a lot of changes in this area.

On xrdp v0.10.x we need another virtual channel Microsoft::Windows::RDS::Graphics for GFX during the login screen. Consequently we have to enable dydynvc much earlier. However, the login screen doesn't handle resize messages yet.

When I look in the log for v0.10.x, I get these messages, along with others:

[2025-09-15T09:56:27.353+0100] [INFO ] [xrdp_egfx_reset_graphics(xrdp_egfx.c:734)] xrdp_egfx_reset_graphics: width 2560 height 1407 monitorcount 1
[2025-09-15T09:56:27.353+0100] [INFO ] [xrdp_mm_egfx_create_surfaces(xrdp_mm.c:1113)] xrdp_mm_egfx_create_surfaces: map surface_id 0 left 0 top 0 width 2560 height 1407
[2025-09-15T09:56:27.494+0100] [INFO ] [libxrdp_process_monitor_stream(libxrdp.c:2024)] libxrdp_process_monitor_stream: Received [MS-RDPEDISP] 2.2.2.2.1 DISPLAYCONTROL_MONITOR_LAYOUT_PDU.DISPLAYCONTROL_MONITOR_LAYOUT Index: 0, Flags 0x00000001, Left 0, Top 0, Width 2560, Height 1378, PhysicalWidth 867, PhysicalHeight 467, Orientation 0, DesktopScaleFactor 100, DeviceScaleFactor 100
[2025-09-15T09:56:27.494+0100] [INFO ] [xrdp_wm_can_resize(xrdp_wm.c:2536)] Not allowing resize. Login in progress.
[2025-09-15T09:56:30.951+0100] [INFO ] [lib_mod_process_message(xup.c:1979)] Received memory_allocation_complete command. width: 2560, height: 1408

In other words, we're getting the resize earlier, during the login screen part of the startup process, even though the login screen isn't being used in this scenario. Then we're ignoring it.

I'll have a think about the best way to deal with this. We may need to cache the last resize message received during login. I don't know whether we can just enable the resize virtual channel later. That might be client-specific.

[alkisg]

I take it the XDG_DATA_DIRS variable is no longer a problem?

Indeed Matt, that was caused by a local misconfiguration (wrong Xsession alternative), so I've edited the issue description to omit it.

When xfreerdp connects (I'm using 3.16.0), an initial size of 2560x1407 is sent, and then a size of 2560x1378 is sent on the virtual channel

I wasn't able to reproduce this issue with Microsoft's mstsc.
If you think I should file it against freerdp instead, I can do that; maybe freerdp can send 2560x1378 in its initial size; I don't see how 2560x1407 would be considered correct as it also contains freerdp's title bar.

[matt335672]

We've definitely got a problem with xrdp, in that we can't handle an early resize, so I'm going to leave this open. I don't think there's anything wrong with the freerdp approach from a standards perspective, and the standard has to be the reference we work to.

I've had a play with the resize logic in xrdp, and I can see this won't be an easy fix. There's a 'resize queue' as currently implemented, and in theory I could just tack client-side resize requests onto that and enable the queue once we've got to a position where we can process it. This will break horribly if (for example), the user sends 10 such requests to xrdp with the login window open. When the user logs in, we'll send 10 resize requests, one after the other, to the desktop. That's not good.

I think the queue needs replacing with just two items:-

1. A 'resize in progress' item.
2. ' A next resize' item.

Furthermore, items need to be marked with their source ('client' or 'server' or 'server force'). The last of these will be used when a server really doesn't want to resize, and will take precedence over the others.

Some simple logic can then be used to work out whether a 'next resize' item can be superceded by another item.

It all sounds straightforward, but it will need quite a bit of testing.

@Nexarian - if you can cast your mind back to when we got this stuff working in the first place, I'd appreciate your comments.

[Nexarian]

@matt335672 The resize queue was created for exactly the purpose described here: If a resize is requested, but we can't process it yet, queue it up and process it when it's "safe." My "stress test" when I originally developed this was to load glxgears (for EGFX compatibility) and then RAPIDLY manually resize the session many many times in a row, and see if anything crashed. The queue was instrumental to this.

This will break horribly if (for example), the user sends 10 such requests to xrdp with the login window open. When the user logs in, we'll send 10 resize requests, one after the other, to the desktop. That's not good.

Why? The queue will just run through them and eventually settle on the last requested resolution. That's the whole point, it's meant to be stable in that way!

I say queue up the "Not allowing resize. Login in progress." request, and process it when it's time.

I do not advise getting rid of the queue.

[matt335672]

Thanks @Nexarian

I'm happy to keep the queue, as we use it for both client and server requests, but given the DISPLAYCONTROL_MONITOR_LAYOUT_PDU PDUs received from the dynamic channel (see [MS-RDPEDISP] 1.3) are just requests and not acknowleged in any way, is there any reason you can see why we can make this optimisation?

If:

1. DISPLAYCONTROL_MONITOR_LAYOUT_PDU received
2. Queue examined and found to be busy.
3. Last request in queue is also a DISPLAYCONTROL_MONITOR_LAYOUT_PDU which has not yet been processed.

Then:

• Replace earlier DISPLAYCONTROL_MONITOR_LAYOUT_PDU with later one.

It's pretty straightforward to implement.

Thanks

[Nexarian]

I think what we're looking for is a ring buffer of size 1 or 2. That would be reasonable.

The case I'm worried about is: Let's pretend the server is spammed with resize requests continually, one will always be in process, while the others have to be queued up. It's true that we only care about ultimately resizing to the final size, but what is it? We only know if we keep the queue.

[matt335672]

Assuming all these requests are coming from DISPLAYCONTROL_MONITOR_LAYOUT_PDU requests, isn't the final size just the last one we received?

I'll try to dump my own mental picture of this.

Say we receive 4 DISPLAYCONTROL_MONITOR_LAYOUT_PDU requests, A, B, C, D.

The current situation might be:

Event	Resize Queue Contents
A comes in and is added to resize_queue. Very quickly it moves from resize_queue to resize_data and starts to get processed.	[]
B comes in while resize_data is active, and is added to the resize_queue	[B]
C comes in while resize_data is active, and is added to the resize_queue.	[B,C]
D comes in while resize_data is active, and is added to the resize_queue	[B,C,D]
resize_data processing completes. resize B is popped from the queue and moved to resize_data	[C,D]
resize_data processing completes. resize C is popped from the queue and moved to resize_data	[D]
resize_data processing completes. resize D is popped from the queue and moved to resize_data.	[]

Final size is D.

With a queue optimisation, this happens:

Event	Resize Queue Contents
A comes in and is added to resize_queue. Very quickly it moves from resize_queue to resize_data and starts to get processed.	[]
B comes in while resize_data is active, and is added to the resize_queue	[B]
C comes in while resize_data is active. Since it is from a DISPLAYCONTROL_MONITOR_LAYOUT_PDU, and the back of the queue is also from a DISPLAYCONTROL_MONITOR_LAYOUT_PDU, C replaces the back of the queue	[C]
D comes in while resize_data is active. Since it is from a DISPLAYCONTROL_MONITOR_LAYOUT_PDU, and the back of the queue is also from a DISPLAYCONTROL_MONITOR_LAYOUT_PDU, D replaces the back of the queue	[D]
resize_data processing completes. resize D is popped from the queue and moved to resize_data.	[]

Final size is D, but with 2 fewer resize processing operations.

Have I missed something in the use-case?

I agree that we might end up just using a ring-buffer, as there aren't many other sources of resize request, but the above would be pretty simple to implement based on what we have now.