When will Wayland be finished and replace X11? Why aren't apps switching to native Wayland support?

>GNOME and KDE
so when are DEs that aren't shitheaps going to adopt it?

>When will Wayland be finished and replace X11?
Sometime between never, and never ever.
The core protocol is done, as per but it's useless in itself because it lacks most of basic desktop features like taking screenshots, color pickers, and so on.
Each compositor has to implement the above themselves, so that just increases fragmentation.
But it's new, so it must be better. Reddit told me so!

Then pay someone.

>It's bad because a different post on Reddit told me so!
All the major compositors already support taking screenshots and color pickers.

why are you using linux if you dont know how to program

>All the major compositors
So GNOME and KDE, and KDE still sucks on Wayland (I know, I tried).
And the problem is not that they can not, but that it's NOT IN THE STANDARD, and each of them implemented it in a different incompatible way.
If you want an external application that does screenshots, then it has to understand ALL the APIs, or else it won't work on, for example, GNOME desktop under Wayland.
That's the problem Wayland evangelists don't want to acknowledge.

You are wrong, they both use xdg-desktop-portal. Any application that uses that will work in both. And even if that wasn't the case, certain things not being in the core protocol is a feature, not a bug. Protocol extensions that everyone reaches consensus on end up in the wayland-protocols package. There are already a lot of things in there that both the KDE and GNOME compositors should support. If it's not in there then that means not everyone has agreed on it yet.

>Yet

We all know freetards never agree on anything.

I urge you to look in the /usr/share/wayland-protocols folder just to see all the things people have already agreed upon. The desktop portal isn't in there because it's actually not a wayland protocol, it's done over d-bus and pipewire.
>freetard
I don't know what this is supposed to mean.

>certain things not being in the core protocol is a feature
Like screenshots, screen recording, color pickers, redshift, remote login a-la VNC/RDP, etc.
How fortunate are we to not have all those dreadful things every other windowing system had for decades.
>Protocol extensions
Oh right, because extensions will fix everything ever. How is that different from X?

All of those things are nice, but are not required to have a desktop. That's why they're extensions. They are supported already in all the major compositors anyway.

>How is that different from X?
It's different because MORE things are made into extensions, not less. That's good if you want the option of a minimal system using only what you need.

>but are not required to have a desktop
I would argue they are required. This isn't the 80s where color display was a luxury.
In 2019, and even 2009 when Wayland originally started those were commonplace. No reason to leave them out except for the usual "let's reinvent X from scratch but let someone else worry about the hard parts".
>It's different because MORE things are made into extensions, not less.
That sentence doesn't make any sense whatsoever.
>That's good if you want the option of a minimal system using only what you need.
And this is somehow impossible with X11?
Actually, 90% of what you do with X11 today is an extension. The current rendering pipeline is an extension. A lot of the original parts don't even work properly anymore as the code has rotted so much because it wasn't used in decades.

Wayland is like those github project that only have a readme and expect people to commit the solution, imagine reading and XML file and then be so retarder to implement their idea... At that point just build you own Window Manager ups I mean just a protocol WM.

Sorry but those things aren't required for a desktop. All you technically need for a desktop is windows and a mouse pointer. Everything else is highly up to the user's preference. You seem to be under the impression that the developers were trying to fuck you over personally by not including 1000000 features in their protocol, which makes absolutely no sense. Especially since those features are all supported by now anyway.

>That sentence doesn't make any sense whatsoever.
What don't you understand? With X, the network transparency and drawing APIs were required. In Wayland this has all been made optional (through XWayland).

user, someone has to do the work. The code doesn't write itself.

>ll you technically need for a desktop is windows and a mouse pointer.
In other words, let's go redefine what desktop means because we utterly failed in producing one.
No, just no. In the year 2019 making screenshots and recording your screen is considered standard. In fact the latter is the foundation of an entire branch of entertainment industry -> streaming. Color picker is essential for graphic design. And while redshift and bitmap scrapers (VNC) are just conveniences, they are pretty common.
But I guess since you don't need those, nobody else does either. The classic argument from utter stupidity.
>You seem to be under the impression
I am under no impression whatsoever. In fact I don't even use half of those features. But I recognize there are people who commonly use them and so far Wayland has been fucking them over. Not exactly the best thing to do when Wayland is fighting an uphill battle over marketshare, along with the entire Linux desktop.
>Especially since those features are all supported by now anyway.
You're deliberately missing the point, I see. The issue is that they are non-standard.
For example, if Twitch were to produce a streaming app for Linux, they would have to explicitly support every Wayland compositor.
Except they wouldn't, because that's insane. They'd instead support X11 because that still has by far the largest userbase on Linux.
>With X, the network transparency and drawing APIs were required.
They are a very, VERY little part of the protocol. In fact the network transparency flows somewhat naturally from the design itself, to an extent.
Not sure what you're trying to do with this point.
>In Wayland this has all been made optional
Optional as in "it doesn't even exist" save for the compatibility layer with X. Again, what's the point of Wayland if everything worth using is on X anyway?

Probably never because the DEs you believe to not be shitheaps have shitheaps of deprecated X11-dependent components in them

>all this autism
just watch this, fags
youtube.com/watch?v=Zsz7Shbnb9c

> d-bus
Oh man It gets even worse. Now fucking bloated d-bus is required to take screenshots.

Wayland has been perpetually 2 years away from full adoption for about 10 years. It might always remain this way, unless corporations pour manpower and money into it.

But X works "good enough" for a shitty desktop system, and Wayland implementations still have enough bugs that they're pretty much unusable, so we're at this impasse and might be for another decade.

Attached: 220px-Tux.png (220x261, 43K)

>making screenshots and recording your screen, color picker, redshift and VNC
And all of those things are supported already. Let it go.
>streaming, graphic design
Those are not more important than anyone else's use case.
>Wayland is fucking them over even though those features are already included!
Let it go.
>Marketshare
This doesn't apply because there is no market, you paid nothing for it just like you paid nothing for X11.
>The issue is that they are non-standard.
This is a cope.
>if Twitch were to produce a streaming app for Linux, they would have to explicitly support every Wayland compositor.
No, they would not.
>They are a very, VERY little part of the protocol.
No, they are not. You have not implemented an X server.
>Optional as in "it doesn't even exist" save for the compatibility layer with X
First you were complaining about features not being there that were in X, now you're complaining about features existing because they are done with X. Look, I get it. You don't want to switch. Don't. Just keep using X, we don't care. You can do what you want, you can even go use Windows 10.

Also please consolidate your paragraphs next time because the way your post is structured does not lead to cohesive discussion.

The key part is pipewire, not d-bus. If you use GNOME or KDE then d-bus is already required to do a number of other things anyway.

Don't always post this garbage presentation.
The guy talking is wrong on so many levels that it makes your ears bleed.
Wayland offers:
- less features
- more fragmentation
- less performance
- worse latency

Also this libinput thing is the worst garbage I ever encountered. A mouse cursor stuttering or not moving because of high CPU load is just not acceptable in 2019. Even fucking Windows 1.0 did this better.

>When will Wayland be finished and replace X11?
never. you heard it here first lads

>When will Wayland be finished and replace X11?

Ideally never

>Why aren't apps switching to native Wayland support?
Because X11 is better.

I haven't read this thread it's possibly 99% FUD but if you want to know KDE is very understaff for this but they started voting on making a sprint on it
>phabricator.kde.org/T11081
>Finalize the transition to Wayland and embrace the future of desktop
I already use Plasma Wayland it's very smooth. If they manage to speed up and finish it, it will be fucking great.

>And all of those things are supported already. Let it go.
Again, they are not standard, but implemented in mutually incompatible way, and hardly usable for third-party tools.
>Those are not more important than anyone else's use case.
And? Is everyone else's use case diminished by the presence of standardized color picker API?
The mind boggles.
>This doesn't apply because there is no market, you paid nothing for it just like you paid nothing for X11.
I get it now, you are retarded.
>This is a cope.
Dilate.
>No, they would not.
It's an example you git.
>No, they are not. You have not implemented an X server.
They don't need to because an X server has standard interfaces that apply to everything running under it. Unlike Wayland where every compositor is its own thing.
>you can even go use Windows 10.
The classic desperate last stand. Sadly, this won't work on me.

The problem is Wayland is half-baked and lacks standardization of common desktop features. Compositors are therefore forced to design and implement them by themselves, resulting in incompatibilities. This creates problems for third-party tools that either have to spend resources to explicitly support every compositor, or fracture their userbase because they only work on some compositors - both alternatives are moronic. This in turn creates even more balkanization in the Linux desktop.
But you do not want to see reason. So how about you stick with Wayland and see where that gets you?

Learn.

Wayland is a protocol, it doesn't have anything to do with the performance or latency of your compositor. Libinput bugs are also not the fault of the wayland protocol and will also affect Xorg if you use the libinput driver (which I actually believe is the default on many distros at this time)

Most features from X are implemented at this point and are standard protocols in some capacity, so any fears about fragmentation are unfounded. Don't forget about all the craziness in X that was EWMH

> Wayland is a protocol
Who cares. I only care about the results. And the practical results are: worse performance, more fragmentation, worse latency and more bloat.
Maybe the protocol is just shit!

>muh fps/my latency
Go back to >muh xorg just werks
No it doesn't. Go to a retirement home.
>muh fragmentation/choice is bad
Go to windows.

Waste of quads.

>Again, they are not standard, but implemented in mutually incompatible way, and hardly usable for third-party tools.
Wrong because those third party tools already exist.
>Dilate.
Don't repeat this meme, it makes your post lose any and all credibility.
>They don't need to because an X server has standard interfaces that apply to everything running under it. Unlike Wayland where every compositor is its own thing.
This is not true. There actually is a shitload of incompatibility between X servers, the only reason you don't notice it is because there is currently only one (extremely bloated) X server that everyone uses.
>Sadly, this won't work on me.
Oh no! Some user will continue trolling, shitposting, being wrong about things, refusing to understand how X and Wayland actually work! I am so angry that someone somewhere on the internet refuses to learn things, what ever will I do!
>The problem is Wayland is half-baked and lacks standardization of common desktop features.
This is wrong. There is a standardization process for protocols that anyone can contribute to. Most features are already standardized this way.
>Compositors are therefore forced to design and implement them by themselves,
Yes, someone working on a new feature does have to design and implement it themselves.
>resulting in incompatibilities
If they don't want incompatibilities then they can get that protocol standardized.
>This creates problems for third-party tools
They can use the standard protocols. gitlab.freedesktop.org/wayland/wayland-protocols
>So how about you stick with Wayland and see where that gets you?
It already works fine for me, and I can do all those things you were complaining about. I can also do them in X too if I want, I have both installed. You don't need to choose one or the other. You can also use Windows 10, although I won't be joining you there.

Those are all issues with your compositor, file your bugs with them. I use sway which is quite minimal and performs better than i3. The protocol is not your issue.

>the only reason you don't notice it is because there is currently only one (extremely bloated) X server that everyone uses.
If that's the case then what's the problem? If the one X server has a literal monopoly over everything, then there's no issue and you're not solving anything.
>Yes, someone working on a new feature does have to design and implement it themselves.
They're not new features though. We've had them for decades.
Don't get me wrong, I'm not him, and I actually like Wayland for being a more secure model, but these aren't really helping your case. The security advantages of Wayland are what's essential.

Take this excerpt from wiki:
>Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; the original X design lacks these important security features,(citations) although some extensions have been developed trying to mitigate it.(citations Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security,(citations) although multiple popular Linux distributions now allow X to be run without root privileges.(citations)
Because X does not isolate inputs and outputs properly, any app can fuck with any other app, making it easier for shit like keyloggers and other nastiness to exist. It may not be too common now, with Linux being a single digit at best percentage on desktop, but what happens when grandma gets on there. The Wayland approach means that when YOTLD eventually happens, we won't end up in a Windows XP "cool toolbars" situation again.

(cont.)
In that wiki section, there are a few bits talking about what X is doing to try and combat these flaws. But that's the problem. It's just band aids and duct tape on top of band aids and duct tape. The problems are fundamental, and it would be most logical to fix the problem at the foundational level. It's like cutting out some tumors on a cancer patient and saying "Yay I cured cancer!" Foundational problems require a re-evaluation of the whole idea.

It's funny to me that there's so much overlap between the X defense squad and the systemd haters. Wayland is good for the same reasons sysvinit/runit/openrc/whatever are good. It's not a bloated spaghetti code mess.

Gayland is for trannies, go dilate.

Attached: 1567468798661.gif (840x559, 245K)

seething

Never, and nobody wants Wayland anyway.

Just ignoring Wayland until it goes away is a better option.

>you should never rewrite working software

If we took your advice we'd all still be using Cobol.

Clearly some were unhappy with Xorg being the only option which is why things like Wayland were created.

>They're not new features though.
It is absolutely a new feature when it's something old but redone in a secure way.

>these aren't really helping your case
I don't have a case, I'm not shilling anything. I'm just explaining how this works. That user can use whatever display server she likes.

X's security issues have all been fixed, Wayland still has tons of unfound bugs, no code audit done yet.

>It is absolutely a new feature when it's something old but redone in a secure way.
fair enough.

Xpra is nice but usability is bad and it's not practical in a lot of situations.

>Wayland still has tons of unfound bugs, no code audit done yet.
Wayland is a protocol. What code are you referring to specifically?

>X's security issues have all been fixed
Yes that's why everyone runs xorg on their servers because there's no potential security problems with using xorg at all.

Attached: 1359666443736.png (735x869, 504K)

>Wayland is a protocol.
It's also a sole implementation.

this, x11 is tried and tested and runs on servers

Proof?

Show me where there are multiple working Wayland implementations which are up to date with the spec / protocol...

Oh wait, "the code is the spec" in the official implementation, how nice. No RFC, no ISO standard, no nothing.

github.com/Smithay/wayland-rs
github.com/abooij/sudbury

I haven't tested these and I don't know if they are up to date. Keep in mind that the way wayland works, the bits that get updated a lot are the protocol definitions, which are the XML files that your protocol implementation should auto-generate most of its code from.

>the code is the spec
wayland.freedesktop.org/docs/html/ch04.html

>No RFC, no ISO standard
Why do you believe these are necessary?

>Haskell implementation of the wayland protocol
I'm impressed this exists.

There was also a golang one somewhere but I forgot what it was called, it probably was outdated though.

>the bits that get updated a lot are the protocol definitions, which are the XML files that your protocol implementation should auto-generate most of its code from
seems pretty gay, they should make sure it works then publish an RFC and not change it

keeping shit in flux is a glownigger trick like they do with systemd

It works fine. Nothing really gets removed from the protocols because that would break all the applications. The wayland equivalent of publishing an RFC is putting things into wayland-protocols.

erm
>github.com/search?o=desc&q=wayland&s=updated&type=Repositories
>github.com/search?o=desc&q=wlroots&s=updated&type=Repositories
the most popular implementations are sway, plasma, gnome, way-cooler (they dropped rust and are now just porting C awesomewm), way-fire, mate desktop (currently finishing their Mir/Wayland implementation) and the weston reference implementation that shouldn't be used
afaik only sway and gnome are really ahead. plasma has very little devs overall, most of the work seems to go to applications and random shit

I don't know how plasma's compositor is doing these days, but QT got way better at wayland recently (for me at least). It's still missing a handful of extensions, but they're almost at 1:1 parity now.

It doesn't lack features it lacks a ecosystem.

Xorg gets features from external programs like xrandr, xscreenshot, compiz that people assume is native to X11 somehow.

>j-just constantly update your shit so you can track this whimsical alpha-grade ten plus year old shitware
no

no wayland, no systemd, no pulse, no dbus, none of it

>a wild suckless shill appears
Wayland is significantly less bloated than x11. You don't need to constantly update anything, the protocol bindings are regenerated any time you recompile any wayland client application.

Xorg has more in common with systemd, pulse, and dbus (i.e. bloated unreadable mess) than wayland does.

Attached: 1503107762537.jpg (202x250, 8K)

Is it possible for one man to implement a wayland compositor from scratch?
How much time would it take?

Wayland already is finished.

Nobody is using it.

based beawsume

wayland is closer to the plan9 graphics stack than xorg is. xorg is a bloated nightmare that exists as proof you can write sepples bullshit in c.

From scratch would take a while. Use a library. For reference here is the simple example for a wlroots compositor. It's 600 lines without the comments. github.com/swaywm/wlroots/tree/master/tinywl

If you want to build completely from the ground up (i.e. just use fucking libwayland), then it would take a very long time since you would need to implement a ton of fine details yourself. If you're willing to compromise, you could just use wlroots and build a compositor with it in a reasonable amount of time. See this example, which is pretty simple and very readable.
github.com/swaywm/wlroots/tree/master/tinywl

using wlroots or equivalent library yes, theres no point in either not using that (unless its for learning purposes) or complaining that the lib is """huge""" when it's just standard boilerplate any kind of protocol would need
just search github for wayland or wlroots and you will find many examples like github.com/st3r4g/swvkc
theres also a blog post from a sway dev that i can remember the name that shows how to do it, google it
but even better, help kde plasma instead ;)

>xorg is a bloated nightmare
lmfao
Show me Wayland causing 0 events in powertop faggot, bloated lmfao.... jesus christ

Attached: hurr.png (2560x1440, 508K)

learn, pay someone, or stop complaining. there's absolutely no reason to make these threads if you're not willing to contribute anything.

>Wayland is significantly less bloated than x11.
X11 is tiny, that's only true if you count all the drivers in the x.org tree too, which you don't actually use or run.

X.org can run on a computer with 2MB RAM. Can Wayland with all its reticulated spline parsing of XML files and so on?

No, no it can't.

wrong, look at its dependencies

Wayland is a protocol. You'll have to be more specific about what compositor you tried.

>you tried
I don't need to try it because I know none of them are as efficient as Xorg.

>wayland is a protocol
no it's nothing yet

protocols are specified, let's wait until wayland is spec'd and published and 'done' before we even think about adopting it

where's wayland 1.0? like the reference spec which is guaranteed for life forever? oh it will never exist

>if you count all the drivers in the x.org tree too
Oh no not this fucking retard again. There are no drivers in the xorg codebase. Drivers in the kernel. Xorg does not touch that shit.

>xorg never ever ulitizes the CPU and just automagically works
A braindamaged tripfag. Imagine my surprise.

>X.org can run on a computer with 2MB RAM
modern xorg? it needs like 40M at the very least

It literally doesn't.
Imagine the Waytards surprise when he finds out Wayland is fucking Waybloated.

>There are no drivers in the xorg codebase. Drivers in the kernel. Xorg does not touch that shit.
you're fucking retarded

x.org/wiki/Projects/Drivers/

Wayland is not an XML protocol, the protocol specs are just written in XML. It's parsed at compile time to generate the bindings. And X11 is not tiny. Go try to write an X server yourself and see how much legacy shit from the 80s you need to support.

x11 is tiny and i used to have one for DOS that was like only 330k or something loaded, i could still use dos hell with it

when switching to custom modelines is as easy as an xrandr command I'll switch

>Make a claim
>Later admit to never having tried the thing you're making the claim about
?

Those drivers were split out and have not been in-tree for quite a while. gitlab.freedesktop.org/xorg/driver

Yes that's true, you could make a really small version of it that supports no extensions and has no hw acceleration and draws right to the framebuffer. But Xorg (the server everyone uses) is not that.

none of this shit is engineered like x

wayland is a project to have a generic display layer running only on modern graphics hardware, only!

it's part of an attack on truly free software and keystone projects, turning over the keys to the kingdom to a bunch of luminescent trannies and we're seeing it across the spectrum of open source projects that multiple projects rely upon

None of these are actually in xorg's code base. When you install xorg, you don't get these drivers.

>programs magically run without using any CPU at all!
tripfags everyone

Doesn't mean I'm wrong faggot.

Nobody will dispute it with actual evidence because Wayland is bloated as fuck compared to Xorg.

technicality

you COULD but nobody will of course

github.com/emersion/wlr-randr
github.com/cyclopsian/wdisplays

The wayland spec is already published. If you have wayland installed it's on your system already, check /usr/share/wayland/wayland.xml

>no wayland, no systemd, no pulse, no dbus, none of it
one of those things is not like the others
opinion discarded, brain dead hypocrite
go troll some other thread

Xorg can idle without using your CPU moron. That screenshot is literally proof.

>When you install xorg, you don't get these drivers.
yes you do, on debian my c&t worked fine

same with netbsd

until somebody shows me wayland running on a 486 it's bloat

No it isn't a technically. Even with the drivers out-of-tree the server itself is still bloated. But yes it was way worse before back when it was a giant monorepo.