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

  • #41
    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


    • #42
      Originally posted by oiaohm View Post

      Xwayland is a Wayland client application. So its not Compositor. Thing to remember as gamescope from valve shows and the Weston reference compositor shows. Is that a Wayland compositor can in fact be a X11 application as well. So if Xwayland was a full blown wayland compositor it would be possible for it to run directly on top of X11 bare metal as well but Xwayland is not its only a Wayland client application.

      Being a compositor is different to being a client application. Compositor has to have all your hardware interface library bits and those open up some really wacky running locations.
      Dude, why are you lecturing? Also, you may want to address the person who brought the idea forward.

      edit:removed not well articulated statement
      Last edited by mppix; 18 February 2021, 10:46 AM.

      Comment


      • #43
        Originally posted by mppix View Post
        PS. Xwayland is not a client, its a compatibility layer
        Is this some form of autism? It is a compatibility layer implemented as a Wayland client. Why do you think they are mutually exclusive?

        Comment


        • #44
          Still, even with Gnome 3.38 Wayland have some annoying issues. Not critical but annoying as hell - I've multi-monitor setup - two displays with equal resolution and size, some applications tend to change size and/or jump from secondary display to main every time I lock and then unlock session. Namely this happen with Firefox and Gnome Terminal. That might be not exactly Wayland compositor issue, but since it happens only with Wayland session I still point finger at it.

          Comment


          • #45
            Originally posted by blacknova View Post
            Still, even with Gnome 3.38 Wayland have some annoying issues. Not critical but annoying as hell - I've multi-monitor setup - two displays with equal resolution and size, some applications tend to change size and/or jump from secondary display to main every time I lock and then unlock session.
            Seems to happen on a single display too. Sometimes I realize all my apps have been packed into the first vdesk whereas I always keep them spread over two to four vdesks.

            Comment


            • #46
              Originally posted by sabian2008 View Post

              Thanks for this. There was a new commit there adding preliminary support for GPU offloading in Xwayland. That's the good enough solution for 99% of Nvidia users I think. Any iGPU from the last ten years can run two (or maybe three) displays at high resolution and you can lunch games, blender / whatever in the dGPU and display it using the iGPU. You can therefore avoid the pile of crap the EGLStreams backend is.
              While I generally agree with you, I think that percentage is just way too random.
              There's a huge amount of people using Nvidia on the desktop without an integrated gpu.

              Comment


              • #47
                Originally posted by timrichardson View Post

                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.
                The Wayland protocol doesn't solve these issues. Some (~2) of the individual compositors do.

                Security of Xorg is a little over stated. For example it doesn't even listen on TCP (or UDP) sockets any more (only internal UNIX domain sockets). So no-one external can break into my session. Any other users running on the same machine can also not break into my session due to the MIT cookie system. What many people say is the "risk" is actually that other programs in the same session can access other windows. This is obviously very important and a required feature for enterprise computing (VNC requires it for one, Web browser screen sharing also). Once Wayland matures, this will also be the case with Wayland compositors. macOS and Windows also have this feature because it is required from all but i.e phone users.

                Honestly the DPI issues are a temporary thing whilst too many consumers are buying absurdly high resolution screens. This will resolve itself once people realize they can save a bit on battery power avoiding such things.

                Comment


                • #48
                  Originally posted by mppix View Post
                  Debian, Fedora (and next iteration of Ubuntu) are defaulting to Gnome Wayland. It is perfectly usable in general. What issues are you referring to?
                  I'm not him, but here's my non-exhaustive list:

                  - No reset for Gnome (blocker for me, given how often alt + f2 + r is necessary)
                  - SMPlayer is not working properly (don't care whose fault it is)
                  - Unite extension doesn't run correctly (among others)
                  - Firefox titlebar in multi-monitor setup doesn't work too well
                  - Ctrl + scroll doesn't work for zooming in gthumb
                  - no xkill equivalent
                  - No support for SSD in Mutter/Gnome wayland

                  And no, I don't care whether it's the protocol design, the DE compositor/wayland implementation, the DE design or the app whose responsible. Maybe if it was just the one, and not properly maintained, then it might be overlooked to go forward. But when it's piling up for well maintained apps (considering many app devs never asked for it and the extra work to adapt), it means the ecosystem is not ready (which is the same as wayland is not ready in my opinion).
                  As a user, this is transparent to me and it should just work as it was (with a tolerance for a couple of changes).

                  It doesn't matter to me and most users who is to blame specifically when we just want to go about our entertainflow or workflow but somehow are not able to.

                  Comment


                  • #49
                    Originally posted by kpedersen View Post

                    What many people say is the "risk" is actually that other programs in the same session can access other windows.
                    And input.

                    This is obviously very important and a required feature for enterprise computing (VNC requires it for one, Web browser screen sharing also). Once Wayland matures, this will also be the case with Wayland compositors.
                    No, Wayland doesn't allow one client to spy on the surface contents or input of another client. (Wayland protocol objects only have local IDs valid in the same client connection, there are no global IDs which could be used by another client)

                    Screen sharing/casting is working in Wayland sessions via separate specialized APIs which require explicit user consent. These APIs can work the same way in Xorg sessions as well, so applications only need to support those APIs to work regardless. E.g. OBS Studio just landed the basic changes needed for using those APIs (the OBS Studio flatpak has been patched to work on Wayland out of the box for some time). Current versions of Firefox & Chromium support them for screen sharing as well, it's mainly a matter of Electron based apps updating to a new enough Chromium base.

                    Honestly the DPI issues are a temporary thing whilst too many consumers are buying absurdly high resolution screens. This will resolve itself once people realize they can save a bit on battery power avoiding such things.
                    Nobody's been able to come up with a solution for X11 on mixed DPI setups which doesn't result in some apps either appearing too small or getting scaled up when they shouldn't be.

                    Comment


                    • #50
                      Originally posted by Mez' View Post

                      - No reset for Gnome (blocker for me, given how often alt + f2 + r is necessary)
                      Shouldn't be necessary ever, and isn't for me and many others.

                      Make sure there are reports about issues you encounter.

                      - Ctrl + scroll doesn't work for zooming in gthumb
                      Works fine here with gThumb 3.11.2, both native Wayland and with GDK_BACKEND=x11.

                      Comment

                      Working...
                      X