IMHO for applications it should be completely irrelevant whether they talk to Xlib, XCB, Wayland, or any other future window-system-glue API which sits below widget frameworks like GTK or Qt (just don't require me to use GTK or Qt in an application which just needs a GL or Vulkan canvas instead of a full-blown UI framework). All those choices should just be differently flavoured client-side APIs to do the same thing…
The technical merits of Wayland are mostly irrelevant
51–60 of 203 posts
Re: The technical merits of Wayland are mostly irrelevant
#52Very true. Wayland is now stable enough to be used in a lot of "production" environments and I've been using Sway as my desktop for years , and yet still, there is work left to be done: - Hardware support. NVIDIA support is spotty still. Easily the biggest issue IMO, though it's better than it was. - Network operation. X will always be better here because it was designed to be (at least with toolkits that can still t…
> Network operation. X will always be better here because it was designed to be (at least with toolkits that can still take advantage of XRender.) That is by no means clear cut - X is competing against specialist applications like VNC and there is a real question mark over whether a critical application uses OpenGL. X can easily win on toy benchmarks that play to its strengths, but it is rare in the extreme for that…
I stay with X because it lets me have multiple independent logins with their own desktops. The last time I checked, Wayland doesn't support this, and this is well outside of what VNC does. This is a very important facility to me.
Re: The technical merits of Wayland are mostly irrelevant
#53Very true. Wayland is now stable enough to be used in a lot of "production" environments and I've been using Sway as my desktop for years , and yet still, there is work left to be done: - Hardware support. NVIDIA support is spotty still. Easily the biggest issue IMO, though it's better than it was. - Network operation. X will always be better here because it was designed to be (at least with toolkits that can still t…
Excuse me, but BS. At least for anything of actual relevance.
X11 networking works okay for stuff that looks like a classic X11 app. That's things like xcalc. Any modern text editor, web browser, or anything else is going to be dog slow.
X11 has a bad networking protocol that's way too latency sensitive, and as a result is nigh unusuable without something like NX, which puts a local cache in front to get rid of that latency.
No, I'd say X11 wasn't designed to be run on the network, in that no particular care seems to have been taken to deal with latency and bandwidth issues. It's more of a feature that could be had for free, because if you can use an UNIX socket, you can also use a TCP one with minimal work, so might as well allow it.
Re: The technical merits of Wayland are mostly irrelevant
#54The security benefits are massive. X allows *every* application to take screenshots of the whole screen. 40 comments and nobody pointed out this benefit...
It's the usual "convenience vs. security" debate all over again
Re: The technical merits of Wayland are mostly irrelevant
#55Case in point: I have to use Wayland, because otherwise my Linux machine just can't reasonably drive my monitors (one 8K, three 4K, and one high-refresh-rate 1440p portable). Upon logging into any modern Linux, like Fedora or Ubuttnu or whatever, X will freak out, jank out with its crank out, and -- only if I am lucky -- finally show the desktop.
If I want to switch some/all of those monitors to some other computer for a while... good luck switching back.
And there is AFAIK no distro that supports mixed 8K/4K/2K monitors with working font scaling using X.
So I need Wayland for all that. Extremely relevant technical merits, for me. Not maybe for you.
Unfortunately, my workflow also requires being able to do remote desktop, and share my screen during remote meetings. Which doesn't work a blood clot on Wayland yet.
The TL;DR is that both X and Wayland have awful, crippling flaws that prevent pretty basic things from working.
Windows has always been able to drive this same setup, and do all of these things, without problem (on the same hardware). Recently, even Macs (M2 onward) can finally do so. Linux cannot.
So there are two main graphics/HID subsystems for Linux, and neither one works well for modern desktop computing with high-end/new displays.
But, only one of them is likely to someday work well. And it isn't X.
Re: The technical merits of Wayland are mostly irrelevant
#56Earlier quoted context omitted.
Would you please talk more about this? * What is your condition exactly? * What were you using on X that made you healthy? * How is it broken on Wayland?
> What were you using on X that made you healthy? Well my WM for a start. It did not migrate to Wayland. And I also need to share screen from time to time (teams, Google chat, etc), which results in a dark screen for viewers in Wayland.
Any updates from Microsoft on this issue?
Re: The technical merits of Wayland are mostly irrelevant
#57IMHO for applications it should be completely irrelevant whether they talk to Xlib, XCB, Wayland, or any other future window-system-glue API which sits below widget frameworks like GTK or Qt (just don't require me to use GTK or Qt in an application which just needs a GL or Vulkan canvas instead of a full-blown UI framework). All those choices should just be differently flavoured client-side APIs to do the same thing…
Is this not really this way? Do you mean a person building a GTK or a Qt app actually has to check whether the app is running under Wayland and do something special to support it nowadays?
I actually wonder what happens if you run a Gnome app on KDE, or a KDE app on Gnome on top of Wayland, does the title bar look consistent in that case?
I guess I also don't understand why there are even multiple Wayland display server implementations with different feature sets. As if desktop Linux wasn't already fragmented enough.
Re: The technical merits of Wayland are mostly irrelevant
#58Currently using XFCE on a remote desktop. This configuration has in the last ten years been met with "theoretically, someone could maybe maybe write something one day that makes this work on Wayland". Well, until it is, then I frankly hope that Wayland fails and is abandoned, because as it is now it sucks up all the mindshare of desktop Linux into what it consider a dead end: having each and everyone doing their own…
Re: The technical merits of Wayland are mostly irrelevant
#59IMHO for applications it should be completely irrelevant whether they talk to Xlib, XCB, Wayland, or any other future window-system-glue API which sits below widget frameworks like GTK or Qt (just don't require me to use GTK or Qt in an application which just needs a GL or Vulkan canvas instead of a full-blown UI framework). All those choices should just be differently flavoured client-side APIs to do the same thing…
Re: The technical merits of Wayland are mostly irrelevant
#60There are plenty of technical differences between how KDE, Gnome, and Wlroots that just cause more work for me. Perhaps most popularly Gnome is dying on the hill of "client side decorations", meaning that without mostly Gnome specific code you will get no title bar. KDE and Wlroots do upscaling different, KDE upscales with video in mind, Wlroots upscales with text in mind. There is no way to specify how a client would like this upscaling to be done, so to get consistent display you have to do the upscaling yourself. Some other minor annoyances include having to implement key repeat yourself, and no standard way for programs to cause a mouse movement.
Like this article mentions I use wayland because it's the "only game in town", but after porting drawterm I became fairly unimpressed with the technical design.