Hutterer: Is Wayland ready yet?

Vulkan is _not_ a "lightweight" API. It exposes low-level memory management and command buffer creation so it's much more powerful than OpenGL exactly because of this. There are real-world applications that have seen 2-3x FPS improvement after switching to Vulkan.

Of course, EGL won't disappear overnight - it'll be supported for backwards compatibility for the foreseeable future.

On principle, I would really like it if X were competitive with native processing over a LAN, and work as well as say RDP over a wide area network, but I have never personally seen X come anywhere close in either scenario. If one uses it at all - in native form - it is probably over a LAN and with some special requirements that make it worth the substantial performance loss compared to running the process in question on the same machine as the display in the first place. The design is basically thirty years out of date.

Unless someone gets really creative, the era of remote command based graphics rendering is about to come to an end, replaced for the users who really need it by some protocol that does differential comparison and compression of damaged rectangle bitmaps.

Both models have existed for a long time.

Now the Vulkan spec is public - https://www.khronos.org/registry/vulkan/specs/1.0-wsi_ext... - you can see that its window system integration does in fact use framebuffers.

There are zero advantages in using command buffers to communicate.

In the embedded space the device often has just one application using the screen, hence the wide use of direct access like linuxfb, EGLFS, and similar on other platforms than Linux (e.g. QNX)

When it comes to Embedded Linux with a multi window requirement, when traditionally one would use X or some vendor specific windowing system like QWS when using Qt, there is now considerably uptake of Wayland.

There are probably devices that run Android instead and thus SurfaceFlinger, but that is more likely in the home consumer product space where device vendors might even want to have user installable apps.

X-org developers (Keith Packard included) say that X-org is pretty much a dead end. It's a very _long_ dead end that will be supported for many more years, but it's still dead.

This one is amusing: http://www.phoronix.com/scan.php?page=article&item=x_...

As for Wayland - it's not only interesting in itself, but also in the way it's implemented. All the complicated parts of the graphics stack are now in the kernel (KMS+DRM) or in libraries (libinput) - refactoring this functionality from X took a LONG time and a lot of of effort. So Wayland itself is _tiny_ - it's barely several thousands lines of C code, and competing servers (Ozone, Mir) are in the same ballpark.

Why do you think such an absurdly high requirement is conductive to providing any insight?

> Wayland is headed by Kristian Høgsberg (Not an Xorg contributor.)

https://www.openhub.net/p/x/contributors/19232863560029

It would appear that he made 745 commits to Xorg repositories, which certainly makes him a contributor, no?

Peter Hutterer is the input person for both wayland and X.

Work on something in X.org is for Xwayland benefit, glamor etc.

I think the problem is you think there are more X developers than there are, there is probably only really 10 people who've done major contributions in 5 years, and most of them have done work directly or indirectly on wayland support.

Incorrect. XWayland is a full rootless Xserver which can do precisely as much, or as little, with the X protocol as any other X server, including X remoting.

The question of Wayland remote capability is completely orthogonal to this.

I have been using nx regularly since its introduction. The library was initially open, but last years development has all been proprietary. It is useless for 3D. I am now using rgs, which at least supports 3D, but has a so crappy interface that it makes me want to scream, not to mention it is expensive. This is after decades of the current xserver. *Anything* Wayland can do to rectify this is welcome. However, I fear this sorry state of affairs is more a consequence of permissive licensing than technical challenge. Moreover, it seems like the solution will be coming through KVM, virtualizing the GPU properly. Not ideal, since it means firing up a full OS for each remote connection. Adding on the security concerns and code quality of X, I find your support for the current xserver strange.

Indeed, I checked through the ten most active developers on xorg and Wayland. There seems to be very little overlap. Somebody has repeated that statement one too many times.

NB: AFAIK there are no real RDP servers for X11, at least not FOSS ones. The only RDP servers I've ever been able to find for X11 are simple ones that ignore almost everything about RDP and resort to shoving massive bitmaps down a pipe, VNC-style.
If that's your point of reference, then you haven't seen what RDP can do, but if you have tried with real RDP servers and got NX to work better, then I'd be pretty interested in hearing what you had to do to make it do so, and if it can be done with entirely FOSS.

I will grant that I've not tried NX in a few years; if it's improved dramatically recently, then it's me that has the outdated point of reference - and I'd kind of be interested in hearing that too.

As I understood it (and I *checked* *up* on it ages ago), Wayland (the protocol, not Weston the implementation) is perfectly capable of doing X-like remote. It was designed in right from the start.

Nobody (who's prepared to do the work) seems to think it's that important at the moment, so Weston the implementation can't do it.

(And the impression I get about all these buffers being passed around, is that there is no problem passing buffers over the network, when someone gets around to doing it. So any app can create its window in Wayland, and it gets passed across to a ?compositor? running on a *different* machine, to display it.)

Cheers,
Wol

I personally fall more into the first camp for my devices, but I like digging into low level things and playing. For the rest of my family, they don't (they have other good hobbies). They don't have time to try and protect themselves from such attacks, and rather someone else do it for them.

Who that someone should be is a tricky question, but at least with Linux/Wayland, we can always dig in and replace it with whatever we wish. On systems like iPhones and most Androids, we don't have that capability built in, forcing us to trust a particular person.

And this applies to many aspects of security. Most users don't the time nor the energy to vet applications, they want someone else to do it for them. If we want truly secure systems for most people, we can't rely on them making the right decision. I don't like it anymore then you seem to. But I don't think we have a choice if we want to make computing secure and easy for people to use.

Fictional example: the color grabber button in GIMP would pop up the privileged application GNOME Color Grabber, which would allow the user to click somewhere and it would return the picked color to the contained GIMP.

Another: clicking on the "open file" button in LibreOffice would pop up the privileged application GNOME File Chooser, which would let the user navigate to a file and select it. The OS would then make only that file available to the contained LibreOffice.

> Similarly for a lot of what you highlight, there is no real standard at the xorg level either.

Not at the Xorg level. But in the rewrite there's no standard at _any level_. At some point, most probably next decade, the "standard" will have reached feature parity with what we have now, and the Wikipedia page listing "failed rewrites" will have another bullet point.