Adam Jackson On The State Of The X.Org Server In 2020

[oiaohm]

I haven't discovered any benifits yet. Please enlighten me.

Seeing them is not that straight forwards with the wrong ideas.

https://www.x.org/wiki/Development/X12/

First thing you need to be aware of is that Wayland is part of process to get to X12. Note part. X12 requires that network transparency be supported but must be secure.

One of the things Wayland brings back even that the protocol itself does not support network transparency is functional network transparency.

https://gitlab.freedesktop.org/mstoeckl/waypipe/

Yes this is true functional network transparency with opengl and vulkan support.

If you be realistic you are not going to use X11 native network transparency because if a network connection drops out for any reason you application dies.

https://xpra.org/trac/wiki/Usage/OpenGL

So you will use xpra notice on of the recommend ways to get Opengl and vulkan support for modern X11 applications is in fact use Wayland to be exact Xwayland. The reason why Xwayland does not work with Nvidia is the same reason why Xdummy does not have accelerated opengl support with Nvidia out the box lack of proper glvnd/libglvnd support from Nvidia drivers. But for us with AMD/Intel GPU setups everything is good of course Nvidia is a sooner or latter by either Redhat or Nvidia that libglvnd work will.

Gamescope from Valve depends on wayland ability to sandbox applications. Flatpak and Snap are also needing wayland to fix the X11 I cannot sandbox anything problem. There were many attempts to add sandboxing to X11 but due to the protocol being a pure mess no one succeed if you tested closely.

Yes gamescope using Wayland around applications it a lot simpler to implement application window scaling than X11. Nothing having a messy protocol helps a lot.

Yes Wayland protocol not wanting to take every feature and the kitchen sink is part of making a clean protocol to allow doing a lot of things. This also cause problems for those who look at X11 and attempt to say Wayland should be the same. Wayland to keep protocol clean something that were implemented in X11 protocol will have to be implemented in third party protocols outside Wayland. Reality here a lot of the things that need to be implemented as third party protocols to wayland like screencapture if you look closely don't work correctly under X11 due to applications by passing X11 so be the future Wayland or X11 for that feature we need third party protocol.

Like it or not there are benefits to Wayland. To get these benefits you cannot do stuff the same way you have with X11 of old of course this generates teething problems from hell. The worse part is some of the differences Wayland needs we also need to keep using X11 into the future even Wayland was not on the table. Yes those features to keep X11 working in future that need to be third party to Wayland core protocol people have been demanding to be made part of Wayland core protocol then getting upset when the Wayland developers are like no we are not doing that because it make no sense. The problem of not stepping back and looking at the problem as a complete eco system.

Hard reality here is Wayland is really about fixing the defects of the X11 solution.

[ferry]

Oh KDE itself also has tons of wayland related issues. I know as I am actually using it and have to deal with those every day. Still need to file bugs for a bunch of those, but claiming that KDE is fine is just not true.

I didn't say that either. All I said is that is nonsense to ask Canonical to make wayland the default. If it works you can do it now. If it's full of bugs as you claim, then it's just not ready yet.

Most of them are just not as important and the benefits of wayland itself still are way more important.

I haven't discovered any benifits yet. Please enlighten me.

[oiaohm]

Well to know.

The with how likely application is to work no one is really bothering doing major lists. Most issues tracing to toolkit issues making a list listing those that don't work is also most pointless as well. Microsoft does not make exact list of applications that work with Windows either you are talking a huge volume of work for basically no practical gain.

[Azrael5]

https://wiki.gnome.org/Initiatives/Wayland/Applications

All the ones that list rawhide there there was not a even a single binary change required.

https://wiki.gnome.org/Initiatives/Wayland/Applications/Porting

Porting instructions for GTK applications first thing just try running it with Wayland you have better than 90 percent chance that it straight up works.

In fact if you are running a wayland desktop and you run GTK application it first trys wayland and if it not Wayland compadible you have to add GDK_BACKEND=x11. to make it use XWayland.

https://wiki.archlinux.org/index.php/wayland#GUI_libraries

The reality majority of applications updating the toolkit to support wayland ported the application to Wayland without having to-do anything else.

Really how far X11 has got abstracted away by the toolkit came clear with how the migration to Wayland has gone. Fairly much 99% applications for over 20 decades now on Linux really have not been using X11 instead have been using a toolkit that would happen to produce X11 output that could just as simply produce something else.

Fun one with like GTK is the fact you can if you want wacky with most applications use a html5 backend as well.

Web browsers like Firefox and Chrome contain their own toolkit they are about the last toolkits to be ported. Majority of the applications that don't work under Wayland native today are using legacy old toolkits or closed source toolkit where the person building the toolkit decided to build it without wayland support. Of course there are the likes of the electron applications that depend on that depend on the chromium rendering engine that of course depends on the same toolkit as Chrome.

The reality is that going to wayland does not require major software rewrites because X11 is insanely rarely used directly. So it now comes about performance. There are going to be legacy applications like old games that Valve has that will require Xwayland for a while yet.

Well to know.

[JackLilhammers]

several people at my home are using wayland without knowing what it is. it just works

Seems like sample significant enough to estimate the worldwide adoption of wayland.

In the meantime:
• Ubuntu and all its derivatives still default to X (*buntu, Mint, Pop, elementary, Zorin, Neon...)
• All the countless distributions and distributions versions that don't run Gnome and are not based on Ubuntu still default to X
• All those who run Gnome, but use Nvidia, nvidiots as you call them

I suspect that something doesn't just work, but maybe they're just outliers

[oiaohm]

I suspect people use X11 because that is what they know and are familiar with, and they do not know how to achieve the same outcomes using Wayland+other tools.

That is a big part of the problem. Other part is basically rose colour glasses kind of problem. Where they are looking back at what they have been doing and have ignored the warning signs of the growing problems.

However, if people insist on using knives as screwdrivers, the intelligent solution is to give them screwdrivers in addition to knives and show how it makes their lives easier. It isn't always obvious; and sometimes having a knife to hand is more convenient than driving 20 miles to get the screwdriver in your toolbox.

Problem here when it comes to interfaces this is not the intelligent solution. You can really think of system latency like a backpack on soldiers back. The more you put in that backpack the slower the solider can move so the higher the latency. So you have to try to pack that backpack with the exact tools the soldier needs and nothing extra.

Managing the display is such a fundamental part of the user interface for most people that changes that diminish functionality, even temporarily, don't go down well.

This is the unfortunate reality for those attempting to fix these problems. In the process of packing the backpack on the soldier back they are going to miss things. Latency when developing interfaces has many effects on what you can and cannot do.

Big part is everyone need to accept X11 protocol has major problems that cannot be fixed inside X11 protocol we will be needing like the dbus screencast solution using pipewire for X11 and wayland. We will be needing a new way or improved way of injecting input. And the list will go on.

The unfortunate part of this is you really need a interface missing all the broken bits so that you can be sure that you implemented the new replacements covering their functionality this is where wayland desktops come in. Also developing new interfaces fragmentation at this stage is not our worse enemy so multi different interface replacement ideas can be tried out.

Its horrible that stuff being feature missing is part of this process. The scary part is over 90 percent of documented X11 protocols need to be redone or disposed(as in totally removed) of for the future desktop environment to be functional. So its quite a monster of a task. Part of Xwayland is not to make old X11 server work on Wayland but to work out what is the bare min X11 protocols applications in fact use so those X11 protocols that don't get implemented in Xwayland can be thrown straight in the bin of never be seen again.

The process at the moment has a lot of very savage cuts to happen. Reality the next major release of x.org X11 server could be major deleting patch. When I say major I mean like 50%+ of the git repository go poof.

[Old Grouch]

oiaohm wrote lots of informative stuff.

Thank you for taking the time and trouble to write that.

I suspect people use X11 because that is what they know and are familiar with, and they do not know how to achieve the same outcomes using Wayland+other tools.

However, if people insist on using knives as screwdrivers, the intelligent solution is to give them screwdrivers in addition to knives and show how it makes their lives easier. It isn't always obvious; and sometimes having a knife to hand is more convenient than driving 20 miles to get the screwdriver in your toolbox.

Managing the display is such a fundamental part of the user interface for most people that changes that diminish functionality, even temporarily, don't go down well.

[oiaohm]

So people are just holding X wrong?

Unfortunately the answer is yes they are holding X11 wrong.

Clue: use-cases are what people use your tool for, which can often be not the purpose you thought you designed for. People often use knives as screwdrivers (and criminals have been known to use screwdrivers as stabbing implements). The fact that people use a flaw in X to achieve something useful to them should tell you something about what their needs are. Giving them a tool that doesn't enable them to do what they could do with the old solution is rarely greeted with enthusiasm.

True but when you are using a tool for a usage case its not design for sooner or latter you start running into problems.

I will start with a basic problem that people complain about Wayland not having and X11 having and show a failure in X11. We will start with screen capture.

People will say screen capture in X11 works. Lets take a broad look at usage case.

First question has anything been added to X11 that could screw up your complete ability to screen capture.

https://keithp.org/blogs/DRM-lease/

Latest thing is DRM-lease in 2017 this means that applications like steamvr you use X11 screen capture methods and what is on the VR headset is 100 percent non existent. . I would not be surprised at some point that that valve gamescope running on X11 will not request a DRM lease to lower latency for contain games so they pull the disappearing act when full screen as well.

Someone might argue that is not a big enough problem because not everyone has a VR headset. Its fun when you are using accelerated video playback under X11 and attempt to screen capture on particular hardware and where the video is in screen is a black box. Again this is another example of opps we bipassed X11. There are in fact multi different cases where screen capture under X11 using X11 protocol just does not work right.

Interesting point is the way you implement remote desktop and screen capture for Wayland by go to the KMS layer if used with X11 server bare metal fixes the above issues

So yes screen-capture is truly a case with X11 where you are holding a completely incompatible tool for the job. X11 screen-capture was designed for debugging X11 servers not for capturing all output interfaces you have. The horrible point is X11 protocol included screen capture methods are really like trying to knockdown the a wall with a tack hammer instead of a proper sledge hammer going forwards. Why is it that bad because modern applications you can expect over time even under X11 to use more interface leasing and its only going to keep on working on the older applications not doing this with basically wall with degraded mortar. Another way to put it X11 protocol include screen capture is like attempting to put a nail in with a screwdriver(yes this is possible but totally not recommend as it a really easy way to hurt self).

Ok what about injecting input into application. Its simple to miss that logind and consolekit before it can have given application on your desktop exclusive access to some input device. so using XTest and the like will not send messages to those applications. The race for more and more low latency we can expect to see more of this. Basically I can repeat the same basic description of putting a nail in with a screwdriver.

These problems are not fixable by extending the X11 protocol because the problems are coming up because of applications bipassing the X11 protocol. Think of VLC supporting direct framebuffer output on Linux. There are quite a few history Linux applications that users could pull the bipass X11 server for a very long time. These were rare corner cases. Problem is these are now coming the normal.

The hard point is for people to accept they have been using a flawed way to-do what they wanted in X11 and they now need to move on to working on making a proper implementation that will in fact work as what was corner cases comes the normal. This change is going to happen to you even if you don't migrate to a Wayland based desktop.

[Old Grouch]

I do not doubt at all that Wayland is the future, I just hope to see compatibility and stability reach the level that we have on X11, and that features like screen sharing, recording and remote control become available in applications on Wayland just like on X.

X never supported those usecases, it just had a giant security hole that allowed people to do whatever.

So people are just holding X wrong?

Clue: use-cases are what people use your tool for, which can often be not the purpose you thought you designed for. People often use knives as screwdrivers (and criminals have been known to use screwdrivers as stabbing implements). The fact that people use a flaw in X to achieve something useful to them should tell you something about what their needs are. Giving them a tool that doesn't enable them to do what they could do with the old solution is rarely greeted with enthusiasm.

[Old Grouch]

https://www.linux-magazine.com/Onlin...land-the-New-X

Old Grouch Wayland origin is X12.

https://www.x.org/wiki/Development/X12/

Wayland is what happens when you take the requirements list of X12 and attempt to implement them.

Adam Jackson writes X12 document and then Kristian Høgsberg implements Wayland using X12 document as reference implementing what he could.

Wayland is a separate project to X11 but its not a separate project to the successor to X11 that is X12. Wayland is a piece of X12.

Old Grouch there is a formal successor in documentation to X11 and that is X12.

Yes the wayland security first second and third that is straight out of the X12 design requirements document.

It is a common mistake that there is no formal successor to X11. Formal successor does not require a functional implementation.

Wayland protcol + waypipe + many other parts would have to be bundled up to meet the X12 design requirements. That collection would be the functional implementation of X12.

Funny right Old Grouch we are starting the migration to the successor to X11 with the conversion to Wayland.

I've given you a like, not least because we have illustrated the old saw about the way of getting an answer to a question on U̶s̶e̶n̶e̶t̶ the Internet is to post a wrong answer that you declare to be definitive. The 386 effect ensures someone will give the right answer.

I admit I searched the x.org website for Wayland, not X12. My error in not looking assiduously enough. Sorry.

But, as you say, Wayland is not X12: it is one component of a bundle that would be the functional implementation of X12 as described in the reference you gave. Thank you for that reference. The X12 description is an interesting read.