Announcement

Collapse
No announcement yet.

More Wayland Fixes Pile On For KDE Plasma 5.20

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

  • More Wayland Fixes Pile On For KDE Plasma 5.20

    Phoronix: More Wayland Fixes Pile On For KDE Plasma 5.20

    Getting KDE's Wayland session into shape remains a priority for developers this year and it's looking like the support should be quite slick come Plasma 5.20...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It would appear a usable Plasma Wayland experience is not entirely out of grasp anymore.

    Comment


    • #3
      Originally posted by aufkrawall View Post
      It would appear a usable Plasma Wayland experience is not entirely out of grasp anymore.
      It looks like a lot of important stuff is being fixed for Plasma 5.20, like clipboard, screen recording, thumbnails in task manager, ...

      Comment


      • #4
        why they dont keep x11 code a side and focus in wayland it's okey to ignore nvidia until they support GBM

        Comment


        • #5
          Originally posted by Aryma View Post
          why they dont keep x11 code a side and focus in wayland it's okey to ignore nvidia until they support GBM
          The big KDE 5 work was breaking frameworks and plasma into a better collection of libraries. For KWin that meant you had libraries which were agnostic and X11 and Wayland libraries which are loaded based on the session you choose to start.

          The challenge is the fundamental difference between X11 and Wayland. With X11 while there are windows, they aren't really separated, Program A can listen/draw over Program B's window. With Wayland each window is it's own discrete surface and can't reach out to other surfaces. This has knock on effects like copy/paste then becomes bound to a specific window. So the challenge is to come up with a design to safely allow that kind of function and implement it as a multi-desktop standard (so coordinate with Gnome).

          This explanation is likely horrible, but hopefully helpful.

          Comment


          • #6
            A crash fix for KWin when logging out of a Wayland session.
            This is the second time I read this in a release note...

            Comment


            • #7
              At this point I don't know whether I'm sad 5.20 is a ways off or I'm glad there's time for even more fixes.

              Comment


              • #8
                Originally posted by Steffo View Post

                This is the second time I read this in a release note...
                Good memory.

                The first one was a case where it would crash 100% of the time. This one fixed an occasional crash that only affected some people. I was personally able to reproduce the first one, but not the second one.

                Comment


                • #9
                  Originally posted by stevecrox View Post

                  The big KDE 5 work was breaking frameworks and plasma into a better collection of libraries. For KWin that meant you had libraries which were agnostic and X11 and Wayland libraries which are loaded based on the session you choose to start.

                  The challenge is the fundamental difference between X11 and Wayland. With X11 while there are windows, they aren't really separated, Program A can listen/draw over Program B's window. With Wayland each window is it's own discrete surface and can't reach out to other surfaces. This has knock on effects like copy/paste then becomes bound to a specific window. So the challenge is to come up with a design to safely allow that kind of function and implement it as a multi-desktop standard (so coordinate with Gnome).

                  This explanation is likely horrible, but hopefully helpful.
                  you mean just like windows and android do ?
                  Last edited by Aryma; 08 August 2020, 10:40 PM.

                  Comment


                  • #10
                    Android keeps each app sanboxed pretty well. Windows does not (well "modern" does). The win32api (which is also 64-bit) has a UI event bus that is pretty unrestricted.
                    The mere fact that a simple anti virus has access to so much in windows basically proves that the sandboxing is done terribly. Whereas on Android their functionality is extremely limited by comparison.


                    Linux can go any of the extremes, which is I think why the security model is so confused.
                    Some things like cgroups is really well isolated, other things like X11 is not. At least the filesystem is mostly protected by default, and with things like apparmor/selinux access to the kernel can be protected pretty wholsesale.

                    Comment

                    Working...
                    X