No announcement yet.

John Carmack Is Interested In Wayland On Ubuntu

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    The network funcionality of X doesn't lower performance on local systems. The latency is negligible. If Wayland really improves performance, it won't be because of that.

    X may be old, bloated etc. It may be yes. But if these were serious issues, someone would have improved them already. So many corporations are working with Linux, if they saw a point in it, they would improve it. But they don't. It is more trouble than is worth.

    It is not because it is hard to change X. No task in programming is really hard, if you really need it.

    I sure hope Wayland to succeed. Choice is good. But i don't get all the fireworks for it...


    • #32
      The biggest distro wants it. The biggest. CPU vendor wants it. The biggest game developper wants it. Red Hat pays for it. Clutter, Gtk and Qt are doing it.

      It will seriously get there!


      • #33
        Actually, Kristian seems to be on Intel's payroll now.

        Anyway, to comment on the story. It would be nice if Michael didn't simply post that John Carmack posted on his twitter that he wishes to have time to contribute, but maybe asked for John's comment on that. Would make the story less sensationalist methinks.

        P.S. I would simpy love to see John Carmack's patch in some open source project.


        • #34
          I don't use twitter, but I was under the assumption that pretty much anyone can ask him.


          • #35
            Originally posted by elanthis View Post
            People who don't understand much about X or Wayland (i.e. you) tend to associate the idea that Wayland prefers client-side window decorations with a ton of problems in Windows. Basically, you are associating a particular implementation with a general idea, which is silly. Windows apps don't lock up the desktop because they use client-side decorations (and, in fact, they don't lock up the desktop ever at all in Windows 7, despite still using client-side decorations).
            That's because Windows has a really ugly, crufty hack where it tries to detect when applications aren't responding and replace their window decorations with a set of system window decorations that provide just enough functionality to move or minimise the hung window. Traditionally, it was also impossible for Windows to change the positioning or layout of the controls because apps made assumptions about it, and unwise for applications to do so because Windows made assumptions about it. Vista/7 seem to have finally dealt with this, but I dread to think how...

            Originally posted by elanthis View Post
            Besides that, GTK+ and Qt already started adding client-side decorations long before Wayland started. And many popular X apps have used client-side decorations for well over a decade, including such olden popular apps like XMMS and modern popular apps like Google Chrome.
            Both of which used them because they were originally designed as Windows applications. XMMS is a clone of the Windows application Winamp, which has a skinning system that requires client-side window decorations. Chrome was actually developed for Windows and ported as an afterthought.

            Originally posted by elanthis View Post
            It's worth noting that client-side decorations do NOT mean client-side window management!
            It does require that a lot of the interaction with window management is done via the client. What's more, the more flexibility you want to have in how window management is interacted, the more complex the API for rendering the window decorations has to be. It's going to develop a lot of cruft in a very short span of time...

            Originally posted by elanthis View Post
            The only feature that might actually be lost is remote-GL, but nobody serious uses that anymore, because GLX is utterly and completely out of date with the current OpenGL specification.
            With X, yes. The trouble is, the entire point of Wayland is that all applications use OpenGL for rendering. Unless someone comes up with a suitable equivalent for Wayland, we're effectively stuck with software rendering and some application-level equivalent of VNC - with the same, fairly fundamental, issues that VNC on X had.

            Originally posted by elanthis View Post
            You want to get a new graphics feature, you need to update your kernel and X, despite the fact that X is just a protocol, windowing layer, and event I/O dispatcher!
            I suspect that, a lot of the time, you'll find the same is true with Wayland. Most of the time, when graphics features requires X updates under KMS it's because they need changes to the core compositing functionality that's also implemented by Wayland. Most of the "cruft" doesn't change all that often. When they requrie a kernel update, it's because the necessary functionality plain wasn't exposed before, and that won't change either.

            What will change is that, with Wayland, you'll have to keep the kernel, Wayland and Mesa all in sync with each other, because Wayland requires both hardware-accelerated OpenGL support that works as expected and a kernel graphics interface that Wayland itself likes in order to run at all.

            Originally posted by elanthis View Post
            Instead, X can sit over Wayland. Wayland becomes the low-level abstraction to the hardware interfaces. It is even lower-level than X, allowing for much more efficient multiplexing.

            So the way things will work in the future is NOT App->Gtk->Wayland but rather App->Gtk->X11->Wayland.
            You're missing out a few steps there, though. Firstly, you're missing out a whole bunch of other stuff that'll be going on above the Wayland layer. X11 will have to use OpenGL to render the stuff it wants composited: X11->Mesa->Mesa Driver->Kernel Driver->GPU. The application may also be using OpenGL, either directly or through GTK. Secondly, you're missing the stuff that happens beneath Wayland and the way it interacts with everything else. Wayland also uses OpenGL, as well as interfacing with the kernel driver itself, and the two are quite tightly intercoupled.

            Originally posted by elanthis View Post
            Anything Wayland does could, in theory, be added directly to X. At some point, though, that stops being feasible in the current Xorg implementation. To get Xorg up to speed with what Wayland is capable of basically requires rewriting huge portions of the internals of Xorg... which is basically saying, "we don't want Wayland because it's written from scratch which is dumb, so instead we're going to write something else from scratch but claim that isn't dumb because we said so."
            Except, of course, they wouldn't be rewriting from scratch at all. For example, they could almost certainly leave the input support totally untouched. (Oh, did I mention - Wayland currently assumes all input is via evdev and behaves exactly like one of the device types it's aware of, and there's no suitable abstraction layer that would allow this assumption to be changed?) What's more, incrementally rewriting large chunks of application is a very different proposition from throwing it away and starting from scratch - the latter throws away all the experience that's gone into developing the application and requires re-learning it, and means breaking a whole bunch of stuff at once rather than manageable chunks.


            • #36
              People who don't understand much about X or Wayland (i.e. you) tend to associate the idea that Wayland prefers client-side window decorations
              It seems to me that some people who imply they do understand the way wayland works also associate client-side decorations with wayland. Clientside windows and clientside decorations are different things. The reason all apps for wayland draw decorations for themselves is simply because drawing decorations is not implemented in wayland-compositor. And wayland-compositor is not meant to be "the one true compositor".


              • #37
                >Oh, did I mention - Wayland currently assumes all input is via evdev
                You're saying that wayland uses portions of X and that is somehow supposed to be bad, but when X uses portions of X - that's good? I'm all confused now.


                • #38
                  evdev is a part of the kernel, not a part of X.

                  X using evdev for input meant that the input handling moved out of X and into the kernel. I think that this is good.


                  • #39
                    One thing nobody seems to have mentioned is that there is another protocol being used today that lets you run an application on one box and have user interaction on another box. It's called HTTP. Many systems are moving to a model of using web apps for configuration/administration... why not adopt a model like that for on Linux as well (web-based UI for configuration / admin that can run locally or remote) ?

                    There seem to be relatively few cases where you need to be able to run "all" apps remotely other than tech support / troubleshooting, and a screen capture model seems best for that anyways.

                    Just a thought...


                    • #40
                      I use three computers (headless server, workstation, laptop), and I use some kind of remote X each and every day. To run apps on the server, to run apps on the notebook without switching over, to run apps on the workstation when I'm not at home, ..

                      Compared to remote X, VNC..
                      * is slow
                      * is poorly integrated (i.e. wrong window decorations, no real compositing)
                      * lacks the option to forward single apps/windows
                      * requires a remote display server, making it largely unsuitable for the headless machine
                      * requires the user to be logged in on the remote machine (i.e. no ssh -X $router; ./wakeonlan $workstation; ssh -X $workstation; /usr/bin/$random_app)
                      * interrupts the remote machine's console (i.e. can't run apps while someone else works on the machine)

                      Some of that could be fixed with a new remote protocol and enough plumbing, but I'm not seeing anyone doing it. It's just "Hey, let's jump wayland, screw features!".
                      Also: how am I going to run apps on my server which lacks a GPU? Software rendering + forwarding image data can't be better than remote X, not when the only remaining rendering protocol shall be openGL.
                      Sure, I can still run X on top of wayland, but that somewhat defeats the purpose of replacing X with something more lightweight..