Announcement

Collapse
No announcement yet.

RealVNC Remote Desktop Wants To Support Wayland

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

  • #16
    Originally posted by erendorn View Post
    Well, that's what libraries are for. Making some given software capabilities available in multiple projects.
    Oh, okay. You want to write a library, and then 20 different kinds of glue code for each and every compositor out there, instead of simply implementing a common interface in one binary. Makes sense.

    Originally posted by dee. View Post
    But there could be a standardized interface for it, defined in the Wayland protocol. The compositor would just implement it - that's what they do anyway, they implement the Wayland protocol.
    If you read my original post, you'll see that I was saying exactly this.

    Edit: Actually nvm, that's not what I was saying. You're misunderstanding something; weston implements the wayland protocol/interfaces, because clients need to talk to it via them. If there is functionality for eg. a screen recorder that's built into the compositor, as is the case with wcap, there is no interface because there is no client to talk to, since the code paths lie directly in the compositor. You'll find that there is no "screen capture" interface in wayland. An interface is needed when an outside client (such as is the case with IM support, see text input protocol extension) provides the service and needs a standard way to talk to a compositor for resources / locked down functions.
    Last edited by Ancurio; 08-03-2013, 02:15 AM.

    Comment


    • #17
      Originally posted by Ancurio View Post
      You'll find that there is no "screen capture" interface in wayland.
      Well no there isn't now but they could add it there.

      The way I see it, having clients request the composited buffer directly from the compositor would be the simplest solution. The compositor being the only part of the stack that knows what it is.
      Last edited by dee.; 08-03-2013, 02:50 AM.

      Comment


      • #18
        Originally posted by dee. View Post
        Well no there isn't now but they could add it there.
        Of course, but then it doesn't make sense anymore to provide this functionality in-compositor.

        Comment


        • #19
          Originally posted by ua=42 View Post
          I wonder if it would be more efficient to have access to all the client framebuffers as opposed to the main one. Then you could set up events to be sent when each client is updated as opposed to every time the main buffer is updated. Also would mean just sending the image of the client that updated, not the entire screen.
          Leaving alone performance, this should make one able to remote single apps. I don't know if that would be useful, but sounds interesting.

          Originally posted by Ancurio View Post
          Repainting in weston is already optimized in such a way that only damaged regions of the framebuffer are repainted. So you get that for free.
          You have no guarantee other compositors will handle it that way (I know it's most likely, but not guaranteed), and those are the ones likely to show real world usage.

          Originally posted by bulletxt View Post
          What about Mir? Are current changes/new_features in Wayland getting into Mir and viceversa? If not in less than two years we will have two completley different softwares.
          Different beasts. That's why some people (including myself) make some fuzz about fragmentation. Because it exists, and it's relatively likely to be of importance.

          Anything done in Mir can't (because of GPLv3) be directly integrated into Wayland. Also, if I understand correctly what the GPLv3 means, some algorithms might be patented and only usable if taking the code from the GPLv3 implementation, which means it can't even be reimplemented locally on Wayland, because it uses a different license. Features on Wayland going into Mir, well, they can copy whatever they want, the license allows them. I ignore if it's technically feasible, and it probably would take some work to port anyway. But if it's this way, then I hope Mir fans don't complain when someone points out Canonical is leeching from a project they did spread pretty harsh comments about.

          Comment


          • #20
            Originally posted by Ancurio View Post
            Of course, but then it doesn't make sense anymore to provide this functionality in-compositor.
            No, the screen recording functionality would be in the client, which requests the full composited buffer from the compositor, via an interface defined in the protocol. So it would be up to the compostitor to decide which clients are allowed to access the compositor in this way and how that is configured.

            Comment


            • #21
              Originally posted by Ancurio View Post
              Oh, okay. You want to write a library, and then 20 different kinds of glue code for each and every compositor out there, instead of simply implementing a common interface in one binary. Makes sense.
              Yes, it makes sense. Because compositors may use different assumptions.
              "One size will fit all" is not the best programming paradigm ever. Actually, it's specifically because X suffered from this problem that we are changing to wayland. Wayland enforces as little as possible.
              Some libs are provided, though, and you can write extensions to the protocol. Extensions that any compositor may, or may not support. Or may support with some other lib.

              Comment


              • #22
                Originally posted by mrugiero View Post
                You have no guarantee other compositors will handle it that way (I know it's most likely, but not guaranteed), and those are the ones likely to show real world usage.
                Well, those compositors would just always give the entire screen rect as damage. It would still work (albeit slow as hell). I think something like damage tracking could just be made mandatory to the extension.

                Originally posted by dee. View Post
                No, the screen recording functionality would be in the client, which requests the full composited buffer from the compositor, via an interface defined in the protocol. So it would be up to the compostitor to decide which clients are allowed to access the compositor in this way and how that is configured.
                Hm okay, so we are talking about the same thing after all. I just got really confused when you started out saying "I think it'd be easiest to just implement it in the compositor." even though I was talking about the exact same concept.

                Originally posted by erendorn View Post
                Yes, it makes sense. Because compositors may use different assumptions.
                "One size will fit all" is not the best programming paradigm ever. Actually, it's specifically because X suffered from this problem that we are changing to wayland. Wayland enforces as little as possible.
                Some libs are provided, though, and you can write extensions to the protocol. Extensions that any compositor may, or may not support. Or may support with some other lib.
                Do you know what the word "interface" as a software term means? It is a way for two or more software components to talk to each other without knowing about their inner workings. It is the reason a GTK app can run under almost any X11 WM. Now, tell me, assuming there is a simple extension defined which says:
                "I as the compositor will provide you with either the screen buffer, or a client's buffer at your choice, preferably as a resource bindable as a GL texture, but SHM buffers are fine too".
                What kind of "assumptions" of different compositors would make this troublesome? Either you can provide the above requirements, or you can't. That's it.
                Oh, and I also wonder what kind of conditions would encourage developers to port/write their software for wayland. "Write one backend that works with all compositors exposing that interface" vs "first split my entire codebase into a library, then write 20 backends for each compositor out there". Hmmm..

                Comment


                • #23
                  Originally posted by mrugiero View Post
                  Anything done in Mir can't (because of GPLv3) be directly integrated into Wayland. Also, if I understand correctly what the GPLv3 means, some algorithms might be patented and only usable if taking the code from the GPLv3 implementation, which means it can't even be reimplemented locally on Wayland, because it uses a different license. Features on Wayland going into Mir, well, they can copy whatever they want, the license allows them. I ignore if it's technically feasible, and it probably would take some work to port anyway. But if it's this way, then I hope Mir fans don't complain when someone points out Canonical is leeching from a project they did spread pretty harsh comments about.
                  funny how mark complains about wayland, accusing intel of paying collabora to keep code proprietary in order to deliberately sabotage mir (which, fwiw, is total total rubbish and 100% unfounded), but he doesn't seem to have any problem with mir depending on xkbcommon, which i wrote at collabora for intel. with neither an apology for the former, nor a thanks for the latter. oh well.

                  Comment

                  Working...
                  X