[0] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
[1] https://github.com/X11Libre/xserver/commits/xlibre/prepare/
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1760#no...
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797
I'll pass.
Looks like developers from Valve that were tasked on working on Wayland don't agree[0].
[0] >>41640420
2019-01-04 (only took 3 1/2 years to resolve!) https://github.com/flathub/us.zoom.Zoom/issues/22
2020-03-07 https://github.com/vkohaupt/vokoscreenNG/issues/51
2020-03-07 https://github.com/obsproject/obs-studio/issues/2471
2020-03-24 https://github.com/jitsi/jitsi-meet/issues/6389
2023-09 https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/
2023-11-17 https://github.com/raspberrypi/bookworm-feedback/issues/149
e.g.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
I think this comment from an Xorg maintainer sums things up (from this issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797 ):
> Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
> It is possible to reduce the complexity of the code, by delving deep into the interactions between DIX/MI/FB/DDX to flatten the code flow, making some deep structural changes. Or by using structured (de)marshalling through XCB. Doing this would be incredibly risky, but at least have a much higher payoff than just cosmetic shuffling because it is 'cleaner'.
> The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work?
> The problem with "X works" type arguments is that, no, no it doesn't, not generally
So, to summarise: what you're saying, in a thread where I demonstrated and you yourself said that X "just works", is that suddenly it doesn't now.
Well I'll be sure to tell my laptop, it's got this thing where it's super stable for weeks at a time. Maybe my laptop hearing that actually it's DE doesn't work and that I imagined all those times I hotplugged my projector is what is needed to magically make wayland usable in the real world.
---
Bwahahahahaha!
So I did about 5 minutes of searching, and found: https://wiki.gnome.org/Initiatives/Wayland/NVIDIA
Accelerated Xwayland clients (GLX)
There is currently no accelerated GLX support when running a GNOME Wayland session no top of the NVIDIA drivers, meaning X11 OpenGL applications will use software rendering.
and: Mode setting
Mode setting is possible, but the current requirement to use dumb buffers during mode setting before establishing the EGLSurface, EGLDevice CRTC stream link, results in memory constraint issues with multiple monitors with higher resolutions.
Monitor mirroring
Monitor mirroring is currently not possible due to the issue that an EGLSurface can only be linked to a single CRTC. The way GNOME Shell currently does monitor mirroring relies on passing the same hardware buffer to multiple CRTCs, which is currently not supported by the API exposed by the NVIDIA driver.
...Which is just a hilarious, hilarious joke. So in other words, wayland is a complete non-starter for any serious use. But I suppose, to be fair, you won't have to worry about that issue you claim is with X where you say you need to reboot to plug in a second monitor: you just can't have a second monitor! Not if you want it mirrored, or at "higher resolutions"Hey, just for fun: I bet you can't guess which windowing system has supported all these things for decades?
One more fun one, from: https://www.xfce.org/about/tour420
"Plans are underway to add Wayland support to Xfwm4 while preserving its existing X11 functionality. However, such a restructurization will be a major effort and we cannot tell yet when/if it will be done, so please don't hold your breath waiting for it."
Lol, yep, it's X that doesn't "just work", hahahahaha.(and no, I wouldn't be holding my breath, would I, given that wayland has now been in development longer than Duke Nukem Forever)
I think we're about done here.
> If nobody wants to maintain it
https://lkml.org/lkml/2021/6/10/957
I always find it ironic how people like this non-stop whine about "politics in mah FOSS" or video games or w/e, but will turn around and write a manifesto in the README drenched in right wing politically charged slop.
ultimately I really don't care what they spend their time doing, some people still want X11 and if they can keep it running then good for them. I use Wayland because it looks a lot better and is a lot smoother. Its that simple.
> I do use network transparency (ssh -Y) quite often and it's not there in Wayland.
There's waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe), which works well in my experience. Although I must say I don't use network transparency (be it X or Wayland) much these days.