Talk:Wayland (protocol)

Functional Benefits?

The article only talks what things replace which other things, and who is committed to port which projects to Wayland. But why is it beneficial? What is the functionality that is impossible, or very difficult to implement, today and will be possible with Wayland? What is the end user benefit? It only says "offering more flexibility and better performance", but what flexibility, why performance benefit and how? For example, I use gnome and kde desktops, many visual apps. Windows transparency works and many very fancy windows effects all work. What will I gain with Wayland? Article doesn't have much, and reader of this article is left wondering why this thing is out there? I only read this article, and I am not even convinced this is a good thing, except it will avoid extra copies of some buffers and will get some performance benefit because of this. Article reads like this is a reshuffling of existing functional blocks with unclear benefits. Yurivict (talk) 10:36, 27 January 2012 (UTC)

Phoronix.com has extensive coverage of Wayland. Research there yourself and add the info to this article. --KAMiKAZOW (talk) 11:08, 27 January 2012 (UTC)

Wayland does not exist to make it possible to do things we can't do. Wayland exists to make it a lot less obnoxious to do things we already do. So from an end user perspective, things should end up looking the same (even the same window managers), just maybe a little smoother. I guess to get a better answer you'd need to look into the details of what a compositing window manager has to go through to work with X. All the kludging of X that's been needed just to make it possible. If there's a single web page that explains this well, I don't know where it is. There are extensions to just let the compositing window manager (like compiz) have direct hardware output control of the display, and extensions to render client output offscreen so the window manager can have full access to their contents, so it can composite them and output them to the display. Wayland just gets X out of the freaking way. And lets X developers stop dragging around old X cruft and do other things. —Darxus (talk) 18:27, 28 March 2012 (UTC)

It also makes it impossibe (or maybe just extremely hard and obnoxious) to do things we can do today, like SSH-tunneling. jae (talk) 01:48, 7 October 2022 (UTC)

Actually, it makes it possible to do things you already do today, in a sane and secure fashion. Previously, X was insecure and is outdated, made for a world where networked display servers were ideal. As the desktop progressed, X tried to adapt but couldn't, so now we have old applications like Discord that rely on security vulnerabilities within X to function, whereas with Wayland we now have proper methods of doing tasks such as screencasting via xdg-desktop-portal.

tl;dr it's likely you can still SSH tunnel, or at least do something similar to it, into a system using Wayland, just in a more secure, modern, and efficient way ;) Orowith2os (talk) 01:29, 12 February 2023 (UTC)

Here we go: Compositing window manager#Linux and AIGLX. AIGLX is the X extension that allowed compositing window managers to work. Its creation was led by Kristian Høgsberg, the creator of wayland. So all those fancy things you can do with X, your "Windows transparency... and many very fancy windows effects..." are all dependent on work by krh, and wayland is him continuing that work. —Darxus (talk) 19:09, 28 March 2012 (UTC)

Compositing window managers waste a lot of resources – time and RAM. So Wayland is flawed from the beginning. -- Sloyment (talk) 03:04, 20 February 2016 (UTC)

Common misconception. Window managers that use a lot of resources tend to be compositing, but it is not compositing that makes them use a lot of resources. Wayland is a protocol. It, and its reference implementation, use less resources than X. —Darxus (talk) 18:45, 19 May 2016 (UTC)

If every window has to use its own off-screen buffer, this will consume RAM. It will consume CPU time to move the buffer to the screen. In X, you don’t need an off-screen buffer for your windows. So where is the misconception? -- Sloyment (talk) 02:20, 12 August 2018 (UTC)

If Wayland was as inefficient as you say it is, then it would theoretically have worse battery life than X, would it not? In the real world, a fully fledged Wayland compositor such as GNOME can be more efficient and perform better than its X equivalent. And, although compositing is a requirement of Wayland, how it handles it is way more efficient than X. So the whole idea of compositing window managers wasting resources is a misconception, the actual resource wasters here are the display server implementations. Orowith2os (talk) 01:33, 12 February 2023 (UTC)

I think your misconception is in thinking that any modern X11 system still works this way. They don't they work the same as Wayland pretty much, with at least as many buffers and copy operations between them, and sometimes more which is why Wayland is faster. Spitzak (talk) 01:52, 12 February 2023 (UTC)

Assuming I understood your comment properly, please do correct me if I didn't, your wording is a bit weird, I'm fairly certain X is way more inefficient than Wayland, even nowadays, especially when it comes to compositing. X compositors do active compositing, whereas Wayland is passive, so Wayland is naturally going to be more efficient and can lead to better visual performance.

If X was able to have just as many operations as Wayland, and keep it to around that level, then it likely wouldn't have the performance and battery life issues it has nowadays.

So no, it's not a misconception that any modern X11 system still works this way, and they don't work the same as Wayland, not in the slightest.

See Wayland (protocol)#Comparison with other window systems, on compositing. Orowith2os (talk) 20:04, 15 February 2023 (UTC)

That's what I meant. Modern X works the same, or worse, than Wayland. The original poster is confused in thinking that X somehow does less buffer copying than Wayland does. Spitzak (talk) 23:08, 15 February 2023 (UTC)

Sounds like they really want the option for a lack of compositing and just EXPOSE/WM_PAINT into the front buffer or something. 24.1.9.141 (talk) 06:10, 24 March 2023 (UTC)

Inaccessible

I find this page very difficult for the average reader to understand. I am not planning to make any immediate edits but article reads very much like it was written by a coder as opposed to a layman and it is evident.

I hope to make some changes to this page in the near future but if there are any other wiki editors with more time than myself right now I would appreciate it if they could distil the text for a lay audience. — Preceding unsigned comment added by 0lida0 (talk • contribs) 01:27, 6 October 2021 (UTC)

Content not up to date

Much of the content of this page describes the situation as of 2014 or so. Is it possible to bring it up to date? m.e. (talk) 02:35, 17 May 2022 (UTC)

Criticisms and (dis-)advantages

This article lacks the criticisms of Wayland as well as its advantages and disadvantages compared to X11. It would be nice if someone with enough expertise could add this. 157.143.15.229 (talk) 20:42, 30 September 2022 (UTC)

Being critical of the wisdom of Freedesktop.org is not allowed. jae (talk) 01:50, 7 October 2022 (UTC)

Weston is no longer the reference compositor

See:

- Merged patch: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1091/diffs?commit_id=515708040a290e6a7692b5547fe21c3f4ff762a7

- Discussion here: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1014 2A01:E0A:71:60C0:B5E5:62BC:8973:126F (talk) 18:06, 23 November 2024 (UTC)