xrdp
xrdp copied to clipboard
neutrinolabs
Implement GFX graphics pipeline in xrdp
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpegfx/da5c75f9-cd99-450c-98c4-014a496942b0
Related issues. GFX issues https://github.com/neutrinolabs/xrdp/issues/1174 https://github.com/neutrinolabs/xrdp/issues/1272 https://github.com/neutrinolabs/xrdp/issues/1420
@metalefty To complete all of it yes it's big. To complete progressive RemoteFX and H264 it's not too bad. I think we can have something by the end of year.
I'll try to update here the progress. I can get a client connection and open the channel. Here is a screen shot of xrdp drawing 2 green boxes with gfx.
I do see from the connection caps that MSTSC claims it can decode h264. That great and it makes things easier as we don't have to implement progressive rfx yet. Then I noticed that the Mac and Android client(from Microsoft) say they don't support h264 in the caps.
The MacOS remote desktop client was just updated this week. Maybe the added that feature?
On Tue, Nov 19, 2019 at 11:23 PM jsorg71 [email protected] wrote:
I do see from the connection caps that MSTSC claims it can decode h264. That great and it makes things easier as we don't have to implement progressive rfx yet. Then I noticed that the Mac and Android client(from Microsoft) say they don't support h264 in the caps.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/neutrinolabs/xrdp/issues/1422?email_source=notifications&email_token=AA4UBHKDHBVFNFF6GXLZWQDQUTQYBA5CNFSM4JAT7VQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEQ7OGI#issuecomment-555874073, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4UBHKNIPMDBARYM3M5QILQUTQYBANCNFSM4JAT7VQA .
GPU accelerate encoding, of course but for now, using x264. I have experience with libva h264 encode and NVIDIA nvenc. Best performance will be using either dri/glamor or nvidia_hack and pass Xorg dirty area directly to encoder, no CPU processing. Odd thing about GFX h264, they use a strange RGB to YUV conversion, see 3.3.8.3.1 in MS-RDPEGFX, so that might be a problem. https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpegfx/954d7546-6873-4466-95c8-20a7569c43e5
@jsorg71 Do you want help writing those conversion functions?
Also, would it be possible to merge these changes with nvidia_hack so that we can test this with Nvidia?
git clone --branch egfx --recursive https://github.com/jsorg71/xrdp.git you need to configure with --enable-x264 git clone --branch egfx --recursive https://github.com/jsorg71/xorgxrdp.git configure with --enable-glamor optional
example connection with freerdp 3.0, not sure what version freerdp added /gfx:avc420 or /gfx-h264 xfreerdp /gfx:avc420 /v:192.168.1.1
I'm trying to use it right now and can't seem to get either /gfx:avc420 or /gfx-h264 working -- it appears neither flag exists (and I can find no references to either in the xfreerdp documentation). I'm running xfreerdp on Mac OS Catalina 1.15.5 and installing it with brew install freerdp --HEAD so I have what I believe to be the latest version.
I also couldn't get it to work with the Microsoft Remote Desktop client on my Mac as well, but that might simply be my fault as I need to debug more what might be wrong with the setup.
@Nexarian For freerdp, I had to enable build with -DWITH_OPENH264=1 before you get the command line options. Also the MS remote desktop on Mac sets the RDPGFX_CAPS_FLAG_AVC_DISABLED flag so they don't support H264. I didn't check latest client yet. Note, with the latest push, MSTSC on windows works, that's big.
That is big! I rebuilt freerdp and I still can't seem to get it to work, either with mate or with Gnome. I simply get an empty black screen.
Hi @Nexarian
I'm not really following this thread in any detail, but commit 5cd36c511cab76ae4a7c14a792055449077e4fc1 which J has in his xrdp repository (mainlined in v0.9.14) requires xorgxrdp to be rebuilt against xrdp. Where there's a mismatch this is something that can happen (e.g. see #1681 and #1674). I'm not saying for sure this is the cause of your problem but it sounds similar enough to me that I thought I should mention it.
Thanks @matt335672! I rebuilt both from source as that's required for the egfx change.
Looking into the logs it looks like everything is fine (I see no obvious errors), but the problem is that either Xorg isn't starting or the transmission is garbled and something is wrong with the freerdp build on Mac.
I do know that if I run FreeRDP without the avc420 flag I get errors related to H264.
Ok, interesting. It works with this command line:
/usr/local/bin/xfreerdp /ipv6 /bpp:32 /v:[server] /p:[password] /w:2560 /h:1396 /gfx:avc420 +glyph-cache
But it hangs for A LONG time before it might start rendering. It may never start. I think maybe there is a deadlock happening.
After further testing, adding /sec:rdp seems to slow down the communication by a lot.
Actually, with /sec:rdp on Gnome isn't functional at all and I rarely get the title bar.
I think I updated the repos last week they should be fairly recent. @Nexarian the login screen is not compressed so that might be the slow part at beginning. Is that a typeo? I think /v: is the server name to connect to. Can you try a smaller window size for now like 1024x768?
Yes, you're right. In my rush to sanitize data, I forgot which flag was which (and I edited it). Interestingly, it seems to be working just fine now. It's possible there were issues with my network connection.
It could be related to the login screen. Anyway, keep up the good work!
I just had another strange incident when reconnecting. The mouse cursor would change to correspond to the actual elements that were on the screen (such as change to a capital "i" icon when hovering over a textbox, but the screen itself was blank. It took another minute for the actual UI to become active.
Also /sec:rdp doesn't seem to matter anymore.
I have this running on FreeBSD 12.1 with glamor (i915) and the MS client. I see the egfx logs in xrdp logs however like when using RFX you see an RFX message in xorg log. Does EGFX do the same or you know you're egfx because of the egfx messages in the log?
I've also tested with the latest macOS client and it will connect, display the painter/login screen, freeze for a second then disconnect. Didn't check the logs to see if anything was different between MS and macOS client. A quick glance didn't show much. The same is true with macOS beta client Version 10.4.1 (1817) connects, login screen, disconnects.
Edits... spoke too soon I forgot to kill the system xrdp. The beta client doesn't work it acts the same as the current 10.4.0.
Does this give anything when it comes to the macOS client?
MS macOS client 10.4.0:
xrdp_mm_drdynvc_up: gfx capable client
xrdp:xrdp_egfx [1992667619]: xrdp_egfx_create: error 0 channel_id 1
xrdp:xrdp_egfx [1992667624]: xrdp_egfx_open_response:
xrdp:xrdp_egfx [1992667624]: xrdp_egfx_process_capsadvertise:
xrdp:xrdp_mm [1992667624]: xrdp_mm_egfx_caps_advertise:
xrdp:xrdp_mm [1992667624]: version 0x00080004 flags 0x00000002
xrdp:xrdp_mm [1992667624]: version 0x00080105 flags 0x00000002
xrdp:xrdp_mm [1992667624]: version 0x000a0002 flags 0x00000022
xrdp:xrdp_mm [1992667624]: version 0x000a0200 flags 0x00000022
xrdp:xrdp_mm [1992667624]: version 0x000a0301 flags 0x00000020
xrdp:xrdp_mm [1992667624]: version 0x000a0400 flags 0x00000002
xrdp:xrdp_mm [1992667624]: replying version 0x000a0400 flags 0x00000002
...
Windows Client:
xrdp_mm_drdynvc_up: gfx capable client
xrdp:xrdp_egfx [1992583769]: xrdp_egfx_create: error 0 channel_id 1 xrdp:xrdp_egfx [1992583771]: xrdp_egfx_open_response: xrdp:xrdp_egfx [1992583782]: xrdp_egfx_process_capsadvertise: xrdp:xrdp_mm [1992583782]: xrdp_mm_egfx_caps_advertise: xrdp:xrdp_mm [1992583782]: version 0x00080004 flags 0x00000000 xrdp:xrdp_mm [1992583782]: version 0x00080105 flags 0x00000000
xrdp:xrdp_mm [1992583782]: version 0x000a0002 flags 0x00000000 xrdp:xrdp_mm [1992583782]: version 0x000a0200 flags 0x00000000 xrdp:xrdp_mm [1992583782]: version 0x000a0301 flags 0x00000000 xrdp:xrdp_mm [1992583782]: version 0x000a0400 flags 0x00000000
xrdp:xrdp_mm [1992583782]: version 0x000a0502 flags 0x00000000 xrdp:xrdp_mm [1992583782]: version 0x000a0600 flags 0x00000000
xrdp:xrdp_mm [1992583782]: replying version 0x000a0400 flags 0x00000000
Two less versions and however the same is used (replyed?) 0x000a0400. macOS has extra flags set? 0x0...2