Announcement

Collapse
No announcement yet.

KWinFT Lands Code To Now Use WLROOTS For Wayland

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

  • #11
    Very wise, forward looking philosophy and changes... I am feeling very positive about this project. Thanks for all of that work!

    Comment


    • #12
      Originally posted by avem View Post
      I'm looking forward to an Xorg-waylandish server being written for Wayland. Once this is done I will switch to this wonderful new graphical subsystem and will never look back. Having two dozen servers ("compositors" which are all essentially Xorg servers) for Wayland is not a path forward, it's a path backward since it means a duplication of effort, code, errors, features and great many bicycles Linux can do without. And wlroots is not the answer, it can't be.
      That's how Wayland is designed, so that part will not change. It will end up the same way web browsers did. You will see some consolidation, and eventually you'll have a handful of well supported compositors.

      Comment


      • #13
        Originally posted by smartalgorithm View Post
        Very wise, forward looking philosophy and changes... I am feeling very positive about this project. Thanks for all of that work!
        Agreed.

        Comment


        • #14
          I still don't think that KwinFT is going to see through a long life, but porting it to make use of Wlroots sounds like a good burn test for Wlroots itself. If this change is successful and comes without major limitations, maybe other big window managers can be ported over to it, too, instead of managing "competing" codebases with no future.

          However, it's still too low-level and choosing Mir would have been better albeit probably requiring rewriting more of the essential code...
          Last edited by curfew; 16 July 2021, 09:32 PM.

          Comment


          • #15
            Originally posted by curfew View Post
            I still don't think that KwinFT is going to see through a long life, but porting it to make use of Wlroots sounds like a good burn test for Wlroots itself. If this change is successful and comes without major limitations, maybe other big window managers can be ported over to it, too, instead of managing "competing" codebases with no future.

            However, it's still too low-level and choosing Mir would have been better albeit probably requiring rewriting more of the essential code...
            First problem with Mir is its license. Mir is GPLv2 or GPLv3 for the core and for the libraries its LGPLv2 or LGPLv3. Nothing like being a legal nightmare pick a license will you please. Yes those or means when a person take the Mir code base and modify it they can go like GPLv2 and LGPLv3 only or any mix so making a fork code unable to up-streamed.

            Wlroots is MIT license the same as what the X11 server was and the reference Wayland compositor weston is. This is way less of a nightmare.

            Mir starts you running back into the same problems as the historic X11 server. You see the too low-level arguement a bit but there are issues with the idea of a higher level. Yes I know wanting the shell/compositor in it own process compared to the display server sounds like a good idea. Until you wake up IPC between processes is not the most effective thing. Using a library you link in means you get to avoid a stack of IPC. Every IPC event means you have to depend on the scheduler to wake up the right other process to provide response.

            Think about it. Task1 does a IPC to task2 now has to wait for task2 to have cpu time to process the IPC request. This has to happen as part of weston/x11 at different points. But the count is important.

            application->sway/any wlroots solution
            That -> is total in the iPC links.
            Yes sway or any other wlroots just function calls the wlroots functions this this means you are not need extra time slices.

            Now lets look at a mir.
            application->mir->graphical shell->mir
            This is not particularly nice. -> please note each of these arrows you end up having to travel both directions. So graphical shell has a extra query about a window does a IPC to mir then mir has to return to graphical shell is the last one there.

            So the best outcome of a wlroots solution for a general wayland application is 1 IPC call set the worst for a wlroots solution is still 1 IPC call set.
            The best outcome of a mir solution for a general Wayland application is 2 IPC calls the worse outcome is infinity IPC calls.

            Remember every IPC call end up wasting a segment of a time slice. The more IPC calls you have more CPU time you are wasting. The more jitter/variation in latency you get with more IPC calls as well so if you are trying to make something low latency you also want to keep IPC usage as low a possible. This is not the simplest problem.

            Comment


            • #16
              Originally posted by avem View Post
              I'm looking forward to an Xorg-waylandish server being written for Wayland. Once this is done I will switch to this wonderful new graphical subsystem and will never look back. Having two dozen servers ("compositors" which are all essentially Xorg servers) for Wayland is not a path forward, it's a path backward since it means a duplication of effort, code, errors, features and great many bicycles Linux can do without. And wlroots is not the answer, it can't be.
              Agree completely.
              This comes pretty close. https://github.com/ackalker/Xweston

              Currently more of a *hack* than anything but if people want to run their own Window Managers (which most people do!) then it will possibly become the only way to do it.

              Comment


              • #17
                Originally posted by C8292 View Post
                This could be the turning point where KwinFT becomes superior to KDE's kwin.
                One of the people on the original Kwin team (can't remember the name, sorry) said Kwin is basically an X compositor and Wayland support will always be just tacked on. He said if he needed something to work specifically with Wayland, he'd start from scratch.

                Originally posted by C8292 View Post
                My perception is that WLROOTs is becoming the wayland reference implementation: tested a lot, used by multiple projects and with a lot attention from developers (making it more stable, faster and better?)
                Wlroots is just a library (or several). There is a reference Wayland implementation and that is Weston. But it's not reusable.

                See this excellent explanation: https://www.secjuice.com/wayland-vs-xorg/
                X has that server which is the reusable part (technically, you can find more servers, but really there's a de-facto standard). Wayland does away with that, when you implement your own compositor, you pretty much have to implement your own server as well. It's probably easier with wlroots around, although I'm not sure wlroots has proven itself outside of sway (but with enough interest it will).

                Comment


                • #18
                  Great achievement to use Wlroots! Something I wonder about is why KWinFT tries to maintain backward compatibility with X11. That is quite well covered by KWin. Wouldn't it be better to cleanly develop KWinFT for Wayland needs more or less like gamescope is implementing X11 support only via XWayland? Anyway I will try KWinFT 5.23 as soon as it's available and hope it can replace KWin for my desktop and gaming use cases.

                  Comment


                  • #19
                    Originally posted by curfew View Post
                    I still don't think that KwinFT is going to see through a long life, but porting it to make use of Wlroots sounds like a good burn test for Wlroots itself. If this change is successful and comes without major limitations, maybe other big window managers can be ported over to it, too, instead of managing "competing" codebases with no future.

                    However, it's still too low-level and choosing Mir would have been better albeit probably requiring rewriting more of the essential code...
                    First rule of a successful project, don't use anything made by Canonical. Not to mention wlroots has years of use in the real world and that's priceless.

                    Comment


                    • #20
                      Originally posted by kpedersen View Post
                      Agree completely.
                      This comes pretty close. https://github.com/ackalker/Xweston

                      Currently more of a *hack* than anything but if people want to run their own Window Managers (which most people do!) then it will possibly become the only way to do it.
                      That has not gone anyone where in 6 years. There is a reason.
                      https://www.phoronix.com/scan.php?pa...ter-X11-Relief
                      Mutter under Gnome when it was first ported to Wayland really was not ported to Wayland. Instead Mutter was running by like Xweston. There is now a performance problem. There is a total miss alignment between Wayland and X11 windows manager protocol. X11 windows managers don't have to consider stuff Wayland applications expect.

                      Originally posted by bug77 View Post
                      Wlroots is just a library (or several). There is a reference Wayland implementation and that is Weston. But it's not reusable.
                      There is a mistake here Weston implementation does have reusable part.
                      https://wayfire.org/2019/02/24/X11-W...n-Wlroots.html
                      libweston is covered here. Just some of the design choices in libweston are a major pain in the but if you are attempting to implement a full desktop environment and the fact that it only has what is in the accepted standard implemented. Yes its really simple to mess that wayfire went though 3 different wayland backend libraries. There are some targeted usage windows mangers today that their back-end is libweston and they are not weston.

                      Wayfire did not go though the qt provided wayland support libraries.
                      libweston is the most suitable choice like if you are implementing a desktop for like a kiosk these are areas being restricted to only approved Wayland protocol is fine. There are quite few items other than weston that tick box and do exist on github.
                      Wlroots is more of all rounder.

                      Originally posted by bug77 View Post
                      X has that server which is the reusable part (technically, you can find more servers, but really there's a de-facto standard).
                      The reality here is a lot more savage. X.org X11 so called reference compositor has a major problem. X.org X11 not a true reference implementation of X11 protocol. How was X.org X11 brought to a more manageable size by breaking sections of the reference implementation and see who noticed if noone noticed remove that section of the X11 protocol from X.org X11 server implementation. Yes you can find other X11 servers that will run X11 applications that will not run on X.org X11 server because X.org X11 server is missing sections of the X11 protocol. Yes really wrong right remove something form X.org X11 server implementation then not mark it as removed/deprecated in the X11 protocol documentation and this has happened.

                      The hard reality here is the X11 x.org server makes no promise that in the future that you old windows manager or de or application will work if development kept on going the way it was. Yes this was happening before the first line of code was written for Weston. There is more to Xwayland than one can think. Xwayland make it possible to run multi different versions of Xwayland under 1 solution.

                      Comment

                      Working...
                      X