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

[Old Grouch]

it was two separate comments to two separate parts of your sentence. the confusion of what wayland is and confusion of clueless wayland criticism with valid wayland criticism. what citations do you need: that wayland is successor to x11 or that successor to x11 is what x12 means?

AFAIK, there is no formal successor to the X Window SystemVersion 11. Wayland is a separate project, with a considerable overlap between people who developed the X Window System and people developing Wayland. If it were a formal successor, you'd expect it to be documented on the X Window System website. It isn't. If you look at natural numbers, successors are easy to define. I would not describe Wayland as a successor to 11, but more like an orthogonal approach, closer to i than 12. Or, if you want a historical perspective, succession applies to royalty, with one monarch succeeding another; Wayland is a revolution, sweeping away the monarchy and replacing it with a republic.

As for Wayland criticism, your reply implies the existence of valid criticism of Wayland, which is good. Wayland is deliberately not a superset of the X Window System, and there is a strong rationale behind the design choices. This will generate invalid criticism, but at the same time, means Wayland does not address the needs of all existing X Window System users. You don't make friends by telling people to use a replacement for what they currently use when the replacement deliberately does not cover all their use cases.

.

[karolherbst]

AFAIK, there is no formal successor to the X Window SystemVersion 11.

There is, and it's called wayland. And nothing you think or say will change that. It's effectively X12. As there won't be an X12 at any time and X won't get any new features API wise.

Sure it's not advertised as such, but this is sidetracking the discussion anyway as it doesn't matter one bit. Wayland supersedes X11, and nothing anybody outside the X community is saying will change that.

[arokh]

** Wayland <-> X - on topic **
I am no programming expert (I might did a lot of programming as a scientist, though - mostly the former century) - so the X code base may be a problem ...
But I am a Unix expert and no: no Wayland implementation (i.e. real code - not a protocol) is currently ready for professional use at all - not even on GNOME desktop.

Now THAT is "rediculous"! Considering Wayland most definitely is being used profesionally, you sound as deluded as the usual anti-progress FUD trolls around here.

So putting the plug before the huge problems are solved is stupid. And yes, it is simple company tactics like MS or Apple.

What problems? Company tactics?

Implementing Wayland and using most of the fat and abandoned X stack is the future - really? Sorry, not at all.
Similar to Apples macOS using Darwin: a microkernel with a fat BSD kernel in it with all rights - so no positive effect (many will doubt that there are any) from microkernel could be seen. And is this a problem - no. As no one knows the facts or is even interested in them.

Well, how to put this... Back here in reality, Wayland isn't the future anymore. It's now.

[oiaohm]

Is there a list of native Wayland apps and desktop environment?

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.

[oiaohm]

AFAIK, there is no formal successor to the X Window SystemVersion 11. Wayland is a separate project

https://www.linux-magazine.com/Online/Features/Is-Wayland-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.

[Guest]

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.

[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.

[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.

[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]

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.