No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by treba View Post

    Can you make a concrete example? Or you claiming that's the agreed opinion of most AMD graphic devs? Because for every random opinion from *some* graphic dev I can give you an example from a contradicting one.
    I was asking why we don't have things like Radeon Super Resolution and was told it was because of the display manager situation. Unfortunately, I can't find that post from sometime in October of this year.

    bridgman agd5f marek

    Can one of y'all comment on the matter regarding display managers and AMD GPU feature parity between Windows and Linux?


    • #52
      Originally posted by treba View Post
      The list of things obviously broken on X11 (and unfixable with major breaking changes) is long enough that I don't think that I have to repeat it here. But let me give you an example for your concrete use case, a simple GTK4 / Qt5/6 app (or Firefox or Chromium). On X11, transparency with EGL has been broken forever on Mesa (and is apparently hard to fix). So all toolkits / apps wanting to do GL with transparency (e.g. for CSD) are stuck with GLX. Which is horribly outdated and doesn't have a sane implementation for partial damage. So now every small change, the whole window has to be redrawn. That's inefficient. Some apps like Firefox do wild tricks to mix GLX with EGL to make things work. But that's just incredibly ugly.

      Now you might say: well, then just do SSD and write your engine in a way so it requests RGB instead of RGBA like you do on every other platform. There you have it. Weird extra stuff just to keep X11 running.

      Yes, people still do that in many cases. But they could invest their time much better.
      Sounds like first world problems to me.

      Nothing of that is a functional issue, unlike Crapland which cannont do something as basic as letting apps position windows.


      • #53
        Originally posted by avis View Post
        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.
        This is not something you can't fix with the proper organization and abstractions, for example, the input stuff is totally standardized through libinput, maybe the way forward to avoid what you say is more libraries or maybe a flexible enough compositor that is compatible with different shells like Plasma and GNOME Shell. But this is hardly a Wayland problem, it's more how different organizations are implementing it and collaborating with each other, maybe they don't see the value of losing flexibility on their own compositor development. But in theory, you could have, let say, KWin, Mutter, etc, based on wlroots, it's not a problem inherent to Wayland.


        • #54
          Originally posted by skeevy420 View Post
          For all the good Wayland offers, it's very stifling to progress due to not having a centralized display manager solution to work with.
          Hit the nail right in the head, beatings will continue to be used as a morale improvement until this situation is resolved, we need a wayland-based "" compositor that would let all desktops build on top of it.

          This will be the end situation at some point, but to get there many more beatings will be required to improve morale. In the mean time at least Nvidia will be forced to fix their drivers' wayland problems.


          • #55
            Originally posted by piotrj3 View Post

            Sorry, when Xorg is definitly not modern, neither is Wayland. Qt doesn't work beautifully on Wayland (a lot of issues that are diffrent on diffrent DEs), neither does OBS (modern recording software), neither GPU drivers (requiring explicit synchronization model), neither modern APIs (implementing Vulkan on open source drivers was pain due to implicitly synced stack).

            Not to mention modern stuff I would expect to have perfect VRR support (nope), HDR (missing except gamescope magic), DRM-leasing (required by a lot of things, Gnome nope), color grading (partial, and annoying), position of window, surviving crashing of compositor (I think only on KDE Qt apps have that possibility everything else dies) and so on.

            Sorry Wayland is not modern graphics stack, especially when it pissed off Nvidia, AMD, Intel, Valve and way more engineers.
            Exactly this.

            I hope RHEL 10 dies from this change so they choke on their own crippled Crapland.


            • #56
              Originally posted by treba View Post

              Funny - all things you mentioned are already there, like explicit sync, good display recording etc., - or in the pipe. The thing that makes Wayland modern here: everything *can* be implemented in a pretty clean manner. And window positioninng - that's a discussion for itself, but arguably it's not *modern* to do that. It's just bad 90s design still hanging around.

              The fact that it's modern is also why it gets picked up so widely - be in Linux desktop, embedded, ChromeOS - even Windows.

              For example HDR is absolutly nope, neither color grading. Some people simply need that.

              VRR is partial (Gnome only supports it for full screen programs, doesn't work for entire desktop, Sway might work for desktop but not for full screen aplication (if direct scannout is on, you need workaround in this case), hyprland and KDE actually works correct (allows both only full screen and desktop VRR support). So i would say only 2/4 works right and is on par with Windows.

              in OBS a lot of plugins like magnifying doesn't work on Wayland. Again not production ready.

              Explicit sync for present doesn't exist in Xwayland. Still.

              Gnome has no DRM-leasing. (all VR is dead)

              Gnome doesn't allow tearing (gamers don't like Gnome).

              Gnome doesn't have fractional scalling still (as far as i know).

              Recovery from driver error is also poor comparing to Windows.

              Only reason why it was picked in Linux desktop because choice is either 40 year old curse or "new" covid. Embedded is fine - it was kinda designed for it, and ChromeOS is kind of closer to embedded (it doesn't care about most features above) and still developed entire new compositor to it.

              Anyway, I seen so many programs/reviews/3rd party opinion something works on KDE doesn't on Gnome and vice versa. This doesn't give confidence.


              • #57
                Originally posted by Britoid View Post

                Many things need now wide spread in the Windows world need to be created by each individual Wayland compositor.

                Non-Display Outputs (VR)
                Session Recovery
                Seamless Terminal Sessions (Remote RDP swap to Physical Desktop and Back)

                Apart from the latter, these are not "niche" things anymore.

                HDR / color management: A big issue for the whole stack where one the Wayland protocol as well as kernel APIs are figured out (and implemented in one/two compositors / drivers) will will like become much easier for others. Especially once more things are moved to drivers via EGL/VK extensions.
                VR: similar - no agreed upstream method yet, but once it is, it'll likely be easy for different compositors to support.
                FreeSync: different approaches about how to do it right (just having a setting or proper automatic detection) - would also have been hard to agree on in a shared lib. Implementation itself no that hard.
                Session Recovery: Also no protocol yet, but work on implementations on a proposal happening. Once figured out and agreed upon -> not that hard to implement.

                So sure, you can argue that some of the developments would be faster with a common compositor library, however it begs the question if it's really easier to agree both on the protocol and the implementation - or just the protocol. AFAICS most protocols with a broad consensus of their usefulness also get supported by most compositors pretty fast. And always requiring more than one implementation likely improves the quality of the protocols - which arguably is good in the long term.


                • #58
                  Originally posted by boeroboy View Post
                  The Red Hat power grab continues. If it's not forcing everyone onto systemd it's forcing everyone onto the next rewrite that they control to stay relevant through false threats. I predict a major boycott starting with Fedora as they're already cutting out XOrg and leaving most users with half-baked replacements of critical daily usage apps.

                  Red Hat survived the systemd blowback because init is vital to both servers and desktop usage. It won't survive this because RHEL and Fedora are far less relevant outside of the server space.
                  I'm not a RH fanboi, but given the lack of leadership in many Linux things, I will say that I'm glad they are the ones doing it.

                  Hell, M$ got scared when Linux had the superior eye candy and hauled ass to update the graphic stack with Windows Vista and then W7. Yet Linux is still struggling to move on from X.

                  My only issue with RH is their unconditional support for the crap that is Gnome today and that group definitely needs a kick in their asses to either stop the nonsense of making the DE as unusable as possible or simply be replaced by a more sane DE.


                  • #59
                    Originally posted by Weasel View Post
                    Sounds like first world problems to me.

                    Nothing of that is a functional issue, unlike Crapland which cannont do something as basic as letting apps position windows.
                    X11 is unsable for whole classes of hardware - with no way out to fix things. Just a few examples:
                    - Multi monitor. Have different refresh rates, scaling or rotation? No good solution for you.
                    - Touch and gestures.
                    - Power efficient video playback. Want to use the display controller to do YUV->RGB conversion and scale things? Or even overlay planes? Not for you.
                    - Proper HDR on the desktop.

                    I'm not claiming all of that is already implemented, especially the last point. But where it's not, there's a clear way to do it.

                    So the difference between X11 and Wayland is: one has a clean architecture to implement things going forward - and some controversial design decisions to *deliberately* not support certain retro features. The other one is unfixable stuck in the past.


                    • #60
                      Originally posted by avis View Post
                      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.
                      Why haven't you stepped up to be the maintainer then?

                      You complain a whole heck of a lot for someone who demands some other developer's time. You've stated on more than one occasion you know how to code.

                      What is holding you back from standing up and doing your job?