Announcement

Collapse
No announcement yet.

RealVNC Remote Desktop Wants To Support Wayland

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

  • #11
    Originally posted by dee. View Post
    I think it'd be easiest to just implement it in the compositor. A screen recorder or such can request the full, composited buffer from the compositor, and the compositor can decide which apps are trusted to get it (which can be user-configurable).
    Problem is you'd end up implementing the same relatively complicated software for each and every compositor, and they'd all suck infinitely more than say XSplit or OBS. That kind of defeats the point of having standardized interfaces like the input method one, no?

    Comment


    • #12
      Oh Boy! VNC! Just what I always wanted in a remote protocol: very limited flexibility and shitty performance! Woohoo!

      /s

      Comment


      • #13
        Originally posted by Ancurio View Post
        Problem is you'd end up implementing the same relatively complicated software for each and every compositor, and they'd all suck infinitely more than say XSplit or OBS. That kind of defeats the point of having standardized interfaces like the input method one, no?
        Well, that's what libraries are for. Making some given software capabilities available in multiple projects.

        Comment


        • #14
          Originally posted by Ancurio View Post
          Problem is you'd end up implementing the same relatively complicated software for each and every compositor, and they'd all suck infinitely more than say XSplit or OBS. That kind of defeats the point of having standardized interfaces like the input method one, no?
          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.

          Comment


          • #15
            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; 03 August 2013, 02:15 AM.

            Comment


            • #16
              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.; 03 August 2013, 02:50 AM.

              Comment


              • #17
                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


                • #18
                  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


                  • #19
                    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


                    • #20
                      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

                      Working...
                      X