Announcement

Collapse
No announcement yet.

A Hot-Replace Server For Wayland Is Proposed

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

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