Announcement

Collapse
No announcement yet.

SDL2 Reverts Its Wayland Preference - Goes Back To X11 Default

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

  • #61
    Originally posted by birdie View Post
    Countless things (for a start X11 has a single server, for Wayland we now have what? two dozens?) prove that whatever developers have on their minds is as remote from being rational and sensical as possible. If requiring common sense and much needed common API is trolling, then something might be wrong with someone's grey matter.
    Weird how you got angry for calling your behavior trolling, moments after you called the developers' decisions asinine. All while believing you hold a monopoly on common sense.

    Sure there's a single X11 server, because that's the only implementation that stayed alive for 18 years among all the other efforts. The same could happen to Wayland where different implementations dwindle with time and everyone converges towards a single best effort. That's not an advantage of X11 nor a limitation of Wayland's design. There's no protocol in the world that mandates a single implementation that should be used by everyone. After all, protocols are made for interoperability. I fail to see how the Wayland communication protocol could force that.

    Originally posted by birdie View Post
    So please kindly never mention me again and never reply to my posts, OK?
    Sorry but, you're posting your opinion on a public forum for everyone to read and comment on. So please kindly ignore my replies if you find my opinion doesn't align with yours, or stop posting altogether.
    Last edited by Vermilion; 19 April 2022, 05:03 PM.

    Comment


    • #62
      Originally posted by tildearrow View Post

      Couldn't the GNOME team just use a shader as a workaround? Night light is nothing more than lowering the blue and green channels...
      This is great question! This was actually mentioned in the issue. I'm just gonna repeat what that posts says over here for simplicity's sake. A shader could absolutely be used to get the same effect but it would requiring rendering the whole screen to an off-screen buffer then applying the shader and displaying that result which would have a non-trivial effect on performance. I'm pretty sure the reason it would have to be drawn to an off-screen buffer is because the intention is to just tint stuff for viewing purposes, it's not the type of thing you'd want to also apply to apply to the results of screen grabs, screen recordings, or a color picker so you'd need a non-tinted version for that and a tinted version for display.

      By using GAMMA_LUT, it just gives the display processor a CLUT that it can use to transform the image right before it gets sent out of the display connector.

      Also it should be noted that this isn't just an Gnome issue. My understanding is that it KDE implements their blue-light rejection feature in the same way. Since GAMMA_LUT is a kernel-level feature, I'm pretty sure that Nvidia support for it would allow them to scrap the XRANDR method of changing the screen LUT that they use under Xorg and just use GAMMA_LUT for both sessions.

      Comment


      • #63
        Originally posted by caligula View Post
        Mostly works? Webcam yes, screen share no. I guess you don't need that.
        IDK about Zoom, but with the latest Discord stable you can launch it with Chromium's Ozone/Wayland flags and the electron version will pick them up and not only render Discord natively on Wayland without xwayland, but also utilize PipeWire properly for screen sharing.

        Comment


        • #64
          Originally posted by tildearrow View Post
          Couldn't the GNOME team just use a shader as a workaround? Night light is nothing more than lowering the blue and green channels...
          Probably won't work with direct scanout, without Wayland protocol this is a genuine driver feature.

          Comment


          • #65
            Originally posted by Daktyl198 View Post

            IDK about Zoom, but with the latest Discord stable you can launch it with Chromium's Ozone/Wayland flags and the electron version will pick them up and not only render Discord natively on Wayland without xwayland, but also utilize PipeWire properly for screen sharing.
            I don't know about you, but if the clients and other groups assume the use of one tech, you can't just switch to something else. I think Discord is great, but it's not that commonly used for transmitting webinars etc.

            Comment


            • #66
              Originally posted by Myownfriend View Post

              X11 now has a single server...sort of. If XWayland and XQuarts are part of the Xserver git but they are different from Xorg. Before Xorg was Xfree86 which is what Xorg forked from and before that there was a number of other implementations that you could even find on the Wikipedia like Cygwin/X, Exceed, MKS X/Server, Reflection X, X-Win32, Xming, WeirdX, Android X Server, etc.

              I'm not sure that Wayland has anywhere near two dozen compositors but maybe I'm mistaken.
              On my Fedora Linux I've had a single Xorg server for over two decades now (I started with RedHat 5.2 - no that wasn't RHEL, it was RedHat). You could stop shoving the examples from the long past or other platforms, OK?

              The fact remains: Wayland has dozens of servers/compositors (which is an asinine idea BTW to combine them because it means everything becomes a lot more prone to crashes) and there's zero work to unify anything - don't BS me please. You cannot use KWin with Gnome, you cannot use Mutter with KDE. Under Xorg/X11 both are perfectly possible.

              Wayland has nice ideas behind it, but overall the way it's implemented now it's worse than Xorg.

              X11/Xorg gives me more freedom and it's more modularized than Wayland/Whatever compositor you wanna throw in.

              Comment


              • #67
                The absolute worst thing about Wayland is that it implies and necessitates that each DE must write their own server/compositor implementing a metric ton of features.

                This is nightmare. Whoever designed/envisaged this really hates people and Linux users in general.

                That's why: IceWM wayland support = WONTFIX
                That's why: XFCE - zero support and near zero work towards supporting it.
                That's why: we only have kinda-OK'ish mutter/gnome and buggy/incomplete kde/kwin. And that's it.

                Comment


                • #68
                  And of course it's all BECAUSE OF NVIDIA.

                  People who say that are either complete idiots, trolls or haters - or all of it at the same time.

                  Comment


                  • #69
                    Originally posted by birdie View Post
                    The absolute worst thing about Wayland is that it implies and necessitates that each DE must write their own server/compositor implementing a metric ton of features.
                    Yeah just like every Xorg WM implements their own compositor on Xorg... mutter, kwin, xfce... everyone has their own compositor on Xorg too. Stop spreading fud

                    Comment


                    • #70
                      Originally posted by birdie View Post
                      The absolute worst thing about Wayland is that it implies and necessitates that each DE must write their own server/compositor implementing a metric ton of features.
                      Citation needed.
                      AFAIK that's just your understanding since wlroots is maintained by one of the core developers working in Wayland.

                      Originally posted by birdie View Post
                      That's why: we only have kinda-OK'ish mutter/gnome and buggy/incomplete kde/kwin. And that's it.
                      Are you deliberately omitting wlroots? It's the closest to what you've been asking so far. A unified library that many Wayland compositors are built on.

                      Comment

                      Working...
                      X