-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xrdp v0.10 incorrect behavior when minimizing and restoring a mstsc.exe connection in fullscreen with multiple monitors (v0.9 works fine) #3075
Comments
Thanks for the detailed report. I'll try to reproduce. |
@pancro Just to be sure, could you let me know the exact commit hash or tag of both xrdp and xorgxrdp? Also, can you increase the log level to
|
Received log in private as it may contain sensitive information. |
@matt335672 Could you try to reproduce this one? |
I'll take a look but it may take me a while to get to it. |
I can't reproduce this on Windows 10 mstsc.exe.
I'm not getting any I don't have a multi-screen Windows 11 machine. I'll try to knock up a VM with two screens later in the week. |
I can't reproduce this on Windows 11 mstsc.exe either
Again, clicking the suggested buttons does not result in any client to server messages related to screen sizes being logged in xrdp.log. @pancro - are you able to share any log details after clicking buttons? Also, have you got any other display options set (e.g. scaling) which might be related to this? |
I can produce this with only gfx connections (32 bit color). Changing the connection to 24 bit doesn't have the same issue and restores to full screen over all displays. Also, this only appears to be when you window/restore/maximize, minimizing doesn't seem to be a problem. The three test cases all had identical resolution displays:
With the 1x2 it full restored full screen to a single display. With 2x2 it full screened to two (bottom two) displays. The server is running fully updated rocky9 with xrdp-0.10.0-3.el9.x86_64 and xorgxrdp-0.10.1-1.el9.x86_64 from epel9-testing and fvwm3 built from source. |
@derekschrock Thanks for the info, I didn't care the color depth. I will test again. |
I've check my config, and I'm running 32-bit colour (this is a requirement for GFX). It's in the RDP config I posted above. I've checked the XRDP log and I'm seeing GFX. This is on Windows 11 with two 1920x1080 monitors next to each other.
Windows 11 Display settings:-Windows 10@derekschrock - can you provide an RDP config, and maybe a connection log? There's clearly some difference here which we're not picking up on. I'm pretty sure it's client-side, as the client will be the one to initiate the resize. |
At least with Windows 10 some extra testing seems to show this depends on the primary display setting. Can you try with setting the right display as primary? With the a 1x2 if the right display is the primary going from fullscreen all displays, windowed, maximize will full screen only on the right displays. Setting the left display as primary you get the expected windowed to fullscreen resize with 32 bit. My RDP config is:
|
Playing around with more displays on Windows 10:
|
I tried the exact same steps on Windows 11 mstsc client against xrdp 0.9.25 vs 0.10, on a 4-screen setup. It's not necessary to log in or interact with the user/password prompt at all, presumably ruling out anything related to the user / Xorg backend / sesman. What's different in the xrdp log output?
Only in 0.10:
It's worth noting in both cases, there is no log output created at all from the client window manipulation. I can't say with any certainty whether xrdp even knows when the window is restored / maximized, but it's not logged at DEBUG level. In the 0.10 case, the window would not maximize back to full screen across 4 monitors, but only 2 of the screens, at which point the login prompt was invisible / rendered elsewhere. |
Thanks both - that's great work. I should be able to reproduce this based on the information you've both provided. I'll have a go and report back. The codepaths for GFX are fairly different from the other codepaths, as Microsoft decided to implement it over a different virtual channel. From what Derek has said, selecting 24-bit colour should result in the same behaviour as xrdp v0.9.x. At this stage, the only analysis I can provide is based on this interesting statement from @rowlap which is in agreement with my own observations:-
You'd certainly get something relating to a client window resize event at DEBUG level. So one of the following would seem to be the case:-
Either 2) or 3) above might take a while to track down. Please tell me if I've missed anything obvious. |
I can reproduce this now. Running the following:-
I see the following:-
As @rowlap mentions, this is all doable on the login screen, so we can rule out xorgxrdp, the X server and anything related to the session. Thanks again both. It might take a while to track down a solution but you've really helped above. |
I'm adding some notes here, as I've got a busy weekend IRL and I may not get to look at this until next week. There seem to be three places where the monitor geometry is sent to the client:-
The first of these seems to be exactly as specified in [MS-RDPBCGR] 2.2.12.1, both for GFX and non-GFX connections. When I get a chance I'll check out the other two. |
I think our implementation of RDPGFX_RESET_GRAPHICS_PDU is incorrect. @pancro, @derekschrock, @rowlap - please try #3111 if you have the time. It's a tiny change, but will need a lot of testing! |
@matt335672, #3111 looks good here as well. I tried 2 adjacent monitors (primary one being on the right) and 3 monitors in inverted pyramid shape (2 monitors on top, on montor in the centre below, primary monitor being the bottom one) |
Works for me. Tested a 2-screen sideways "T" layout, and a regular 2x2 with main display in the bottom left. Before the patch, both fail on maximise. After, both work as expected. |
To be honest, I didn't really think hard about which of those two arrays to use when I wrote this originally. It is very possible that this is the correct way. I agree extensive testing is needed though. |
xrdp version
0.10.0
Detailed xrdp version, build options
0.10.0
Operating system & version
various
Installation method
git clone & make install
Which backend do you use?
xorgxrdp
What desktop environment do you use?
i3 and GNOME
Environment xrdp running on
kvm virtual machine
What's your client?
Win11 mstsc.exe
Area(s) with issue?
Graphic glitches, Other
Steps to reproduce
In Summary, when you open a multi-monitor full-screen remote connection to xrdp 0.10, it's not possible to minimize and then maximize correctly the remote desktop connection: only one monitor is displayed when you maximize. The same workflow works correctly with xrdp 0.9.
Equipment utilized:
i3
becausei3
makes it very easy to identify monitors and desktops by number, but the issue also affects GNOMEReproducer:
✔️ Expected Behavior
❌ Actual Behavior
i3
, if you had Desktop 1 and Desktop 2, now you can only see an empty Desktop 3 which didn't exist before, and the status bar does not show indicators for Desktop 1 and Desktop 2 anymorexrandr
still shows two connected monitors, which seems correctAnything else?
The workaround is to disconnect and reconnect, and the monitors are once again displayed correctly.
The text was updated successfully, but these errors were encountered: