I figured out how to get xrdp_mm.c to communicate to xup.c! Now I can see resize messages being sent from the client all the way to the xorgxrdp backend. The key was the mod structures. Really xrdp_mod is the same as mod, but the idea is that they may have slightly different formats to allow for implementation details.
Dynamic resizing is still not working however. I suspect I need to be cautious about the way the signaling mechanism works. Recently Jay had made some changes to the way xorgxrdp handles resize events, and it's possible those were oriented to resize-on-connection scenarios and aren't flexible enough to handle dynamic resizing of the xorgxrdp backend.
Continuing to investigate. I'm really proud of the progress I've made on this thus far!
Here is my latest change: Nexarian/xrdp@05a3a9a
It works now! To my knowledge, this is the first time dynamic monitor resizing has worked with XRDP!
In the end, it was mostly a matter of taking the dynamic_monitor branch that Jay had already created, and then moving out the "on connect" screen resize functions such that they could be called from a network response function rather than only on session connect.
Anyway, testing/comments appreciated. Build this custom branch and let me know: https://github.com/Nexarian/xrdp/tree/devel
No changes to xorgxrdp are necessary.
@Nexarian - I haven't looked at your code so far, but I'm really pleased you're on board with looking at this!
We got resize-on-reconnect working with the VNC backend working some time last year. I'll be happy to work with you on getting the dynamic resizing working with VNC when you get round to looking at it.
@aquesnel I wanted to talk to you more about issues I've seen in FreeRDP with this. I've noticed a lot of strangeness that I don't see on the Microsoft clients
Also if you're using MSTSC you're missing out, use the App store version, it has the resize-on-the-fly feature!
[_send_data_pdu: sending data (type=0x1f size=49 channelId=1002) [ ] [ ] [ ][ ] - BIO_should_retry returned a system error 32: Broken pipe [ ] [ ] [ ][ ] - transport_default_write:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] [ ] [ ] [ ][ ] - rdp_recv_callback: CONNECTION_STATE_FINALIZATION - rdp_client_connect_demand_active() - -1 [ ] [ ] [ ][ ] - transport_check_fds: transport->ReceiveCallback() - -1 [ ] [ ] [ ][ ] - transport_check_fds() - -1 [ ] [ ] [ ][ ] - rdp_recv_tpkt_pdu: rdp_recv_deactivate_all() fail [ ] [ ] [ ][ ] - rdp_recv_callback: CONNECTION_STATE_FINALIZATION - rdp_recv_pdu() - -1 [ ] [ ] [ ][ ] - transport_check_fds: transport->ReceiveCallback() - -1 [ ] [ ] [ ][ ] - transport_check_fds() - -1 [ ] [ ] [ ][ ] - rdp_recv_tpkt_pdu: rdp_recv_deactivate_all() fail [ ] [ ] [ ][ ] - rdp_recv_callback: CONNECTION_STATE_FINALIZATION - rdp_recv_pdu() - -1 [ ] [ ] [ ][ ] - transport_check_fds: transport->ReceiveCallback() - -1 [ ] [ ] [ ][ ] - transport_check_fds() - -1 [ ] [ ] [ ][ ] - rdp_check_fds() - -1 [ ] [ ] [ ][ ] - Network disconnect! [ ] [ ] [ ][ ] - close_channel_iface: id=1] [ ] [ ][ ] - rdp
While working on #1802 I got build errors in the FreeBSD CI build: https://cirrus-ci.com/task/5691866718928896?command=configure#L8
The error message is:
./bootstrap /usr/local/bin/autoconf /usr/local/bin/automake /usr/local/bin/libtool /usr/local/bin/pkg-config autoreconf-2.69: Entering directory `.' autoreconf-2.69: configure.ac: not using Gettext autoreconf-2.69: running: aclocal --force -I m4 autom4te-2.69: need GNU m4 1.4 or later: /usr/local/bin/gm4 aclocal: error: /usr/local/bin/autom4te-2.69 failed with exit status: 1 autoreconf-2.69: aclocal failed with exit status: 1
The diff from the last commit that successfully built on FreeBSD in that branch is https://github.com/neutrinolabs/xrdp/pull/1802/commits/b87c73eedd5def6980292eea141b07f7b4a6451a
The previously successful build on FreeBSD can be found here: https://cirrus-ci.com/task/5676524592431104
I have no idea why this is failing since both builds say that they are using the same FreeBSD-12-1 version. Does anyone have an idea of what's causing this failure or how to fix it?
@aquesnel @metalefty - I think I've found this. See neutrinolabs/xrdp#1804
I'm nearly out of time today, but if the CI clears and I get time later I may merge this later today.
@matt335672 My understanding is that the xorg backend was vastly superior to the VNC one in terms of capabilities and performance. Every time I try to use VNC it's unusably slow, not so with xorg.
What is the advantage of the VNC backend relative to xorg?
Also -- Any feedback as to why xorg isn't starting would be massively helpful. Normally it's black-screen-hell. I've seen everything from bad RSA keys to incorrect Nvidia drivers block it.
@Nexarian - I agree that in theory Xorg should be able to replace Xvnc, but this isn't always the case.
Xvnc has the advantages of being simple to understand. It won't set the world alight in terms of benchmarks, but it performs adequately over WAN links for many use-cases. I was using it for a few years in this way over a corporate WAN from home, although I wasn't doing anything graphically intensive. Some users have found it works better for them than Xorg - see for example this comment. It also supports
login and connect to a VNC server which allows us to support things like MacOS, albeit in a limited fashion.
Xorg can be much faster than Xvnc, but this speed increase comes at the expense of complexity and maintenance overhead. It requires more work to set up (see for example neutrinolabs/xrdp#1026 and also introduces a coupling on the X server internal interface version. The latter of these is important for longer-lived distros like Ubuntu LTS and CentOS. When the X server version changes, a new version of xorgxrdp is required and this isn't always apparent to the user - see for example all the confusion that the Ubuntu 18.04 HWE packages introduced. CentOS neatly avoids this by shipping Xvnc as the default config. There's also the breakage that can happen when the user is running NVidia drivers which you've already mentioned.
For someone like you who has bought in to the whole xrdp architecture, there's little reason to consider Xvnc. For many first-time users in particular (many of whom raise issues which I end up addressing!) Xvnc is a simpler way to get started. Some of this can probably be addressed by better logging, but this needs changes to the architecture so that the user is informed when the X server fails to start in a more timely fashion.
Happy to discuss this further. Come back at me if you disagree with any of the above.
VNC's main advantage has always been portability and simplicity, and what you've mentioned here aligns with that. I think it makes sense to have a "break glass/simple" configuration in case the fancier/super-car-style xorgxrdp isn't working. Very often in my job, I need some graphical remoting to do some things, like run an application that has graphical options that aren't available on the command line (yes, it's possible, even in Linux). And until xorgxrdp is better supported or more stable, I think it makes sense to have this as an "it just works" option that may have less feature-rich compatibility.
I also think I agree that we need to invest heavily, and soon, into the reliability of the connection backend, be it VNC or Xorgxrdp. In my dynamic monitor testing, I can't get XRDP to connect properly the first time, I have to restart/re-sync often.
@Nexarian - I've not seen ogon before. Thanks for the heads up. It wouldn't surprise me if the same issues are being faced by both projects.
Can you be a bit more specific about the connection issues you're having? Is it the xrdp connection to sesman, or something else? I've not had any significant issues here.