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

[oiaohm]

Sorry but you're missing the mark here. The point is that Wayland misses a TON of actually useful features from X11, with the excuse that it's the compositor's job to implement them.

This is a bad thing for application DEVELOPERS, not necessarily users of said compositor. If they want to use a feature in compositor ABC, they will be bound to compositor ABC for it. What if another compositor implements the same feature but in a different way? Now you need two different code paths in your app to deal with both compositors. What if in the future there will be another compositor but you got sick of working on your app (which is now in a finished state) and work on something else entirely (another app maybe)? Now you need to update it to work with the new compositor, just because there is no standard, backwards-compatible protocol..

Even the X11 protocol does not cover all stuff you are talking about. http://www.jcraft.com/weirdx/ Try some of the side X11 servers some time and learn a few things. You have got use to everything using x.org X11 server.

Yes X11 servers do implement feature differently like it or not. Current compositors are no different, Wayland is the wire protocol between client and server. Weston is reference implementation and its the reference implementation with X11 that stabilised it behaviour not the X11 protocol. If you compositor behaves to an application different to Weston is defective. As yet we do not have solid conformance suite this is how Vulkan and Opengl does it. Basically we need weston go grow a conformance suite.

[shmerl]

Its important to understand the split between weston the reference implementations also the project that provides the generic abstraction layer then you have the protocol wayland. Protocol wayland is getting fairly closed to complete so they are talking about slowing down updates. The abstraction layer libweston and the reference compositor needs more work.

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.

instead of having all of it bundled into Wayland itself directly?

Wayland defines protocols, it's not providing their implementation on the compositor side. You aren't viewing Wayland in the manner of what it is.

[Weasel]

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

But that's the thing. What is the point of having a "standard" library on top of Wayland that "everyone should use" (to reduce fragmentation) to provide much needed features, instead of having all of it bundled into Wayland itself directly?

[crazyloglad]

Replacing X11 is with the difficult of managing legacy and migration from legacy - Apple level of skills are needed there. The actual technical parts in how clients interact with the display server isn't unless you chose to ignore almost all prior work on it. Whatever the extent you need a protocol (locally, you don't... windows, osx and android are all better off for not having one), there are many competent alternatives that predates Wayland - Including Quamranet/RedHat's own SPICE. Anything that fulfils the criterion for a remote desktop protocol is obviously a potential building block for a protocol.
Wayland devs should have a ton of credit, rewards and back-patting for the work done decoupling drivers from Xorg, just none for the protocol itself.

[Weasel]

Can I make up a protocol that does absolutely nothing and delegate everything to the compositor and call it a success? I mean, since it has no bugs and all and no unnecessary features because they will all have to be implemented in the compositor.

This is 100% not true. There 1 part true and most of it bogus idea..
https://www.phoronix.com/scan.php?pa...KMS-Progress-1
Not everything has to be implemented by the compositor. As the Virtual KMS is showing some things need to be rethought.

Also you have libweston
https://www.phoronix.com/scan.php?pa...and-Compositor
Result of libweston is that each wayland compositor does not need to duplicate everything. So there is already an abstraction layer.

Its important to understand the split between weston the reference implementations also the project that provides the generic abstraction layer then you have the protocol wayland. Protocol wayland is getting fairly closed to complete so they are talking about slowing down updates. The abstraction layer libweston and the reference compositor needs more work.

Yes with wayland everything has to be implemented by the compositor since it only a protocol it does not forbid a compositor using a common library to implement most of wayland. Using a library means most of the duplicated work with wayland is totally optional and the duplicated work is caused by a implementation not using libweston. Of course someone could choose to write X11 server or mir from scratch as well if they have determination to duplicate work.

People forgot at one point of history there were 20 different implementations of the X11 server.

Sorry but you're missing the mark here. The point is that Wayland misses a TON of actually useful features from X11, with the excuse that it's the compositor's job to implement them.

This is a bad thing for application DEVELOPERS, not necessarily users of said compositor. If they want to use a feature in compositor ABC, they will be bound to compositor ABC for it. What if another compositor implements the same feature but in a different way? Now you need two different code paths in your app to deal with both compositors. What if in the future there will be another compositor but you got sick of working on your app (which is now in a finished state) and work on something else entirely (another app maybe)? Now you need to update it to work with the new compositor, just because there is no standard, backwards-compatible protocol.

This is why stuff like this has to be in the PROTOCOL itself, so that a STANDARD WAY to get access to that feature is done. Developing for these features is a massive pain in the ass for Wayland, end of story.

I mean, dude, it's like saying we don't need OpenGL or Vulkan, they have too many features, just code directly for the graphics card in question! This way it doesn't have "unnecessary features"? wtf. The protocol's job is to abstract away so that these features are accessible in a standard and backwards compatible manner. If a new graphics card is released, your app written for Vulkan will still work, because it's in the protocol. If a graphics card wants to advertise itself as Vulkan capable, it will have to adhere to that protocol.

That's why if someone makes a different implementation of X11, he will have to implement the whole protocol if he wants it to actually be X11 and not something else. And apps written for X11 will "just work". On the other hand with Wayland a compositor isn't required to use a standard protocol to implement a feature Wayland misses.

[oiaohm]

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

Its not easy process. Does not help with Nvidia being late to say GBM will not work.

It's definitely a problem, though it's hard to find "the" problem, there are many. I have thus far avoided doing any real kind of technical posts on the matter (current notes would put it into the ten-thousand-word range and my patience is running thin), but really - the technical underpinnings are *extremely* shaky, the ecosystem scattered, fragmented and incomplete thanks to the 'extensions and community will fix things' and as a dev, it is extremely frustrating to use. The issues highlighted by the WLC dev before he quit ( https://github.com/Cloudef/orbment/i...ment-227720157 ) just scratches the surface.

https://lists.freedesktop.org/archives/wayland-devel/2018-March/037610.html

Fragmented is a big problem. Input under X11 was very fragmented in configuration. Moving that it libinput is taking some time. Yes issue list from 2016 some of the issues are gone but others still need work.

Replacing X11 is not an easy process. The need to add to protocol coming to end now opens up path to focus on generic configuration options and the like.

[oiaohm]

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

This is 100% not true. There 1 part true and most of it bogus idea..

https://www.phoronix.com/scan.php?page=news_item&px=VKMS-Virtual-KMS-Progress-1

Not everything has to be implemented by the compositor. As the Virtual KMS is showing some things need to be rethought.

Also you have libweston

https://www.phoronix.com/scan.php?page=news_item&px=Wayfire-Wayland-Compositor

Result of libweston is that each wayland compositor does not need to duplicate everything. So there is already an abstraction layer.

Its important to understand the split between weston the reference implementations also the project that provides the generic abstraction layer then you have the protocol wayland. Protocol wayland is getting fairly closed to complete so they are talking about slowing down updates. The abstraction layer libweston and the reference compositor needs more work.

Yes with wayland everything has to be implemented by the compositor since it only a protocol it does not forbid a compositor using a common library to implement most of wayland. Using a library means most of the duplicated work with wayland is totally optional and the duplicated work is caused by a implementation not using libweston. Of course someone could choose to write X11 server or mir from scratch as well if they have determination to duplicate work.

People forgot at one point of history there were 20 different implementations of the X11 server.

[crazyloglad]

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

It's definitely a problem, though it's hard to find "the" problem, there are many. I have thus far avoided doing any real kind of technical posts on the matter (current notes would put it into the ten-thousand-word range and my patience is running thin), but really - the technical underpinnings are *extremely* shaky, the ecosystem scattered, fragmented and incomplete thanks to the 'extensions and community will fix things' and as a dev, it is extremely frustrating to use. The issues highlighted by the WLC dev before he quit ( https://github.com/Cloudef/orbment/i...ment-227720157 ) just scratches the surface.

[Azrael5]

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

[davidbepo]

Wayland mature? But it can't even do[list of stuff that should be handled by the compositor...] yet!

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