@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.
I am Looking for setting up a message in Banner for Linux server while loggin usinf xrdp. I tried to add my banner msg in this file /etc/xrdp/xrdp.ini :
; Login Screen Window Title
But its no success. I have restarted the xrdp service as well. Any help/Suggestion. Thanks and Advance.
I'm trying to think how I might force the callbacks to work with up-to-date memory. Essentially this is a pretty fundamental shift for the driver in this regard. The size of video memory could shift at any time, whereas before a baked-in assumption was that it would only change during connection time.
So -- How to fix that? A couple ideas off the top of my head:
Then again, the entire reason the suppress output was created was to prevent the driver from writing to memory when the window was minimized -- Because that narrow use-case is in effect a resolution change, but under a very specific circumstance.
Fun fact: In Windows 95, it never actually minimized the windows. Instead, it just moved them off to (MAX_INT, MAX_INT) in virtual video memory. If you ever had a display that could show that much resolution, you would never see anything minimize, so there were some people who came up with hacks, like scaling the desktop in the extreme, to be able to see it :)
I also don't know the driver code at all, I'm largely just railing against this out of pure passion/tenacity. I think that the lack of overall knowledge as to how xorgxrdp works something the XRDP community could use an improvement on (and I guess I'm trying to improve it by helping out myself)
But I do like that strategy! I suspect it might be a rather large undertaking as the buffer in question may in fact be aliased to something internally represented in the X Window system, but X itself may also support that. But yeah, all of this is speculation at this point.
At present I'm having a spot of trouble reproducing the issue consistently. It seems to reproduce most clearly over WAN connections with some latency (which makes sense since this is invoked by timer). On my local desktop, getting it to crash is really hard because I have two VirtualBox Ubuntu VMs connecting to each other, and the latency on that is nearly 0, and the resizing is rock solid. I can't get it to crash in spite of doing lots of crazy resizing.
My next step is to test out with WAN connections the "suppress" flag and the "resize" flag that Jay added last year and see if either of them help the issue.
I think I've got it! The fix was indeed to move suppress around
Give this a whirl with FreeRDP /usr/local/bin/xfreerdp /bpp:32 /v:c[hostname]:3389 /network:lan /sound /u:[user] /p:[password] /rfx /dynamic-resolution /w:2560 /h:1396
Note that the height is calibrated for Mac OS X Catalina on a 1440p display, it takes into account the height of the title and menu bar (assuming you have the dock minimized)
Seems like a reasonable approach, but it still leavers us with a fragile xorgxrdp driver.
A couple of other possibilities:-
Hope that's useful.
@metalefty @matt335672 Here's my first PR! I figured out the issue with xorgxrdp, and this should fix the issue and lock it up tight: neutrinolabs/xorgxrdp#183
This change will help with overall driver stability regardless of the dynamic resizing, but it should be viewed as a pre-req to checking in the xrdp resizing feature.