No announcement yet.

Red Hat Enterprise Linux 10 Dropping The X.Org Server Except For XWayland

  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by hughsie View Post

    I'm sorry, but this is just nonsense. Even if the design of graphics hardware never changed, the number of Xorg CVEs the graphics team handles is huge, and each is usually high severity and requires a massive amount of validation and testing. The reality is that the X protocol is obsolete and designed for hardware that doesn't exist any more, it does not "work beautifully" by a long shot.
    Talk about the following: (KWin Wayland)

    - One frame of output lag
    - Possibly one frame of input lag as well
    - Tearing is impossible unless you disable atomic DRM/KMS or upgrade your kernel
    - Tearing is only available on clients that support the protocol

    X11 definitely needs replacement, but I cannot go Wayland until proper, pain-free tearing is available.
    Last edited by tildearrow; 28 November 2023, 03:22 PM.


    • Originally posted by muncrief View Post
      I have no problem with a new display server being implemented.

      The mystifying aspect for me to understand is why a new server was chosen that requires applications to actually be rewritten to utilize it.

      Really, that's just mind boggling.

      There are a plethora of applications that will never be rewritten because the resources to do so are unavailable, and unfortunately XWayland only partially implements X server functionality.

      But hey, I don't want to start a flame war or get into an argument about it.

      I just wanted to put in my two cents and state that obvious fact, which is sometimes drowned in the dissent.
      15 years later, people still think they had a good plan for the transition, and it was all inevitable that we're in this situation. What boggles my mind is that so much of this stuff was funded by companies. Seems like a lot of them were duped. If all things were going well redhat removing xorg 15 years later wouldn't required advanced notice and consultation with customers. It would be a non event. it's shocking but not surprising that people still want to pin this on nvdia. it's mostly the fault of the gnome cabal funded by red hat desktop effort who have led us here. they are following rules and design principles created by really good people back in the early days of wayland who have moved on, and if they were still involved they would have long since abandoned those rules.


      • Originally posted by Panix View Post

        Does KDE have one? I guess ppl are going to say 'use....'blah,blah, blah now - when something doesn't work. RHEL doesn't care about a few programs/issues and if they impact only a smaller percentage of users - it seems like they are making this major decision pretty early?
        How about this video?


        • Its the year 2099

          The source code of is lost after the last server hosting it dies

          Not a single developer has laid their gaze in the code for decades

          Wayland has replaced all windowing protocols, even in Windows 95

          Phoronix releases an article describing the history of display servers

          A discussion breaks out about whether Wayland or Xorg is better


          • Originally posted by avis View Post

            How do you know there are no people/orgs willing to maintain Who told you that? RedHat in this press release?

            Lastly when was the last time you checked Xorg's git repo? Look, it's totally dead: Oh, wait, it's very much alive.
            Take a closer look, that's the X server repo, which contains Xwayland, which is maintained by Red Hat engineers. If you look a lot of the commits to that repo are not for Xorg server anymore, they are for Xwayland and they are from Red Hat.


            • Wayland looks like a huge mess to me. But, yes, end Xorg - use XWayland - the sooner Nvidia has better support for Wayland, the better- if there is less incentive to change from Nvidia - then, perhaps, AMD might start supporting productivity software and implement features so their cards can be undervolted and you have fan control.

              But, look at the Wayland slow....:

              Think twice about Wayland. It breaks everything! GitHub Gist: instantly share code, notes, and snippets.


              • Originally posted by avis View Post

                Need fix link you missed a l.

                The KMS foundations was happening before wayland. You end up back in 2007 with the TTM the precursor to GEM and DRI2 with the KMS foundation. Wayland protocol is linked to the KMS changes.

                Something to remember DRI2 is 2008, KMS as a formalized mainlined API in the Linux kernel is 2009 but as a normal formalized API in development branches you see it in 2007.

                Wayland protocol comes out of the KMS/DRI2 work due to a problem found. SHM of X11 protocol turns out not to be suitable for zero copy operations.

                GEM and TTM both did support zero copy operations but there was a big security fault with both leading to the newer DMABUF solution. Yes 2007 it was kind of clear the existing X11 protocol was not going to be suitable going forwards without major changes.

                Remember this is before libglvnd when installing ATI/Nvidia closed source drivers was nuke the mesa opengl drivers or other vendors driver on Linux. This problem of drivers stomping on other drivers files effects windows up until Microsoft with Windows 10 mandates drivers updated to their portal for signing so this has not been a Linux only problem.

                Microsoft has not had a easy time getting GPU hardware vendors to play nice with each other. Linux has had a worse time getting drivers vendors to play nice with each other.

                Thing to remember when it came to KMS equal API on windows Nvidia and ATI argued against a platform defined on with Windows Vista.

                People talk about windows kernel being explicit sync of course complete miss that Windows has a kernel mode support for implicit sync emulated on top of explicit sync for legacy applications.

                There are many times that Linux core kernel developers and Microsoft core kernel developers would have loved to be able to get all the GPU driver developers in one room and lock the door until they would all come into agreement or remove themselves from the market.

                The KMS/DRI3 and DMABUF bits are stuff that needed to happen. Some replacement protocol to X11 has to happen because X11 protocol design does not match up with modern hardware.
                Last edited by oiaohm; 28 November 2023, 04:09 PM.


                • Slowayland...


                  • Xorg = outdated and high unsecure piece of software
                    Wayland = 15 years old and doesn't have this, doesn't have that etc
                    XWayland = An abortion

                    The absolute state of opensores.
                    Attached Files


                    • obsolescence
                      Originally posted by avis View Post
                      The corporate speak in this press release is as sneaky and deceitful as always.

                      The person who wrote this statement went to great lengths to portray as something that requires a ton of dedication, work and resources which is just utterly untrue.

             has been in pure maintenance mode for over a decade now. It requires nothing more than occasional security patches. That's it. Otherwise it works beautifully.

                      This is not's depreciation, this is imposing Wayland on everyone whether they like it or not.

                      I still cannot grapple with one thing.

                      Linux for years now has been about unification and standardization: systemd, pipewire, /usr merge, NetworkManager, DBUS, devtmpfs, etc. etc. etc.

                      Why did someone high up in graphics [development] decide that it would be great to have twenty discrete display servers with various levels of features implementation, bugginess and readiness? What's the point? The amount of maintenance, work, resources, etc. required to develop 20 different display servers trumps what might have needed by an insane margin. Somehow it's totally ... fine.
                      It's not a conspiracy reason to cause the termination of Xorg, but Xorg itself. Xorg is obsolete, unsafe, unreliable causing inefficiency. It's the main cause for which linux graphical stack cannot increase in performance. Xorg developers themeselvs claim the end of Xorg as well as Vulkan, explicit sync and simplification ask for a modern solution. It's modernity that impose the end of Xorg. After Xorg, Opengl must be deprecated soon as possible. So don't cry, be happy for the new improvement. on the other hand, it seems that xorg enthusiasts want to impose obsolescence to the others. It's a puerile way to approach linux.