hello-wayland

> multiple monitors 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/emersio

The standard “hello Wayland” project[1] is basically that, using an interface called wl_shm. You still need to do some IPC in order to arrange for the environment to so that for you, obviously, so a library called libwayland-client handles the necessary Unix socket handshake, plus some more of that to tell the system you’re done with the buffer and want to submit it. It would be possible to isolate the first part into a reusable executable that performs it then execs you leaving a well-known mmapable fd for the buffer, but the second you’d still need to do yourself. (Wayland isn’t willing to just use a pixel buffer you’re still writing to—indeed I don’t think discrete GPUs can do that as opposed to requiring an explicit transfer to video memory.) [1] https://github.com/emersion/hello-wayland

> there's nothing at the protocol level that prevents the long tail Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level". As example: Compare the Wayland "Hello World" [1] with X11 "Hello World" [2]. If you want to add the ability to take screenshots it gets exponentially worse. (Also the Wayland version is not even capable to render strings.) 1.: https://github.com/emersion/hello-wayland/blob/master/main.c 2.: https://rosettacode.org/wiki/Window_creation/X11#C

> Why does it matter that it is merged into an extension that will become core, or it was already core at inception? > Wayland has a really sane way of extension querying so it is not like clients will suffer due to these A client shouldn't be able to use Wayland without considering the color space of the pixels it's providing. By not having it in core from day one, there's already apps out there which will need patching to work properly. Here's[1] a random Wayland hello world example I found. It memcpy's the image it wants to display into a wl_buffer. What color space is that pixel data in? How can this work correctly without changes when the Wayland color management protocol lands? [1]: https://github.com/emersion/hello-wayland/blob/master/main.c...

You think this is bad? Just look at a native Wayland "Hello World" client [1]. This doesn't even print hello world. You have to do the text rendering yourself. And you need at least 500 more lines to implement the equivalent to a simple XGetImage() call. 1.: https://github.com/emersion/hello-wayland/blob/master/main.c

>Does Wayland even have a mechanism to allow the compositor to tell the application that it is time to draw another frame? Yes, Wayland will tell you when it's time for another frame. >If I give the compositor a bitmap every 60th of a second, to I get any guarantee it will display it at the right time? Basically you should wait for the compositor to tell you when it's time to draw the next frame, diff it from the time you drew the last frame, and smoothly animate over the difference. If you don't want to draw on the GPU, what you can do is allocate a pixel buffer with wl_shm (shared memory). Then the compositor will read from this and presumably upload it to the GPU (with wlroots the GPU is always used, but you can probably convince it to use blitting instead with a custom renderer). Check out my intro to writing Wayland clients article: