Announcement

Collapse
No announcement yet.

XWayland 21.1 Release Candidate Offers Split From The X.Org Server

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

  • #31
    Finally. Xorg and Xserver had been nothing but pain.

    I don't wish to ever relive those days where the xserver refused to start and Xorg -configure returned all manner of obscure errors that simply could not be fixed or addressed to obtain a working graphical desktop. Which I experienced again first hand when trying out both FreeBSD 12-CURRENT and FreeBSD 13-BETA.

    Comment


    • #32
      Originally posted by muncrief View Post
      Well, it doesn't appear that there's ever going to be a "drop in" Wayland replacement for X. Wayland was first released 9 years ago, and XWayland 7 years ago. And yet even the developers still have great difficulty with it.
      That was never the intention, sorry that it took almost a decade for you to understant that. Supporting Wayland basically requires every single application to be patched for it. Sure, at least for Qt and GTK-based apps it's mostly very painless: just let the toolkit do all the heavy lifting. But even after that many apps simply cannot work, because they try to do something that Wayland explicitly forbids. Apps like screen recorders and others that want to access the "global state" which doesn't really exist anymore in the same way.

      Comment


      • #33
        Originally posted by muncrief View Post
        I'm primarily referring to the issues with KDE and XFCE mppix , but also with all other things that aren't Gnome. If XWayland was a drop in replacement for X, which is how it was initially presented, it would just work with everything.
        Sounds like a misunderstanding on your part. Xwayland is a drop-in for running Xorg apps on Wayland, but even then you first need the Wayland session to exist. And after that Xwayland and the primary Wayland session somehow need to interact, which probably requires some additional work implemented in the Wayland host.

        Comment


        • #34
          Originally posted by curfew View Post
          That was never the intention, sorry that it took almost a decade for you to understant that. Supporting Wayland basically requires every single application to be patched for it. Sure, at least for Qt and GTK-based apps it's mostly very painless: just let the toolkit do all the heavy lifting. But even after that many apps simply cannot work, because they try to do something that Wayland explicitly forbids. Apps like screen recorders and others that want to access the "global state" which doesn't really exist anymore in the same way.
          Yeah, plus the other dozens of scenarios that don't work anymore. That's not a misunderstanding, that's a fact.

          Comment


          • #35
            Originally posted by mppix View Post
            Xwayland runs on top of Wayland. Therefore, a Xwayland based Xserver is a Wayland compositor.....
            Is a text editor running on Wayland a compositor? No.

            My understanding is that apps draw themselves inside Xwayland but after that Xwayland itself delegates the actual rendering to the compositor it's attached to. In other words Xwayland is sort of a virtual screen but doesn't manage outputting to the real display.

            Comment


            • #36
              Originally posted by duby229 View Post
              Yeah, plus the other dozens of scenarios that don't work anymore. That's not a misunderstanding, that's a fact.
              Misunderstanding is when you expect something else that contradicts the facts.

              Comment


              • #37
                Originally posted by duby229 View Post
                Hence the -entire- reason why 94% of all linux users are still on xorg...
                Could you please provide the audited source reference (from a reputable research firm) for that number.....

                Comment


                • #38
                  Originally posted by kpedersen View Post

                  It very likely is going to be implemented as a compositor (due to the Wayland architecture, you have to implement an entire compositor to do anything). But either way, it will ultimately be an Xserver. Basically just a more stripped down re-implementation of Xorg. I personally am fine with that.

                  Sure, they might screw it up, but it probably still wont be any more annoying than Xsun to deal with.
                  If it can't do mixed-dpi properly, no one will take this seriously. The wayland protocol solves two big problems for desktop users: security, and mixed DPI. Over time, more Linux desktops will confront or adopt mixed DPI situations. As for security, X should send shivers down your spine.

                  Comment


                  • #39
                    Originally posted by mppix View Post
                    The X window system was developed in the 80s and 90s. However similar to VNC, its governing bodies are defunct and the protocol cannot be changed anymore. Any change would result in a non-conformant implementation.
                    Interoperability matters only when there are multiple servers to talk to. With X there is only X.org Server left standing, so it can do whatever it wants, really. The procol has been changed, *erm*, "extended" many times over recent years by modules such as DRI3.
                    Last edited by curfew; 18 February 2021, 12:54 AM.

                    Comment


                    • #40
                      Originally posted by AmericanLocomotive View Post
                      Pardon me if I'm misunderstanding things (as the Linux GUI/Graphics stack still baffles me for the most part): Is this article really saying that x.org - something used by nearly all distributions, has no one actively developing/working on it? How is that even possible?
                      Well what is there to develop? Much of the stuff that needs active maintenance have been split off Xorg a long time ago so there is not much need for even maintenance releases that would update contributed bits. I guess the only reason for a new version would be breakage in some of the libraries that it uses.

                      Comment

                      Working...
                      X