The main killer feature for me is how easy it is to run graphical applications over the network using X.
I run a FreeBSD desktop with virtualized Linux, OpenBSD and Windows systems. the ability to run applications like they are on the host system is something I have not yet seen how to do with Wayland.
Well to my surprise, waypipe seems to be faster, especially when it comes to input latency and such.
I assumed it was a bit slow because of the long startup lag; but it seems it's mostly because of my slow (WiFi) network, and is even worse with X forwarding.
I just tried opening the same (simple) application through waypipe and through X forwarding, and using waypipe it's actually a lot more usable.
While it's a cute idea, I doubt this feature of X has serious support behind, and I don't think any future graphics system, be it Wayland or something else, will support it. Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream.
Sending rendering commands over a network is only decently fast if you have simple windows and no pictures. As soon as you want anyhting fancier, even as simple as opening a high res photo, the video streaming approach becomes significantly better.
X's model can have one advantage, when the machine running the X client doesn't have rendering resources locally at all (so that local rendering + video streaming would take too long for the CPU, despite the network advantage). But that is an even rarer use case.
>Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream.
The RDP protocol also sends graphics commands (mostly). It works really well on Linux with Xrdp/rdesktop. The idea of sending a video stream over network sounds good but somehow the implementations always manage to screw it up (especially on high bandwidth networks). I just did a quick test by directly streaming video over WLAN and it performed way better that VNC. I was able to stream a videogame smoothly on 30FPS, which is pretty impressive considering this was done in a very unoptimized way (netcat, TCP instead of UDP, etc.)
I always found rdp on Linux far easier to use than all that X11 network stuff. I think it was a neat idea to have it built-in, but also never quite worked all that smoothly in my experience and really does complicate things quite a lot. Sometimes the practicalities of neat ideas don't really work out unfortunately.
To be honest it's been quite a while, so you'll have to forgive me if I don't recall the specifics, but rdp was essentially "I start daemon, I run rdp [dst]", and it works", whereas Xorg involved a lot more mucking about with commands and reading manpages and whatnot.
I will admit that in part this was just my ignorance; I just used it to access my desktop on occasion from my laptop on the sofa and didn't really want to spend a lot of time on it. rdp was "it works out of the box effort-free and I can move on with my life" and X11 wasn't. Maybe I just didn't RTFM hard enough, but I didn't have to RTF anything for rdp, so...
I use samba/SMB for similar reasons by the way; recently I wanted to setup a network drive (for the first time in about 10 years) and samba provided a much smoother "just works" type of experience than NFS. Sometimes I find the old-type Unix stuff a bit painful, especially for the "just want to get shit done" type of workflow (I did use NFS extensively with FreeBSD and NetBSD back in the day, but it seems I've forgotten almost everything).
Huh, interesting. I made that conclusion based on how I see objects loading, with sharp outlines appearing before other elements. Also, some programs which draw their UI in a specific way become very slow, presumably due to some kind of graphics sync, something that I wouldn't expect from a video based protocol.
Even on X11 almost nothing sends server-side rendering command anymore. Almost every recent application (save for suckless stuff) renders cliends side, which means that if the x server is forwarded over the network every frame is a bitmap download.
It's an extremely inefficient way of doing things and it should have improved upon but wayland choice to just discard this use case was, imo, extremely narrowminded.
That's not as true a you may think. While Gtk+ and browsers do render everything locally using OpenGL and what not, Qt has these days a way to fallback to just sending simple rendering commands over the wire, and most other toolkits do use render commands too. Admittedly for a lot of desktop users "browser" covers 100% of what they do with the desktop, but for many professional/industrial users does not.
> I don't think any future graphics system, be it Wayland or something else, will support it
Which is another reason xorg isn't going to disappear, since large labs absolutely need computer A to display a resource-intensive program running on more-powerful computer B
The X protocol is only really necessary for the opposite case - for allowing powerful computer A to render the display of a weak computer B. If B is powerful, it can render the display itself and send the rendered images, as I was mentioning earlier.
The idea was I sign in to my underpowered workstation and run spice (or whatever) on the more powerful server. I would like the outputs to display on my weak computer. That's the whole point of this, and labs still use it religiously.
That “the network is slow” is not something I am willing to accept and go to great lengths to make sure it doesn’t happen. Which is why I run a virtualized Linux(with PCI pass thru)for max wifi performance and have a 10Gbit internet pipe at home.
Besides, we are talking local virtual machines in my case. Any performance issues so far has been negligible.
> While it's a cute idea, I doubt this feature of X has serious support behind, and I don't think any future graphics system, be it Wayland or something else, will support it. Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream.
I totally disagree. Obviously it just depends on your use case, but most user interfaces are almost completely static and sending vector commands is going to be a win over raster in almost any condition. Low bandwidth? Vector wins. High RTT link? Vector wins. Dual 4k screen? Not a problem with vector, but difficult with video and disastrous with raster.
One may argue whether the current implementation in Xorg is useful or not, but conceptually, I see vector as definitely the way to go. Vector even allows you to do some predictive interpolation, while raster -- good luck.
Maybe sending HTML+javascript over the wire is the solution, ala Display PostScript except more fashionable these days. Thinking about it, one could argue that's exactly what we have these days with the web...
If your UI is basically static, your video stream will also be low bandwidth.
Sending vector commands only makes sense if you have simple vectors. That isn't the case for modern apps and can't be the case for many kinds of apps.
Have you tried modern remote desktop solutions, like Parsec? Streaming 4K games or CAD works quite well, latency is about 20ms over the internet, low enough for most things.
We have had like one hundred X11 replacements between 1990 and now, and at least half a dozen have caught on with the open source community
What makes Wayland different is that it has attracted multiple vendors supporting it. Most notably IBM/Redhat, Intel, AMD, and, to a lesser extent, nVidia.
I am posting this message from an X11 environment, because I need X11 for a lot of things, home and work both, but, I can at least imagine a world where Wayland is the new default. That is not something I could say about the last hundred attempts to replace X11.
Edit: Again, this is just a suspicion. A notion. I neither hope for Wayland's success nor failure. I just keep my finger to the wind.
The core wayland protocol have so many missing piece and many extension are not standardized nor well defined. This is basically killing the interoperability between UI toolkit for non-trivial cases.
Well.... yeah? GNOME doesn't care about interoperability; they're the ones known for ex. suggesting that applications remove features for other desktops because GNOME doesn't use them ( https://trac.transmissionbt.com/ticket/3685#no1 ).
Wayland might be the future (though I'm personally a bit skeptical). It is already the default on many distros. At the same time, X11 is very unlikely to just stop working or disappear, since there's really no good reason to kill it.
X11 will stop working if things stop supporting it.
Stuff might eventually decide to render directly to Wayland only APIs or something.
I'm actually not a very big Wayland fan, I prefer the single implementation model rather than all the different implementations of Wayland.
But I'd rather have just only the Wayland fragmentation mess, instead of the Wayland mess plus also X11, so I'm glad Pi OS and Ubuntu(Right now the only distros I pay much attention to) have switched.
Agreed that it’s made the best show of attempting, but Wayland’s only got about nine years before it’s as old as x11 (the protocol) was when the Wayland showed up.
If it’s gonna mostly displace x11… man, it’s sure taking its time.
It’s older than xfree86 was when the xorg fork occurred.
Tons of X11 infra will have to remain for a long time to support X11-only "legacy" apps that can't easily be updated. There's a long tail of that from games to scientific software to just unmaintained software that still works and is used.
The major bit will be when and if toolkits like GTK, Qt, SDL, etc. drop X11 support and applications update to X11-less versions. AFAIK there are no plans for that and is still years away (there was some talk about GTK 5, but nothing firm and no one even started work on GTK 5).
I also think Wayland will eventually replace all of X11, in the same way as IPv6 will eventually replace all of IPv4.
Well, also libX11 and all of that type of stuff. And as I understand it XWayland shares a lot of code with the regular xserver (it's built from the same repo).
Yes, it just sits in a Wayland "container". So we can have security/fractionalScaling/modernMultiMonitor by default and X.oldness when required for that last bit of stubborn software.
What I mostly meant was that for people who prefer to use X11, that will probably remain viable for a long time, without any Wayland. There's this notion that X11 is "deprecated" and that "no one is maintaining it", but the reality of it is far more nuanced. The main "flag day" will probably be when toolkits start shifting away from X11 to Wayland only, and applications start using them (there's usually big lag between release and widespread adoption of new GTK versions and such).
Some qualified language in all of the above, because hard to predict the future etc. etc.
> What I mostly meant was that for people who prefer to use X11, that will probably remain viable for a long time, without any Wayland.
Or, if necessary, with just a tiny bit of Wayland; XWayland rootful mode lets you run a full X stack with Wayland as little more than a shim to the graphics driver. As a worked example, Puppy Linux implemented this: https://github.com/puppylinux-woof-CE/woof-CE/pull/2265
RedHat pushes hardest, they basically do GNOME, GNOME does GTK. So GTK will be first --my prediction-- to drop X11 support.
People that prefer X11 is not what I'd optimize for. To me X11 is deprecated, unmaintain{ed,able}. It became too much of a stumbling block for Linux and other opensource OSes. It's painful, but we have to move on. Wayland is not perfect but it seems to be doing the job lately. In two year --my prediction-- it will be more stable than X11 in all aspects.
> People that prefer X11 is not what I'd optimize for.
I wouldn't either, but that doesn't mean it won't work.
both Wayland and X11 are fairly stable AFAIK. For my part I'd rather not rewrite all my X11-specific stuff. For some I probably need to have direct compositor support as you can do less with scripts, so that's not so easy. I'll probably have to spend the effort at some point, but until I don't have to: why bother?
I'm also using X11, even though I've attempted to switch to Warplanes twice and had to switch back due to screen sharing and remote desktop being trash or just breaking after some update or other (most recently, browser). It's a work machine and I simply can't waste an hour fucking around with it. Aside from those issues which are deal-breakers in work, there's a bunch of minor annoyances I won't go into, thrust not deal brakes but they're "there". With X11 everything I need just works. I'm on a bleeding edge distro (OpenSUSE Tumbleweed) so I'll probably try it out on a weekend every few months to see if it's better. But in fairness I did that before, made the switch and then lost screen sharing after some random update...
Screen sharing was the final hurdle for me. I switched to running Slack in a Chrome tab and it works better than it ever did on X11 for me. I've used it on both my work computers for a few years now and it's been totally solid.
Well, the main reason why Wayland even exists is, that the X11 maintainers got fed up with a design from a time when graphics cards were not even a thing yet and decades of patchwork. They wanted to move on to something that has way less technical debt. Sure, X11 won't go away anytime soon, but finding people who actually want to work and maintain that codebase will be more than a little difficult.
No, they mention that they work closely with the OpenBSD team, which maintains an explicit fork ("xenocara") that maintains the NetBSD ABI. It was OpenBSD that added wsdiplay and wsinput, which are frankly better in a lot of use cases than Wayland.
wayland's main purpose is to isolate ~~malware~~ proprietary software running in a container, which Xorg doesn't allow (unless of course you run nested servers).
It wouldn't be too bad of a goal if it had feature parity, which it still doesn't have.
X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.
It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.
There's nothing that forces a Wayland compositor to be written in C. I've seen ones written in C++, Zig, and Rust, but you could really use any language as long as you can still call the appropriate system/kernel APIs
Nothing preventing you from writing a X11 server in something else either (and people have done so!). But fact is, most wayland compositors right now are either pure C or C++ (and I think the rest uses at least wlroots?).
Many X11 window managers are written in non-c languages too and I don't think I am too far off the mark when I say that a decent fraction of wayland compositors would just be external window managers if there existed a standardized interface for window managers when they were written (I think some compositors have an interface for external window managers now, but is there a standard interface by now?).
Linux is not as secure as most tech people would assume at first glance. The monolithic kernel with all device drivers in ring0 is, let's just say, not the best approach if one were writing a new OS from scratch.
It is mostly "secure" due to it being used in practically every server and billions of devices, so there is an active maintainer community around it. Xorg has none of that.
Eh, wlroots is in C. Tons of the Wayland stuff is in C. There's a bunch of good reasons to prefer Wayland, but this is probably the worst reason I've seen yet.
Unless your application use GPU for rendering and you have more than one GPU involved, or have GPU driver that doesn't implicitly serialize events behind the scenes (as it should NOT), and your display stack has not yet migrated to experimental extension that patches Wayland with actual support for synchronized rendering (explicit sync).
If any of the above applies, tear-free behaviour is accidental, because Wayland protocol design fucked up synchronization primitives from day 1.
tl;dr the core protocol only lets you inform the compositor that the surface object is "ready" - which turns out to work effectively only for software drawing, or waiting possibly entire frame for your image to show up on screen.
That's if you're careful about calling "commit" on the surface only after whatever GPU draw calls you executed on it finished and the surface has been fully rendered to memory.
Turns out it somewhat works even if you're not properly careful because a lot of drivers (especially Mesa) had unspoken, implicit serialization happening in the drawing pipeline.
One issue is when you have more than one GPU (common on higher-end laptops). Even when you're rendering application surfaces on one GPU, they will often have to be synced to another GPU's memory to render them, because it's common to have some video outputs on iGPU and some on dGPU (example from my 2023 laptop: internal screen is behind mux that allows either GPU to exclusively write, but USB4 DP is iGPU exclusive, and separate USB-C DP is dGPU exclusive).
But with increased use of asynchronous rendering APIs (OpenGL AZDO patterns, Vulkan) and with variable refresh rate screens becoming more common (even if you don't have physical one, RDP/waypipe/etc are possible users for that) you can find out a situation where compositor will start drawing a window using a surface that is not yet fully rendered, bringing back tearing. It also means it's harder to properly utilize VRR in cases where applications render at different speeds (which is fine - not everything has to render at highest possible FPS), possibly locking you down to slowest rendering element.
So, the new extension, available if you ride latest patches on linux (the final part missing is new nvidia beta driver release, but not because nvidia lagged on the issue - nvidia apparently spearheaded it because their driver internals had no implicit synchronization), compositors are able to synchronize their rendering at the GPU level, getting fence objects for DRM buffer based surfaces. Meaning compositor can attempt to prevent drawing an unfinished surface, nor will application have to add extra waits in its display code.
Is there any definitive documentation regarding what causes X11 screen tearing? I've never seen it personally and most of the complaints I see on the internet are very vague.
I too have never actually seen this "tearing" despite being a Linux user for nearly 30 years. I am charitable enough to believe it is actually a thing, but somehow it has never impacted my life, so I'm kind of skeptical about arguments based on its alleged existence.
tl;dr: X11R6 is very healthy on NetBSD and has active contributors
from the same blog: Wayland is also approaching healthy on NetBSD and has active contributors
There is no reason to get bent out of shape. NetBSD as a project has commitments to desktop support and seems to be living up to those commitments very well.
What about the fact that X.org itself is unmaintained and falling apart? It's nice that the modesetting driver covers most new hardware, but without active maintenance and governance the writing is on the wall for X.org.
Without a Wayland story, the BSDs will really end up dying, at least as desktop systems.
Maybe give it a rest and let others have their toys without flying off the handle with comments that say or contribute nothing.
And it's not even applicable here; there's literally a linked post about how Wayland is being worked on in this article's first sentence. But I guess the volunteers of NetBSD aren't working hard enough or something.
X11 has been unmaintained not once, not twice, but THREE times and it's still the dominant system on UNIX-type things. Xorg is, itself, the thrice-disowned descendant of the o.g. X project.
That is what it is! It's fine! if Wayland is the future, so be it, but it won't be because X11 got deprecated again. X11 has been deprecated plenty of times before!
Wayland may very well take over the unix and most especially linux desktop story, but that is not a done deal, yet. My last two? three? jobs all explicitly required X11 as a thing, so if giant enterprises are not picking up wayland, the deal ain't done, yet, you read me?
It won't be replacing XOrg anytime soon, because XOrg is a walking example of "worse is better". Yes, it's ancient, bizarre in some ways, cluttered with feature bloat and a security nightmare. Nobody denies that.
The problem is that said feature bloat is also exactly what makes it attractive to desktop users. I'm not saying that Wayland has no use; it can reliably cover ~90% of all computer tasks and if you're just setting up some sort of kiosk/server with one application, I think it's hard to not pick Wayland since you can just grab a thin renderer and avoid all the extra crap that comes with XOrg.
But for desktop, the weird/random things XOrg allows you to do are what makes it the undisputed king to this date.
It's not what's best that wins. It's that what covers the widest amount of usecases that does, regardless of any amount of bizarre rituals that you need to do to get it working (and only if you have feature parity does less weird rituals take over in priority). Wayland already lost that race before it even started since feature parity with XOrg is a non-goal.
Other examples of this concept in action: Any old-school Microsoft project (really, just all of MS Office), the entire HTTP frontend stack, SQL, PDF.
And regularly releasing new x server versions. It seems like there's a new release every couple of months.
For example, in January this year, xrandr got code to allow for multiple virtual monitors on a physical display. In April, there were 2 bugfix releases.
If they were all-in on Wayland, they wouldn't be making regular xorg-server releases, and definitely wouldn't be adding new features to xorg components. (Because, yanno, they wouldn't have any staff available to do those things.)
Indeed; and if you read that article it says that current Wayland compositors depend heavily on Linux infrastructure, and have not yet accepted patches to support NetBSD. Everything Wayland on the BSDs is in the "one guy faffing about to see if he can get it working" stage. Unless/until the Wayland project starts mainlining BSD support, or the BSD projects have robust parallel maintenance of the core Wayland packages and compositors, BSD as a desktop system is dead in the water.
Ah, what a delightful opportunity to delve into the nuances of the English language and its wonderfully intricate idioms! Let's embark on an enlightening exploration of why the phrase "dead in the water" is certainly not the same as simply being "dead." For anyone less familiar with the idiomatic expressions and metaphors of English, this can be a fascinating journey.
To begin with, when we hear the word "dead," one's mind might instinctively leap to its most literal and unfortunate meaning—devoid of life. In biology, this means the cessation of all vital functions: no heartbeat, no brain activity, no breath. The ultimate and irreversible state that all living things, sadly, will eventually meet. It's quite final, isn't it? The end of the line. Kaput. There's no ambiguity here; dead means dead.
However, the wonders of language allow us to use words in metaphorical or idiomatic expressions to convey more complex or nuanced situations or states. And that's where "dead in the water" swims into the scene. This phrase, you see, has nothing to do with the literal cessation of life. Oh, no. It's far more colorful and applicable in a variety of non-lethal scenarios.
Originally, this idiom comes from the nautical world—a domain rich with metaphorical language, given the myriad challenges and adventures faced at sea. Imagine a ship, if you will, its sails billowing as it cuts through the waves. Now, picture it suddenly unable to move; the wind has died down to nothing, the sails slump, and the ship is merely adrift, going nowhere. It is, quite poetically, "dead in the water." The ship isn't literally dead, of course—it's just temporarily incapacitated, unable to proceed along its intended course until the wind decides to grace it with its presence once again.
Transposed into everyday usage beyond the high seas, "dead in the water" is a vivid metaphor for projects, plans, or initiatives that have come to a halt—stymied, unable to progress, much like that becalmed ship. It's used to describe something that has little hope of success or revival in its current state. For instance, if a business venture runs out of funding or a new policy is halted by regulatory issues, they might be described as "dead in the water." Not literally deceased, but stuck, with no forward momentum.
In essence, while "dead" is the cessation of life, "dead in the water" is about cessation of progress or movement—figuratively speaking, of course. The latter suggests a temporary state, a problem potentially fixable, perhaps with effort, change in strategy, or a shift in external conditions, unlike the permanence and finality of being literally dead.
Isn't it simply marvelous how language lets us draw such specific shades of meaning with just a tweak of phraseology? Through this exploration, we can appreciate not only the richness of English idioms but also the joy of explaining something so deceptively simple yet profoundly different. Here we stand—or float, if you will—at the junction of literal and metaphorical, grasping the beauty of expression. And isn't that what language is all about?
Language is great and rich and all that but you forget too quickly that it's a two way street. Nothing gp said implied that they didn't know the idiom. Indeed, it seems obvious to me they were just being concise, which is perhaps a virtue of prose you could benefit from.
As an outside observer, it seems reasonable to assume asveikau missed the figurative language. The original phrase used was "dead in the water," which as noted does not imply death; however the response alleged that death was (rudely?) what the original commenter was talking about.
Seems blown out of proportion, at least partially because of missing figurative language. The above wall of text seems a long-winded, somewhat tongue-in-cheek way to say "yeah I didn't say that."
The guy in the old west who drew his gun and said “them’s fightin’ words?” He probably didn’t enough English to understand the whole sentence but picked out a few words which meant to him “fight.”
Of course not everyone understands English perfectly. Even among native speakers it's easy to misunderstand (especially on a web forum). I wasn't making a judgement.
Anyway, it was pointed out that the same user that said "dead in the water" did indeed comment upthread that BSDs will "end up dying," so goes to show that I wasn't paying attention.
I am a native English speaker raised in Washington DC.
I am literally pointing out that Wayland enthusiasts love to gang on X11 as "dead" as a put-down and anybody who still uses it is evil or something. It's a toxic attitude that I've seen a lot here. It should ... pardon the metaphor .... die.
I think one should allow others to look at the entirety of the thread started by bitwize, where they claim:
> ...the BSDs will really end up dying,...
That wasn't very figurative, even if "dead in the water" was. For all it's worth, bitwize might have been using that figure of speech inappropriately when they really meant "dead".
All this to say that even as an outside observer, one can read exactly the same things differently, so perhaps we should all get off our high horses and start riding ponies or bicycles (what? :)) — I mean, back to the discussion at hand.
> As an outside observer, it seems reasonable to assume asveikau missed the figurative language.
No, I didn't miss it at all, and this is a weird take.
However, its appropriateness as a metaphor does have to do with the literal meaning. Even a less maintained software project with a longer-term deprecation roadmap that still has millions relying on it is not "dead". This very article is talking about how the *BSDs are putting more maintenance into that tree than upstream, and those are actually signs it isn't a total dead-end; they've done that maintenance over the years because it's valuable to them. But bitwize was calling it dead in an attempt to put it down. I've found this particular brand of negativity is very common in Wayland enthusiasts. It is like ad hominem in software maintenance discussion. The source is available for anyone to hack on and use, or not, as they please. There's no sense in ad hominem attacks, exactly as bitwize engages in above, for that.
To be honest, the attacks like this remind me of the XZ backdoor. The sock puppets in those mailing list threads complaining, I would say whining, about "dead", "unmaintained" libzma were channeling the exact same energy. Cool it down. It's not necessary.
I think it's more the detail they lost (or do not agree with) is that working successfully in multiple environments can valide the strength of the design. Some people will look at a slightly different structure underneath and see it as noise and hassle instead, where you or I may see their action as taking unnecessary or questionable dependencies.
The short version is that the Linux ecosystem has for whatever reason spent a decade or so resolving the already-solved problem of "who is logged in to this TTY?" and came up with a new way to solve that that the BSDs don't in general implement and Wayland relies on.
Red Hat wants it to be really hard to remain compatible with Mainstream Linux (whatever Red Hat does) while also differentiating your distro from theirs in meaningful ways, and wants some good old “fire and motion” against competitor distros.
At least, I think everything they’ve been up to and these projects they heavily influence have been doing makes a ton more sense if that’s the plan. It’s that or a lot of weirdly-hostile and disorganized stuff has been happening by chance in a way that achieves that effect by accident.
> Without a Wayland story, the BSDs will really end up dying, at least as desktop systems.
Good news then, FreeBSD already has working Wayland and NetBSD is working on it. Granted, I think OpenBSD stands out without a Wayland plan, but maybe I'm wrong there.
When you look at how long it’s been around versus where Xf86/x.org were on a similar timeline… yeah, we’re almost halfway through the life of the project, if history repeats itself. Its replacement may be expected to start designating it “legacy” and its boosters sneering at out-of-touch Wayland users well inside a decade.
(It fares better compared against x11 instead, but not as much-better as one might guess—either way, it’s been a sloooow moving project)
All of that things that weren't truly handler right by wayland anyway, thanks to pushing everyone and their pet hamster into implementing complete display servers :P
I find especially funny how Wayland attempted to have "tear free done right"... and the expected display path (GPU accelerated) turned out to either involve 1 or more frame delay, or tearing because Wayland protocol didn't support explicit sync on render finish.
