On Mon, 9 Jun 2025 08:48:10 -0500 Vasily <[email protected]> said: > > > > > that's not a wayland thing. wayland is just a protocol plus associated > > tooling and libraries to speak that protocol. panning is a compositor thing. > > > > if you wanted a compositor to support this then add it to that compositor. > > as there is no single compositor in the wayland universe, you'd have to > > make a choice. you could also build your own compositor. > > > > And that is the main issue with wayland. > "Very intelligent" people created a protocol plus associated tooling and > libraries and expected that community will build a new great compositor. But > if X11 was developed for ages and polished for decades by people who loved > it, no one want to spend his time and design a new compositor for every > existing GPU Because in this case it will be just another X11. > > If you take a look on Linux there are few servers in it already - like > systemd or dbus, pulse/pipewire, named ... For my understanding there is > nothing wrong with a server/client approach and right now there is not any > evidence that there is a wayland compositor that works like X11 Second > problem that desktop must adopt such compositor.
that is the POINT. it is not meant to be one single display server (the wayland one). because .. such a display server embodies POLICY and DESIGN too... that's why we have window managers/compositors in x - they break out this policy + design. the problem is that also comes with other gotchas. there will always be latency and performance prices to pay for this. just design-wise. a LOT of what you see as a ui is enforced and implemented by a wm/compositor (or desktop environment... let's not debate the exact terms and exact bounds). and these are all different even in x. the idea for wayland is that there will be competing compositors like there are competing wm's(/compositors/desktops) based on x11. this competition allows for innovation but there is still agreement on the "bounds" between regular apps and these - so an app can display and work in all desktops pretty much the same (unless it starts to enter the domains of what each desktop does and assume things it shoudln't). wayland is the same. it doesn't cay a lot of x11 baggage. but this is also a problem with wayland. it makes the effort to build a wl compositor much higher. sure - there's wlroots but it also is very opinionated on how you will do things and it is not compatible with various ways of doing things. no point debating this unless you are a developer who knows this stuff but i'm pointing out the wl solution to some shared/common server is wlroots as a blob of code to include in your compositor. > My personal opinion is that there are some issues need to be solved before > wayland compositor can substitute X11. So I think X11 will work for us > another 5 -10 years. oh absolutely. wl needs maturing - a lot. there is much work to do. there also is no reason you couldn't also take xorg and "strip it down and divide it up". you could solve a lot of security and boundary issues by e.g. disabling any xrandr "write" access (modification) to any client by the wm. first client in wins (wm) and it's in charge. this stops any random client form messing with screen layout. we could start limiting access to xinput and xinput devices, limit what events you can listen to on windows that are not your own (unless you are the wm), and so on - it'd break some functionality in x - but it'd start solving problems. you could tackle it from this angle or from "build wayland" angles. either way it'll result in something breaking and some transition mess etc. etc. now my issues with wayland are indeed that it has yet to fully mature. there have been some not so great decisions that are seemingly heading in the right direction now. there are other things that are core issues. IMHO wlroots is a stab at some of that but IMHO there should have been much more done earlier on here and in ways that are more render-agnostic. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected]
