As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.
This has grown out to be a really great abstraction, where later multiple implementations can decide on new protocols/extensions to support. And they have already done plenty of such extensions, and they are compatible with each other. Remember, these are protocols. There is no need to implement them yourself, they can be made into a library, like wlroots, and you can build your compositor on that base, without any repetition. Also, multiple implementations only mean that there won’t be implementation-specific quirks.
As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue perfectly, and it is indeed working correctly for like a year already, with screen share even in proprietary apps like teams.
If I understand the OP correctly, this sort of philosophy is deeply troubling to some people. For simplicity-oriented folks, trivial things should be trivial, as a matter of principle. If some trivial thing becomes slightly less convenient so that complex stuff may be possible, this is an unacceptable compromise; or at least a very worrying one. When taking static screenshots requires an entire "project" that is "just ready this year" , the threshold of unacceptability is long surpassed.
I get that wayland folks do not share this worldview and they want to do the right thing, even at the expense of sacrifying things that were previously easy. But, to other people, this rubs them in a very wrong way.
(Also, if we have a complex program that does all the things we need and a simple program+the complex one, we will have more complexity in the latter case so the previous one may be preferred)
I suspect those people don't matter to this conversation and would not be working on things related to Linux graphics at all. Once you start involving DRM and Mesa (or the proprietary nvidia drivers...), everything gets really complicated, and it's not easy to come up with a one-size-fits-all approach.
In particular: the lack of GBM/dmabuf support prevented having any kind of consistent API for efficient screen capture when using the nvidia drivers, but I think that is changing slowly.
As someone who tried to do this... Ouch. Things like this are why X will still be around in 15 years.
Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots?
Ref: https://wayland.app/protocols/wlr-screencopy-unstable-v1
> "Warning! The protocol described in this file is experimental and backward incompatible changes may be made.
and the compositors were there way before 2018, so it's a bit too much to expect them to jump on the protocol.
In general, when your diagnosis to a problem is "the people using my product are all just too lazy to use it right", the problem is almost always that your product is the problem.
Or, compositors can use these wonderful things we have called dynamic libraries, and simply link against implementations of that desktop functionality, such as wlroots -- which implementations, by the way, will be far less crufty and ad hoc than the equivalent X11 solution!
Much of the reason why X is the way it is is because back in the day, Unix lacked dynamic libraries in general, so in order to share an implementation of, say, graphics primitives, the best way was to write a server that implemented them and have clients communicate with that server. Now that we have dynamic libraries, we can share a single implementation of graphics rendering across multiple programs, and still have all the speed advantages of doing all the rendering client side!
https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
A side note, but I really hate this ideology of 'x does one thing' outside of command line tools. This is a display server we're talking about. It should be able to enable normal desktop usage. Maybe not everything but core features like brightness control, screen sharing, screenshots, etc. Otherwise every wm that comes along is going to have to reinvent the wheel. There are tons of really great window managers out there, where the authors have looked at all the work it will take to get running on wayland, and have simply thrown their hands up in frustration.
It seems to me the only people that really benefit from the switch to wayland are the wayland devs themselves.
I've used gnome wayland, and sway. It's pretty damning that so few other window managers support wayland due to the sheer difficulty of the task.
Someone could build a compatibility layer based on picom or something, and that has been talked about for a while, but I don't think it will happen unless somebody funds it with some real dollars. And I'm skeptical of whether people using those window managers would even pay for it at all, based on the comments here it seems they would rather put the money towards keeping Xorg alive.
Oh wait, the architects of Xorg designed Wayland!
X11 is a dead end. Its authors have deprecated it and offered an upgrade path: Wayland. Time to make like Elsa and let it go.
Xorg was designed decades ago. The architects of Xorg are dead, retired, or overwritten with their stupider future selves; you're talking about maintainers.