Skip to content
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

RDP (remote desktop) backend #1578

Merged
merged 1 commit into from Apr 8, 2019

Conversation

Projects
None yet
4 participants
@ddevault
Copy link
Member

ddevault commented Feb 25, 2019

  • Spin up FreeRDP server
  • Allocate headless outputs for each peer
  • Send frame updates to clients via RFX
  • Send frame updates to clients via NSC
  • Send raw frame updates for clients which support neither
  • Keyboard input
  • Pointer input
  • Clean up

@ddevault ddevault force-pushed the rdp branch 3 times, most recently from 55786bd to 93f9d84 Feb 25, 2019

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Feb 25, 2019

Would be nice to let the compositor allocate the output, so that it can decide to either create a headless one or use an existing one. That would also remove all the OpenGL stuff from the backend.

@ddevault

This comment has been minimized.

Copy link
Member Author

ddevault commented Feb 25, 2019

Hmm, maybe. The way I saw this working out is that the compositor would mirror to the RDP outputs if they wanted to use an existing one. I also like that this lets you transparently add RDP support without any changes to the compositors.

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Feb 25, 2019

Still unsure whether this should be merged or not. A client with virtual-keyboard + virtual-pointer + virtual-output would probably be better.

@ddevault

This comment has been minimized.

Copy link
Member Author

ddevault commented Feb 25, 2019

I'm starting to wonder if it wouldn't be nice to have both.

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Feb 25, 2019

In any case, you could use a headless backend inside the RDP backend to avoid having to re-implement wlr_output.

I still think the compositor should be able to customize the output if needed, this could be optional. This can be useful for mirroring or remote controlling.

@ddevault

This comment has been minimized.

Copy link
Member Author

ddevault commented Feb 25, 2019

That seems like a nice to have for a future patch.

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Mar 1, 2019

Note: this backend is better than Weston's because it uses OpenGL (the Weston backend forces the software renderer).

@ddevault

This comment has been minimized.

Copy link
Member Author

ddevault commented Mar 1, 2019

Or it would be if this didn't force llvmpipe for some reason <_< headless backend has the same problem. No luck figuring it out yet.

@progandy

This comment has been minimized.

Copy link

progandy commented Mar 1, 2019

@ddevault Maybe open a render node fd (/dev/dri/render...) and create a normal GBM backed mesa platform just without any crtcs or outputs? My very shallow reading of surfaceless mesa seems to indicate that it is built on top of llvmpipe.

@ddevault

This comment has been minimized.

Copy link
Member Author

ddevault commented Mar 1, 2019

Maybe? I'm not sure how that works to be honest. Interested in trying a patch?

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Mar 1, 2019

Maybe open a render node fd (/dev/dri/render...) and create a normal GBM backed mesa platform just without any crtcs or outputs?

That's how the not-yet-merged Weston patch works: https://lists.freedesktop.org/archives/wayland-devel/2017-July/034423.html

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Mar 1, 2019

I'd first try to read the mesa code though.

@progandy

This comment has been minimized.

Copy link

progandy commented Mar 1, 2019

Maybe? I'm not sure how that works to be honest. Interested in trying a patch?

Currently not really. I don't really know how that works either. I just remembered reading about render nodes for unprivileged gpu access without a DRM master for computation and DRI_PRIME.

I found this implementation in virgl: https://gitlab.collabora.com/virgl-es/virglrenderer/blob/master/src/virgl_egl_context.c

#1114 is probably related. A single DRM backend could be designed that supports physical and virtual outputs if it is run as DRM master. If it is started on a render node, it will only have virtual outputs and be completely headless.

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Mar 1, 2019

Other idea: use EGL_PLATFORM_DEVICE_EXT. I might try this this weekend.

@ascent12

This comment has been minimized.

Copy link
Member

ascent12 commented Mar 1, 2019

use EGL_PLATFORM_DEVICE_EXT

Mesa does not support this.

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Mar 1, 2019

On my machine EGL_PLATFORM_SURFACELESS_MESA correctly selects i915 and doesn't fallback to software rendering. Maybe this is a Mesa bug?

Can you try with export EGL_LOG_LEVEL=debug, just to make sure we're not missing anything?

@progandy

This comment has been minimized.

Copy link

progandy commented Mar 1, 2019

I walked through the code and it look like surfaceless does try to create a render node: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/egl/drivers/dri2/platform_surfaceless.c#L358

  • first try: render node and hardware rendering
  • second try: DRM master with software rendering
  • last try: swrast without DRM

I did a log as well, looks like r600 is loaded.

EGL_LOG_LEVEL=debug WLR_RDP_TLS_CERT_PATH="$PWD/cert/cert.pem" WLR_RDP_TLS_KEY_PATH="$PWD/cert/key.pem" WLR_BACKENDS=rdp ./rootston 2>rootston-rdp.log

rootston-rdp.log (rootston 0.4-9-g71abbdfd)

@emersion emersion referenced this pull request Mar 22, 2019

Open

Remote access #2939

@ddevault ddevault changed the title [WIP] RDP (remote desktop) backend RDP (remote desktop) backend Mar 25, 2019

@ddevault

This comment has been minimized.

Copy link
Member Author

ddevault commented Mar 25, 2019

This is ready for review. It still ends up using llvmpipe on my system, but that can be solved separately.

@ddevault ddevault requested a review from emersion Apr 2, 2019

Show resolved Hide resolved backend/rdp/keyboard.c
Show resolved Hide resolved backend/rdp/listener.c
Show resolved Hide resolved backend/rdp/listener.c Outdated
Show resolved Hide resolved backend/rdp/output.c Outdated
Show resolved Hide resolved backend/rdp/output.c Outdated
Show resolved Hide resolved include/wlr/backend/rdp.h Outdated
Show resolved Hide resolved include/wlr/backend/rdp.h Outdated
Show resolved Hide resolved include/wlr/types/wlr_output.h Outdated
Show resolved Hide resolved include/wlr/types/wlr_output.h Outdated
Show resolved Hide resolved backend/meson.build Outdated
@ddevault

This comment has been minimized.

Copy link
Member Author

ddevault commented Apr 7, 2019

Addressed @emersion's comments and rebased into a single (changelog-ready) commit.

Show resolved Hide resolved backend/rdp/peer.c Outdated
Show resolved Hide resolved backend/rdp/output.c Outdated
Show resolved Hide resolved backend/rdp/output.c Outdated

@ddevault ddevault requested a review from emersion Apr 7, 2019

@ddevault ddevault merged commit fd0d7d0 into master Apr 8, 2019

3 checks passed

builds.sr.ht: alpine.yml builds.sr.ht job completed successfully
Details
builds.sr.ht: archlinux.yml builds.sr.ht job completed successfully
Details
builds.sr.ht: freebsd.yml builds.sr.ht job completed successfully
Details

@ddevault ddevault deleted the rdp branch Apr 8, 2019

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Apr 8, 2019

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.