Wayland's Weston Gets A FreeRDP-Based Compositor
Phoronix: Wayland's Weston Gets A FreeRDP-Based Compositor
There's now a Wayland compositor that's based upon FreeRDP, the open-source implementation of Microsoft's Remote Desktop Protocol...
This is a Weston back-end. So this has to be implemented for every compositor over and over again?
It's a back-end. So, it's not clear to me if this allows me to take control of a session that is already running on a local display through another back-end. I checked the makefile, and it says the following:
How does that make any sense? Is Weston capable of running on DRM or X11 directly??
Furthermore, it was mentioned (link!) that the main developer was working on this. Is this for Wayland itself??
If you write a new wayland compositor from scratch, then yes you have to reimplement it again. But I will not make any assumption about the future development of wayland compositors and how they share their code. That said I like to see something like a base compositor or library. Weston has a plugin interface and the developers are testing some stuff about the plugin interface, but I don't really know how far they have come.
Originally Posted by Rexilion
Weston is able to run as x11 client with the x11_backend (like XNest or Xephyr) and it is also able to run on a tty with the drm or fbdev backend. The headless backend is just for testing and debugging the wayland code independent of the backend (the functions are just stubs). They wayland backend lets you run a wayland compositor as wayland client/window (also like XNest).
Wayland - protocol
Weston - implementation of Wayland protocol
So Weston gained another back-end. Now it can work on fbdev or drm or on FreeRDP. Nice.
Still Wayland as protocol do not specify HOW things should be implemented but WHAT is required.
So any other Wayland server can do without any dependency on FreeRDP.
If this leads to smooth remote GUIs then that is absolutely awesome.
I second Rexilion's question though, can it be used to connect to existing sessions, new ones / ones started specifically for RDP, or both?
I presume the module is loaded when you start weston, and then weston listens for incoming RDP connections and allows RDP clients to control the session over RDP.
Originally Posted by roland
The answer to this is: it depends, if the other compositor is able to use Wayland as its back-end (Weston can do this) then you can nest/stack them..
Originally Posted by Rexilion
Ok, lemme get this right...
So, comparing this to vnc. First variant would be starting Xvnc being rendered locally yet viewed over the RFB protocol (which is optionally locally possible). This is comparable to a server with thin clients (right?). And the second variant would be running X locally, and have x11vnc polling for changes and making those available as an RFB stream (like me assisting my parents).
Originally Posted by Nobu
But this time, it's integrated into the compositor in the new Wayland 'model'.
So, something like: a compositor (e.g. Weston) depending on a library (e.g. librender). This librender depends on libfreerdp, libvnc, libnx or whatever. So whatever compositor links against librender get's the rest for free. Would be nice.
Originally Posted by renox
So, instead of what renox said: You write a compositor purely for RDP and another compositor purely for VNC and stack that on a compositor currently rendering on a local backend (like DRM or FB).
Originally Posted by EricG
But for that to work, you need screen to manage this shell in order for this terminal to be available both locally and remotely. I guess Wayland is analogue to screen in this case?
Originally Posted by elanthis
But you still need Wayland for every backend, right? E.g. gtk is ported to Wayland. So you should get GTK+ -> Wayland -> Weston -> FBDev. And not GTK+ -> Weston -> FBDev. And the final step depends on Weston supporting whatever back-end you want it to.
Originally Posted by giselher
This is getting 'interesting'. X was split into Wayland and Weston. Okay, so one could say that Wayland is purely a middelman that connects toolkits to your screen. But to manage your screen you use a compositor that responds on user input. I follow on that. Now, this compositor get's all sorts of plugins. BUT, the functionality those plugins provide could also be used by (supposedly) other (stacked of course) compositors. So you have 2 ways of implementing the same functionality. Just one is compositor specific and the other one is not. However, the compositor specific method could be build into a library so that all the compositors that link to it recieve that same functionality.
Please understand that I don't quite follow the general idea anymore...
Wayland =~= X11
Weston =~= X.org/X86free/Anything else implementing X11