XWayland 21.1 Release Candidate Offers Split From The X.Org Server

[dpeterc]

I think this has wrong and false assumptions. I also tend to think the first thing is likely to happen, and developers with X11 applications will be starting to validate their erffort against Xwayland, so that full xorg x11 will get bitrot. Not instantly, but steadily.

I think you're also right in your belief, that xwayland will become kind of a common demoninator, but it will never be the full xorg x11 packages: It won't drive any hardware, it will not render fonts, it will not be a compositor,... and I think this makes "just another Xserver" a wrong assumption.

It most definitely will render fonts, or the whole Xwayland will be useless, without any text display. It will need both to render both old bitmap fonts for compatibility, as well as vector fonts like TrueType using XFT.
Last time I checked libXft was a X11 application.
https://github.com/freedesktop/libXft

[mppix]

Honestly the DPI issues are a temporary thing whilst too many consumers are buying absurdly high resolution screens. This will resolve itself once people realize they can save a bit on battery power avoiding such things.

IMO, it is unlikely that screen resolution decreases... Screens get cheaper quickly, and computation power is getting better and consumes less energy. Many like that they don't see any pixels, ever.. Still we will likely see display resolution stabilizing at some resolutions, e.g. 4K or 8K depending on display size. What screen size do you need to distinguish 8K and 16K?

[mppix]

It works fine with Xorg but not with wayland for me (on both Manjaro and Ubuntu and 2 different computers).

Not sure about Manjaro but Ubuntu's Wayland implementation used to be fairly broken (20.04)... Should be in good shape for next release..

[mppix]

Is this some form of autism? It is a compatibility layer implemented as a Wayland client. Why do you think they are mutually exclusive?

Sure. Is Xwayland also an X server for X clients then?

[Mez']

Shouldn't be necessary ever, and isn't for me and many others.

Make sure there are reports about issues you encounter.

Yes, it is.
When all Gnome apps freeze (happens once in a while, sometimes because of a bad handling of mounted drives, sometimes because of Gnome instabilities), when Gnome eats up twice the RAM of the session start RAM (a refresh solves that), when you get some kind of artifacts, when you play with theme customizations (sometimes they don't apply straight away if you don't reset), for extensions update not to disappear temporarily from the Extensions app and display correctly on the Extensions web portal. Logging out and back in is a horrible hassle to solve these issues.

Works fine here with gThumb 3.11.2, both native Wayland and with GDK_BACKEND=x11.

It works fine with Xorg but not with wayland for me (on both Manjaro and Ubuntu and 2 different computers).


Also, reporting bugs is time-consuming, especially in the wayland case, because nobody is taking responsibility for the issues and you're bounced back from one to the other, sometimes having to start over a few times. I only file bugs when it's a real blocker. And for now Xorg is working perfectly fine for me, so I'm not wasting my time if it can be easily avoided. Maybe when X becomes problematic, and if it hasn't been ironed out already, I will spend more time to it.

[MrCooper]

- No reset for Gnome (blocker for me, given how often alt + f2 + r is necessary)

Shouldn't be necessary ever, and isn't for me and many others.

Make sure there are reports about issues you encounter.

- Ctrl + scroll doesn't work for zooming in gthumb

Works fine here with gThumb 3.11.2, both native Wayland and with GDK_BACKEND=x11.

[MrCooper]

What many people say is the "risk" is actually that other programs in the same session can access other windows.

And input.

This is obviously very important and a required feature for enterprise computing (VNC requires it for one, Web browser screen sharing also). Once Wayland matures, this will also be the case with Wayland compositors.

No, Wayland doesn't allow one client to spy on the surface contents or input of another client. (Wayland protocol objects only have local IDs valid in the same client connection, there are no global IDs which could be used by another client)

Screen sharing/casting is working in Wayland sessions via separate specialized APIs which require explicit user consent. These APIs can work the same way in Xorg sessions as well, so applications only need to support those APIs to work regardless. E.g. OBS Studio just landed the basic changes needed for using those APIs (the OBS Studio flatpak has been patched to work on Wayland out of the box for some time). Current versions of Firefox & Chromium support them for screen sharing as well, it's mainly a matter of Electron based apps updating to a new enough Chromium base.

Honestly the DPI issues are a temporary thing whilst too many consumers are buying absurdly high resolution screens. This will resolve itself once people realize they can save a bit on battery power avoiding such things.

Nobody's been able to come up with a solution for X11 on mixed DPI setups which doesn't result in some apps either appearing too small or getting scaled up when they shouldn't be.

[Mez']

Debian, Fedora (and next iteration of Ubuntu) are defaulting to Gnome Wayland. It is perfectly usable in general. What issues are you referring to?

I'm not him, but here's my non-exhaustive list:

- No reset for Gnome (blocker for me, given how often alt + f2 + r is necessary)
- SMPlayer is not working properly (don't care whose fault it is)
- Unite extension doesn't run correctly (among others)
- Firefox titlebar in multi-monitor setup doesn't work too well
- Ctrl + scroll doesn't work for zooming in gthumb
- no xkill equivalent
- No support for SSD in Mutter/Gnome wayland

And no, I don't care whether it's the protocol design, the DE compositor/wayland implementation, the DE design or the app whose responsible. Maybe if it was just the one, and not properly maintained, then it might be overlooked to go forward. But when it's piling up for well maintained apps (considering many app devs never asked for it and the extra work to adapt), it means the ecosystem is not ready (which is the same as wayland is not ready in my opinion).
As a user, this is transparent to me and it should just work as it was (with a tolerance for a couple of changes).

It doesn't matter to me and most users who is to blame specifically when we just want to go about our entertainflow or workflow but somehow are not able to.

[kpedersen]

If it can't do mixed-dpi properly, no one will take this seriously. The wayland protocol solves two big problems for desktop users: security, and mixed DPI. Over time, more Linux desktops will confront or adopt mixed DPI situations. As for security, X should send shivers down your spine.

The Wayland protocol doesn't solve these issues. Some (~2) of the individual compositors do.

Security of Xorg is a little over stated. For example it doesn't even listen on TCP (or UDP) sockets any more (only internal UNIX domain sockets). So no-one external can break into my session. Any other users running on the same machine can also not break into my session due to the MIT cookie system. What many people say is the "risk" is actually that other programs in the same session can access other windows. This is obviously very important and a required feature for enterprise computing (VNC requires it for one, Web browser screen sharing also). Once Wayland matures, this will also be the case with Wayland compositors. macOS and Windows also have this feature because it is required from all but i.e phone users.

Honestly the DPI issues are a temporary thing whilst too many consumers are buying absurdly high resolution screens. This will resolve itself once people realize they can save a bit on battery power avoiding such things.

[kon14]

Thanks for this. There was a new commit there adding preliminary support for GPU offloading in Xwayland. That's the good enough solution for 99% of Nvidia users I think. Any iGPU from the last ten years can run two (or maybe three) displays at high resolution and you can lunch games, blender / whatever in the dGPU and display it using the iGPU. You can therefore avoid the pile of crap the EGLStreams backend is.

While I generally agree with you, I think that percentage is just way too random.
There's a huge amount of people using Nvidia on the desktop without an integrated gpu.