Announcement

Collapse
No announcement yet.

A Hot-Replace Server For Wayland Is Proposed

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

  • #11
    Potential...

    *IF* this happened and Wayland protocol could go over TCP, this could be very good for remote desktop. " it would need to support proper disconnecting of Wayland clients," I would *love* for a screen-like capability in X (currently using NX to get that in X) Where each window is presented indiviudally down to the client and the client can then do the compositing. VNC is too 'dumb' (just move pixels back and fourth) and X has no inherent detach capability and works poorly with high latency. This sort of enhancement would really sell me on Wayland as a worth-ditching X solution.

    Comment


    • #12
      i think there was a thread in the mailing list about possible solutions to the networking problem a few months back.

      however the devs are probably working on other stuff right now

      Comment


      • #13
        Originally posted by elanthis View Post
        Also, it allows apps to recover from a server crash. Which seems to happen often enough already on X11. You want the system to be resilient. Nothing sucks harder than having a single buggy process bring down your entire desktop and all your applications and data working set.
        This, assuming the proxy isn't buggy and won't crash as much as the "server" (I'd hope the compositor wouldn't crash, since it shouldn't be doing anything that would incite a crash).

        The idea is good though; will keep those people who often change window managers happy...and those who live on the bleeding edge, too, I guess. ;-)

        Comment


        • #14
          Originally posted by elanthis View Post
          It allows the server to be replaced with a different one. In theory, Wayland servers include the window manager and compositor behavior built in (though nothing about the protocol stops you from building a server that uses a separate process for those) and you may want to swap those out. Same as today you can swap out window managers or compositors on X11 today.

          Also, it allows apps to recover from a server crash. Which seems to happen often enough already on X11. You want the system to be resilient. Nothing sucks harder than having a single buggy process bring down your entire desktop and all your applications and data working set.
          This means you can update Wayland to a new version and not have to restart it by closing and opening right?

          Comment


          • #15
            Originally posted by pvtcupcakes View Post
            This means you can update Wayland to a new version and not have to restart it by closing and opening right?
            Well, sort of. The way I understand it, the compositor is (or was) supposed to be part of the window manager (or any program that implemented window-manager-like functionality. This "Server", or "proxy" (depending on how it's implemented, it could be called either) that is being proposed is supposed keep some of the information that the compositor would lose in the event of a crash. If it works, you'll be able to change compositors much like you are able to do "openbox --replace". You shouldn't need to restart the compositor when it's upgraded (you'll just run the older compositor until you do), unless it needs to access some libraries that have changed and there's an internal or external ABI/API break.

            /end

            Comment


            • #16
              Originally posted by dufoli View Post
              Can it solve issue with nvidia optimus?
              No.

              Optimus would never ever require switching display servers. It just requires for one app to be able to render to the screen with one GPU and another app to render with another. That basically just means doing the work in Gallium to allow textures from FBOs on the NVIDIA GPU to be used by the compositor (or in fullscreen mode) to scan out on the Intel GPU.

              At most all Wayland needs to support this is for the Wayland compositor's EGL implementation to hand out the proper GL context to the application. Everything else needs to happen inside of Gallium or the internal compositor code.

              You could do that on X.org even, I'm fairly certain. Just nobody is because Linux graphics is understaffed.

              The problem is that Optimus isn't that useful outside of WIndows, because Optimus is not automagic. It relies on NVIDIA providing a list of apps and which GPU they should use. That's not all that great, and in the Open Source world, it's not even remotely feasible to maintain such a list.

              So you at the very least need a way for the app to specify whether it needs a basic context or a high-performance context. That may require a Wayland protocol update, but still does not at all require swapping servers.

              Comment


              • #17
                Originally posted by makoto42 View Post
                *IF* this happened and Wayland protocol could go over TCP, this could be very good for remote desktop. " it would need to support proper disconnecting of Wayland clients," I would *love* for a screen-like capability in X (currently using NX to get that in X)
                You're over-complicating things by assuming an X-like model.

                With a TCP-based compositor, you already have a screen-like setup. You don't need any extra proxies, restartable servers, or anything. Each app gets its own networked Wayland server and then you can connect/attach those to view them.

                You'd need client reconnection if you want to be able to move between a local-native Wayland display server and a networked one (e.g., if you opened an app, then decided you wanted to keep it running but log out of the desktop), but that's something you can do just as easily on X.org if your app/toolkit supported reconnecting to the X server (which almost none do).

                Really, this proposal is most useful for crash protection. Moving between servers and such all needs to happen on the client end. What the hot restart allows is for a display server to be replaced without losing all of the metadata the display server keeps around (like window positions and transformations that the clients are agnostic to).

                It would also allow client developers to wimp out and not implement reconnection client-side, but that's a horrible idea IMO. Hell, I'd make a conformance testsuite that forces clients to support disconnection and reconnection to a server gracefully.

                Specs that don't include test suites are utterly useless, after all. Nobody cares what some piece of paper says _should_ happen. All that matters is what _does_ happen.

                Comment


                • #18
                  Originally posted by elanthis View Post
                  Specs that don't include test suites are utterly useless, after all. Nobody cares what some piece of paper says _should_ happen. All that matters is what _does_ happen.
                  ...as long as what _does_ happen is the same (as in, compatible) between implementations. Sometimes having that down on paper helps.

                  Comment


                  • #19
                    Originally posted by Nobu View Post
                    ...as long as what _does_ happen is the same (as in, compatible) between implementations. Sometimes having that down on paper helps.
                    Oh, you always want it down on paper to tell devs what to implement. You just want the test suite to make sure the dev implements it correctly and isn't introducing incompatibilities.

                    Just look at HTML. It's only gotten better finally with IE9 because Microsoft wrote a huge test suite for the current "standards." And then was nice and donated it to the community, which in turn has helped improved WebKit and Gecko's conformance as well!

                    Comment

                    Working...
                    X