KDE's window manager KWin gets forked with 'KWinFT' to accelerate the development and better Wayland
Stick a fork in it! KDE's window manager KWin officially has a full fork with a new project called KWinFT, with an aim to support modern development practices and further expand Wayland support.
Announced by Roman Gilg, the same developer who became a contractor for Valve last year and part of that work was actually to improve KWin so it looks like this may have come as a result of that. What's interesting about KWinFT, is that it's supposed to be a "drop-in replacements for KDE's window manager KWin and its accompanying KWayland library" making it easy to get started with it.
Gilg said they did this because "Classic KWin can only be moved with caution, since many people rely on it in their daily computing and there are just as many other stakeholders" so they can push through more advanced changes and overhauls.
What's already in? According to Gilg:
- My rework of KWin's composition pipeline that, according to some early feedback last year, improves the presentation greatly on X11 and Wayland. Additionally a timer was added to minimize the latency from image creation to its depiction on screen.
- The Wayland viewporter extension was implemented enabling better presentation of content for example for video players and with the next XWayland major release to emulate resolution changes for many older games.
- Full support for output rotation and mirroring in the Wayland session.
The first public release was put out along with the announcement and if you use Manjaro Linux, it's already available in the unstable branch under the kwinft package. You can read the announcement here.
What are your thoughts on this? As someone who transitioned to KDE from the GNOME a while ago, anything that can further improve it sounds excellent.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
19 comments
I am not for full forks. We'll see if this projects won't join together again once KWinFT has reasonable stability, or maybe it will replace KWin and the teams join together.
I understand the need to move faster at the risk of breaking, and that KDE is reluctant to do that. For the future it would be great if those improvements find their way to KWin / get upstreamed. Much like Proton and Wine or DXVK/D9VK.
I understand the need to move faster at the risk of breaking, and that KDE is reluctant to do that. For the future it would be great if those improvements find their way to KWin / get upstreamed. Much like Proton and Wine or DXVK/D9VK.
4 Likes, Who?
I hope the fork is merged back later on, otherwise it is a waste of time and energy.
3 Likes, Who?
An experimental branch that tests things out before they get polished and moved upstream would be great. This, though, sounds like someone just got grumpy that their "revolutionary" Wayland ideas weren't immediately accepted by Kwin. I hope it turns into the former even though it's starting out as the latter.
4 Likes, Who?
Mohandevir Apr 16, 2020
Does it means that Valve is planning on using KWinFt at some point? SteamOS Clockwerk? Gamescope?
1 Likes, Who?
no_information_here Apr 16, 2020
This looks interesting. I hope his ideas can be rolled back in to KWin once the project is mature.
Does it means that Valve is planning on using KWinFt at some point? SteamOS Clockwerk? Gamescope?That was a question that jumped out to me, as well.
2 Likes, Who?
Does it means that Valve is planning on using KWinFt at some point? SteamOS Clockwerk? Gamescope?
didnt valve do something for KDE and VR?
0 Likes
TheRiddick Apr 17, 2020
in which millennium will NVIDIA drivers properly support Wayland?
0 Likes
in which millennium will NVIDIA drivers properly support Wayland?
Never. Seriously, if you care about modern Linux desktop it's long past due to ditch Nvidia for good :)
5 Likes, Who?
Ah that sounds good. KWin has a long list of outstanding issues which are difficult or near impossible to solve without breaking something. So making this fork sounds good to me, and Roman is one of the main guys behind KWin, so everything is fine.
2 Likes, Who?
The previous maintainer of KWin, Martin Flöser, has written a blog post about the fork, for those that are interested.
3 Likes, Who?
An experimental branch that tests things out before they get polished and moved upstream would be great. This, though, sounds like someone just got grumpy that their "revolutionary" Wayland ideas weren't immediately accepted by Kwin. I hope it turns into the former even though it's starting out as the latter.
I doubt that. Roman for sure wasn't happy with the development process of KWin, wanting a faster pace of development with less stakeholders (and there are quite a few in KWin), and without a fork it probably hardly would be used and tested.
It's a fork to get a different development model, which can disrupt things and make things not work. KWin with the focus on reliability hardly can do that. Though, that certain improvements once stable enough can find their way back to KWin. Wonder how complicated that'll be...
0 Likes
I personally find a quick iterating fork an acceptable method, when the main project has so many constraints that it slows down progress by months if not years in introducing new features or major bug fixes.
Also, huge dependency on Qt that Roman pointed out is a major problem.
I don't think the intention is to keep this fork separate forever. Once it matures, it can replace the original KWin if the upstream of course agrees on that.
Last edited by Shmerl on 17 April 2020 at 3:00 pm UTC
Also, huge dependency on Qt that Roman pointed out is a major problem.
I don't think the intention is to keep this fork separate forever. Once it matures, it can replace the original KWin if the upstream of course agrees on that.
Last edited by Shmerl on 17 April 2020 at 3:00 pm UTC
3 Likes, Who?
I feel like we have some preconceptions of what a fork is for, which is colouring the discussion a fair bit. We mostly see them in the context of severe developer disagreement or actual project death. In this case I don't see an issue with a fork, since the fork isn't really competing with KWin proper, from the description it sounds like they want to code fast and break often in order to pursue progress. It probably could have lived as a branch in the main KWin development tree but that would either limit the ability for users to test it or you would end up in a situation where the branch is a de facto fork except without its own repository.
I do naturally hope that any usable improvements get picked up by KWin and the two projects merge back together when the goals of the fork have been achieved.
I do naturally hope that any usable improvements get picked up by KWin and the two projects merge back together when the goals of the fork have been achieved.
6 Likes, Who?
Hey guys,
thanks for your interest in the project. So as I'm a gamer myself one thing I also want to aim for with KWinFT is to make the gaming experience in its Wayland session really top-notch.
I did work on that in the past already so it is normally usable nowadays without major issues but I want to really polish it out over time.
So it would be cool, even when you don't normally use KDE Plasma, if you could try it out from time to time and report any issues you might experience at https://gitlab.com/kwinft/kwinft/-/issues.
For example I found out when I played some SoSe recently that right-click-panning doesn't work on Wayland.
There are for sure more such small issues so getting in feedback on that from many people would be super helpful.
Thanks,
Roman
Last edited by subdiff on 17 April 2020 at 7:11 pm UTC
thanks for your interest in the project. So as I'm a gamer myself one thing I also want to aim for with KWinFT is to make the gaming experience in its Wayland session really top-notch.
I did work on that in the past already so it is normally usable nowadays without major issues but I want to really polish it out over time.
So it would be cool, even when you don't normally use KDE Plasma, if you could try it out from time to time and report any issues you might experience at https://gitlab.com/kwinft/kwinft/-/issues.
For example I found out when I played some SoSe recently that right-click-panning doesn't work on Wayland.
There are for sure more such small issues so getting in feedback on that from many people would be super helpful.
Thanks,
Roman
Last edited by subdiff on 17 April 2020 at 7:11 pm UTC
6 Likes, Who?
There are for sure more such small issues so getting in feedback on that from many people would be super helpful.
Thanks for trying to accelerate things and keeping gaming in mind!
I'll surely try testing it. How is subsurface clipping faring in KWinFT? That's the major issue that was blocking me from switching to Wayland Plasma session. Another one is lack of adaptive sync, but that was more of an uptream Wayland issue.
Looks like there is some progress on it, but it's slow: https://gitlab.freedesktop.org/wayland/wayland/issues/84
Last edited by Shmerl on 17 April 2020 at 7:36 pm UTC
1 Likes, Who?
There are for sure more such small issues so getting in feedback on that from many people would be super helpful.
Thanks for trying to accelerate things and keeping gaming in mind!
I'll surely try testing it. How is subsurface clipping faring in KWinFT? That's the major issue that was blocking me from switching to Wayland Plasma session. Another one is lack of adaptive sync, but that was more of an uptream Wayland issue.
Looks like there is some progress on it, but it's slow: https://gitlab.freedesktop.org/wayland/wayland/issues/84
I'm not aware at the moment of any specific subsurface clipping issues, but the last state I know of was that the subsurface implementation in Scene is still somewhat broken. I plan to look at this at some point in the future but it is at the moment not on my priority list, sorry. I would still urge you to open a ticket for it if you experience it when you test KWinFT. I will shift my priorities depending on how many people "like" issues.
Adaptive Sync is something I'm following passively at the moment until I find time to go in depth. I have a nice 144Hz FreeSync2 monitor standing around here, so I also have a personal interest in making this happen. :D
3 Likes, Who?
I'm not aware at the moment of any specific subsurface clipping issues, but the last state I know of was that the subsurface implementation in Scene is still somewhat broken.
<...>
Adaptive Sync is something I'm following passively at the moment until I find time to go in depth. I have a nice 144Hz FreeSync2 monitor standing around here, so I also have a personal interest in making this happen.
Thanks!
The upstream issue for subsurface clipping is here: https://bugs.kde.org/show_bug.cgi?id=387313
And also some thread here: https://phabricator.kde.org/T10530
From the comments, it sounded like as serious issue that needed a deep redesign, rather than a minor fix.
I'll check how KWinFT compares in this regard and if anything is similarly broken, I'll open a separate ticket for it.
Last edited by Shmerl on 17 April 2020 at 8:07 pm UTC
1 Likes, Who?
Patreon
PayPal
See more from me