Announcement

Collapse
No announcement yet.

Wayland's Weston Gets A FreeRDP-Based Compositor

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    http://www.phoronix.com/vr.php?view=MTMxNjE

  • #2
    Question(s)!

    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:

    $(x11_backend) \
    $(drm_backend) \
    $(wayland_backend) \
    $(headless_backend) \
    $(fbdev_backend)

    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??

    Comment


    • #3
      Originally posted by Rexilion View Post
      Question(s)!

      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:

      $(x11_backend) \
      $(drm_backend) \
      $(wayland_backend) \
      $(headless_backend) \
      $(fbdev_backend)

      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.

      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).

      Comment


      • #4
        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.

        Comment


        • #5
          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?

          Comment


          • #6
            Originally posted by roland View Post
            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.

            Comment


            • #7
              Since you can nest Wayland compositors... anRDP "client" can be started and run I ER any other compositor. Similar-ish to how you can use any text shell, since sshd handles the networking, not the shell itself.

              Comment


              • #8
                Originally posted by Rexilion View Post
                Question(s)!

                This is a Weston back-end. So this has to be implemented for every compositor over and over again?
                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..

                Comment


                • #9
                  Originally posted by Rexilion View Post
                  Question(s)!

                  This is a Weston back-end. So this has to be implemented for every compositor over and over again?

                  Is this for Wayland itself??
                  1) Yes until we get a library that can just supply all possible backends (probably a good idea for someone to write) to any wayland compositor that wants it... until then, every compositor has to implement this on their own.

                  2) Its for Weston, which is the reference / example compositor that is in the Wayland repository that is actually fairly usable to show people how to write a wayland compositor and what you should do style / implementation wise.

                  Comment


                  • #10
                    Originally posted by renox View Post
                    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..
                    In other words, you could launch [RDP_Compositor] and have your desktop compositor run underneath it, and/or run your desktop compositor and have [RDP_Compositor] run under it. Or, your desktop compositor could be [RDP_Compositor].

                    (1) would be weird...not sure how it would work. Sort of like remoting multiple desktops, I guess. (2) would be like running a single app remotely, or running multiple apps in a virtual desktop remotely. (3) would, obviously, remote your whole desktop.

                    remote -- not just an adjective anymore, now it's verbing.

                    Comment


                    • #11
                      Ok, lemme get this right...

                      Originally posted by Nobu
                      In other words, you could launch [RDP_Compositor] and have your desktop compositor run underneath it, and/or run your desktop compositor and have [RDP_Compositor] run under it. Or, your desktop compositor could be [RDP_Compositor].
                      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).

                      But this time, it's integrated into the compositor in the new Wayland 'model'.

                      Originally posted by renox
                      1) Yes until we get a library that can just supply all possible backends (probably a good idea for someone to write) to any wayland compositor that wants it... until then, every compositor has to implement this on their own.
                      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 EricG
                      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..
                      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 elanthis
                      Since you can nest Wayland compositors... anRDP "client" can be started and run I ER any other compositor. Similar-ish to how you can use any text shell, since sshd handles the networking, not the shell itself.
                      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 giselher
                      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).
                      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.



                      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...

                      Comment


                      • #12
                        Wayland =~= X11
                        Weston =~= X.org/X86free/Anything else implementing X11

                        Comment


                        • #13
                          Originally posted by przemoli View Post
                          Wayland =~= X11
                          Weston =~= X.org/X86free/Anything else implementing X11
                          Repeating what you said earlier won't make stuff more understandable. And besides, if Wayland is purely a protocol then explain me why I'm seeing c code and header files inside it's git repository? Why is there an executable called Wayland if it's only protocol?

                          Your statements make no sense to me.

                          Comment


                          • #14
                            Originally posted by Rexilion View Post
                            Repeating what you said earlier won't make stuff more understandable. And besides, if Wayland is purely a protocol then explain me why I'm seeing c code and header files inside it's git repository? Why is there an executable called Wayland if it's only protocol?

                            Your statements make no sense to me.
                            That package that is called wayland provides a library and headers for implement how the clients communicate with the server (compositor) in C. In fact it just a proxy in this regards which handles the communication through a socket.

                            Comment


                            • #15
                              Originally posted by Rexilion View Post
                              Ok, lemme get this right...

                              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.

                              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...
                              Lemme see if I can't clear this up Rexilion, because this is getting WAY off track.

                              1) A librender would be a good idea, assuming its technologically feasible. I put that disclaimer inl because I don't know the design spec for Wayland compositors, and therefore maybe it wouldnt actually work. But assuming it could work, thatd probably be a good idea.

                              2) X, Wayland, and Weston are three VERY different things. X was not split into anything. X, was a protocol from the 1980s. Wayland is a new protocol started I think 2years ago, and Weston is the reference/example compositor for Wayland.

                              X and Wayland are JUST protocols, they don't actually handle screen management (maybe X did or can but it doesnt anymore, so peanut gallery: shush). To handle window management you need a separate application that speaks the X / Wayland (or both) protocol. For X we have like...God only knows. There's metacity, mutter, Kwin, the *boxes, the *poisons, E17, and tons of others.

                              For Wayland we have... Weston, which is the EXAMPLE compositor that the Wayland guys themselves wrote to show people how things work and what you should/shouldnt do when youre writing your own compositor. Gnome Shell and Kwin (KDE) Are in the process of being ported over to Wayland, they are doing it in such a way that they will detect at runtime whether they are being run on X or Wayland, and choose the appropriate codepath.

                              Now, as far as the backends. Typically you want to run Wayland on pure hardware. Not always though. Thats when the backends come into place: people have written a DRM backend (thats the hardware one) theyve written a Pixman one (thats software rendering on the cpu, bad idea for the most part. But if your graphics card is crap / broken drivers, it'll get the job done. So its a good backup to have.) They've now written an RDP one.

                              The idea of the backends is its different ways the compositor (not the protocol) can be run. So if you have a FreeRDP-capable compositor on a server, and you connect via a FreeRDP client to that server. The compositor will see the incoming connection, recognize it as FreeRDP, and give you a connection. Maybe it will be the current session, maybe it will be a new session (probably able to choose between those two) and a few seconds later the desktop will appear on the computer you're connecting from.

                              The protocol itself does not care about backends, backends are for the compositor. All the protocol cares about is getting pictures from A to B, where B is a screen.

                              Now, you brought up the X backend. The X backend, unless im mistaken, is XWayland. XWayland is so that if you have an application that was specifically written for X (Not done in a modern version of GTK or Qt) that they can still run under Wayland. Wayland will spawn a special X server that is the exact size of their window. X thinks its in charge but when it goes to display the contents of the screen, its actually pushing them to a Wayland buffer and then Wayland handles where, when, and how to display the contents.

                              Dear god do I hope that clears things up because your last post was a complete mess >.< (not your fault, everyone elses)

                              Comment

                              Working...
                              X