xrdp for Mac

[swetepete]

Hey,

Just curious if there’s a chat group or something for people trying to make this work for Mac? I’d be interested in trying to complete the work so it’s ready to go for anyone that wants to use it.

https://github.com/neutrinolabs/xrdp/wiki/Building-on-OSX-(not-official)

Mac really needs a good open source remote desktop protocol.

thanks very much

[metalefty]

Hi, I've created the room. Feel free to have a talk there: https://gitter.im/neutrinolabs/xrdp-mac

Please note that there's no official support for Mac by the development team. xrdp on Mac is 100% users' contribution-based. If users contribute nothing, nothing'll happen. Development team will accept & merge pull requests to improve Mac support if someone raised it.

[metalefty]

Just pinned this issue. Good luck.

See also Platform Support Tier.

[matt335672]

Just to add to @metalefty's comments, this will only get harder as MacOS transitions to ARM - there's no way around requiring Mac hardware to support xrdp at that stage, and that costs money. For many of us xrdp is a hobby only.

[swetepete]

What’s the relationship between ARM and xrdp? I didn’t know a remote desktop protocol could depend on the CPU. I thought it was just software that intercepted and transmitted data on certain layers of the operating system or something. Why would the change in chip affect it? Thanks very much

[matt335672]

It's not the change in chip - it's the change in OS.

I run a lot of VMs on a virtualisation rig to look into xrdp issues. At the moment I could in theory run a Hackingtosh on this setup to support MacOS, but this will not be possible in the near future, when Apple drop support for x86_64. As a result, I'm not keen personally on getting involved in supporting this, as I can't do it in the long term.

[Nexarian]

@matt335672 It might still be possible, albeit with a huge perf hit: https://superuser.com/questions/469525/how-can-i-virtualize-an-arm-machine-in-windows#:~:text=You%20simply%20can't%20virtualize,you%20can%20emulate%20it%20%3A)&text=Virtualization%20is%20used%20to%20run,not%20an%20OS%20(software).

[matt335672]

I've tried this for some of the rPI problems we've got.

It really is slow! Also, you need QEMU to emulate the ARM machine in question. At the moment, the QEMU Wiki is only listing up to an rPI 2, unless I'm missing something - the Wiki might be out-of-date.

[unstabler]

Hello, I am developing an xrdp module for macOS and have met with a snag. I am currently using the paint method with a normal bitmap, but it slows down when playing movies, etc., and it is very expensive, using ~300Mbps of traffic during peak times. I would like to try other methods (RFX, GFX ...), but RFX crashes with a green screen, and GFX had a forked branch but no progress since 2021, so I'm a bit worried to try it.

Translated with www.DeepL.com/Translator (free version)

[Nexarian]

This is awesome that you're working on it! It's true that GFX has been evolving slowly, but it has been evolving. I have rebased all the necessary bits for the GFX H264 encoding changes here:

https://github.com/Nexarian/xrdp/tree/mainline_merge https://github.com/Nexarian/xorgxrdp/tree/mainline_merge

There is an issue with RFX at the moment, but H264 accelerated (X264 probably for Mac OS) should work just fine!

Also, any integration with Mac OS is a win, so feel free to cut us some PRs and we can test!

[unstabler]

After a few hours of work, I finally got RemoteFX to paint the screen! https://www.youtube.com/watch?v=xa0oY1mUStE

It's 5am here in Korea, so I'm going to sleep a bit. I'll publish the repository when I wake up.

[Nexarian]

Ok this is really cool because not only is RemoteFX working, you're also capturing the native session, something XRDP doesn't normally do! I'd love to see how you did this :)

[unstabler]

I've published the repository!

• https://github.com/unstabler/ulalaca-xrdp (xrdp module; should/can i create merge request to xrdp upstream?)
• https://github.com/unstabler/ulalaca (session projector)

[Nexarian]

@unstabler This is really excellent work! I'd have to ask @metalefty and @matt335672 and @jsorg71 what they think about how to merge this upstream.

Two questions:

1. Do you want to try to get H264 working as well with GFX?
2. Clearly you're passionate about this space. Have you looked at FreeRDP? The Mac OS client on it (including the XQuartz project) could use some work. I've thought about trying my own hand at it, but right now I'm focused on trying to get EGFX merged in.

[paulb39]

Once I get some time I will try this out. But I am so confused, can someone explain this to me like I'm an idiot?

If I am understanding it correctly, instead of making xrdp work with Xorg, you created your own protocol ? It must be pretty powerful if it works with RemoteFX, doesn't that mean it works with 3d acceleration? It is just using VNC under the hood?

[unstabler]

@Nexarian

1. I'd like to try!
2. :ok:

@paulb39 I may have created my own protocol. When a connection comes in from Xrdp, it receives screen data from Ulalaca-sessionprojector through AF_UNIX and draws it.

Ulalaca-sessionprojector uses ScreenCaptureKit provided from macOS 12.x instead of X11 or VNC. if GPU supports Metal, 3D acceleration is applied to capturing screen.

Eventually I would like to create an Ulalaca-sessionbroker to support multi-user session like Windows Terminal Server using the Private API (CGSSessionCreateLoginSessionID, CGSCreateLoginSessionWithDataAndVisibility ...) of the macOS SkyLight framework.

[Nexarian]

Protocol is a funny word with respect to this situation. RemoteFX is full-frame JPEG compression (JPEG 2000 I believe), and it was a precursor to Microsoft's H264 acceleration. The reason H264 is superior to JPEG is that while JPEG compression is super efficient, with every frame you are still sending a full frame. The insight for H264 is it's a diff-ing protocol. It sends a "key" (full) frame, and then for a long while after the fact it sends compressed diffs (and then occasionally another key frame to make sure things are in sync). This turns out to be WAY faster than JPEG, so much so it's why we have Nvidia's NVENC encoder and Intel's QuickSync decoder implemented in hardware, but hardware accelerated JPEG? That's nowhere to be found, the best XRDP has in that regard is assembly-written encoders/decoders, which are still fast, but not as blistering as H264. This is also what YouTube, Netflix, OBS, and any other modern video streaming tech uses. There are other derivatives such as H265, VP8, and VP9 as well, and I believe AV1 is coming out soon which promises to put all of what I listed to shame.

We don't have to write these encoders/decoders, they are complex and take years of work and Ph.D.-level expertise to build. Most of that is built into OpenH264, FFMPEG, X264, libva (Intel), and Nvidia's libraries like cuda.

With my prototype of H264 on XRDP I can watch 1440p YouTube videos with sound at ~10 MS latency. With RFX, well :trollface:

What @unstabler did was capture the Mac OS screen, then built a module that plugs into XRDP's server network architecture in such a way that it can feed the XRDP server RemoteFX-compatible (JPEG compatible) bitmaps that are then transformed into the Microsoft Remote Desktop network messages that anything that speaks RDP can connect to (FreeRDP and any of Microsoft's clients). The xorgxrdp module is very similar, it just uses the Xorg server to feed XRDP data instead.

Anyway, @unstabler, feel free to start chatting with us on the https://gitter.im/neutrinolabs/xrdp for any technical questions or assistance.

[metalefty]

@unstabler @Nexarian Personally, I would welcome merging that if it will be maintained countinuously.

[unstabler]

https://teamunstablers.notion.site/xrdp-Ulalaca-Getting-started-f82b0c55f0b540a6ac277cc5902361b1

I have written a new installation guide for xrdp+Ulalaca on macOS. The installation process has changed and is much simpler than before.

I am looking for someone to test the installation procedure as per the guide above. It should probably work fine on M1-based Macs with macOS 13 or higher, so if you are interested, please test it and let me know the results. (It may not work on Intel-based confirmed working on Macbook Pro 15" (2018)¹²)

¹: requires low resolution; use EasyRes. ²: ScreenCaptureKit stops working when HiDPI (retina) resolution is set

[myusrn]

@unstabler, Would you expect that I could test using a remote macos setup, e.g. macincloud remotely accessed physical machine or aws / azr / gcp cloud provider remotely accessed virtual machine, or does it require local physical apple silicon mac console interaction to setup the test?

Looking at macincloud faq it says the following "Connecting to Mac servers provided in our MacinCloud Managed and Pay-As-You-Go server plans will utilize a RDP (Remote Desktop Protocol) client". This makes me wonder what did they do to get macos rdp access working? Also probably suggests that using one of their setups to test your open source rdp listener for macos system probably isn't going to be viable unless the fact that their solution lives on port 6000 avoids any conflicts.

[unstabler]

@myusrn [machine-translated]

1. You can probably install it, but it may not work in a virtualized environment. Ulalaca uses ScreenCaptureKit/AVFoundation to capture the screen, but we have not confirmed that it works in situations where GPU acceleration is not available.

2. there would be one non-free RDP server implementation for macOS.

[AntonOfTheWoods]

@unstabler thanks for all your work! I am just starting to use my first Mac (Mini 2023) so I'm probably holding it wrong... but I was unable to get things to install. Can you confirm that the instructions are in the right order? I first install xrdp-tumod, right?

Compilation fails:

...
  CC       xrdp_rdp.lo
  CC       xrdp_sec.lo
  CCLD     libxrdp.la
Making all in libpainter
make[2]: *** No rule to make target `all'.  Stop.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
...

I noticed that it says that Rosetta 2 isn't installed when I definitely installed and rebooted, so not sure whether that is related.

Here are the system details:

HOMEBREW_VERSION: 4.0.14
ORIGIN: https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git
HEAD: ac0663ae5d2d4c76bb62363592d77dbad49ac30c
Last commit: 3 days ago
Core tap origin: https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git
Core tap HEAD: 974b6f2d2bb9b6f5f38d9c67f24ec0aa5c74dabe
Core tap last commit: 6 hours ago
Core tap branch: master
Core tap JSON: 18 Apr 10:53 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_API_DOMAIN: https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles/api
HOMEBREW_BOTTLE_DOMAIN: https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles
HOMEBREW_BREW_GIT_REMOTE: https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git
HOMEBREW_CASK_OPTS: []
HOMEBREW_CORE_GIT_REMOTE: https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git
HOMEBREW_EDITOR: vim
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_NO_AUTO_UPDATE: set
HOMEBREW_NO_BOOTSNAP: set
HOMEBREW_NO_INSTALL_FROM_API: set
HOMEBREW_PIP_INDEX_URL: https://pypi.tuna.tsinghua.edu.cn/simple
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_blizzard_avalanche
Clang: 14.0.3 build 1403
Git: 2.39.2 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.84.0 => /usr/bin/curl
macOS: 13.0-arm64
CLT: 14.3.0.0.1.1679647830
Xcode: 14.3
Rosetta 2: false

HOMEBREW_CC: clang
HOMEBREW_CXX: clang++
MAKEFLAGS: -j8
CMAKE_PREFIX_PATH: /opt/homebrew/opt/openssl@3:/opt/homebrew
CMAKE_INCLUDE_PATH: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers
CMAKE_LIBRARY_PATH: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries
PKG_CONFIG_PATH: /opt/homebrew/opt/openssl@3/lib/pkgconfig:/opt/homebrew/opt/libxau/lib/pkgconfig:/opt/homebrew/opt/libxdmcp/lib/pkgconfig:/opt/homebrew/opt/libxcb/lib/pkgconfig:/opt/homebrew/opt/libx11/lib/pkgconfig:/opt/homebrew/opt/libxfixes/lib/pkgconfig:/opt/homebrew/opt/libxext/lib/pkgconfig:/opt/homebrew/opt/libxrender/lib/pkgconfig:/opt/homebrew/opt/libxrandr/lib/pkgconfig:/opt/homebrew/opt/xorgproto/share/pkgconfig
PKG_CONFIG_LIBDIR: /usr/lib/pkgconfig:/opt/homebrew/Library/Homebrew/os/mac/pkgconfig/13
HOMEBREW_GIT: git
HOMEBREW_SDKROOT: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk
ACLOCAL_PATH: /opt/homebrew/share/aclocal
PATH: /opt/homebrew/Library/Homebrew/shims/mac/super:/opt/homebrew/opt/automake/bin:/opt/homebrew/opt/autoconf/bin:/opt/homebrew/opt/libtool/bin:/opt/homebrew/opt/nasm/bin:/opt/homebrew/opt/pkg-config/bin:/opt/homebrew/opt/openssl@3/bin:/usr/bin:/bin:/usr/sbin:/sbin

[drewdelano]

@unstabler it seems to almost work, but then crashes right after entering credentials

[unstabler]

(machine-translated)

Hello, there was a bug in the installer where the LaunchAgent definition for sessionprojector-launcher was not installed properly, resulting in a problem where sessionprojector.app would not start and the user could not log in to the session.

We are planning to release new installer that fixes the above problem by the end of tomorrow, so please wait a little longer.

[zahtec]

I have managed to compile and run xrdp and xrdp-sesman on my M1 Macbook Pro, however, when connecting with a remote client, the authentication repeatedly fails.

In the sesman logs, I am receiving an issue about PAM, but there is not a lot of information online pertaining to macOS's implementation of it.

[20230826-21:00:32] [TRACE] config loaded in main at sesman.c:747
[20230826-21:00:32] [TRACE]     sesman_ini        = /etc/xrdp/sesman.ini
[20230826-21:00:32] [TRACE]     listen_address    = 127.0.0.1
[20230826-21:00:32] [TRACE]     listen_port       = 3350
[20230826-21:00:32] [TRACE]     enable_user_wm    = 1
[20230826-21:00:32] [TRACE]     default_wm        = /etc/xrdp/startwm.sh
[20230826-21:00:32] [TRACE]     user_wm           = startwm.sh
[20230826-21:00:32] [TRACE]     reconnect_sh      = /etc/xrdp/reconnectwm.sh
[20230826-21:00:32] [TRACE]     auth_file_path    = (null)
[20230826-21:00:32] [DEBUG] libscp initialized
[20230826-21:00:32] [DEBUG] Testing if xrdp-sesman can listen on 127.0.0.1 port 3350.
[20230826-21:00:32] [DEBUG] Closed socket 4 (AF_INET 127.0.0.1:3350)
[20230826-21:00:32] [INFO ] starting xrdp-sesman with pid 85762
[20230826-21:00:32] [DEBUG] sesman_create_listening_transport: address 127.0.0.1 port 3350
[20230826-21:01:10] [INFO ] Socket 11: AF_INET connection received from 127.0.0.1 port 51631
[20230826-21:01:11] [ERROR] pam_acct_mgmt failed: permission denied
[20230826-21:01:11] [INFO ] AUTHFAIL: user=zahtec ip=192.168.0.232 time=1693108871
[20230826-21:01:11] [ERROR] sesman_data_in: scp_process_msg failed
[20230826-21:01:11] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20230826-21:01:11] [DEBUG] Closed socket 11 (AF_INET 127.0.0.1:3350)

I am on version 0.9.19 as it was the latest version I could get to compile.

[myusrn]

@zahtec i am wondering if issue you are seeing is same as one i ran into [ https://github.com/neutrinolabs/xrdp/discussions/2725 and https://github.com/neutrinolabs/xrdp/discussions/2732 and ] that kept me from successfully using current release build output on macbook pro 13" m1 with latest macos ventura 13.x installed [ xrdp 0.9.22.1 may22 and xorgxrdp 0.9.11 sep22 with this work around for getting latter to build https://github.com/neutrinolabs/xorgxrdp/discussions/263 ]. i've been waiting for updated release of xrdp and xorgxrdp to do a newer build and see if it reproduces.

[zahtec]

In https://github.com/neutrinolabs/xrdp/discussions/2732 you appear to have gotten farther than me as your authentication is working ([20230615-13:35:19] [INFO ] xrdp_wm_log_msg: login successful for user wendyqiu on display 10), but something afterward is an issue.

I might attempt to get a later version to compile, but I have a feeling this PAM issue has to do with how macOS does user permissions. Also, for now as it is not working, I have been launching xrdp and xrdp-sesman from the terminal, not a LaunchDaemon. Not entirely sure if that makes a huge difference.

[myusrn]

Hi @zahtec, curioius if you included build and install of https://github.com/neutrinolabs/xorgxrdp in your process? i wonder if that might explain our different outcomes. i was following instructions in https://github.com/neutrinolabs/xrdp/wiki/Building-on-OSX-(not-official) post ignoring the fact that the tested versions for xrdp, xorgrdp and macos where older than the current releases i was trying with.

[zahtec]

I got xorgxrdp to compile after editing all X11 #include statements to be "../X11/foo" rather than <X11/foo>. I did this with a bash script I made.

Keep in mind I am entirely unknowledgeable on C and header files, mostly done low-level stuff in Rust where that is often not dealt with, so my solution here may be entirely unnecessary or the wrong way to do it.

[superbonaci]

Just to add to @metalefty's comments, this will only get harder as MacOS transitions to ARM - there's no way around requiring Mac hardware to support xrdp at that stage, and that costs money. For many of us xrdp is a hobby only.

I guess you could set up some Patreon or something...

[RJVB]

What @unstabler did was capture the Mac OS screen, then built a module that plugs into XRDP's server network architecture in such a way that it can feed the XRDP server RemoteFX-compatible (JPEG compatible) bitmaps that are then transformed into the Microsoft Remote Desktop network messages that anything that speaks RDP can connect to (FreeRDP and any of Microsoft's clients).

Sorry for jumping into an old exchange with a probably naive question, but just how is this different from VNC, esp. Apple's VNC server that doesn't simply connect to the running local session? From what I understand you still get the entire desktop image sent over (or at least the parts that changed)?

[superbonaci]

@RJVB RDP is different from VNC.

[RJVB]

@RJVB RDP is different from VNC.

Well, doh...

[myusrn]

@RJVB my experiments with attempting to use macos built in settings | general | sharing | screen sharing enabled vnc server is that it provides an unusable experience, performance is really bad, when you are connecting to it using open source vnc client from a non-macos system, i.e. windows and linux. Conversely if you connect to it from another macos device using the findor or screen sharing app built in vnc client solutions you get a usable experience. My hope with an open source xrdp service solution for apple silicon macos installs is to get around this arbitrarily imposed behavior and land on a good performing remote macos desktop connectivity solution from both windows and linux systems.

[RJVB]

On Monday May 20 2024 14:42:16 my usrn wrote:

@RJVB my experiments with attempting to use macos built in settings | general | sharing | screen sharing enabled vnc server is that it provides an unusable experience, performance is really bad, when you are connecting to it using open source vnc client from a non-macos system, i.e. windows.

I don't do it very often because all my other systems have smaller screens than my Mac, I don't notice any differences in performance when connecting to it using TigerVNC compared to using TigerVNC on the Mac to connect to Linux (running TigerVNC's x0vncserver) or MSWin hosts (running RealVNC). TigerVNC is definitely the best open source client I know, both in terms of speed and image quality. Evidently I don't expect to be able to use it to watch videos or play games, and I don't use fancy user interface animations/effects but for regular GUI interactions it is perfectly usable. Except for clipboard copy/paste, which can be a pain at times, but I think that's a flaw in TigerVNC rather than in the protocol.

The backgroun to my question is that it has been my understanding that the RDP protocol as used in the MS remote desktop server and client doesn't send a video stream of the screen contents but does something that's more akin to how X11 works, allowing to display individual remote windows on the client's desktop rather than in a "session window". I never actually used it that way myself so I may simply have misunderstood.