What does Wayland actually do better

what does X.org do better

>>105870287
Lower input latency, up to 2 frames (33ms) faster.

>>105870199 (OP)
>What does Wayland actually do better
It's not 10 millions lines of code (including a printer driver) to do:
1. Get a GPU buffer
2. Draw on it on time
3. Occasionally handle inputs

X is a lot of useless lines of code and dead code and useless features no one cared since 1990, all of which are bypassed using modules because since 2007 you really only cares about:
1. Get a GPU buffer
2. Draw on it on time
3. Occasionally handle inputs

But of course the whole thing is tarded and the X protocols is famously slow and stateful and a lot of bad stuff, even if you bypass 99.99% of the code using modules you still need to keep the tarded proto.

Wayland was 3 years too late and should have been widely adopted 8 years ago.

>>105870348
How does this affect me, who wants to run applications

CCP wants you to use more complex software with higher chances of security issues
That’s all this and many other threads are
CCP garbage

>>105870348
Then why is Wayland consistently and measurably slower than X11 both in terms of latency and raw profiled speed?

HDR

>>105870402
>CCP wants you to use more complex software with higher chances of security issues
Even if X.org is several millions lines of code overbloated, I don't think the CCP would invest any amount of money to torpedo Wayland. It seems a little bit paranoid. Nvidia, though, tried, but that's just Nvidia being a shitter like always.

In any case, anyone knows the X protocol among its countless other issues is not a security risk, it's a security clusterfuck, so any half competent admin sys will force you to use NX. NX doesn't solve the X protocol, nor its probably thousand of security holes, but it forces at least the attackers to work for it.

Point is, I don't think the center of the issue is security.

>>105870608
Works on my machine.

>>105871410
Subhumans can't detect 33ms latency

>>105871444
>works on my machine
>n-no it doesn't
What?

>>105870348

Xorg is 221 kloc actual display server including all the deprecated stuff and 188 kloc drivers for dead VGA cards.
Every basic thing in Wayland is crazy complex at the level of X11 or much much worse.

1. "Open registry"
2. "Enumerate existing objects and find wl_shm, xdg_wm_base, wl_compositor, wl_surface, wl_buffer, wl_seat".
3. Instantiate each of these with the expected versions not missing details like "wl_seat < 3 doesn't understand mouse wheels and if you don't check that and still send a wheel you crash with nonsense messages" and bind to a vtable.
4. Create a shared memory buffer and fill with pixel data according to some format, do check that your pixel format is in the set of 30+ formats that it can chose to expose or not expose" and bind that buffer to to your wl_buffer.
5. Use wl_compositor to create a wl_surface and bind the wl_buffer to that surface.
6. Attach that surface to a xdg_wm_toplevel from xdg_wm_base.
7. Commit the surface and register a frame callback so you know when you can draw next.

Now you (possibly) have a dead surface without any decorations. Hello world achieved, without help other than libwayland-client that should land you at about 1kloc for what other systems can do in 20.

Then dig through an infinite pile of XML files scattered in the quantum fucking wind to try and work yourself towards the basic shit any client expects. Then try and create fallbacks for the handle the cases where someone's compositor didn't also find the the same definition. There are no tests for any of this.

Joke without a punchline.

>>105870348
Well said. To the point, even if a bit oversimplified.

>not 10 millions lines of code
X.org is more like 1.2 millions lines of code, but I understand it's a hyperbole.

>X is a lot of useless lines of code and dead code and useless features no one cared since 1990, all of which are bypassed using modules because since 2007 you really only cares about:
>1. Get a GPU buffer
>2. Draw on it on time
>3. Occasionally handle inputs
That's the crux of the issue. The X protocol was made in a time when you expected the X server to handle fonts, text, filling boxes, and filling boxes with colours. Degraded colors. Shadows. Basically clients sent commands like "display A in that font with a shadow" to the X server, which then did its best. A lot of code was made for the X server to handle the most inane of graphical commands.

This was a 1988 paradigm. It worked. The protocol was also kinda extremely slow (each command are sent *individually* and then *acknowledged* individually, introducing many round trips, which wasn't an issue when you were in a fast LAN in 1988 with extremely weak computers, but is nowadays) and also kinda bad (if there is an error the X server returns *lmao there was an error* to the client, it is to the client to know what it did wrong, OpenGL had the same philosophy).

Except nowadays we expect things to our fonts, like, I dunno, anti-aliasing. And all of this is not handled by the graphical stack, but by whatever library you use to actually display characters, which simply put them into a GPU buffer. This hasn't been handled by X since yes roughly 2008. Well, more like early 2000s.

But the code remains. The protocol remains. The absurdly huge amount of code remains.

Since early 2010s, all any conceivable graphical softwares ask of X.org is: a buffer, a draw() command, and the input on it. Both of which are handled by two extensions to X.org, Xinput and whatever is for gpu access I forgot the name.

>>105870348
Just implement WDDK for Linux already

>>105871694
So X works like a GPU and can offload it’s graphical drawing primitives to a GPU, and wayland acts like a memory buffer and forces everything to manually draw into that buffer.

Got it.

So wayland is not there, functionally or even conceptually, and never will be.

Thanks for the explanation.

>>105871603
>1. "Open registry"
>[...]
>7. Commit the surface and register a frame callback so you know when you can draw next.
And? It appears to me the bare basics to get a buffer correctly on a modern system graphical stack. It's even a bit simpler than the equivalent under iOS and Windows. I don't understand the point you're trying to make, honestly.

>Every basic thing in Wayland is crazy complex at the level of X11 or much much worse.
Ah, you don't get it, I understand. Ok. That? Getting a buffer correctly from the GPU drivers, the kernel? This is handled by the obsolete X server in an obsolete graphical stack, so you never see it.

Like everything with X, it's not where it should be handled. It should be handled by the application, the libraries you're using, not X.org. It's where it is handled since early 2010s. Especially when X does an especially bad job of it. You want a buffer, you need to specify what kind of buffer you want. X adds ton of bugs and latencies over what should be an extremely simple job, but yes, technically, does some of your job for you - in the worst way possible.

But let's assume you are right, for the sake of the argument, and Wayland is difficult to use (which it isn't, it's your own incompetence speaking), you're not fighting the real issue that X11 is an obsolete server full of obsolete code, serving an extremely slow protocol full of security holes, that no one wants to maintain anymore (the X.org dudes literally bailed out when they saw the iPhone 1 graphical stacks, it's hilarious, they looked at the iPhone 1 and literally said "the fuck am I maintaining this piece of shit", look at it, it was hilarious).

>>105870199 (OP)
VRR, running hyprland, triggering tinkertroons

>>105871402
Wayland is an extreme security risk.
They just “fixed” this DOS attack that makes it burn CPU forever in an infinite poll loop by hardcoding the buffer size, and now the dynamic buffer resizing code is dead.

In the 90s, on X on sun machines, we were already using 8k packets over loopback (just memory with access controls, really).

The problem is the wayland perpetrators really don’t seem have any experience in software development, computer architecture, networking, graphics, etc, so you’ve got this thing where if you send it a 4097-byte message, it’s now permanently burning a core 100%

>>105870199 (OP)
It offers corpos this: Wayland is licensed under the MIT Expat license.

>>105872096
xcels btfo, its actually so retarded how people keep shilling for x as if it was good at anything it did and everyone wasnt always constantly complaining about it for decades

>>105872096
> It should be handled by the application, the libraries you're using, not X.org
Doesn’t understand X and wayland are made up of, and have, libraries.
Sure, you can just open up memory windows to the GPU and do everything yourself or with “libraries”

> … b..b..b..ut osx and ios, it’s hard… really really hard so I reach for the logo programming language
Move those goalposts, eh?
The primary difference was X historically supported IBM and SGI graphics hardware on high end workstations, so they knew what they were doing.
Wayland’s developers know how to play videogames (probably) but consider the gnome desktop to be the pinnacle of human achievement.

>>105872012
Don't be tremendously silly. The whole point of getting a GPU buffer is to use OpenGL/Vulkan to draw on it. Which is why Wayland's whole concept is to get you a GPU buffer with the minimal lines of code, which is the entire point of this affair, really. iOS and Windows do exactly the same thing.

X11 has 1.2 millions line of code that are not GPU accelerated that handle things like 1990 fonts. This is kinda the problem.

>>105872216
It's not that X is good — it's that Wayland is somehow worse.

>>105872276
> bitmap fonts.. i cannot abide
It must be weird living in a world where you can’t sleep at night knowing your linux distro might have “dead code” like drivers that support old-fashoned mice and keyboards… even ps2(!) keyboards…

…instead of exclusively touch-screens with haptic feedback as the only acceptable input method.

> wayland devs don’t use bitmap fonts
Yes they do! In fact they use non-blurry fonts every time they have to drop into one of the ctrl alt F3 console sessions to kill their locked up wayland processes. Which is literally all the time.
In fact, when wayland starts, it should put a big system modal dialog up on the screen.

They can’t print it out, because their printer drivers and printer ROMs were re-burned to get rid of bitmap support.

Don’t tell them that GPUs support bitmap operations.

>>105872346
this

>>105872346
its literally not but ok

>>105870199 (OP)
It's better at consuming more watts

>>105870336
>2 frames (33ms)
What if I have a 144hz monitor?

>>105870371
Google measured eight years ago that 70% of Chrome launch was lost inside X protocols roundtrips and callbacks. Something like 1.3 seconds on 2s. Also they said their only recourse to know if X was badly configured was to launch a process using it, and if it crashed without reason, then X was badly configured, because literally X couldn't give them anything else as an error message other than crashing Chrome.

>>105873405
Two frames is like 14ms.

>>105870336
Take your meds

>>105873641
>chrome
okay but how does that affect me personally

>>105872118
>running trannyland

>>105873766
Well if Google is willing to put a lot of money in order to only admit failure and that X adds a 70% latency on the launch of their star application, I think many other applications lose much more than that.

In fact much of the issues with the latencies on click Linux has can be rooted on X. Pretty sure. Android doesn't have that problem.

>>105873806
maybe they should start improving their shitty applications written in pajeet code then.

>>105873887
but both kde and gnome basically said the same thing at the same moment, impossible latencies, shitty server, stupid proto, too slow, can't answer any of our questions about how it didn't work

i mean, I hate both of those, but when everyone who has ever worked on X shits on it, including corpos, including DE devs, including rando on the internet, including X.Org devs who literally fucked off and made several conferences about how X.Org was shit

you can't help but wonder, you know

Maybe it isn't shit. But unlikely

>>105873740
Measure it https://gitgud.io/CrunkLord420/crunkbench/

>>105870199 (OP)
HDR.

>>105874017
Points for being autistic enough to create a kernel module doing that.

Minus points for not being autistic enough to understand what is X, how Wayland works, and why Wayland is better, and not trying to understand why your test failed.

>>105870199 (OP)
Its X with the dead code removed and some extra questionable design choices added.

>>105874071
>He didn't measure it

>>105870199 (OP)
better at being IBM and redhats testing ground for AI

>>105874071
so why is Wayland better?

>>105870659
>>105872118
>>105873405
>>105874036
you dont need that

>>105870199 (OP)
it can draw non-square windows and do 3d TRANSformations.

>>105874017
What if I don't have a numlock button

>>105874344
You can do it with any LED your kernel recognizes. It's arbitrary. Ideally you'd build a USB HID out of a microcontroller so you can ensure the reliability of the firmware driving the LED.

X can't even draw rounded corners

>>105874398
Use case for rounded corners?

>>105874582
theyre a lot more comfortable for your mom when im shoving her into a corner as im fucking the shit out of her

>>105874327
Yes I do, I will literally die if I don't have those things
Also the question is "what does wayland actually do better" and you got your answer, fuck off

>>105874647
but it doesnt do anything better

>>105874679
But it does and you got dicked down

>>105870287
Window managers
Screen recording
Screen shotting
Low latency drawing
Longest running graphics API used by popular software
Remote drawing
Not being extraordinarily gay

>>105873740
We sit in front of video terminal emulators 12 hours a day. Yeah we fucking notice if you add an entire frame of latency.

>>105870199 (OP)
trackpad gestures

>>105870199 (OP)
study the xenomorph?

>>105874398
AeroThemePlasma works just fine on X, in fact it's buggy on Plasma

>>105874398
AeroThemePlasma works just fine on X, in fact it's buggy on Wayland

>>105872749
>It must be weird living in a world where you can’t sleep at night knowing your linux distro might have “dead code” like drivers that support old-fashoned mice and keyboards… even ps2(!) keyboards…
You're still tremendously silly. You're a little troll, aren't you? Are you cute? You are very cute. *pat on the head* You are very cute. Trying to be silly. Ah. Here, you're a good boy.

But if you're somehow serious, the entire issue with Wayland vs X stupid conversation is that software since a decade ago only want access to a GPU buffer in a sane way to do their own GPU magics, in a sane way. And X is so insane the X.Org devs needed to patch X several extensions which were just used to _bypass_ 95% of the X.Org code just to handle the far off case of "I want a GPU buffer pls".

And then they loudly, loudly said X.Org was never made to do that.

And then everyone saw the 70%+ latencies introduced by the most overbloated graphical stack imaginable. And then many X.Org devs literally said "I can't take it anymore" and fucked off when they discovered smartphones. That was 10 years ago.