Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: RealVNC Remote Desktop Wants To Support Wayland

  1. #11
    Join Date
    Aug 2011
    Posts
    432

    Default

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

  2. #12
    Join Date
    Sep 2008
    Location
    Seattle, WA, US
    Posts
    87

    Default

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

    /s

  3. #13
    Join Date
    Sep 2012
    Posts
    24

    Default

    I prefer vnc as it's persistent and i can choose a different window manager from the main screen.

  4. #14
    Join Date
    Sep 2012
    Posts
    568

    Default

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

  5. #15
    Join Date
    Jan 2013
    Posts
    1,352

    Default

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

  6. #16
    Join Date
    Aug 2011
    Posts
    432

    Default

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

    Quote 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 at 02:15 AM.

  7. #17
    Join Date
    Jan 2013
    Posts
    1,352

    Default

    Quote 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 at 02:50 AM.

  8. #18
    Join Date
    Aug 2011
    Posts
    432

    Default

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

  9. #19
    Join Date
    Jan 2011
    Posts
    1,287

    Default

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

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

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

  10. #20
    Join Date
    Jan 2013
    Posts
    1,352

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •