Thread 106286524

They both suck. Wayland had every opportunity to be desktops done right, but it ultimately doomed itself with poor design choices just like X11.
Call me when we have a third option.

>third option
arcan

>>106286524 (OP)
Just be normal and use Windows. Linux is a waste of time unless you have a spare laptop that you don't care much about.

Latency concerns are exaggerated.

>>106286525
Arcan uses xwayland, it's not standalone like xorg. Don't get your hopes up. Ultimately its just a hobby project.

>>106286551
For fuck's sake. Guess I'll install Haiku then.

>>106286544
no offense but with glfinish, a +37% latency penalty is very fucking noticable.

>>106286605
Now see without glFinish() :^)

Valve chose Wayland. No tech-adjacent company of any significant size has done the same with X. Therefore, Wayland has a future, and X does not. Therefore, Wayland won.
>inb4 "but steam deck ACKSHUALLY defaults to X on desktop mode!!!"

>>106286672
Valve is not happy with the choice though and has to try and persuade Wayland developers to extend the spec to allow them to bypass certain things to improve the performance.

>>106286528
that's the npc parrot take

>>106286672
Wayland won by default, not because it was any good.

>>106286631
vsync off is vsync off , if we don't know the frame rate its meaningless.
aka a frame of lag at 200fps is only 5ms, vs 33ms at 30fps

>>106286735
All are with Vsync. Max FPS is a 59 cap.

>>106286672
valve has the money to hire people to patch gayland into whatever they need for steam

>>106286927
post src then faggot

Not really about choice when RedHat is involved
>dbus
>systemd
>pulseaudio
>pipewire
>wayland
Wayland isn't the first software from RedHat that seemingly gets adopted by everyone even if the concept and or implementation isn't the best, my list even isn't half done. The fact that RedHat made it means it'll be the "winner".
And also that Xorg is also controlled by RedHat so if you want to keep X11 going you have to fork it.

I have no problems with XLibre and MATE, I don't know what more you could want? Everything just works flawlessly for me

GUIs suck, just like USB.

More at 12.

SurfaceFlinger but nobody in the Linux desktop scene is ready to take the binderpill

>>106286524 (OP)
I think Wayland is actually best platform for a desktop. I really like consistency and predictability in window managing. All the problems with Wayland are coming from X11/Windows devs when they try to use their retarded principles on Wayland and rage when it doesn't work.
Most window managing issues are coming from X11/Windows retardation, where half of design choices are retarded, and the other half was left for backward compatibility. Windows doesn't even have any window managing, it just gives the applications ability to move themselves and tell developers to fuck off. And then you have shit like application starts in the middle of two screens because developer tried to implement heuristics to launch application in the middle of the screen and didn't account for multi-monitor case.
I've seen (and fixed) a lot of issues with application (primarily games) on Wayland where issues were caused by devs implementing such things as "position save", or placing window at 0,0 because on Windows primary display is located at 0,0 (which even hurts X11 configuration when display at 0,0 is not primary). And then developers whining "uuugh, why can't I embed window into windows?" or "uuugh, I'm playstatyion emulator developer and I NEED fine control over my window positing even though my application has like one window and would have no problem just letting the compositor managing it".
I think world would be a better place if ALL window managing protocols would adopt Wayland principles. Protocols like xdg-session, xdg-toplevel-tag and xdg-pip should already fix ALL the issues caused by Wayland restrictions.
>>106287663
Wayland restrictions caused controversy in desktop community? What would fix this? Even more restrictive display manager!

>>106287836
>Even more restrictive
Retard
The WM can provide more control to clients if it wishes

>>106287857
>The WM can provide more control to clients if it wishes
Care to post protocols that implements this functionality on Android?

>>106287836
bro the problem with wayland isn't that it can't work, its that it gives you NOTHING, and expects everyone to play nice and agree on standards.
which they have indisputably have failed to do,
the fact that color management was literally stalled for 5 years for some pedantic masturbatory retardation is proof enough

as far as I'm concerned the people running freedesktop are functionally retarded, and should expel all of the cucks that block this shit for no reason.

>>106286525
Complete Bollocks.

Arcan is standalone or run inside another desktop just as one would do with Xnest.

I use it standalone.

The arcan-wayland protocol bridge (-DDISABLE_WAYLAND=OFF) that you wrap around a Wayland application if some useful wayland client ever arrives supports Xwayland. That's a last resort if some x11 ever becomes dependant on Xwayland specifically.

They have their own Xorg fork "Xarcan" that works great for me and does shit the others can't. https://arcan-fe.com/2024/12/25/arcan-0-7-the-all-tomato/

"In the last release post we hinted at how Xarcan can be used to keep your own window manager, letting Arcan act as a display driver — as well as a security, control and configuration plane that selectively merge in arcan native clients with options for how, or if, X clients gets to see inputs and clipboard action."

>>106287895
>its that it gives you NOTHING
Why you mean by "you"? As a user I get next things:
1. Tear free experience
2. Sane compositing
3. Sane window managing
4. Multimonitor support with different refresh rate
5. Secure display protocol (no applications can spy on me by abusing display protocol functionality.
>and expects everyone to play nice and agree on standards
Yes, and?
>which they have indisputably have failed to do,
How so? Most of my applications are running on Wayland. Those who don't run aren't doing so for ideological reasons.
>the fact that color management was literally stalled for 5 years for some pedantic masturbatory retardation is proof enough
Color management didn't "stalled", it was actively developed and most of its development went into kernel and mesa. When KDE implemented HDR support the necessary bits weren't even in kernel and mesa.
Prolonged development times of wayland protocols were also by no protocol testing before merging. Now with experimental protocols this should be resolved

>>106288012
>5. Secure display protocol (no applications can spy on me by abusing display protocol functionality.
This sounds like a pro on paper, but what this actually means is that you can't have global hotkeys, take screenshots, or record video without jumping through hoops, and even then it's infamously buggy.
This "security" is not something anyone ever asked for anyway. We use Linux because like to tinker with our stuff, and Wayland is very opposed to us doing anything of the sort. On X11, if you want to do or script something, you can just fucking do it, while on Wayland, no fun is allowed. I don't understand how anyone on /g/ can defend this kind of freedom-hostile (as in gentoo-freedom) software here. Must be some kind of corporate psyop to Embrace-Extend-Extinguish everything that made Linux good.

>>106287236
>valve has the money
Not if gayben keeps buying up all those yachts.

>>106286672
Valve chose wayland for the part that is as close as a kiosk mode as it can be, but had to use X for a full fledged desktop experience, go figure.

>>106288012
im am going to assume you purposly chose 5 things that i, specifically, dont care about.

>>106288012
>Sane window managing
Applications can't even know where's their own window.

ie. for an image viewer that you want to resize according to the image size shown, when you grow or shrink the window it will always do it from the top left corner as the anchor and most of the image might end out of the screen, In x you can reposition or even grow from the center, making navigating between images a more sane experience.

Turns out on wayland you can't know where is your own window for muh security, they just made it too restrictive, it feels like the firefox xul/xpcom debacle once again.

>>106288437
>Applications can't even know where's their own window.
So?
>ie. for an image viewer that you want to resize according to the image size shown, when you grow or shrink the window it will always do it from the top left corner as the anchor and most of the image might end out of the screen, In x you can reposition or even grow from the center, making navigating between images a more sane experience.
Wtf is that mean? My image viewer works just fine?

>>106288460
Your image viewer will probably just resize the image inside its own window, and even if an image takes 128x128 the window will still be the same size and just waste the extra space, if you use an image viewer that can resize itself to the images when you move to the next one and the image size is bigger or smaller, then it will work great on X but it'll work like shit on wayland.

There's also some software that creates new windows taking as reference something on their own UI as position, and that can't be done anymore.

>>106286524 (OP)
>but it ultimately doomed itself with poor design choices
No, it isn't, Wayland's design choice makes sense security wise and where desktop Linux is heading, the problem is that doing it the way Wayland does this makes things too complex and needs to be abstracted away for programmers I keep hearing devs need to do big changes to make Wayland work, that shit should be handled by the toolkit and good easy APIs.

>>106288537
>Wayland's design choice makes sense security wise
LITERALLY NOBODY EVER ASKED FOR THIS "SECURITY"

>>106288494
>Your image viewer will probably just resize the image inside its own window, and even if an image takes 128x128 the window will still be the same size and just waste the extra space, if you use an image viewer that can resize itself to the images when you move to the next one and the image size is bigger or smaller, then it will work great on X but it'll work like shit on wayland.
This sounds retarded. I use gwenview, and it don't change window size according the size (which is fucking great, why would image viewer change its windows when content changes, that mean ui control will go all over the place with next image which makes mouse experience fucking awful). If I theoretically need to browse images at 100% size I can make it fullscreen which will save space by hiding DE panel and position image properly while not fucking up ui controls.
>There's also some software that creates new windows taking as reference something on their own UI as position, and that can't be done anymore.
Wrong, application can make child windows and position themselves relative to parent windows

>>106288545
>LITERALLY NOBODY EVER ASKED FOR THIS "SECURITY"
You will be saying this now, but in a alternative timeline you would have shat on the Wayland people for not not having considered it and "making Desktop Linux as insecure as Windows".

>>106288537
They should have added more flexibility to it and just add permissions to the "risky" stuff so users can choose.

As it's right now windows can't even remember their own position, that's a more common usecase that this person might understand.

>>106288547

Or he can just say that, as he don't like windows remembering their positions, it doesn't make sense having the feature at all.

qimgv does the resize stuff while navigating thru images by default if you enable some option in the settings, I recently worked on making an option to do it with the zoom, the vid is a rough prototype that works only on X.

>that mean ui control will go all over the place
Why will I want UI on an image VIEWER, if I want to edit them I will open an editor.

>if I theoretically need to browse images at 100% size I can make it fullscreen
If i want to browse small images I don't see any reasons to make the image viewer take 100% of my screen.

I know it might not have an use case for you, but that doesn't mean it doesn't have it at all.

>Wrong, application can make child windows
There's something, can't remember what's called, that is not a window that can do that, but not windows.

>>106288597
In alternative timeline we would have "Wow, this new Wayland things forces windows to position themselves while macOS, X11 and Windows are managing windows themselves!"
And, you know, that sounds kinda logical. Why would windows manage themselves when you literally have application called "window manager" to do such task?

If gnome didn't go version 40 I might have tried gnome again but they had to go full retard.

>>106286544
/g/ posters (you) are absolutely retarded nowadays.

>>106288647
In the right timeline the window manager will manage windows positions and there will be a permission for when windows need to manage it themselves.

And in that timeline the menubars will also work on all applications on wayland, global menus or not, cause right now mumble can't be properly managed from wayland on kde (idk if it works on other wayland DEs) cause the window menu bar doesn't show up.

>>106288012
Almost everything on Wayland ends up stalled, and it would be even slower if Valve hadn’t threatened them with the frog protocols that would have lessened their grip on Wayland, as more DEs could have implemented Wayland+frog to bypass all their nonsense.

Stuff that was stalled for years suddenly started moving again when they realized they've gone to far and they might loose control of the project.

>>106288012
wayland is a protocol, it does NOTHING , you have to write everything yourself.

2. it was stalled, the original merge request was completely serviceable, and minimal changes were made to it, its the sort of thing that should take a few weeks to a couple months to decide on, not 5 YEARS, it literally took so long that valve implemented their own color management which kde also picked up.

>>106288843
I still don't understand whats your fucking point? Yes, it took some time to implement color management in Wayland, so what? No we have color management protocol, and it supported in gnome, kde, hyprland. It supported by mpv, native Linux games, wine-wayland driver in proton-em, even in firefox development. It's still not suppoted in Nvidia. And it will never be supported in Xorg.

>>106289001
>And it will never be supported in Xorg.
What are you talking about? Xorg has been able to load gamma luts and advertise icc profiles since forever.

>>106289031
>Xorg has been able to load gamma luts and advertise icc profiles since forever.
So you can have HDR on Xorg? Why Valve didn't implement it then?

>>106289001
you don't understand how dysfunctional it is that basic features take 10-20X longer than they should because the cock suckers running the thing are retarded, and that the way it is governed has led to fragmentation , where you need a different workarounds for different compositors?

This is plainly obvious to anybody paying attention, closing your eyes and ears doesn't make the bad stuff go away.


if all of those faggots had kept working on xserver, no matter how crappy they might think it is, nobody would even need to have a discussion about color management , because it would be implemented by the xserver and everybody would just use it, instead of 10 cock suckers jerking off for YEARS to accept a merge request they have no capability of improving because they don't even understand it.

>>106288680
Seethe

>>106289037
Just "color management" traditionally implies just gamma luts and icc info to clients. HDR is a separate thing.

>>106289057
>if all of those faggots had kept working on xserver, no matter how crappy they might think it is, nobody would even need to have a discussion about color management , because it would be implemented by the xserver
People couldn't even figure out how to make xorg work with multiple outputs lol, and you expect people to implement even harder things. Well, now you have xlibre so I guess all that whining about wayland is irrelevant because xlibre chads could just team up and make their dream display server, am I right?

>>106289037
HDR is being worked on for xlibre.

>>106289077
>Just "color management" traditionally
You're just bored and came here for shitposting? Talk was clearly about wayland color management protocol.

>>106289037
xserver was already abandoned it by the time valve wanted to do it. there was an extension proposed by nvidia in 2017 but nothing ever came of it.

>>106286524 (OP)
As a windows baby, I find it's incredible how shills war with each other and completely ignore the fact that they have nothing to say against op's point.
>only two fundamental display services
>in linux, which always has alternatives to satisfy tinkertrannyism
Grim and cucked by freedesktop.

>>106289103
What are you talking about? Dude is clearly implying that xorg fully supports color management and there is no problem implementing HDR in its current state.

>>106289082
>People couldn't even figure out how to make xorg work with multiple outputs lol, and you expect people to implement even harder things.
actually I don't, the xserver is already setup to support 10bit color, the video drivers already support all the necessary features, its just a matter of implementing the HDR spec, which was already proposed 8 years ago by nvidia, https://www.phoronix.com/news/X11-DeepColor-Visual-RFC, but abandoned because the xserver was already effectively abandoned at that point.

BUT EVEN SO, I don't actually care for X, its a piece of software that was designed for a different time, what I do care about is DOING SHIT THAT MAKES SENSE, and not being ABSOLUTE FUMBLING RETARDS , with the amount of effort wasted, they could have rewritten the X server in rust 3x over.

I'm all in for wayland to success but not if it's gonna be restrictive as fuck, I want software like autohotkey on linux, I don't want wayland telling me what keys a software can or can't listen, I want permissions.

>Hey, this software is asking to listen to all keys, do you accept? -> Yes / No
>This software want permissions to set its own windows positions, do you accept? -> Yes / No
Instead of removing features add permissions for it.

>>106289132
xserver already supports most of what is needed for HDR, but not completely, valve would still need patches to make it work afaik, though you might already be able to hack around it via a vulkan layer.

>>106289173
>xserver already supports most of what is needed for HDR
Bullshit. What was the latest version of xorg, 21? Most necessary DRM bits weren't there in 2021. When KDE 6 with HDR was released you needed patched kernel and mesa because those changes weren't upstreamed.

>>106286551
Arcan doesn't use Xorg at all, its window manager durden implements Xorg/Wayland protocol so users can use applications on it but you can use for example shmif applications if you want, you could use qtarcan plugin for example to run qt apps as shmif

>>106289196
xorg has supported 10bit color for ages,
it lacks the "dynamic part".

both wayland and the xserver use the same interfaces, the work for bringing HDR to linux started on the xserver, and those efforts were abandoned as time went on.
last effort was from nvidia, but nothing ever came of it.
https://www.phoronix.com/news/X11-DeepColor-Visual-RFC

>>106289068
flesh gpt

>>106287267
Someone posted it on Plebbit.
https://www.reddit.com/r/linux_gaming/comments/1mscqi1/wayland_opengl_latency_test/

Is it true that features like push-to-talk cannot be used in an unfocused app like Discord because of the "secure" design of Wayland?

>>106289300
They can't be used because Discord didn't implement support for them

>>106289304
>no no its their fault!
kek always the same with you people

>>106286672
Valve chose wayland because they needed a closed kiosk mode with only 1 window. But it's not really "wayland", it's a wayland compositor designed to run x11 application primarly. Many things in the compositor can only be controlled through X11: https://github.com/ValveSoftware/gamescope/blob/master/src/steamcompmgr.cpp#L7315
As you can also see at the top of the file, the compositor is actually based on a x11 compositor. It's by no means the same as any other wayland compositor and they use their own protocols instead of standard protocols because the standard wayland protocols are bad: https://github.com/ValveSoftware/gamescope/blob/master/protocol/gamescope-swapchain.xml#L71
>inb4 "but steam deck ACKSHUALLY defaults to X on desktop mode!!!"
Yes, they decided that outside of a closed kiosk, wayland is not usable and x11 is needed.

>>106289278
my next question would be is he measuring from the top or the bottom of the screen, 4.5ms is too small of a different to make sense, if wayland is buffering the same amount of frames as X why would it be slower? if it is buffering an extra frame, how is it faster than what is possible?

only explanation I can guess is that hes measuring from the top of the screen on wayland and the bottom for X or something to that effect. intentional or not , the data seems smelly to me.

>>106289103
Nvidia proposed that back in 2008. But nobody else was interested.

>>106289352
the deep color extension was 2017, you must be thinking of something else.

There is no point posting in these threads. It's the same thread everyday with the same shills posting the same bullshit over and over again no matter how many times they're proven wrong. This is how big tech works. They release garbage then beat every discussion platform into submission by shilling and pretending people actually want their crap that doesn't work. Plenty of other examples;
>systemd
>pipewire (formally pulseaudio)
>fear mongering about need to update windows
>linux in general now that it's windows clone
>any apple thread
>any cell phone thread
>wayland or xlibre hate threads
>webp

Notice how the moment something actually interesting was mentioned (Arcan) these faggots just make up lies about it. That's because they don't want to bring attention to any real project attempting to solve problems or improve our lives. See s6/66 and anything happening in non-Linux UNIX.

They can't participate in a real discussion because they have to stick to the same talking points and scripts. I bet anything there are multiple shills dedicated just to wayland here with plenty of residential IP addresses to burn for their army of bots.

>>106289351
They are the same. Look at the camera frames. Both get as low as 7. The sample size is just dogshit.

>>106288001
i'm sure this anon meant to reply to
>>106286551
anyway arcan wins for those that actually care about design :)

>>106286524 (OP)
>third option

jesus christ, please don't let there be more of these

i've switched to linux a year ago and discovering all this bullshit around X11 and wayland has been yet another user-experience-pitfall that makes me hate linux the more i'm using it

>>106289784
>he doesn't know about the frame buffer option
linux is about diversity and choice if you want something that works then go back

>>106286544
Every single wayland compositior has 1-2 frames of additional latency, up to 33ms. It's atrocious and instantly noticable for anyone with a functioning nervous system.

Wayland is genuinely worthless and a huge waste of time.

Your stats are fake because they're not measuring desktop latency. Wayland's numbers are far worse.

>>106290435
why is that, compositors are compiled into a single blob how is it they cannot compete against x11 in that regard?

>>106289278
It's not a real test because he's measuring full screen exclusive mode. It largely negates the issue. Which is 2 frame delay when in non-exclusive mode.

>>106290466
Software cursor atomic commit into the single framebuffer instead of just drawing it on top of the frame like everyone else.

Perfect frames autism. Kiosk display manager. Not intended for actual desktop usage.

>>106290435
Sway is not every compositor.
>But X11 is still best
By a few milliseconds. A whole frame would be 16.7 milliseconds, which matches the Sway result.

>>106291172
All Wayland compositors have 1-2 frame delay on cursor. 33ms is unacceptable and the fact Wayland devs gaslight people into thinking it isn't real is an embarrassment.

>>106292274
>All Wayland compositors have 1-2 frame delay on cursor.
Lol, no? Why do you just blatantly lie? As a matter of fact it's Xorg which has 1 frame latency guaranteed with compositing and vsync on: https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html
As for KDE not only it doesn't have any extra latencies for cursor it also has proper scheduling that ensuring you get the lowest latency for cursor.

>>106292274
>Wayland devs gaslight
Users too, as we see here.

>>106292530
Zamundaaa is spreading misinformation as usual. He doesn't know shit about X11.
>Due to limits in the X11 protocol when an application does VSync, the image from it goes to the compositor exactly at the time when it’s too late to present it for the current frame - it gets delayed by one additional refresh cycle
This is not a limitation in the x11 protocol. It's only how xorg server works.
>There is another big reason, another limitation of X11: the handling of multiple monitors. All the monitors you have are put together into one screen for X, which means that the compositor can only present one big image for all outputs at once. The result is that compositors can’t synchronize rendering for all outputs at the same time, causing stutter and limiting the refresh rate to the slowest monitors - and making adaptive sync with multi-monitor impossible
Same here, it's not a x11 limitation, this is specifically an issue in the compositor (in this case, kwin which part of the project that zamundaaa works on) and xorg server. The x11 protocol does allow per monitor synchronization, even with compositing. It explicitly states per monitor pixmap for crtc sync. I asked zamundaaa to point out where in the x11 protocol it states that all monitors have to be combined into one framebuffer and he was unable to answer that.

>>106293350
--- and you can create a compositor for x11 right now that runs on xorg server and synchronized each monitor separately by creating a pixmap for every monitor (crtc) and sync it to the specific monitor it is on with PresentPixmap (which allows you to choose which monitor to sync the pixmap to). This is non-blocking and you get an event back when the PresentPixmap has been synced to the monitor.

>>106286524 (OP)
xlibre is about to replace x11 and render gayland completely unnecessary, much to the chagrin of red hat shills

>>106286528
All hail the Desktop Window Manager.
All hail the Desktop Window Manager!
ALL HAIL THE DESKTOP WINDOW MANAGER!

member when a huge swath of wayland users didnt notice their monitors running at 48hz? i member?

>>106293654
And trannies alike, it's a win win.

https://www.youtube.com/watch?v=KdmNHM9BKY0

interesting video on the design choices made for X, the contrast in the quality of the thought process for designing X vs what is happening today is sharp

>>106295028
>21:13: keep as much out of the server as possible (window managers, etc)
>keeps server from bloating
And now here we are with a billion wayland compositors, all implementing their own compositing, window management, desktop portal (dbus) and pipewire support

>>106287836
>I think Wayland is actually best platform for a desktop.
The biggest problem is that it's really designed to give you nothing that the original makers didn't plan for. If your use case is slightly different to what they decided was the "Correct" way to use a desktop, you and your applications are fucked. When anyone calls them on this shit, they bleat on about security and policy over mechanism.
This is compounded by the terrible documentation, and the way that the makers decided to throw away everything about X instead of first asking what parts worked well in practice and could be stolen for their new system. Idiots. Imbeciles. Morons. Retards. Fuckwits.

>>106295028
but we no longer use applications over the network like X11 was intended for

>>106295416
Its not really the what x does that I find interesting in this video, its the design process, if you took the same approach to something like wayland, you wouldn't have many of the core issues plaguing its development.

>>106289304
lmao

>>106295416
You can use most applications over the network. Glx applications might try to force direct graphics but you can force remote glx.

>>106295028
45:42 something wayland compositors still cant handle

>>106286528
Windows has all the same issues as Linux but worse. It's all just behind closed doors rather than autistically argued about in public.

>>106295169
>>21:13: keep as much out of the server as possible (window managers, etc)
>>keeps server from bloating
So now the window manager gets bloated instead. Might as well kill off X at that point and just let Mutter et al do all the heavy lifting.

>>106295958
and thats how you end up with a billion different servers (wayland compositors) just to have different window managers

>>106286524 (OP)
>Call me when we have a third option.
fuck off, faggot

>>106295986
More, but smaller servers that are specialized. It's better that way. Xorg is a behemoth now.

>>106286524 (OP)
>x11? wayland? what are you talking about anon? i was asking what kind of pizza you wanted haha! sometimes you start talking weird gibberish i dont understand, but oh well. we gotta order soon, the movie we wanted to watch is gonna be on in an hour!

>>106295028
this guy would troon out if his timeline were shifted 30 years ahead

>>106289842
Linux is literally about freedom of choice and free software. If you want the official Linux experience and not to think about anything ever again then switch to Fedora or stay with Ubuntu. Nerds like arguing about minutiae. That's how it's always been.

>>106286528
shit bait, yet faggits fall for it

>>106296933
good thing the oppressive corporate environment kept people in check.

>>106289343
Wayland fags especially that guy you are replying to blown the fuck out.

Riddle me this wayland fags... If Wayland is so good, why is X11 still better and more performant at almost every single workload. Wayland is a regression.

>>106286524 (OP)
wayland is a protocol. add whatever you fucking want. if it works, others will follow.

>>106289343
do retards really use gamescope?
honest question.

>>106296658
But none of them are specialized (with the exception of gamescope). They all do the same shit, with the minor difference being window management. It's a huge waste of engineering effort.

>>106287836
should be fp because it's bp.
Wayland preventing retards shitting up everything like they can on Windows and X.org is based.

>>106301665
It's mostly useful for steam deck, but on desktop you can also use it to run applications that behave dumb or break when alt-tabbed (in other words, broken applications). You can also apply shaders to it like crt effect, upscaling with fsr and things like that but I dont use that. It also used to be the only way to play hdr games on wayland.

>>106301690
>HDR
oh, ya. I see.

>>106288012
>1. Tear free experience
>2. Sane compositing
>3. Sane window managing
>4. Multimonitor support with different refresh rate
These have nothing to do with wayland. There is no reason why you cant do those on x11. The first one has been fixed for 3 years also, TearFree is enabled by default in xorg server but they never put it in a release because the people in charge have explicitly said that they want to kill x11.
Do wayland retards actually never know anything about the x11 and wayland protocols?

>>106301727
there are multiple reasons though. X composition requires adding latency. I kek how you ignored the more important one like actual security too.

What's the point of wayland when it still depends on hundreds of x11 libs to actually work?

>>106301760
>X composition requires adding latency
No it doesn't. Thats a myth that wayland devs have spread. Point to me where in the spec it says that.
>I kek how you ignored the more important one like actual security too.
Xorg has had XACE for mandatory access control for over 20 years, with restricting what applications can do. NSA added it for use with selinux with a gui where you control access for every application, like android.
Now on wayland every application can read the clipboard to steal your password (which can happen because password managers like keepass copy password to clipboard since on wayland they cant write the password like on x11). On any wayland compositor you can also capture the screen without any permissions using internal wayland protocols. These internal wayland protocols aren't secured on any wayland compositor.
Wayland retards know absolutely nothing about security.

>>106301727
>2. Sane compositing
You mean a different compositor for every DE with its own unique quirks?
>3. Sane window managing
Wayland doesn't have a lot to do with window managing aside from having random limitations to annoy the actual wm developers.

>>106302531
>Sane window managing
i guess he means clients not knowing shit on how to position them self's.
If Wayland had EHWM with ha concept of window manager everyone would have switched by now

>>106302531
I guess you replied to the wrong post

>>106292274
>All Wayland compositors have 1-2 frame delay on cursor
That's by design to combat this.

>>106304852
That is not an issue on compositor presentation delay, that's an issue of opengl driver buffering (likely on nvidia). Gnome could fix it if they added a glFlush/glFinish to their x11 compositor.

>>106304938
to explain more, some drivers (especially nvidia) add extra frames of buffering to all applications (for smoothness or performance or whatever reason). This affects all graphical applications, it happens even if you dont use a compositor and just run a game with vsync on.

>>106304938
>Gnome could fix it if they added a glFlush/glFinish to their x11 compositor.
They already do. XFCE's OpenGL compositor is significantly worse than this. glFinish still leaves one frame of latency.

>>106304974
One frame yes, but in that video it's much more than 1 frame. That amount of delay happens with missing glFlush/glFinish. I think you even have to use an environment variable for nvidia to bypass default behavior.

>>106304982
>but in that video it's much more than 1 frame
That's just the triple buffering in action.
https://www.phoronix.com/news/GNOME-48-Triple-Buffering
It's only used when the performance is low. Latency remains good on a fast system. This was recorded on integrated graphics.

>>106304852
That is just awful. In a properly functioning windowing system the window should not lag behind the mouse at all. I have actually seen the window lead the mouse, this was typical in XP, since the GDI had zero latency, whilst the cursor surface was often updated on vsync.

>>106286544
https://mort.coffee/home/wayland-input-latency/
>Wayland, on average, has roughly 6.5ms more cursor latency than X11 on my system

>>106305003
In that case wouldn't the wayland one also lag more?

>>106305073
That's the point. You don't see it because the cursor is lagging too.

>>106305089
I dont believe you

>>106305112
That's pretty much what the testing shows.
>>106305018
That extra latency would have to manifest in some way, and the video demonstrates how.

>>106304852
You should ask yourself,
>Is it worth rebuilding the whole thing from scratch to fix this properly?

if you answered yes, you are mentally ill.

>>106301760
Kwin proved that you can do it without a latency penalty. It needs a little black magic to do it, but its not impossible, X compositors are laggy because they tend to use triple buffering, not for any technical limitation.

>>106301810
kwab
literally didn't even need to debate you, someone already posted a vidrel to destroy you >>106304852

to you second point, show me the code. where is this mythical XACE security in shit like flatpak or snaps or anywhere, really? is it maybe because it doesn't actually work in practice? too impractical to use? don't know, clearly no one else does either because only retards like you ever bring up XACE.
In wayland, this sane default just works.

>>106305567
>he has a choice of using something
>chooses not to

>he has no choice of not using something
>he chooses to use it

retard

>>106305567
>>106304852

By the way, this is my cursor theme.

>>106305567
That video has nothing to do with the x11 protocol retard.
>to you second point, show me the code
Thanks for proving you dont understand shit. Let me show you where it's used: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/dix/events.c#L2280 here is one place. This allows you to restrict which clients receive global inputs. You can prevent keyloggers here in the xace hook.
It works, NSA used it. This is used to restrict other users from accessing your x11 resources on all distros. Xlibre also uses it for xnamespace, to namespace x11 applications: https://github.com/X11Libre/xserver/blob/master/doc/Xnamespace.md . But other than that it's not utilized fully yes.
The reality is that nobody _really_ cares about security. It's trivial to utilize it if people cared, as proven by Xlibre. 99% of wayland users run applications with access to their $HOME (that includes many flatpaks, including steam, obs, some browsers, gimp, libreoffice, etc). With access to $HOME wayland "security" can be completely bypassed, installing a keylogger.

I see that you also ignored my point about it being possible to read clipboard on wayland and record the screen without any permission on all wayland compositors. Which proves that wayland users dont care about security. You are the proof.

>>106305638
Nice theme.

>>106305655
>no actual use anywhere.
ok kid. thanks for proving my point.
also you don't know how Wayland and clipboards work so shut the fuck up about security.

>>106305668
>show me the code
>I did
>n-no use case!
>also you don't know how Wayland and clipboards work so shut the fuck up about security.
I do. I have written wayland applications. The wayland clipboard works on x11 and wayland is retarded. If you want proper security you need to do it the way it works on android.

>>106305698
The way clipboard works*

>>106304852
wait so they ruined gaming on linux forever, by design, that nobody can escape, just so moving windows doesnt lag behind the cursor - something literally nobody EVER cared about and improves nothing practical?

god i hate red hat people with burning passion, i cannot even believe theyre THIS stupid.

>>106286544
Why the fuck xwayland is faster than Xorg or wayland?

>>106305698
>>I did
you didn't show shit. where are the DEs, WMs, application sandboxes using XACE? they don't exist.

>>106305740
xwayland actually gets updates
xorg is trash
wayland is eventually going to supplant both.

>>106305655
>Xlibre also uses it for xnamespace, to namespace x11 applications

.... are you really shilling for this garbage?
first issue: https://github.com/X11Libre/xserver/issues/713
>random inline function that does return str ? strlen(str) : 0
>breaks shit anyway
kek.

>>106305783
you are dumb as fuck, read the whole thing you linked idiot

>>106305807
are you literally not seeing the comedy of str ? strlen(str) : 0
holy shit.

>>106305753
XACE is not handled by DEs and WMs, it's enabled by the user. Anyone can use it right now, as xlibre does with xnamespace. But nobody does because nobody really cares. They like to pretend they are secure with wayland when 99% of wayland users have a writable $HOME/.bashrc / $HOME/.zshrc, even if they use flatpak applications.
>>106305783
>.... are you really shilling for this garbage?
>first issue: https://github.com/X11Libre/xserver/issues/713
Im not shilling it, but you are being retarded now. A bug has nothing to do with XACE.
You are just moving the goalpost since you are proven wrong about x11 security. Its trivial to prevent global keyloggers on x11. But you dont know how to because you are a retard who pretends that his system is secure when it's not.

>>106305813
That code has nothing to do with the issue and there is nothing wrong with that code

>>106305813
>str ? strlen(str) : 0
what a ternary check? i don't like them because they are not readable.

>>106305831
>there is nothing wrong with that code
nigga, are you fucking retarded?

strlen("\0....anything else") is 0.

>>106305842
I don't like them when it's just a shitty null check in disguise.

>>106305843
ok you are officially dumb

>>106305887
if you assume str could be NULL, it's pretty retarded to pass it to strlen since you probably don't have good knowledge of the string enough to ensure it's actually NUL terminated. it's pretty stupid.

>>106286524 (OP)
XLibre will finally move ahead with fixes and improvements the X.org/Wayland people have been rejecting for literally decades and it will be all fixed up in short order. Don't worry lil kiddo.