The discussion is circular, and it ultimately amounts to a lot of dissatisfaction on either side. People should use what they want to use and support what they're capable of supporting. Neither x11 or Wayland are going away, so we need less of the "make Wayland more like x11" and "make x11 more like Wayland" bandwagoning.
Maybe not, but the fact that Wayland doesn't support an important use case for me is why, regardless of any benefits Wayland may have over X, I won't be using Wayland.
> Neither x11 or Wayland are going away
I sure hope this is the case. I don't care if Wayland exists, I worry that it will become the only realistic option.
That's fine. I don't really know what your 'mystery feature' is, but I feel pretty certain it's on a Wayland roadmap somewhere. The same cannot be said for new features in x11.
> I don't care if Wayland exists, I worry that it will become the only realistic option.
It is the only realistic option, if you care about security and isolation. x11 is very flexible and fun, but it's not surprising that the people taking the Linux desktop seriously are pushing for Wayland. It sucks that you're unable to use it for whatever reason, but people aren't going to reallocate development resources to give a dying protocol new features.
Which is actually fine by me. I don't need it to have new features.
My point isn't that X is better or worse than Wayland -- clearly the answer to that question is "it depends". I was just expressing the concern that Wayland may eventually become mandatory.
So I don’t get it. How exactly is the core Wayland protocol a good base for the GUI parts of isolation?
So... I don't see how the isolation design is strange. Wayland makes sure that windows are individually isolated, and Flatpak/Bubblewrap isolates the backend and provides interaction portals. It's not a perfect solution, but it does stop your timer application from being a secret keylogger. If your biggest concern is a Trojan horse attack, it sounds to me like Wayland did what it set out to do.
Also it is again the rules to backhandedly ask "Did you read the article." Please read the guidelines.
The only solution for the end user is to vote with their wallets if running linux and/or wayland is important to them.
Bringing it as an argument _against_ wayland, however, is missing the point entirely in my opinion.
https://indico.freedesktop.org/event/2/contributions/78/atta...
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
https://wayland.app/protocols/linux-explicit-synchronization...
They're doing the code and releasing the patches, and they largely capitulated on whatever the EGLStreams issue was supposed to be about, they are leading in what everyone involved seems to agree is "the right direction" and the linux community still can't find their way to "yes". At some point you have to start looking at it as not being entirely NVIDIA's fault - "fuck you, NVIDIA" is no longer an expression of how difficult they are to work with, but rather a generalized expression of hostility from the linux community over perceived historical slights etc.
Like, if there's some big history of warfare between IBM and the kernel team, are you just going to reject any patch coming from IBM because you don't like the company, even when it's generally agreed that the patch is generally right and going in the consensus direction, just because you don't like the name on the signoff? That seems to be where the linux community is at these days.
The whole "fuck you, nvidia!" thing has always been noxious, that's an example of linus's personal toxicity that a certain segment of the linux community has eagerly celebrated. At best it is a thought-terminating cliche that contributes nothing and drags down the debate, and at worst it's given covering-fire for that segment to act out in their own immature, negative ways, to the detriment of the users.
It's not a good look, it's just immature, and at this point it's practically expected from the kernel team. Look who's in charge (and it's not just linus, GKH seems pretty bad too, from a casual observer every time I see his name come up it's some childish troublemaking like the symbols-relicensing warfare thing).
* 3 monitors
* 1x 2560x1440@60Hz
* 2x 1920x1200@75Hz
* X99 - Broadwell chip
* Fedora Workstation 38/39
* GTX 1070
* Driver 545 from RPM Fusion
* Currently on 545.29.06
* Excessive terminal use
* Code authoring (VSCode/Vim)
* Web browsing/app usage in Firefox/Google Chrome
* Screen sharing and recording (browser/OBS)
* Electron apps including Slack, Element, and Discord
* Occasional use of Krita^
I decided to give Wayland on my workstation another go when the 545 series dropped. Hilariously, the main reason being the underlying features added that enabled support for GNOME's Night Light feature.
Other than the first day of going through my apps and making sure things worked, I haven't had any real issues. For the work I do, Wayland more than covers my needs.
I have gotten a smidgen of cursor glitching after upgrading from the released 545.09.02 NFB driver to the beta-NFB 545.09.06 version. It only happens when GNOME switches to its "loading" cursor, but it's mostly been ironed out by now. I updated the driver as part of the system upgrade from Fedora 38 to 39, so that probably had a hand in causing it.
- open a new Chrome window
- snap the new window to fill half the screen by dragging it to either left or right edge of the screen
- result: solitaire-like window glitches
- if I resize the window a bit before snapping it, it works.
I haven't seen this glitch on any other app.
You are talking about a very rare niche case where one monitor runs with VRR and the other doesn't. Everything else is handled just fine with X.
> screen tearing.
"No screen tearing" just means forced vsync which is easily possible on X11 with a configuration switch or by using a compositor. Actually forced vsync is one of the great disadvantages of Wayland because it always comes at the cost of higher latency.
> Wayland rocks those two challenges.
And it sucks in every other challenge. Most importantly standardization and development. The Wayland API ecosystem is ultra developer unfriendly and complicated and will pose serious harm to the FOSS landscape which thrives on hobbyist and niche applications. It's so bad it wouldn't be far fetched to call it sabotage. (E.g. look at the hello world: https://github.com/emersion/hello-wayland/blob/master/main.c it's a complete mess)
Due to design issues relating to implicit sync with wayland any misbehaving app can cause your entire desktop to drop frames so if you're a multi monitor user expect stutters when the browser you have open in the background was a little too slow. Or worse if an app is badly broken [1]
The good news is that all of this is fixable. Windows has forced compositing for most cases and it performs much more consistently. A browser taking a while to render can't hang unrelated windows' composition. Wayland compositors can get there too eventually by moving to explicit sync APIs [2].
For now if you do care about these issues staying on compositorless X is the least bad option.
[1]: https://github.com/ascent12/compositor-killer
[2]: https://www.collabora.com/news-and-blog/blog/2022/06/09/brid...
The basic idea here is that you provide some callback functions the handle events, setup a framebuffer with mmap, and register your surface and framebuffer with the compositor. There is nothing complicated or messy going on here.
This is also the low level interface, most people will not being using this directly and instead will be using a GUI library like GTK or whatever.
I don't know very much C and I have been able to get a "hello world" wayland window setup and displaying some silly graphics with cairo in a few hours or less.
- Wayland can not render strings. You need something external just to render some other text than "hello world". And depending on the library text rendering will look different for each application.
- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely.
- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor.
Wayland is not X11 and doesn't want to be, it doesn't implement even a fraction of what X11 did and that is an intentional design choice!
Wayland does not provide any graphics drawing primitives at all. It only sets up a handle to some shared memory and expects the client to do all drawing.
I think the point here is that you shouldn't be using the display protocol to render text in the first place. If you want to draw text you use a library that is designed for that task rather than shoving that functionality into the compositor and into the Wayland protocol itself.
>- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely.
You don't have to use a thread to do this! You aren't forced to block and wait for the callbacks, you can implement your own event loop and check for messages when you want to!
>- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor.
I think it's good that clients can't capture the screen without permission, and I think using dbus for IPC is very reasonable, but I don't know anything about pipewire or the compatibility stuff.
Also I think it's fair to not like some of these design choices for sure, but it would probably be better for people who like X11's design to continue to use X11 rather than trying to force Wayland into an X11 clone. X11 will be around for a very long time so I don't think anybody will be forced to stop using it any time soon, and people can pick it up if development stops!
Wayland is a display server. Display servers in general do not render strings. They render bitmaps passed in by the clients. Clients are welcome to use their favorite string render libraries into those bitmaps.
> Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely.
Do you realize that all wayland calls are async? On the client side, you don't have to block on waiting on empty socket, if you do not want.
Few conmmens above, someone complained that a basic wayland client is complicated. The complicated thing was... setting up an event loop.
> If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running.
Yes; but these dependencies are in different processes, not yours. From the POV of your process, it is just an structured IPC.
XGetImage() is not that simple; it only coincidentally worked due to implementation detail. Having a global framebuffer is not mandatory, just at the time all the PCs had it. Nowadays, even PC hardware is getting overlays, so there might not be a buffer that represents what's on the display anymore.
Another issue is, that it is impossible to implement zero-copy screen casting with XGetImage(). It is possible and has been done with wayland and dmabuf, feeding the screencasted surface into hardware video encoder (without the buffer bouncing between system and GPU ram several times), and the userspace getting already compressed video stream.
Final issue is, that XGetImage() is not gated via user permission and does not provide indicators, that the screen was grabbed or is being casted. Wayland does.
Now the separate X11 displays do not have this limitation, but they have other ones: like not being able to move your window from one to another, without restarting the app. Historically, there was only one app, that was capable of changing the display without restart: XEmacs. For all the others, I have my doubts, that users would accept such limitations.
Now, both Xinerama and Xrandr standardized on using X11 screens for multi-monitor displays for exactly this reason. With displays roughly with same DPI and the graphics becoming truecolor, it wasn't really problem. But nowadays, it is.
That is mixed-DPI hardware. Another issue with your argument is, that "DPI and pitch information is accessible via xrandr extension". Yes, it it, that is true. The problem is, that it is one-way street. The client can read that, then it can respect that and adjust its rendering... but it doesn't have to. The client is free to ignore all that. Now the display server has the problem, that it doesn't know, how the client decided: should it upscale the client, or not? Nobody knows, all the display server has is an opaque bitmap.
With wayland, the client must explicitly set the scale, communicate it do the display server, so then the compositor knows, how to handle that surface. It can even transparently downscale the surface, when the user moves it from HiDPI to normal-DPI display. Something impossible on X11.
And no one cares about standardization and development. They just want to use their blasted laptop. I don't know about any of that stuff, I just know Wayland works better out of the box.
Wayland rocks those two challenges. No screen tearing, I can pick scaling for individual monitors on the fly, and the colors look gorgeous.
There were features that it was missing in the previous releases -- I have to use a pretty recent version of Fedora to have all the bugs that I need rattled out of KDE so that I can use Wayland -- but it's really going well now. Zoom works thanks to pipe wire, copy and paste works. I hope KFonts will get working soon but I've been able to work around that with fc-cache.