Announcement

Collapse
No announcement yet.

RealVNC Remote Desktop Wants To Support Wayland

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

  • RealVNC Remote Desktop Wants To Support Wayland

    Phoronix: RealVNC Remote Desktop Wants To Support Wayland

    Aside from the progressing PRIME support for Wayland, more good news today for this X.Org Foundation backed project is RealVNC expressing interest in supporting Wayland for their remote desktop software...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    That would be nice if RealVNC going to use the new multi-seats feature from wayland. This will make remote desktop much better!

    Comment


    • #3
      This dev opened up a topic that would have to come up sooner or later: Somehow Wayland compositors will have to expose an interface that allows
      access to either the main framebuffer, or all separate client buffers, for applications such as screen recorders or streaming software such as XSplit or OBS.

      The question is, how does one make this secure.. I guess the only way would be to ask the user with a visual promp to grant a specific binary access to a
      secure interface, maybe using checksums to store certain already approved apps in a white list.

      Comment


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

        Unless I'm missing something obvious , I don't think security will be that big an issue. Only provide the program the same level of access to the frame-buffers as the user who is running the program.

        Comment


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

          Unless I'm missing something obvious , I don't think security will be that big an issue. Only provide the program the same level of access to the frame-buffers as the user who is running the program.
          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.

          Comment


          • #6
            Originally posted by Ancurio View Post
            This dev opened up a topic that would have to come up sooner or later: Somehow Wayland compositors will have to expose an interface that allows
            access to either the main framebuffer, or all separate client buffers, for applications such as screen recorders or streaming software such as XSplit or OBS.

            The question is, how does one make this secure.. I guess the only way would be to ask the user with a visual promp to grant a specific binary access to a
            secure interface, maybe using checksums to store certain already approved apps in a white list.
            The issue is that a visual prompt on the local machine is problematic for remote operation (or machines without screens).

            I suppose that when a program requests the main framebuffer, the compositor should ask for user password/authentication, so that a random app could note access it in background. And the remote session requires user login anyway, so you could ask for access to a new session, or to one or all existing one for the same user.

            Comment


            • #7
              Originally posted by Ancurio View Post
              This dev opened up a topic that would have to come up sooner or later: Somehow Wayland compositors will have to expose an interface that allows
              access to either the main framebuffer, or all separate client buffers, for applications such as screen recorders or streaming software such as XSplit or OBS.

              The question is, how does one make this secure.. I guess the only way would be to ask the user with a visual promp to grant a specific binary access to a
              secure interface, maybe using checksums to store certain already approved apps in a white list.
              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).

              Comment


              • #8
                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).
                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.

                Comment


                • #9
                  Originally posted by bulletxt View Post
                  in less than two years we will have two completley different softwares.
                  Exactly. This is why many people think that Mir is a bad idea.

                  Comment


                  • #10
                    Originally posted by erendorn View Post
                    The issue is that a visual prompt on the local machine is problematic for remote operation (or machines without screens).

                    I suppose that when a program requests the main framebuffer, the compositor should ask for user password/authentication, so that a random app could note access it in background. And the remote session requires user login anyway, so you could ask for access to a new session, or to one or all existing one for the same user.
                    Wayland was designed from the ground up to maximize performance and ease of maintenance of local user sessions disregarding any "network transparency". If there's a problem with remote operation, then the people responsible for it will either have to just say "not supported on this compositor" or implement it somehow their way. Remote computing is always an afterthought, not a main deciding factor (otherwise we'd still be stuck with horrible render protocols such as GLX).

                    Comment

                    Working...
                    X