Weston Might Move To 4 Month Releases While Wayland's Maturity May Stop Timed Cycles

[R41N3R]

well your second phrase is interesting, beacuse if wayland devs did really put much thought then desktops would have reached feature parity with Xorg, none has done that yet, gnome is the closest, but for example (and there are more) i cant run any app that doesn't support my current resolution, this matters for old games especially under wine, i think the problem is that wayland is designed for developers and not for end users, gparted not running because the root thing is another example

Are you sure your critic is really regarding Wayland? By reading your post it seems like most of the issues are Gnome issues. I use Plasma-Wayland since more than one year and for me it is really stable and I don't see the same issues there. Issues do exists, but not really more than with X11. Missing functions like remote desktop and screen recording are addressed now as well. What's not working well at the moment are games, XWayland introduced with xorg 1.20 several new bugs with fullscreen apps (e.g. crashes in F1 2017) and then the input doesn't work well (e.g. in Rise of the Tomb Raider, Tomb Raider or Ballistic Overkill), sometimes the mouse jumps or the cursors seems to be blocked, but I don't think this is the fault of Wayland itself.

[kaprikawn]

well your second phrase is interesting, beacuse if wayland devs did really put much thought then desktops would have reached feature parity with Xorg, none has done that yet, gnome is the closest, but for example (and there are more) i cant run any app that doesn't support my current resolution, this matters for old games especially under wine, i think the problem is that wayland is designed for developers and not for end users, gparted not running because the root thing is another example

Rome wasn't built in a day. Nobody (sane) will argue that Wayland currently has feature parity with Xorg. But the list of features it's lacking is dwindling constantly. So just because it isn't ready now, that means it's worthless? If it doesn't do something like play old games, just use Xorg for now.

[kaprikawn]

major question concerns with the inability of the several operating systems' developers to implement wayland because of their incompetence and their laziness

Wayland isn't ready yet, and some DE devs might just not want to implement it yet. Take Cinnamon for example, it is the standard DE for Mint which is a very conservative distribution. People who run Mint don't want to be dealing with issues related to cutting edge software, they want it to just work. For them, Xorg is the obvious choice right now. Whereas Fedora is a testing ground for the latest software, and therefore it was no surprise it was the first fixed-release distro to have Wayland by default.

If the DE dev team isn't corporate sponsered, I think it's a bit rough to call them incompetent and lazy. If they're donating their free time you can't expect them to support something which doesn't even have feature parity with Xorg yet. I have a Wacom tablet, and it didn't work on Wayland until Xorg 1.20 was released very recently because of an issue with XWayland. This is one bug amongst many, and I'd expect to run into stuff like that on Fedora (or Arch which is what I'm on), but if I plug my tablet into a machine running Mint, I'd expect it to work.

[davidbepo]

That's by design, they chose it to be that way (do one thing and do it well...). And by they, I mean the Wayland devs who were Xorg devs and know all the problems with Xorg. Xorg is broken by design at this point. It may work and is convenient, but it's horribly insecure, dated and bloated. It has no business being the unpinning of a modern Linux desktop.

When people critisize Wayland, they talk as if the Wayland devs didn't put much thought into everything and just made it up as they went along.

well your second phrase is interesting, beacuse if wayland devs did really put much thought then desktops would have reached feature parity with Xorg, none has done that yet, gnome is the closest, but for example (and there are more) i cant run any app that doesn't support my current resolution, this matters for old games especially under wine, i think the problem is that wayland is designed for developers and not for end users, gparted not running because the root thing is another example

[kaprikawn]

this is the problem with wayland EVERYTHING has to be implemented by the compositor...

That's by design, they chose it to be that way (do one thing and do it well...). And by they, I mean the Wayland devs who were Xorg devs and know all the problems with Xorg. Xorg is broken by design at this point. It may work and is convenient, but it's horribly insecure, dated and bloated. It has no business being the unpinning of a modern Linux desktop.

When people critisize Wayland, they talk as if the Wayland devs didn't put much thought into everything and just made it up as they went along.

[davidbepo]

I was ready to agree with your comment right until I saw your suggestion to use effectively dead project as a stop gap solution. That is purely retarded IMHO.
What we actually need is unifying library on top of wayland which would make writing compositors easier.
Something like wlroots, but actually stable (both API-wise and code quality wise) and working well (even with nvidia).

https://github.com/swaywm/wlroots

mir is not anywhere near dead

[tildearrow]

Yeah, with Mir it's much better 'cause it's a very great idea to run a compositor (any) on top of an abstraction layer (Mir) on top of a protocol (Wayland)!

Why can't people say exactly this but for Sway?

Yeah, with wlroots it's much better 'cause it's a very great idea to run a compositor (Sway) on top of an abstraction layer (wlroots) on top of a protocol (Wayland)!

(or is wlroots not an abstraction layer?)

[tildearrow]

this is the problem with wayland EVERYTHING has to be implemented by the compositor, leading to duplicated work and a lot of issues that didnt happen in X, using mir as an abstraction layer might improve this

That's because Wayland is just a protocol.

The same would apply to X11, but since X.Org is there, nobody is willing to create another X server.

(P. S.: I am actually worried that Wayland was created so people complain about this issue, and eventually Red Hat will propose a solution, and that solution is that GNOME/Mutter becomes the only Wayland-implementing compositor/desktop... )

[Vistaus]

this is the problem with wayland EVERYTHING has to be implemented by the compositor, leading to duplicated work and a lot of issues that didnt happen in X, using mir as an abstraction layer might improve this

Yeah, with Mir it's much better 'cause it's a very great idea to run a compositor (any) on top of an abstraction layer (Mir) on top of a protocol (Wayland)!

[oiaohm]

How about features like screen recording, screen sharing and so on? That shouldn't be left up to compositors to design, but should be based on some standard Wayland features (protocol extensions or what not). That's what's very much lacking and causing a lot of pain for compositors developers who need to come up with incompatible solutions, which results in even bigger pain for end user applications developers who can't make their applications work across multiple Wayland compositor cases.

Screen recording comes very hard where should it be implemented. Should it be in KMS/DRM should it be Video 4 Linux. Screen sharing is the same problem. This feature really should not be based in wayland protocol.

Next question is a good one why are compositors implementing features they have not submitted to the reference implementation?????????

https://github.com/krh/weston/blob/m...s/screenshot.c << Like there is a screen shot feature in the reference implementation. Remember if you implementation does not perform like the reference implementation its broken.

Reality here the fact each compositor maker is taking their own path is totally invalid and is totally disrespecting the role of a reference implementation. We have seen the same thing with X11 and Opengl over the years. Heck how often wine project has an X11 WM fall over dead just because it asked the WM to do something exactly to X11 reference implementation and specifications.

Yes failure to understand Protocol and Reference implementation. General rule reference implementation exists its you gold standard ahead of protocol. Protocol is just general guidance.