Sway's wlroots Lands Initial Vulkan Renderer

[boxie]

When one "reinvent the wheel", the rationale behind is usually that the old wheel is too old and can't support new hardware / software feature cleanly anymore. What end up in Wayland is... this reinvented wheel is still clunky to support new hardware / software feature. It is still impossible to render a surface natively that overlap displays with mixed pixel density / color space / refresh rate. Also no native support of fractional scaling.

On the security aspect, I heard they still haven't completed native support of IME, which is essential for East-Asian text input.
p.s. There are supports adding to it, but various issue can occur.

<pedantic>Wayland itself is a set of protocols</pedantic>
Yes, we have a lot of new project implementing the same thing - strangely this is a good thing as you end up figuring out where different people want to go.

Sometimes rebuilding something is better as you do not have to drag (in this case 30+ years of) legacy around with you.

[boxie]

Honestly yes. I mean, I just want a fully featured & functioning display server, which X is, and no wayland compositor provides this, I'm even questioning if wayland is ready to support this in the first place by now.

Wayland's entire design philosophy is literally: That's the compositor's problem.

(And it's not fucking working)

Gnome is has been using its Wayland compositor by default for a long time now (>1 year) and as of the recent Plasma 5.23 it's pretty solid. 2 Major DE's.

But yes, it has taken a looooooooong time

[oiaohm]

On the security aspect, I heard they still haven't completed native support of IME, which is essential for East-Asian text input.
p.s. There are supports adding to it, but various issue can occur.

https://wiki.archlinux.org/title/fcitx

https://wiki.debian.org/I18n/Fcitx5

The reality here is a lot worse. XIM under X11 when using Qt and GTK applications don't use this any more instead are after a direct IM module.

The reality is X11 server native IME support(XIM) is basically being bypassed even under X11. So IME makes no sense to be part of Wayland protocol any more.
The replacements to XIM want to use dbus as their core IPC.

Honestly yes. I mean, I just want a fully featured & functioning display server, which X is, and no wayland compositor provides this, I'm even questioning if wayland is ready to support this in the first place by now.

Wayland's entire design philosophy is literally: That's the compositor's problem.

This is in fact wrong.

https://wayland.freedesktop.org/docs/html/

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a Wayland client itself.

Wayland protocol is only for the compositor part of a display server. IME like fcitx for example this is not something that part of the compositor.

There are lot of parts that were part of the X11 server like XIM that end up no longer used. So there are lot of items that make no sense to be part of Wayland compositor at all.

X11 server has a lot functionality that when you look closer modern applications just straight up bypass instead use dbus instead.

rabcor have you asked yourself the question if the features you except in a fully featured & functioning display server should be in a fully featured & functioning display server. I bet you have not asked the question if those features should be in a protocol for a compositor either or if they should be dbus based so be generic between X11 and Wayland.

Weston the reference wayland compositor/display server combination uses Wayland Protocol and Dbus protocol (yes a stack of different dbus standards with the biggest being xdg-desktop-portal).

Reality here is not everything that a display server should do owns in the Wayland protocol because that a protocol for compositors. Quite a bit of what a display server is owns in what should be dbus standards that are universal between Wayland and X11 desktop environments..

[rabcor]

Gnome is has been using its Wayland compositor by default for a long time now (>1 year) and as of the recent Plasma 5.23 it's pretty solid. 2 Major DE's.

But yes, it has taken a looooooooong time

Last I checked, plasma couldn't even run properly on wayland, it only has partial wayland support, if you try to launch it in 'full wayland' mode, things go to shit, or at least that's how it was maybe half a year ago.

And just because Gnome uses wayland by default does not mean wayland is ready, it just means that the gnome devs are still masters of bad decisionmaking.

rabcor have you asked yourself the question if the features you except in a fully featured & functioning display server should be in a fully featured & functioning display server. I bet you have not asked the question if those features should be in a protocol for a compositor either or if they should be dbus based so be generic between X11 and Wayland.

I'm an end user, I literally couldn't care eless about all this shit, I just want my display server/compositor/whateverthehellyouwanttocallthegui to work, and work well, and not be missing important features. And all wayland compositors are missing important features that wayland should be providing but isn't providing, because indeed, they should not be part of a compositor, they should be a part of the display server, but wayland is a protocol and it is meant to be used to run compositors without any display server so many features that should belong in the display server are just ignored.... And the compositor devs will say: Wayland devs should add this. And wayland devs will say: Compositor devs should add this.

Thus nothing gets done and everything remains broken, I don't give a shit where the feature should be, only thing I care about is that I can use my PC normally and wayland, or indeed, any wayland compositor, all have too many important features missing.

So no, I have not asked myself this question, it is irrelevant to me.

[Danny3]

So in the future we could possibly just switch Kwin with KWinFT and have KDE Plasma powered by a Vulkan renderer ?
That would be awesome !
I can't even imagine how cool this would be on low-power devices like Raspberry Pi which keeps having better Vulkan support.

[oiaohm]

I'm an end user, I literally couldn't care eless about all this shit, I just want my display server/compositor/whateverthehellyouwanttocallthegui to work, and work well, and not be missing important features. And all wayland compositors are missing important features that wayland should be providing but isn't providing, because indeed, they should not be part of a compositor, they should be a part of the display server, but wayland is a protocol and it is meant to be used to run compositors without any display server so many features that should belong in the display server are just ignored.... And the compositor devs will say: Wayland devs should add this. And wayland devs will say: Compositor devs should add this.

Thus nothing gets done and everything remains broken, I don't give a shit where the feature should be, only thing I care about is that I can use my PC normally and wayland, or indeed, any wayland compositor, all have too many important features missing.

So no, I have not asked myself this question, it is irrelevant to me.

Because you have not asked the questions you have not worked out that particular features should not be part of a display server either. IME its not part of wayland protocol because it makes no sense to part of the Wayland protocol. IME also turns out not make sense to part of X11 server either. Instead it makes sense to be part of application toolkits and to be handled by dbus and this is even under X11.

Notice you said "whateverthehellyouwanttocallthegui" the reality is there is no name for the complete thing even in a X11 solution.

Like under X11 you have the Display server that is X11 server, You have the X11 compositor, You have Windows manager, You have desktop environment then you have your IME stuff then you accessibility stuff.... Stack of different parts that have to work with each other.

Did the reality of a stack of different parts providing different things having to work with each other change when we move to Wayland the answer is yes but it still a stack of different things provided by different parties that have to work with each other. Each area is responsable for it own set of problems.

The reality is like it or not the is not there has never been a single party responsible for everything.

And the compositor devs will say: Wayland devs should add this. And wayland devs will say: Compositor devs should add this.

This is not how it going wrong. End user goes to Wayland developers asking for X feature they respond this does not own in Wayland protocol. End users goes to wayland compositor groups asks for X feature they respond this does not own in Compositor. Now they stupid argue with both Wayland protocol and the parties making wayland compositors believing that one of those parties have to be responsible for the feature they want even that both have told them no they are not. This happened with screen capture and many other features. Question where did screen capture in fact own that right over in a dbus protocol standard the xdg desktop portal https://github.com/flatpak/xdg-desktop-portal

Lot of cases people are attempt to demand that people implement features where they do not belong and then wonder why they are not getting anywhere.

rabcor see the problem now lot of people are like you who incorrectly presume the has to be name that covers the complete Linux desktop environment not willing to see its a fragmented system with no single name.

Remember features are done in dbus are generic between X11 and Wayland solutions as well. So do we really want to duplicate the wheel.

Rabcor something you have missed about Wayland protocol as well. Take sway/gnome/kde... all compositors are allowed by Wayland protocol to implement any draft Wayland protocol extension they like once they prove the idea works then submit this draft protocol up to Wayland protocol standard for review for include. So that idea that Compositor developers have to get Wayland core developers approve to implement anything is bogus. So yes wayland developers can say that want to see a draft implementation in compositor to prove that the idea is valid.

Then the compositor developers can say it makes absolutely no sense and they will only implement if someone else successfully gets it added to the core wayland protocols. When the compositor developers are point back to the main Wayland protocol they are in fact saying no this does not make sense. Of course if the wayland compositor developers say X feature makes no sense next stop should be dbus protocols.

[rabcor]

I can tell you're not wrong, but I still blame the wayland devs. Wayland has been pushed as an alternative/replacement for X, but it fails to provide critical features that X has. Sure, when these features can be implemented in a way that is agnostic of whtehre you use X or Wayland, like with dbus, that's great.

But the reality is, 13 years we've had, and a lot of these critical features have not been implemented by dbus or anyone else yet.

So you know what maybe you're right yeah, the wayland protocol's philosophy is not inherently wrong, but it's an incomplete solution, and the wayland devs are unwilling to step up and complete it.

The wayland project is apparently just some people deciding that the way X does thingsis not good enough; creating partial functionality for some aspect of X and then leaving pretty much everything else undeveloped.

They then claimed to provide an alternative to X (In their words: "Wayland is intended as a simpler replacement for X, easier to develop and maintain."), but they failed to provide a complete alternative, they really just provided an alternative to a small part of X, and whenever anyone complains about missing features in their alternative to X they point fingers, usually towards the compositor devs; to avoid taking any sort of responsibility for their own claims.

The only people I can respect in all this are the sway devs who have actually been trying to turn wayland into something usable. Everything besides sway and their other projects like wlroots surrounding wayland is a huge clusterfuck of disappointments, that includes libinput.

The wayland devs have a vision but no drive to actually see it through. They just did one small part, then hope all the heavy lifting gets done by others. There's nothing stopping the wayland devs from starting up their own dbus like projects or joining existing ones to implement functionality that completes wayland. But that's not what they did, apparently.

[oiaohm]

I can tell you're not wrong, but I still blame the wayland devs. Wayland has been pushed as an alternative/replacement for X, but it fails to provide critical features that X has. Sure, when these features can be implemented in a way that is agnostic of whtehre you use X or Wayland, like with dbus, that's great.

Except there is one big problem. https://people.freedesktop.org/~dani...ayland-x11.pdf The reality here is the Wayland developers themselves never in fact pushed Wayland as a replacement to X. As an alternative has very different meaning. Remember as alternative you are not required to implement every single feature the prior solution had. Wayland was to rebuild the core without hugh stack of critical design flaws. That has been successfully completed with wayland.

But the reality is, 13 years we've had, and a lot of these critical features have not been implemented by dbus or anyone else yet.

No dbus is not a single group. dbus is a IPC protocol. xdg desktop portal that is linked to flatpak work is one of the groups making standards for dbus. Yes 13 years we have had people attempt to implement different features using wayland protocol/IPC where it don't fit and then not be interested in attempting a dbus solution.

Also you will normally be surprised how many so called critical features when you go looking in KDE and Gnome and other parties you will find prototype forms based on dbus. This is of course more of a case how to get KDE/Gnome/... in the same room and sit down and write a common protocol. Like KDE has it own dbus protocol for global shortcuts this would of course be good as a generic no matter the desktop dbus protocol. The reality here if you truly go properly looking at what has been implemented you will find that most of course so called critical features have been implemented by someone and tested to work over dbus. Problem is lack of standardisation.

So you know what maybe you're right yeah, the wayland protocol's philosophy is not inherently wrong, but it's an incomplete solution, and the wayland devs are unwilling to step up and complete it.

Like it or not the feature you will be asking for was never in the Wayland developers objectives. X11 was also a incomplete solution that stuff just keep on getting bolted on until it was a totally broken mess.

The only people I can respect in all this are the sway devs who have actually been trying to turn wayland into something usable. Everything besides sway and their other projects like wlroots surrounding wayland is a huge clusterfuck of disappointments, that includes libinput.

Gnome and KDE have also played their parts in testing out the standard. Please note libinput was added to x.org X11 server before it was added to wayland. Yes libinput first started as attempt to fix the major broken X11 input stack.

The reality is like or not the people you are blaming in most cases are not the people are truly responsible. Like it or not clusterfuck is exactly how X11 protocol has been.

Part of fixing this problem is stop blaming the Wayland developers and instead be up the ribs of KDE/Gnome/... that they have to get out of the historic problem of developing solutions only for their desktop environments and start working on shared solutions.

Please note fragmentation dbus protocols under Gnome/KDE/other desktop environments exists under X11 and Wayland this is not a Wayland unique problem.

Its really easy to yell at the Wayland developers and fail to see that majority of the problem also exists under X11 as well so is not only the Wayland developers problem.

[bearoso]

Like under X11 you have the Display server that is X11 server, You have the X11 compositor, You have Windows manager, You have desktop environment then you have your IME stuff then you accessibility stuff.... Stack of different parts that have to work with each other.

I was just theorizing a definitive compositor. Writing a compositor is difficult. We have a definitive input library, libinput, so that's handled. But as billyswong said, things like mixed pixel density, color space, refresh rate, fractional scaling--these are complicated display issues which need experts to do properly. At this point, even just swapping buffers smoothly and getting clients to update in sync is failing. I can't count the number of times I've been frustrated at the Mutter issue tracker when I see something that is being done with complete naivety, and I'm certainly no expert.

I'm reminded of when Windows switched to a compositor, and they went through all the same teething problems. It's only with WDDM 3.0 in Windows 11, barely released, that they got all of those ironed out. We're about Windows 7 level at this point.

For me, the biggest thing keeping me from switching is that nobody updates the mouse cursor asynchronously, adding at least a frame of latency. Use the hardware overlay plane and a separate thread to handle input events! This is the primary method of interaction with the display 90% of the time, and they won't prioritize it.

[doomie]

The reality here if you truly go properly looking at what has been implemented you will find that most of course so called critical features have been implemented by someone and tested to work over dbus. Problem is lack of standardisation.

So your main point of disagreement is whom to blame. Might I point out that even if the Wayland devs haven't pushed Wayland as a replacement for X, practically everyone else does... loudly. End-user (app devs, consumers, etc) perception, experience and responses are kind of expected... Especially if removing even a single function that WAS practically standard, that they expect or relied on.

Part of fixing this problem is stop blaming the Wayland developers and instead be up the ribs of KDE/Gnome/... that they have to get out of the historic problem of developing solutions only for their desktop environments and start working on shared solutions.

Maybe I'm wrong, but KDE seems at least somewhat more capable of this. Gnome, from the top, seems to be very... "streamlined" and "highly-focused." Heh, the default linux desktop. Hecc, their political culture is so streamlined and highly-focused it forgets about software...

Still, one can hope, and for better communication. wlroots is pretty rad thus far.