Announcement

Collapse
No announcement yet.

KWinFT Going Through Code Refactoring, Working On WLROOTS-Based Usage

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

  • #21
    I definitely want to add that Roman's KwinFT fork and friends have made my experience on KDE much better. Surprisingly, I think the best part of his work is the wrapland, disman, and kscreen projects. They completely fixed multi monitor configuration stickyness, as in when you take your laptop from one setup to the next, it remembers the screens properly. For some reason KDisplay is inconsistent with this feature and overall requires me to reconfigure my displays every other boot.

    As for KwinFT itself, I found the compositor works very well with nvidia GPUs, but the performance suffers on integrated graphics. So for my desktop I use `kwinft` and for my laptop(s) I use `kwin`. But for both systems I use wrapland, disman, and kscreen in-place of kdisplay since they remember my monitor configurations correctly.

    Comment


    • #22
      Originally posted by ms178 View Post
      smartalgorithm [...] but there are binary packages available - albeit not the latest - on a community repo for openSUSE) [...].
      I just updated the packages to 5.22. Have not testet them myself yet, though.
      Last edited by seijikun; 13 June 2021, 06:16 PM.

      Comment


      • #23
        Roadmap? What's missing?

        Promising project. Needs more developers though, issue reports would probably explode in numbers if this was used as a daily driver by more people. 90% of that being NVIDIA users and the usual wrong packaging/compiling from manjaro and arch users. Or configuration clashes with KWin.

        Comment


        • #24
          Originally posted by seijikun View Post

          I just updated the packages to 5.22. Have not testet them myself yet, though.
          that's nice, thank!
          one day i also should sit down and learn how to use that OBS...

          Comment


          • #25
            Originally posted by smartalgorithm View Post
            one of the most intriguing project of the year for me, personally... i'm really looking forward for this project. wlroots is a wise choice and the next wise choice would be making kwinFT a drop in replacement for kwin, and also maybe coming up with a new nice name...
            thanks to the authors and keep up the good work!!!!
            It is already a drop in replacement for kwin. I have been switching back and forth between kwin and kwinFT in manjaro to test it out. Its easy since kwinft is also in the repositories

            Comment


            • #26
              Originally posted by shmerl View Post
              Yeah, I think it was with Firefox / Wayland (not XWayland, real Wayland mode). But I'd need some more tests to verify.
              Wayland and XWayland versions of firefox on Linux both use GTK library for the clipboard. There was a issue with GTK applications including firefox having clipboard issues with wayland due to defective gtk library.
              The firefox bug with more details is: https://bugzilla.mozilla.org/show_bug.cgi?id=1631061 I open an issue here as I am not sure if this is...


              This is a horrible little mess. There have been bugs found in firefox own internal clipboard handling code that have been fixed as well that causes random failures under X11 but had been happening way more often with Wayland version as well.

              There also bugs open against sway and mutter as well. Yes the reference weston compositor did not show all the faults that cause the same problem with the clipboard here.

              I would call this a teething problem all around the failure points are following.
              1 defective handling of clipboard in application code(this is not only restricted to firefox). Yes the defective handling also results in random cases where the clipboard fails under X11 at roughly 1 in 10000 hours of use but due to the difference wayland causing different code flow path this comes back to 1 in 24 hours of usage. So it a case bug was always there just the change to wayland makes it more visible.
              2 defective handling a wrapper library this case gtk. Yes some of this is the same bad logic as the applications so X11 issue way less frequent and some of this is doing non standard stuff.
              3 compositors not being 100 percent compatible with the reference for clipboard handling. There are fixes in mutter and wlroots to fix this.

              Of course with such a broad set of failure points being sure they are all fixed it will take a while. There are many issues open about it that developers are looking at.

              Comment


              • #27
                Originally posted by damentz View Post
                Surprisingly, I think the best part of his work is the wrapland, disman, and kscreen projects. They completely fixed multi monitor configuration stickyness, as in when you take your laptop from one setup to the next, it remembers the screens properly. For some reason KDisplay is inconsistent with this feature and overall requires me to reconfigure my displays every other boot.

                But for both systems I use wrapland, disman, and kscreen in-place of kdisplay since they remember my monitor configurations correctly.
                Going to take a guess that you mixed these two up? kdisplay is the one from KWinFT project, not kscreen which is older.

                Originally posted by damentz View Post
                I found the compositor works very well with nvidia GPUs
                I assume that's on X11 not Wayland?
                Last edited by polarathene; 14 June 2021, 01:33 AM.

                Comment


                • #28
                  Does anyone know why he choosed wlroots over Mir? The latter is based on modern C++.

                  Comment


                  • #29
                    Originally posted by Steffo View Post
                    Does anyone know why he choosed wlroots over Mir? The latter is based on modern C++.
                    Modern C++ would be enough reasons not to use it. wlroots being C does turn out to make things simpler.

                    Think about this if KDE code and Mir code update there C++ standard support out of alignment with each other the result can be incompatibilities in interpretations. C might be horrible and old but horrible good feature about is it standard changes slowly leading to low alignment issues. There are enough C++ incompatible issues that can come up from mesa3d libraries leading to valve supporting libcapsule work in the first place. Yes you already have a two way tango between mesa3d and kwinft over C++ features that can lead to code reworks without making this a three way.

                    Other thing at this stage as well more parties use wlroots than Mir as well so more parties to share maintenance with.

                    Comment


                    • #30
                      Originally posted by oiaohm View Post
                      Modern C++ would be enough reasons not to use it. wlroots being C does turn out to make things simpler.
                      Well KWinFT also uses modern C++. I think a library like Mir would update their C++ standard requirement carefully.

                      Other thing at this stage as well more parties use wlroots than Mir as well so more parties to share maintenance with.
                      This is actually a good reason. But I really don't like C, because it is more probable that use after free or memory leaks bugs occur.
                      Last edited by Steffo; 14 June 2021, 03:21 AM.

                      Comment

                      Working...
                      X