Graphic glitches when running targetting a windows RDP server from within an xrdp session

[datiscum]

xrdp version

0.10 and higher

Detailed xrdp version, build options

xrdp 0.10.80
  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-x264
      --enable-fuse
      --enable-jpeg
      --enable-rfxcodec
      --enable-mp3lame
      --enable-vsock
      --enable-painter
      --enable-pixman
      --enable-tjpeg
      --enable-fdkaac
      --enable-opus
      CFLAGS=-O3 -march=native
      CXXFLAGS=-O3 -march=native
      LDFLAGS=-flto

  Compiled with OpenSSL 1.1.1f  31 Mar 2020

Operating system & version

Ubuntu 20.04

Installation method

Doesn't matter

Which backend do you use?

xorgxrdp

What desktop environment do you use?

KDE

Environment xrdp running on

Incus container

What's your client?

No response

Area(s) with issue?

Graphic glitches

Steps to reproduce

Hello, I have been using Xrpd/XorgXrdp for more than 5 years. I have always compiled it myself and the error described here is present from version 0.10 onward.

This is my main workstation open 14 hours a day continuously and only disconnected in the evening, the session always runs for several weeks. Client RaspberryPi5 resolution 2560x1440 does not play a role in the error.

I have compiled version 0.10.0 / 0.10.1 and the master branch for testing. The error described here does not occur in any earlier version before 0.10. Tested with 0.9.26 / 0.9.21. I have also tested with different FreeRdp versions (2.10/3.8), which showed no differences.

The error only occurs in special constellations.

If I open an RDP session in the Xrdp session or operate the screen of a VM with Virtmanager or Spiceviewer. The prerequisite is also that the mouse cursor is in the window of the RDP session. With a Windows login sequence in which the mouse is outside the remote desktop window, for example, there are no character problems. If the mouse is only in the window, even without movement, there are massive drawing problems. Which are also very similar to those in this bug report https://github.com/neutrinolabs/xrdp/issues/3211

Exactly the same black lines across the whole screen but also others.

There is also a RustDesk running in the session, which makes it possible to see the screen of the same session in two different views, so when I use the mouse in the RustDesk session to move windows, for example, there are no display errors in the RDP session.

I can offer a Video to illustrate this, but the drawing problems in the video are not particularly pronounced, in some RDP sessions it is no longer possible to work at all.

The left window is the RustDesk window and the right one is an Xfreerdp. I hope that this error description can help to find the problem. I am always willing to retest the master branch to see if the problem has been fixed.

✔️ Expected Behavior

No drawing errors, even when the mouse is in the window.

❌ Actual Behavior

No response

Anything else?

No response

[matt335672]

Hi @datiscum

An interesting problem indeed.

If I understand correctly, this is the configuration you're describing. Please correct me if I'm wrong. I've removed any reference to RustDesk or virtmanager/spiceviewer to reduce the variables in play.

PI 5                      Workstation (Ubuntu 20.04)
+--------------------+   +---------------------------+   
|                    |   |    Incus container        |
|                    |   |   +--------------------+  |
|                    |   |   |   xrdp session     |  |
| +------------+     |   |   |  +--------------+  |  |
| | RDP client |-----|---|---|->|              |  |  |
| +------------+     |   |   |  | +------+     |  |  |
|                    |   |   |  | |RDP   |     |  |  |
|                    |   |   |  | |Client|-----|--|--|---> ???
+--------------------+   |   |  | +------+     |  |  |
                         |   |  +--------------+  |  |
                         |   +--------------------+  |
                         +---------------------------+

Despite the simplification there's a lot of moving parts in here, and I'm not going to attempt to reproduce exactly what you've got above. However, it might be useful if you could fill in some missing bits of information so that we can get a fuller idea of what is going on:- 1) Can you describe what is running on the PI 5? In particular, the RDP client and version. 2) Which RDP client are you using from within the xrdp session? 3) Can you say more about what you mean by "Client RaspberryPi5 resolution 2560x1440 does not play a role in the error"? How have you discounted this?

Thanks.

[datiscum]

1. I have also tested with different FreeRdp versions (2.10/3.8), which showed no differences.

2. FreeRDP version 2.7.0 / 3.8 self compiled

3. I have tried it with all possible parameters, but also wanted to test a Microsoft Rdp as a reference. I have now done that too and the problem is gone. When I use the Microsoft RemoteDesktopClient, it works wonderfully and extremely quickly. I will now report it to freerdp as a bug.

[matt335672]

Thanks for getting back to us.

FWIW, it sells like a problem with hardware acceleration to me. If you're able to try disabling graphics acceleration on the PI (which I believe is partly-provided by a closed-source kernel blob) that could be useful info.

[datiscum]

Unfortunately, I must have made a mistake and the link with video showed the same parameters as without video.

If I start xfreerdp in video mode ( /gfx:avc420 ), then it also works with xfreerdp.

I think that the Microsoft client has also selected the video mode.

So of course the question remains whether the problem is on the client or server side.

On the RaspberryPi5 I use:

Enable DRM VC4 V3D driver

dtoverlay=vc4-kms-v3d

[datiscum]

The error depends on the mouse settings.

If “mouse pointer shadow” is activated in Windows,

only the video mode works correctly. If “pointer shadow” is switched off, it also works with a non-video mode.

Now you would have to adjust the title accordingly, maybe it can help someone else.

All the dependencies can be difficult to find.

[matt335672]

Thanks @datiscum

To be clear - this occurs when Windows is the target of the RDP client within the xrdp session. Is that correct?

[datiscum]

Yes, exactly.