Very wise, forward looking philosophy and changes... I am feeling very positive about this project. Thanks for all of that work!
Announcement
Collapse
No announcement yet.
KWinFT Lands Code To Now Use WLROOTS For Wayland
Collapse
X
-
Originally posted by avem View PostI'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.
- Likes 6
Comment
-
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.
- Likes 3
Comment
-
Originally posted by curfew View PostI 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...
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.
- Likes 5
Comment
-
Originally posted by avem View PostI'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.
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.
- Likes 1
Comment
-
Originally posted by C8292 View PostThis could be the turning point where KwinFT becomes superior to KDE's kwin.
Originally posted by C8292 View PostMy 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?)
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).
- Likes 3
Comment
-
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.
- Likes 2
Comment
-
Originally posted by curfew View PostI 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...
- Likes 3
Comment
-
Originally posted by kpedersen View PostAgree 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.
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 PostWlroots is just a library (or several). There is a reference Wayland implementation and that is Weston. But it's not reusable.
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 PostX has that server which is the reusable part (technically, you can find more servers, but really there's a de-facto standard).
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.
- Likes 1
Comment
Comment