Playing fast FPS games under wayland/xwayland (and under Gnome/gnome-shell/mutter) is currently suboptimal. It's because gnome-shell will pass mouse moves only at the speed of your monitor refresh rate (see https://blogs.gnome.org/shell-dev/2021/12/08/an-eventful-ins... for the explanation)
So, my expensivish 1kHz (or even 8kHz mice - as these exist) will pass mouse movements with 4ms+ delay and only <240 times per second.
Under Xorg, the xinput proto will pass data at the ~usb polling speed. For my 2kHz mouse, the tool (event-freq) shows ~1700 events / second.
By the way, this ~220Hz is the speed at which gnome-shell passes data to clients (via XWayland or directly). The libinput accepts and passes data at correct 2kHz - and it's only gnome-shell aggregates it under wayland - this can be seen e.g. in the evhz tool (direct /dev/input access) vs event-freq tool (gnome-shell in wayland session, and xinput in xorg session).
I have been playing under sway which removes many bottlenecks (or at least haven’t noticed any), you could give it a try
https://github.com/swaywm/sway
Yup, other compositors might not have this limitation. I might one day switch to sway, but currently staying with Gnome, cause it'd take a couple of days to get used to it I suppose.
BTW, gnome-shell supports so called compositor bypass for windows which request it (and games which I play request it via probably libSDL) - more on that here https://specifications.freedesktop.org/wm-spec/wm-spec-lates... - but I still wonder what kind of visual delay I'm getting with gnome-shell vs e.g. sway.
My understanding is that with _NET_WM_BYPASS_COMPOSITOR it should be the same (vs non-compositing window manager), but the devil is in the details.
I like gnome-flashback/metacity (non-compositing WM), but there are some strange quirks of it, which make me avoid using it on my 21:9 monitor.
Mice have supported 1KHz since the 90s; They are merely set to 125Hz by default. The problem is some can handle low sensitivity and some cannot (due to slow sensor sample rate afaik): http://www.esreality.com/?a=post&id=1265679. This of course is no different than the "gaming" mouse market. Some can handle fast movement, some cannot.
4ms latency is basically nothing (Relatively. Yes, it should be zero). Games already add 10s of ms, modern monitors all add around 3ms-10ms for no reason at a bare minimum. And the latency of each pixel varies depending on the start and end luminance level of a pixel moreso than the [0,8] ms of a mouse at 125Hz being sampled at an arbitrary position in your game cycle (yes, even on many "240Hz" LCDs). Though, it's unclear to me if you get other undesired effects from resampling the output of already sampling the mouse.
1KHz+ mouse sampling's primary benefit is that panning is smooth (perhaps on a properly configured system with a CRT and non-bloated stack then the 8ms max latency becomes an issue). If using a 125Hz mouse polling rate, you circle around an object while keeping your crosshair it, it will be easy to see how wobbly this is. At 1KHz that mostly goes away. Higher mouse DPI on low sens additionally visibly adds to the smoothness.
Having two monitors with different DPI or physical size. Wayland supports different scaling per monitor, so your windows will look thesameish in terms of physical or pixel size (depending on your wishes) when moving them across monitors :).
There isn't really a reason for this to not be done on Xorg too, aside from having the window manager keep track of per-monitor scaling information (note that scaling, physical size and DPI do not have to be tied - someone may want to use a big scale for a low DPI monitor because they have it across the room for example, what really matters is a per-monitor scaling factor - DPI can be used to set up some sane defaults but this should be overridable) and pass it to applications to scale themselves with a fallback if the application doesn't support scaling (be it client-side composition or server-side composition, though the latter will also need merging Keith Packard's patch that implements composition-based server side window scaling)... and someone to specify the messages/events involved.
But really almost all the tech exists (aside from server side scaling, but this can be ignored for an initial implementation) and toolkits (or at least Qt and perhaps Gtk) should already support this as Windows scaling works in a similar way, it is largely getting a bunch of different projects to play nice together.
I think Qt supports it in some quirky way. It supports this DPI notation of something like
QT_DPI="192;128"
via envvars. But it only means that when moving window to another monitor the window will get suddenly re-scaled/re-sized, instead of being smoothly drawn using different scaling factor.
Well, yes, this is basically all what applications can do by themselves without support from the rest of the stack. It isn't impossible but it will be limited to application/library-specific hacks and those have a limited view of the system anyway. Ideally you want support from the environment itself and applications only be responsible for scaling themselves properly.
The window manager is at the best position to support something like this since it handles window placement. It is possible to have a separate program that can keep track of window placement and support the relevant events too (for window managers that wont support this) but it can be tricky to get it work smoothly.
The sudden scale/resize is something that can't really be avoided without support from the compositor (be it the window manager, a separate compositor or server-side composition), assuming there is one of course (this should work without a compositor too, you'd just wont get the scaled fallback unless the server-side scaling patch is also added to Xorg). Again, can be done and the tech is there, it just needs wiring all these things up.
The problem with environment variables is that it doesn't support dynamically adding and removing monitors and changing the scale factor of an existing monitor.
Also personally I think integer (if any) coordinate scaling, and fractional font-only scaling (or fractional blurry server-side scaling) is the only way to support fractional DPI scaling without breaking the fundamental assumption that integer-aligned pixel rectangles don't overlap or partially cover pixels. Qt's fractional coordinate scaling breaks much of current theming and app painting algorithms.
The Qt QPA for Wayland supports this properly and natively since ~2017 or earlier, and will render one single app at multiple DPIs around screen boundaries.
Yes, but the discussion here is how that could be done with Xorg, not Wayland. My point is that the tech is there and at least Qt already has code for it, but it just needs all the relevant projects to work together. Or more accurately, someone to make all the necessary patches for all the affected projects and have these patches be accepted :-P.
I don't plan on getting one since i find even 1440p/27" too much for my taste (i only got it because it was the only high refresh rate monitor with a flat VA panel i could find available when i decided to get a new monitor) but if i ever have to get a hidpi monitor (e.g. someone finally released an OLED monitor but does the annoying thing and only makes it available in a single configuration that happens to be 4K because bigger numbers are better, all other concerns be damned), i'll try to go through everything to get it working on my PC (assuming noone else does it before).
I doubt this will get done on Xorg any time soon, there is very little incentive for anyone to do it when it's already working much better on Wayland. The problem is in finding someone who will do it, it's not really a problem to figure out how it could be done because we already know that: just copy the Wayland API back into X. A good way to start would probably be to get scaling working in XWayland applications and then backport from there; amazingly, we're finally at the point where Xorg is playing catch up to Wayland in terms of features. I can't understate how huge that achievement is for the Linux display stack.
I don't think so, the X.org server would likely have to be rewritten entirely to get some of the improvements of Wayland. And at that point you might as well use Wayland. People have written alternate X servers before but I've never seen one that was totally feature compatible with X.org.
I am suggesting that wayland may not reach critical mass because of backporting these features, and wayland lacking a lot of functionality would prevent me from using it, until its reach partiality or enough functionality. I had mostly a great time with it on GNOME and a tablet interface, but I missed widgets and some functionalities.
In terms of developer velocity I think it has already reached critical mass. I can't comment on any particular missing features in GNOME, to me it is probably more likely that a GNOME contributor is working on getting those features ported over to Wayland than somebody working on backporting things to X.
That's great, I'll switch when its not a skeletonized version of the functionality I use now, I hope there is an easy way to import global hotkeys in my current programs, and have widgets or GUI support. I tried using ctrl and up as a hotkey in the compositor for instance and it never worked in dbus when I tried last week.
I just mentioned GNOME because I actually really dislike it, and was forced to use it for good tablet support with wayland, they broke those plugins I used.
I've been out of the X vs Wayland discussion for ages, but have been on Gnome / Wayland on my work laptop for the last 2 years and wouldn't say that this use case is perfect or even great (though... it gets the job done). Guess your comment means it's even worse on X.
My work laptop is 4k 13" while my second monitor is 1440p 27". I had to enable some gnome custom scaling flag to unlock fractional custom scaling (as you probably also had to do) - not because I want to run my laptop at e.g. 175%, but because setting the laptop scaling to 200% without fractional scaling turned on would mess up all scaling on the external display too (many elements also 200% etc).
So with fractional scaling on, laptop at 200% scaling and external monitor at default 100% everything does work mostly right... except for all the programs that didn't get the memo and seem to scale properly but show up all blurred. I know it's a big Electron issue (so affects Slack, Chrome and VSCode... my 3 most-used programs) - unsure if it's a problem with other stuff.
But all in all has been kind of annoying.
I know they are working on fixes from the Electron angle but last I checked none of it was very stable.
Thanks, now I know for sure the steam deck will just be another windows computer that came with linux. Even these assumptions about its use case were wrong. How could anyone in good conscious support switching to this? I can see noobs who think newer is better, but wow, horrid. Android is pretty smooth, I wonder if running the framework of it on linux could work lol.
Feel free to leave the thread because you can’t handle these truthes. Wayland by itself is complete shit and will be enough to ruin the deck experience.
X.org has many other problems, mostly related to screen tearing or security bugs. It is getting closer for the end of its life as being too complicated and not well designed project.
> It is getting closer for the end of its life as being too complicated and not well designed project.
X11 is 37 years old. Even taking at face value the rumors of its death, I'd say it was shockingly well designed if it's finally - maybe - starting to hit its limits.
It's not really a rumor, if you check upstream you can see that nearly all work on new features is now happening in Wayland and Mesa and then eventually might get backported to X. That's what the article is about.
> X.org has many other problems, mostly related to screen tearing or security bugs. It is getting closer for the end of its life as being too complicated and not well designed project.
That is FUD.
Screen tearing is subjective issue, personally i never cared for it and my biggest annoyance with Windows is that its forced compositor also adds vsync which forces input lag across the desktop. X allowing me to not use that garbage is a big plus. With a fast refresh rate monitor tearing is practically invisible anyway. Also X11 applications can avoid screen tearing, if some do not then this is a bug in the application.
Security bugs is overblown and Wayland security features are akin to keeping your computer turned off to get the best security. In practice if you do not trust an application you can isolate it, though it is really futile since applications can simply use other means than X to "spy" you. X already provide functionality for doing that but if you are really paranoid (why are you running untrusted applications in that case?) you can run a nested X... or even X under Wayland under X. Then once you notice the onionwrapped application launch your browser or any other application, you'll realize the futility of said onionwrapping but hey, until that moment you'll feel safe.
> end of its life
Xorg is an open source program, you can't "end of line" an open source program, it isn't Visual Basic 6 that died because Microsoft decided it should die. As long as someone wants to improve it, it will get improvements.
Also a new version was released just a few weeks ago with a new maintainer that offered to make new releases.
> being too complicated
Have you actually checked the source code? If you ignore the drivers and all the satellite libraries (like Xt, Xaw, etc) the X server itself isn't really that big or complicated.
> not well designed project
This is irrelevant, it does what it is supposed to do.
I always hear these same talking point as well. Why do they want to say things that doom x.org so much? It is some sort of meme that's spewed out from people that want everyone to switch to wayland? I feel like everytime I hear a security issue almost anywhere its paranoia, overblown and generally so improbable that if I never heard of it I would be fine. I disabled spectre and meltdown and recommend everyone else who has an updated browser to as well.
> In practice if you do not trust an application you can isolate it, though it is really futile since applications can simply use other means than X to "spy" you. X already provide functionality for doing that but if you are really paranoid (why are you running untrusted applications in that case?) you can run a nested X... or even X under Wayland under X.
This exactly is the point. Wouldn’t it be nice to just use apps without extra steps? It would make Linux better for non-experts.
You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything.
And you can’t really rework that. Sometimes you need to rewrite whole thing.
Applications cannot normally spy on you unless you run everything in root. It is X.org which provides access for keystrokes and windows.
> Xorg is an open source program, you can't "end of line" an open source program, it isn't Visual Basic 6 that died because Microsoft decided it should die. As long as someone wants to improve it, it will get improvements.
Because the design is bad, it gets harder and harder to add new features. Fixing bug introduces two new ones. Complexity makes it hard to approach project and control everything. Red Hat has maintained it so many years with proper funding, otherwise who knows what would have happened.
>This exactly is the point. Wouldn't it be nice to just use apps without extra steps? It would make Linux better for non-experts.
I don't run untrusted apps, at the cost of crashing, and less overall functionality? Its cutting the nose to spite the face.
>You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything. And you can’t really rework that. Sometimes you need to rewrite whole thing.
Not a real world scenario problem.
>Because the design is bad, it gets harder and harder to add new features. Fixing bug introduces two new ones. Complexity makes it hard to approach project and control everything. Red Hat has maintained it so many years with proper funding, otherwise who knows what would have happened.
Wayland design is... good? So it's taken over a decade to add a fraction of x.org features, and it still crashes? If it so simple and it still sucks, are you calling the programmers incompetent for not making the simple compositor functional?
> I don't run untrusted apps, at the cost of crashing, and less overall functionality? Its cutting the nose to spite the face.
The best practice is zero-trust; handle everything equally. You can't fully say by yourself which is really trustable, and if you are, then you are 0,01% of the actual population, and decision cannot be based on that.
> Not a real world scenario problem.
Of course it is, it is the biggest attack surface for normal application.
No, I am asking about attacks in the wild. I know spectre and meltdown were possible to exploit, but its different from it existing as an attack, like a recipe versus a cooked meal.
I'm not sure what you mean by attacks in the wild. I don't have any news stories talking about how companies lost millions of dollars due to an X.org-based ransomware; but I hope you can see how it's not a good idea to wait for that to happen before fixing a security bug :)
Encryption attacks are being mitigated by backups, but Linux servers don't usually use x.org or GUI do they? This might be why desktop linux isn't being adopted by business, but my point was that we hear of encryption attacks often, but not a single x.org attack that would make migration more pressing. Its living in a nuclear shelter when there is no nuclear threat, and living in an uncomfortable state out of paranoia.
Linux is said to be safer in the public, but if x.org is that bad, is windows actually safer since it doesn't use x?
I think its useful to mitigate problems, without real world examples its hard to care about invisible hypotheticals, especially at the cost of lost functionality.
I'm still not sure I understand. If there is a working proof of concept for the exploit that is published, would you still consider that an invisible hypothetical? To me, it's not, I would like to have those patched. As with meltdown and spectre there may be functional tradeoffs, but when significant money is at risk from security vulnerabilities then I'd usually expect security to win out.
The attack vector for a trojan or ransomware can be a GUI system. It can be anything really, the malware just needs a way to get into the network and then it can cause more trouble and spread to more nodes.
>I'm still not sure I understand. If there is a working proof of concept for the exploit that is published, would you still consider that an invisible hypothetical?
Yes. If deployment is difficult and not applicable in real world settings it isn't really a threat, its like reading about the TouchID since the first iPhone 5S being tricked by copying fingerprints, or needing a bust of a person to trick FaceID. Do people still usually use it? Its a recipe, maybe even its cooked, but if nobody eats the poisoned food because it smells bad, I am not worried I might eat it.
>then significant money is at risk from security vulnerabilities then I'd usually expect security to win out.
In practice it sadly isn't true like the leaks of other people's data that constantly happens.
I think updating browsers is a good idea, I think sandboxing apps can be safer, using a VM for some functionality could be useful too (if you run XP and malware detects its a VM, it doesn't even infect it). Basically I see most security issues as paranoia when its academics publishing hypothetical attacks that have never been seen in the wild, if they made super ebola in a lab or anthrax, I am not too worried about breathing it in.
I would like it patched if the cost is worth it. Intel's was not, I disabled it, and religiously update my browser, my computer is faster, I have safety despite it never existing as an attack because it was easy to defeat.
>its like reading about the TouchID since the first iPhone 5S being tricked by copying fingerprints, or needing a bust of a person to trick FaceID
That's not really comparable, these are trivial exploits that can probably be targeted with a 100-line program, or less.
>In practice it sadly isn't true like the leaks of other people's data that constantly happens.
I've known many security people who take their jobs very seriously. If they weren't doing their jobs, you'd see quite a lot more data breaches than you do now :)
>That's not really comparable, these are trivial exploits that can probably be targeted with a 100-line program, or less.
I feel like it would be newsworthy if they were trivial, or we'd see more of them. Today there was a story on malware on Pinephone, a device almost nobody has that didn't cost any money to anyone. If they were trivial, it would be utilized more and we wouldn't need to care about the wayland issues as much since the alternative is worst.
I tried wayland just because of this thread, and I got 2 crashes within minutes.
I will, KDE discourages me somewhat because it’s not enough or relevant information the few times I tried using their reporter. I think it has to do with mouse speed like gnome.
> You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything. And you can’t really rework that. Sometimes you need to rewrite whole thing.
Actually you can, the X server can run applications in an untrusted state where they cannot see other resources. It is not straightforward to setup though so running a nested X server is much simpler - at least until you realize that the same "untrusted" app has access to the rest of your system anyway.
> It is X.org which provides access for keystrokes and windows.
You can avoid that if you want but as others have mentioned you are way more likely to need that functionality for legitimate purposes.
You can finetune access control of your app into filesystem for example with AppArmor, but access for X.org is always required, remaining as the biggest attack surface.
Neither are really good options for graphical applications. The focus now is on using container sandboxing, at least with things like flatpak and snap anyway.
I'm not an expert on the wayland/xorg/xinput/gnome-shell stack, but unless someone smarter takes good measurements of various things (visual and input delays), I'd suggest
1). Xorg + gnome-flashback or Xorg + other non-compositing WM
or
2). Non-gnome compositor under wayland
As for 1).
Xorg b/c it can provide pointer movements at ~native speed via xnput vs Gnome/Wayland 60-240Hz. And gnome-flashback b/c it's a non-compositing WM, so there's no frame buffering (unless you enable it in nvidia's panel, or via TearFree in amdgpu).
As for 2).
Sway, I suppose, doesn't aggregate mouse movements, but
looking at https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-... the author used some hack to enable "immediate" "drawing" under KWin. I'm not sure what's the default behavior of e.g. Sway - does it buffer frames?
I'm getting increasingly frustrated with Wayland. I cannot share my screen with Zoom. I cannot use applications like gcolor2. It is often that I find an application just does not work with Wayland and I have no idea how to troubleshoot.
I know a lot of people complain about Linux being much more complicated to use, but my experience for the last ten years is that Linux almost always works better than Windows and OSX for the basic 90% of things. But, Wayland has changed that for me entirely, now it feels like 50% does not work.
For me the most frustrating thing about Wayland is that with Wayland a crash anywhere in the stack means I lose all my work. I really like the fact that under X I can simply restart my DE after a crash to get a working desktop back and the open apps are unaffected, this saved me so many times. I tried Wayland for a while, but after losing all my work twice to crashes I came back running to X.
I love X, etc and use it all the time, but let's be honest, X isn't exactly rock solid either. I had X crash due to video mode switches (mainly via games) so many times that nowadays unless i know a game behaves nicely, i tend to first run it under gamescope[0] which shields against these issues. I do find it kinda amusing that my only use for Wayland so far has been to avoid driver issues by running a compositor inside an X window :-P
[0] https://github.com/Plagman/gamescope - it is a fork of Valve's wayland compositor which actually works under X11 inside a window and effectively creates a nested XWayland environment but also attempts to minimize latency... it doesn't eliminate it completely but outside of twitchy shooters it is ok
The thing is, with X there were a lot of separate parts - the display server, the window manager, and the compositor were separate packages and if either of the latter crashed and you were set up for it you could keep going. With Wayland, the display server is the window manager and compositor - and is directly responsible for handling all audio, video, input devices, color management, clipboard, and probably other things I'm forgetting - so there's only one thing to crash and it's game over. This also is a pain in terms of features, because you can't tack on, say, a clipboard manager, it has to be directly supported, hence things like GNOME, KDE, and basically everything else (via wlroots) having different, incompatible ways to do things like screen shots.
I have never had that ever happen, I am guessing nvidia? Are you aware of VFIO? Its probably a better solution, 100% gaming on linux with a Windows VM that uses GPU passthrough.
No, AMD, i have a Radeon RX 5700 XT with the open source drivers. One of the sure-fire ways to crash the entire server seems to be trying to run Wizardry 6 from GOG via Wine, which essentially runs DOSBox for Windows. Somewhere when it tries to change video mode it crashes. Note that this doesn't happen if i use Gamescope under X (which essentially runs Wine under XWayland under its own Wayland compositor that runs in an X window).
Of course since this is a DOS game i can simply run it with native DOSBox, but this is just a way to replicate the issue.
Since i've found workarounds for these issues i didn't bother much, but i might try and see why it crashes at some point.
Also FWIW i do not really consider "gaming on Linux" when i have to use a Windows VM. Besides Wine (well, Wine staging) nowadays works perfectly fine. And if i wanted to use Windows, i'd just be using Windows :-P.
Thing is, with Proton and X I have a rock steady and capable env to do all of my gaming, and I have been doing so for years now. I've no need or desire to bring windows back into the mix.
Wayland messes that up, on top of frequent crashiness. Wayland does not solve any problem I have, but it does break most of the things that were working well.
I don't like windows either, just the best method to run 100% games.
>Wayland messes that up, on top of frequent crashiness. Wayland does not solve any problem I have, but it does break most of the things that were working well.
That's all I get from the thread, it works well as long as you don't do anything other than use the browser.
To add to this, thunderbird has started to crash and hang in Ubuntu 21+ because of Wayland[0]. It's feeling the old days when I had to separately install wireless drivers to make WiFi to work.
Most new linux users don't know this and will give up., Ubuntu really shot in their foot when they made Wayland default in 21.04 and beyond. It's going to lose a lot of new users.
Never had that issue myself, but it can crash and lose all my work? Wayland sounds like 100% regression on functionality for some lame graphic benefits.
If the X.org crashes then you lose all of your work. Same as your compositor. The difference is that your WM is just a client to the X server and so can crash and restart without affecting other clients.
A great solution until software declares X11 "deprecated" and refuses to support it. For instance, the only way to run Waydroid under X11... is to nest a Wayland session inside X11.
FWIW as someone who uses Xorg exclusively i do not see an issue with using a nested Wayland server to run Wayland applications. The only issue is that current Wayland servers only support running inside their own windows instead of creating "rootless" windows that can be integrated with the rest of the X desktop, but that is something that can be fixed at some point if needed as neither X nor Wayland limit this functionality.
Not sure if you want to change programs, but I use telegram to screen share, not sure if wayland supports it. Can you screen capture with a video card? I don't know if you plan to stay on it.
Well, given that `gcolor2` is open source, it does already work with Wayland if you have XDG Portal setup correctly.
And Zoom could, too, if they cared. (And by the way, I use Zoom in browser with Wayland when required by <obligation>, and it works fine.)
Once again, people miffed at Linux because closed source app developers are lazy and don't give two shits. (Which would be and often is a pain for plenty of other reasons than Wayland.)
I don't know what xdg-portal is or how to set it up. When I searched in Google, the very first link has a bad SSL certificate (which I accepted anyway, but seems very complex at first glance), the next from Reddit didn't work and said the tutorials were all out of date.
I totally agree Zoom should fix it, but they haven't yet.
I tried to install xdg-desktop-portal with ` nix-env --install xdg-desktop-portal` but running xdg-desktop-portal does not find the binary. I'm just confused what this command does anyway.
Apparently, there has been some recent activity via support channels. But I’d bet it’s probably not that difficult, just a matter of the team’s priorities to get to it. Then again, zoom isn’t very active or transparent in the OSS world, so it’s hard to say.
More accurately, the developers need to a) fix the buggy implementation of the Gnome-specific protocol they currently use, and b) switch to the standard screensharing protocol.
For what it's worth, I do use screen scaling (in fact: different scales on different screens) and haven't had trouble with screen sharing on Zoom on Ubuntu in over a year.
The descriptions in the article are very handwavy (especially on the X side) and they blame X for things it doesn't do yet while at the same praises Wayland for things... it doesn't do yet either (HDR).
However the measurements at least are good (interestingly i was actually planning to do the exact same thing at some point using pretty much the same approach) and basically show what most people expect: X without a compositor (or with the compositor being disabled for fullscreen gaming, though note that not everyone may want to play games in fullscreen - e.g. i often play games in a window myself) and vsync disabled provides the best responsiveness.
Also one thing that should be made very clear is that these are about KWin/X11 and KWin/Wayland, not X11 and Wayland in general. For example last time i checked XFWM allows disabling vsync in the compositor, which would certainly affect the results here. Also it isn't made clear (and actually i don't know myself) if KWin disabled the compositor for fullscreen Wayland applications or not: i'd guess it doesn't because under X in my laptop where i use KDE i had to explicitly disable it even for fullscreen games (there is a shortcut key for that), so i'd expect the same behavior in Wayland too.
I wonder why there is so much hype with wayland, in use its mostly terrible unless you choose GNOME. Have these people ever used linux or xorg? Are they all just hyped from what it can do than what it does do, and will steam deck gamers also hype it up just reading that its faster?
I'm not so sure it works like it is explained in the article, or maybe I missed something.
When using Gnome + Xorg + proprietary Nvidia driver with multiple monitors, with different refresh rates (144 and 60), they do not limit both to 60. Each monitor has different refresh rate and it is clearly visible that 144hz monitor is running correctly.
And while Gnome is obviously running the compositor, I can turn off vsync for fullscreen game and remove fps limit and it does seem like it's not using vsync. Maybe I just don't notice it with my monitor and games anymore, but it certainly doesn't feel like I'm locked in and delayed with vsync.
I read that Nvidia is adding some Wayland and Xwayland support for their proprietary driver but I haven't tested it yet. I wonder if I'll notice any difference there.
If the compositor isn't synchronizing rendering it'll work fine. Options there are GPU level vsync or no sync. I think these are the "workarounds for this problem but none of them can remove all problems at the same time." being referred to though at this point I forget the downside of GPU level vsync (tearing is the obvious downside of no sync).
I don't remember if GPU level sync with compositor sync off solves VRR with a compositor on X11 though or if it did but with side effects. Been a while since I've messed with it.
X11 has about 9 billion configurations, some of which have v-sync, some of which don't, and some of which depend on something like how broken your drivers are. I don't normally use any of this fancy compositing stuff let alone anything from gnome, but on a lab machine I have Ubuntu 20 (gnome / X11), and from moving the window around you can clearly see vsync is off.
a) Both screens are receiving a 144Hz signal and your 60Hz screen just happens to accept this and drop the extra frames
b) It works as long as it can actually hit 144Hz. As soon as anything drops it will drop to 60 instead of whatever is appropriate for a 144Hz screen. (This comes from the article on how mutter finally split the frame clock on Wayland)
> a) Both screens are receiving a 144Hz signal and your 60Hz screen just happens to accept this and drop the extra frames
No shot. All 60Hz monitors created before the 120Hz+ era cannot handle a signal above 75Hz. The exception being the few that can go up to 85Hz. They cannot just drop every second frame at 120Hz; that would require timing faster than what they're capable of.
I think the entire desktop is running at the highest refresh rate, which is not only wasteful but can cause glitches when the lower refresh rates don't cleanly divide the highest.
First of all, why would you want the game to interact with your display server what so ever (aside from alt+tab)? This is why full screen exists.
>[In VRR] Whenever an application is slower than the displays maximum refresh rate the display will wait for the next frame before it updates the pixels and thus you don’t see any stutter
Nothing so simple. VRR means your framerate fluctuates, which means you have stutter, by definition. Perhaps if you can bound it within a sufficiently small range that it wont be perceptible. If game framerates _did_ have predictably small variance, everyone would just generate the new frame right before VBI and have perfect (practically) latency free, no tear, no stutter, no motion blur (via BFI/CRT) rendering.
>Not all displays have this functionality (yet) because it’s difficult to make it work well: In many displays with different refresh rates the brightness changes a lot, so if the refresh rate jumps around you’ll see the display constantly flicker in brightness.
The brightness only changes if you are using Black Frame Insertion (on old monitors you can't use VRR at the same time as BFI; on newer ones this is supposedely fixed, i have no idea how or if it's valid). One big issue though is that VRR makes liquid crystal transitions even harder than it already is to happen fast and artifact-free.
These measurements are bad for various reasons. There's also the obvious question: how does Wayland actually change the framebuffer? Direct scanout is a term I've never heard that could mean many things... I guess you get control over scanout, so you could render during VBI and have zero latency in this part of the loop, in which case why even measure it.
Some questions from someone who is obsessed with getting 0 frames of latency:
>the one frame of added latency with compositing and game VSync does not apply to Wayland
I thought that on X with vsync disabled, a fullscreen game will write pixels directly to the framebuffer on the gpu without going through the x server / compositor, so there will be 0 frames of delay. Is this correct?
> application contents can be put directly on the screen with the display hardware (which is called “direct scanout”. You may have heard the X related term “unredirection” used for the same thing, too).
So on a machine running wayland, direct scanout would let a fullscreen game render directly to the framebuffer without any copying, compositing, color remapping, etc etc, just pure pixel data to the screen without any intermediate steps, right?
And how does this work exactly, like does the program that wants to render to the screen have to call some API function to explicitly opt-in to direct scanout? Because most games, even the ones designed to run on linux, are not aware of wayland.
Also I think something is up with the final measurements, on his 120hz monitor one frame of latency is about 8 ms, but the lowest he ever measured was 19ms so it seems like something is adding at least a frame of latency.
These days, a game has at least double buffering. This means one frame is currently displayed on the monitor (front buffer) and one frame is being drawn by the game (back buffer).
In a classic "fullscreen game" situation, whenever a back buffer is finished, the game would configure the GPU's CRTC (the hardware that generates the data stream that goes to the monitor) to read from this back buffer instead. This turns the back buffer into the current front buffer and releases the old front buffer to act as the next back buffer ("page flipping").
When this happens without any synchronization with the monitor, the buffer can be changed in the middle of the frame, causing the characteristic tearing. With VSync, the game delays the swap until the monitor is between frames.
With Wayland, the game swaps buffers with the compositor instead. Direct scanout means that the compositor will configure the CRTC to read from the game's front buffer. So this is really similar to the "classic" situation, except it involves a bit of inter-process communication.
Otherwise, the compositor has its own set of front and back buffer, and the game's front buffer is copied (composited) into the compositor's back buffer first. So we have another buffer swap that has to be done, and this is what causes the composition lag.
Whether direct scanout happens or not is transparent to the game, which does not need to care.
Wayland enforces VSync by default, though there's a protocol being designed (`zwp_tearing_control_unstable_v1`) so a game can request asynchronous flipping.
Ah, so this "direct scanout" is just an improvement over the previous bad situation, not an improvement over the classic double buffered vsync, and not a way to give the application the choice to write directly to the active framebuffer during scanout.
Games typically go through OpenGL (or D3D), and don't touch the framebuffer. 2D games will be going through SDL or something else. All of these involve transformations in internal memory far before writing out to the framebuffer. Edit: the other guy explained it better.
> but the lowest he ever measured was 19ms so it seems like something is adding at least a frame of latency.
Ignoring the fact that the measurements are completely bogus and nothing can be taken from them, the monitor itself will add lag, and the mouse/keyboard will add between 0 and 8ms lag per frame if it's a standard 125Hz polling rate configuration.
The starting description of how displays work isn't entirely accurate.
"The GPU sends some image to the display, beginning from the pixel on the top left and going through them line by line"
This isn't necessarily accurate. On many SoCs (like the entire ARM ecosystem), it's the DPU that sends the image to the display, not the GPU. They are different hardware blocks.
That DPU then also takes its input in the form of a list of buffers, not a single buffer, and does composition during scanout. Hardware overlays are very much alive & well, after all (hence their support in DRM/KMS, as well as Android's HWC HAL)
Which in this case isn't pedantry and is really important, since we're talking about compositors. It's really important for power, performance, and features (assuming DRM'd video is a feature you want, anyway) for the window compositor to be able to farm out to the hardware compositor for various things.
It's also not entirely accurate in the case of newer DisplayPort interfaces offering Panel Self Refresh / Panel Replay, where only the changed area is sent over the interface and static refreshes come from the panel's own memory https://vesa.org/press/vesa-publishes-displayport-2-0-video-...
I thought about including PSR but the article's take is still mostly accurate in that you do still send pixel by pixel, row by row, in the case of a panel with PSR. Just the panel then remembers those pixels.
On something like an ARM SoC where this is all unified memory, I couldn't entirely remember where exactly PSR sat. In that case you could argue the transfer is an atomic switch to a different buffer, but I thought the PSR memory was still a different segment even in that case.
This is a neat and helpful comparison, but to me the issue was never really latency; it's more the fact that Wayland isn't neccesarily a direct upgrade over x11 in a lot of ways.
Now, I can anticipate a number of responses to this. Firstly, a lot of people will (correctly) point out that x11 isn't a very good window server, and doesn't account for things like compositing, security or proper window management. Fair enough, they're all valid complaints. Wayland's solution to the dog bite seems to be pulling the teeth off the dog though, and I don't really agree with a lot of the design philosophy that went into making it. It reminds me of the recent GNOME releases, where their solution to inconsistent user theming and poor extension support was just to remove both features altogether. The trap that a lot of modern Linux developers seem to fall into is fragmenting their userbase under the guise of "finally fixing" some pain point or bug, and cutting off the users who disagree with them instead of Doing One Thing, and Doing It Well. Everyone is big-picture these days, wanting to take giant leaps for the Linux desktop experience without really considering how extensible or feature-complete their program is, and slamming the "f*ck it, ship it" button before it's ready.
Admittedly, there's not an elegant solution to any of this. However, in this specific example, I think the best course of action would have been to just outright plagiarize Apple's Quartz. The development cycle for Wayland has been painful to say the least, and a lot of it came from wildly unnecessary breaking changes, vendor apprehension and arguments about ideology that really shouldn't have wasted our time in the first place. Now that it's "ready", there's a couple hundred asterisks following every feature, and the experience is generally shaky enough to keep me fearful of God and contented with x11, no matter how bad it is.
Edit: Quick shoutout to PipeWire while I'm here, for actually creating a crowd-pleasing solution where nobody had to be thrown under the bus. They were given a herculean task of unifying 4 different audio standards, and they shipped it when it was ready instead of letting it languish in development hell. The result was fantastic, and distro uptake was almost immediate. If more projects were like PW, we wouldn't be here having this conversation right now.
DPI scaling and full screen playback without screen tearing are pretty huge upgrades.
You might argue that it’s not worth overhauling everything for that, but it’s undeniably a huge quality difference and was one of the major reasons I moved to wayland. Having a 1080p screen and a 4K screen “just work” has been my reality for a few years now - to the point where I get surprised when people talk about it as if it’s an issue.
I do have screen sharing issues though. With basically everything.
> full screen playback without screen tearing are pretty huge upgrades.
Tearing in full screen (video) playback was not an issue for decades, since X video extension and later OpenGL-based playback. Fullscreen video and 3D is easy, because it is one program that controls buffer flipping. It is windowed video/3D that always has tearing.
> Tearing in full screen (video) playback was not an issue for decades
Either you're being hyperbolic about the length of time or this is simply untrue.
I have been using Wayland full time for 3 years, and 3 years ago the main driver of me switching was screen tearing.
I was heavily invested in the X11 ecosystem with highly customised fontconfig's, so this was quite painful for me at the time and I definitely tried to solve the screen tearing issue. Part of it was that Linux did not have hardware acceleration in browsers, which is where I spent most of my time (especially for video playback, such as YouTube).
So those extensions didn't help, and when you get used to the buttery smooth scrolling experience of MacOS and iOS it feels quite janky going back to linux- especially when you've invested so much into making it a more beautiful experience for yourself.
> Either you're being hyperbolic about the length of time or this is simply untrue.
I am not hyperbolic, X11 has this Xv API, video players generally use it since early 2000s (as that was only reasonable way to even scale video to fullscreen with contemporary computers). Browsers - well, that is a different issue. I do not think Firefox uses it and have no idea about Chromium.
> Part of it was that Linux did not have hardware acceleration in browsers, which is where I spent most of my time (especially for video playback, such as YouTube).
Linux also have hardware decoding acceleration API (even multiple ones - historic XvMC, NVidia-specific VDPAU and current mainstream VA-API), their support in software is more spotty than basic Xv API (AFAIK MPlayer implemented VDPAU but not VA-API, MPV required for some time explicit option to use VA-API and i have no idea about VLC). Firefox got support just recently: https://ubuntuhandbook.org/index.php/2021/08/enable-hardware...
I would generally suggest to view web video such as YouTube in MPV video player using its youtube-dl integration. It is much better experience than playing video in Firefox.
> I would generally suggest to view web video such as YouTube
I’m talking about more than video though. I’m talking about scrolling text. You can see visible lines when you have a large display and scroll a page.
Anyway. It doesn’t matter. You want to run X11 then that’s fine, but I’m quite happy with wayland and I’m happy to leave the weird configuration and cacophony of hacks behind.
Nobody here is trying to take your experience away from you, if Wayland makes you happy then by all means, keep using it. Without users on the cutting edge, it's hard to debug new software. However, what others have been saying here, is that x11 typically doesn't have screen tearing issues on the majority of hardware/software configurations. Yes, it is possible to remove a composition pipeline and disable all of the safeguards put in place to eliminate screen-tearing. If you're using a barebones system like i3wm or similarly stark systems, you will probably notice tearing; however, the vast majority of hardware/software combos that people actually use these days do not exhibit this issue. On my Nvidia and Intel machines, I do not notice any tearing on fresh installs without configuration. This goes for gaming, video watching, 3D modelling, reading, website scrolling and quite literally everything else I do on my desktop and laptop.
DPI scaling is undeniably nice, unfortunately I never got far enough in my Wayland journey to see the benefits. Screen tearing is an interesting issue to parse, but it's also perfectly fixable in x11 if you force the compositor pipeline. Especially since my main monitor has G-Sync, I've not really noticed any tearing on Linux unless I use a desktop that explicitly lacks a compositor on an integrated GPU.
I really like what the Wayland people are trying to achieve, I just don't agree with their methodology, and their results have spoken for themselves.
I can do font scaling in x.org, my screens also just work. I have DPI scaling but it doesn't seem to be switch when I take my laptop off the dock. Wayland sessions seem smoother, most software I use isn't adapted to the new model yet, and for the cost of losing my global hotkeys, redshift, and other useful things that matter, its not worth it to see smoother animations, I'd rather turn them off.
Hot keys are handled by the compositor. Global ones especially. (Apps stealing keystrokes? Sounds like an anti feature)
Point stands. But I’d rather we work on improving things than just living with X11- it’s like continually adapting token ring networks instead of embracing star topology. It’s fundamentally difficult or impossible to fix.
The wayland authors (who are former X11 devs) talked about this extensively.
I use a widget that I can scroll my mouse to change the color, does it have it? It doesn't look like it does.
>Hot keys are handled by the compositor.
Yes I know, I don't like it, I have hotkeys setup in a way that I like, and I don't want to redo it all, I even tried.
>Global ones especially. (Apps stealing keystrokes? Sounds like an anti feature)
Framing app hotkeys as theft of my input is like saying that my window I am tying in is stealing my keystrokes. If you consider breaking userspace as an benefit, I am confused. It is an optional feature I turned on myself, and you call it keystroke theft, when it was ME that enabled it. Linus Torvald's one rule is that userspace should never be broken. This breaks userspace.
> It’s fundamentally difficult or impossible to fix.
Or its not broken.
>The wayland authors (who are former X11 devs) talked about this extensively.
They are still improving it like btrfs, but I would rather stick to something that just works, and so far it has more problems, anti features, needs configuration to be functional, and for what benefit? No battery benefits, no extra functionality in fact less features, breaks workflow, and smoother animations. I also forgot to mention it breaks some of my terminal emulators, every time I try it I have a horrible experience, it breaks things that matter to me, and still does for most people.
Even if its "good enough" it will take a long time for more application support, unless I hate myself and resign myself to no configuration GNOME.
Alt tab not being stolen might be jarring. But I’d rather not have apps overriding the compositor because then I might not be able to escape them. There is some comfort in the universality of many things.
It is jarring to need to remember different keystrokes by the compositor if you use more than one computer, especially if they're not all linux. Why do you think its worth all this pain?
Every "feature" of wayland sounds like a regression. I hope someone makes x.org in rust
Which I could agree with you- I dislike change too, I fight systemd because I don’t see it benefiting me.
But this is a bit silly, you keep coming up with rotating surface level complaints but the main reason X11 was replaced was because it was architecturally broken not because they wanted to solve specific issues.
That there is no great community around wayland is because of naysayers like yourself. Things are easier to solve than they used to be but people are doing everything they can to avoid using wayland.
Things like nvidia forcing people to use X11 have caused distro maintainers to do double the work to maintain backwards compatibility; which means it hasn’t had as much love as X11 over the years either.
Normally I would take the stance of “what ever works” but you sound like you’ll do anything to justify not switching. Arguing about creature comforts or that your compositor has more control over your UX than some random program is an absolutely surface level argument when we’re talking about fundamental and required architecture changes for us to go forward with desktop Linux.
That you don’t understand how dire the situation was becoming is quite telling. It’s not worse, it just doesn’t have the community stuff behind it yet, and the reason is the mentality you have.
I would gladly hop in a better car, if the newer car has less features and is worst, I will not.
>That there is no great community around wayland is because of naysayers like yourself. Things are easier to solve than they used to be but people are doing everything they can to avoid using wayland.
Rust has plenty of naysayers, as does pipewire. People hate Apple stuff with a passion, but they are all good. Wayland works on GNOME, which is a fact. I even said if its "good enough" it will take a long time for more application support, unless I hate myself and resign myself to no configuration GNOME. The reason it has no community is because it sucks.
>Normally I would take the stance of “what ever works” but you sound like you’ll do anything to justify not switching. Arguing about creature comforts or that your compositor has more control over your UX than some random program is an absolutely surface level argument when we’re talking about fundamental and required architecture changes for us to go forward with desktop Linux.
You don't get to decide what the direction of desktop linux is, or what people want to do with their open source software. I could say that the dolphin is the stupidest animal in the world, and nobody would take me seriously. Wayland sucks, if tomorrow x.org didn't exist, I would not continue to use linux. There is no benefit for most users in this thread. I even said I used it on a touch device to get rotation working on my touch tablet, but you ignored that because I have a different preference than you. Every "feature" of wayland sounds like a regression if doublespeaking as regression in features is going forward.
>That you don’t understand how dire the situation was becoming is quite telling. It’s not worse, it just doesn’t have the community stuff behind it yet, and the reason is the mentality you have.
There is a new maintainer, I will continue to use the best tools for myself, which will not be wayland for any non touch computer. Wayland design is... good It's taken over a decade to add a fraction of x.org features, random plugins needed to make it imitate x11, and with less features it still crashes? If it such a required architeture change, why is it making everything worst? What does forward even mean, less features with more crashes? No thanks. If it was so great why does it still suck compared to the so called dire x.org?
>It’s not worse, it just doesn’t have the community stuff behind it yet, and the reason is the mentality you have.
Do you love broken userspace? That's great, choose a compositor that breaks your userspace? My mentality of having robust software is the opposite. Suprise! Nobody wants to use crappier software with less features despite the dire "problems" of x.org, they made a rational choice, which bothers you so much. Why does it matter what I run? You look down on everyone's problem as invalid, calls our mentality wrong, and can't even define what forward is, or why anyone cares, because nothing you say is a benefit matters. Don't be suprised if wayland never gets used or doesn't ever gain traction, other half baked projects like btrfs that are inferior to even older software are not going to be used over better alternatives.
You are dishonest about screen tearing being an issue, and calling my custom hotkeys "stealing keystrokes", saying its fundamentally broken when wayland breaks more things, and instead of the project acknowledging user needs, they ignore it and somehow wonder why nobody want to use it.
I'll end by saying wayland is fundamentally broken, it has less features, no gains to non graphics or productivity, no benefits and more drawbacks to most users, the wonderful future of the "forward thinking" design that strips useful features and ignores what people like about x.org is beneficial to everyone. No, it is inferior in every way except for gyroscope screen rotation and slightly smoother movements, something that is compartively worthless to the suite of useful x.org features.
> I would gladly hop in a better car, if the newer car has less features and is worst, I will not.
The ecosystem around bicycles is much better than the ecosystem around trucks.
You are tasked with getting to and from work every day, in the beginning it's just you who travels, but over time you have more and more things to carry with you- shovels and such.
You buy a trailer.
You find that with your trailer it's more difficult to see what is coming up behind you, so you buy side mirrors.
You find that in the cold it's difficult to keep your hands warm, so you buy hand warmers, and lights on a dynamo.
Eventually your bike is quite heavy, you carry much and requires much more effort to operate.
But it has a lot of "features".
This is the sunk cost fallacy in action.
> Do you love broken userspace? That's great, choose a compositor that breaks your userspace? My mentality of having robust software is the opposite. Suprise!
My userspace is absolutely not broken. Arguably it's less broken than yours but you've patched around the issues or are blind to them.
Sway crashes for me less often than Xorg did; but I understand that Xorg and Wayland are not the same, and that took some getting used to, and indeed it was uncomfortable in the beginning.
You are passionately arguing from a place of absolute ignorance, I have used both. I have used both professionally. I have used both for years.
Yes, I replaced a lot of my normal programs.
Yes, Wayland has issues, many of which could have been addressed if people weren't conservative. Not that I begrudge them for it, I believe choice is good.
But, it's absolutely ignorant to claim that X11 has features. X11 does not have features, it has people willing to hack on it and an architecture that allows disgusting and ugly hacks to work.
You might like that, I absolutely despise it- because malicious software exists (and I use it), things like Zoom which if given the opportunity would love to run as root and capture all my keystrokes.
Things like Teams which on Android devices managed to block 911 calls.
Things like Chrome which is attempting to be my userland.
Ultimately, I trust my windowing system more than I trust random programs I may run to bind my hotkeys.
> I'll end by saying wayland is fundamentally broken.
Wayland is not "fundamentally broken" it's been working for me professionally for years. The "features" you cite so often are non-features "my cursor can change color!" which are not inherent in x.org at all.
Wayland "breaks" things that are designed to work exclusively with X11. Much like how graphics cards "break things" that are designed to work on a serial console.
> Yes, Wayland has issues, many of which could have been addressed if people weren't conservative. Not that I begrudge them for it, I believe choice is good.
Them the developers should do something about it, instead of calling a comparatively crippled compositor complete. If choice is good, respect everyone who says x.org is better, instead of trying to scare drums or use vague words like “progress”. Progress towards what? Lower Linux satisfaction?
If you think I’m a troll because I refuse to lie about how the useless wayland is actually good and don’t engage in an encho chamber of praise, you need to listen to complaints and respect opinions of others. Your analogy is of it being a truck instead of a bike, it’s hard to take you seriously unless you’re trolling, that is unless it’s a plastic toy truck. You bring up nonexistent threats like Android not calling 911, and demonstrate it’s being a no threat, and an irrelevant threat.
Don’t joyfully call everyone to switch from fine software and enjoy their new crippled and child proof space progress and applause the broken userspace for the sake of scaling, slightly smoother movements and colored cursors. Respect other people who don’t like the same thing you do instead of calling them wrong. You wouldn’t do this to a sexual preference, not Thor compositor.
That you can't steal keystrokes from other programs?
Screensharing? (which is an adoption issue for clients, not a "problem" with Wayland)
Your X11 programs (not hacks) already work as if they were X11 with Xwayland, but it has the same drawbacks as running it natively with X11. (with a small bonus that it's rootless... unlike X11 which is assuredly not rootless by default).
Do you honestly believe that wayland developers should reimplement all software that has leveraged and abused the X11 system? Seems asinine, what are your _real needs_ that Wayland isn't providing support for?
You call it "hacks and abuses", but it's actually extensibility. Which Wayland kind of lacks (you need support for all of this in the compositor, rather than 3rd party processes being able to provide it).
> Do you honestly believe that wayland developers should reimplement all software that has leveraged and abused the X11 system?
Most definitely not, but what they should do is just to _allow_ the continued existence of all the software which has leveraged X11 in their garden, if the garden is to have any kind of success. And not as 2nd grade citizens.
The analogy is not correct, because in the case at hand, it is _by design_ that X11 allows this -- the entire "mechanism not policy" thing.
And the problem with "it's potentially dangerous" is that you can use it as justification for removing any feature, so much that it doesn't really have any meaning left.
X11 definitely wasn’t designed for this. It’s a byproduct of its (poor) design and the fact you can directly interfere with the renderer.
It’s the same as the c64 not protecting memory addresses so you can poke memory to fuck with the video output, which people did, but the c64 is not a good computing platform in the modern age almost because of this.
You might be better served by actually looking how X11 works, with quirks and what it was originally designed for, I promise you that your hair will stand on end.
I should note: “potentially dangerous” is seriously downplaying a genuine problem linux had with keyloggers- it just wasn’t overly common because Linux is not a big enough platform for trojans to target, but it was known to be easy. Hugely easy.
> You might be better served by actually looking how X11 works, with quirks and what it was originally designed for, I promise you that your hair will stand on end.
You are confusing things. Where can you "interfere" with the renderer? What you can do is _replace_ the renderer. This is one extension point Wayland _forces_ on you, so what is your complain exactly?
Manipulating things around using the ways provided for things to be manipulated is not a quirk. The server allows other processes to render to windows they don't own because this is how you implement decorations and the like. The server allows you to read the contents of windows you don't own because this is how you implement screen grabbers and color pickers. The server allows any two processes connected to it to communicate in any way because that is how clipboards and things like that are implemented. This is all by design.
And that is the problem. If all of this was still possible with Wayland (WITHOUT having to patch the compositor), I'm certain there won't be as many complains.
But no; they tried to fix "security" (for some definition of security) at the same time and thus had to spend a decade to see any hint of adoption. And face a lot of resistance.
At least fetch the UNIX haters handbook if you want to see a minimally valid criticism to X...
> but it was known to be easy. Hugely easy.
Still is. Wayland or not. Therefore: Yes, I will downplay this issue.
You would need an even more radical design to make it not trivial on Linux (e.g. passing individual input device descriptors to the process owning the focused window or the like, and then make each process a different user or god knows). Basically: something like Qubes (which used to do it with X11). And then face all the "it's not working!" complains because you break even more things.
I'd definitely not want to work on a desktop where I can't have an app set up a global hotkey. Do you never record with e.g. OBS, simplescreenrecorder or things like that ?
I tried to setup my music controls with dbus but not all the keyboard shortcuts function either for some random reason, so its fundamentally broken if you want to change it still can't do all that x.org does.
Personally I use sway and tell my compositor to bind certain hot keys to certain commands.
The downside is that once a command is bound it cannot be reused: so if I wanted to have OBS and simplescreenrecorder that both use “meta+S” to start recording then that’s not possible.
The biggest issue I have with wayland is that OBS and screen recording simply do not work, I’m not sure if there are effective workarounds but a consequence of one program not being allowed to spy on another program is that you can’t record the screen.
> is that OBS and screen recording simply do not work
That is not true (at least in sway). You need the xdg-desktop-portal-wlr installed and running for it. Gnome and Plasma have similar desktop portal utilities, but I'm not sure they fully support the screen sharing wayland extension.
>They can be configured in your compositor. For those used to using i3, Sway makes this easy by being mostly compatible.
Pretty annoying to do this, too bad there's no easy import. A lot of effort for a lot of loss of functionality for smoother animations. Nice to know that redshift is updated thought!
If Wayland fixes screen tearing I might be able to stand desktop Linux. Is it time to give it another go?
Has the font rendering improved at all? My eyes can't handle some of the ugliness and my skill with code ends where the browser closes, so I've never tried to fix it.
I have always been happy with font rendering in GNOME3 under both Wayland and X (I don't think there is any difference). It is maybe not quite as good as MacOS, but it doesn't also have that artificial heaviness that plagued OSX/MacOS for many releases and only seems to have really gone away on Retina screens). It is light years ahead of Windows, which is always bad in confusing ways.
If you have Intel or AMD graphics I think you will be happy with Wayland and Linux.
Nvidia had a politics problem for a long time that is being resolved but the resolution is still on the cutting edge so I would wait a while. XWindows is generally fine.
Dual-GPU laptops with an integrated as well as a discrete GPU seem to still be buggy. Best bet is probably to not use the discrete GPU or plan for the occasional driver update kerfluffle. AMD again is better here.
Yes and no. The Linux default are bad because people lack some common taste in font rendering. The default fonts on most distros are pretty awful. Here's my recipe for the best font rendering setup on Linux, which in my eyes is as close as macOS (tested on Fedora 35):
* Have a high DPI screen at 2x scaling
* With a custom fontconfig, force the default sans, serif and mono to the Google Noto fonts. DejaVu and Bitstream are ugly. Don't use them.
* Copy and install the ttf files from your closest C:\Windows\Fonts directory. Everyone on the internet uses Windows fonts. HN and Old Reddit use Verdana.
* And the best for last: disable font hinting. Modern distros default to slight hinting, which is still too much hinting and distorts the font. MacOS doesn't apply any hinting.
Screen tearing is mostly just a matter of configuration. The only platforms that really suffered from it were Nvidia systems, and with the v470/v495 drivers those have pretty much sorted out.
Font rendering is fine by my eyes, but apparently it has gotten significantly worse on GNOME 40/GTK4[0]. On KDE it's quite nice these days though, so I guess you should just give it another whirl and see for yourself.
> Screen tearing is mostly just a matter of configuration.
This is not true. It's caused by drawing out sync with the vblank cycle. It has nothing do with specific hardware. Older versions of X11 didn't even allow drawing to be synced to vblank (the start of the raster retrace).
This is mostly irrelevant with modern compositors. If you force the compositor pipeline, the worst it will do is drop frames. To my knowledge, the only hardware that doesn't do this by default is Nvidia GPUs, which have a specific configuration option to enable it.
I always find such statements very confusing. It's like hearing someone if TVs still have that problem with needing to adjust the rabbit ears constantly while 90% of people have plugged theirs into a cable or satellite receiver. Font rendering worked fine in 2003. There is under skin certainly a lot of potentially interesting complexity around font rendering but you needn't much care about the details.
Some distributions look like Ubuntu look pretty good out of the box others look like garbage out of the box. Fedora used to be notoriously ugly out of the box in part because it was wary of implementing patent encumbered techniques. It's probably improved since. Notably firefox when rendering websites with some common on windows fonts in systems without many fonts installed may make some interesting and crappy choices insofar as substitution. If you install common MS fonts or tell firefox that websites aren't allowed to do their own thing you can avoid firefox raining on your font rendering parade.
If you want good looking fonts and don't like how it looks out of the box you mostly want to google good looking fonts in "foo" where foo is your distribution even though most advice is universal between distributions then consider installing some decent fonts.
For example in void linux following this gets good results.
No wizardry involved just rote direction following.
For void the google-fronts-ttf provides an absolute ton of fonts in ubuntu ttf-mscorefonts-installer provides some common ms oriented fonts. Nerd fonts provides a lot of interesting fonts. https://www.nerdfonts.com/ which you can install manually or via a distro package if there is one for you. They provide many fonts patched with lots of additional symbols.
I also happen to think San Francisco from Apple looks nice. If you use the font patcher from nerd fonts you can have Apple font's on your Linux Desktop.
No, according to the post I shared, you can do more than that:
> You can also recolor any part of a widget however you like
And they show an example of a gradient background and stuff like that.
And I mean, for most people, a theme is just coloring things how they like and setting the font and visual things. While full-blown stylesheets are very cool, and I think still “allowed,” you can’t really officially support that in a compatible way. You have to set an API so that everything can be consistent.
For example, it can currently be a huge pain to change the accent color on PopOS away from orange because you can’t just set a variable somewhere. It seems like the new system will improve that.
I'm going to be real with you, if your definition of 'theming' is setting an accent color and choosing between light and dark mode... I think I feel really bad for you.
I don't see any screen tearing on X11, with cinnamon on archlinux, on a 4K monitor, with Nvidia. No tearing when dragging windows around, scrolling text, playing fullscreen games at 4K (both native and with steam proton) or watching video at 4K. This without doing any special configuration, as far as I remember.
As for font scaling, I just choose a big enough font or default zoom level in the browsers, VTE's and text editors I use, looks perfect.
it's a monument on how things should be done, without breaking anyone's workflow.
edit: I really want to use Wayland, it is so much better for so many things, it looks better, font rendering is better, scaling is better, but it introduces new bugs that really are a no-go in my day to day usage, for example sometimes copy&paste shortcuts don't work.
I'm sure it's the fact that I use KDE and support is not top notch, but I have no such problems on X.org.
I would really love to see Wayland succeed, but how long is it gonna take?
Yes, I am very positively surprised. I always though PulseAudio was growing to be one of these "too big to rewrite" projects. And PipeWire started with a premise that was very off-putting to me ("The PulseAudio of Video"). But I was tired of filing PulseAudio bugs (e.g. HFP support which never went anywhere), so I decided to try. Not only PipeWire turned out to be a purely drop-in replacement (not a single feature broke, and Bluetooth support started working correctly), but I immediately gained new power-user friendly features even while keeping the same clients! Like the ability to choose the codec used for A2DP.
And then the small improvements started trickling in, such as absolute volume support in headsets. The stupid PA limitation of only being able to configure the 1st ALSA mixer element. And so on and so forth.
That was truly a killer feature. Sadly I have 2 similar pairs and one I cannot change the audio quality on sadly, but wow it really works seamlessly to replace pulseaudio.
> and cutting off the users who disagree with them instead of Doing One Thing, and Doing It Well
Your complaint is the opposite. You're complaining that Wayland is trying to do one thing & do it well instead of trying to be a kitchen sink.
X11 is the antithesis of Unix philosophy. It tries to do a hundred unrelated things (compositing, clipboard, drawing, input, etc...)
> Admittedly, there's not an elegant solution to any of this. However, in this specific example, I think the best course of action would have been to just outright plagiarize Apple's Quartz.
Or Windows' DWM. Or Android's SurfaceFlinger.
Android being Apache 2 would have been the more obvious one to take code/design from in this case, but desktop Linux seems to have a general disdain for anything coming from Android.
Well, curiously, X11 has no compositor, no definition of clipboard, and a drawing API that no one uses. It seems to me that precisely it is not trying to do any of these things, but rather providing the mechanism by which some other process (or processes) can do these things.
E.g. if tomorrow I want to implement a toolkit that wants to have 3 clipboards, I can; even without changing the server or the compositor process.
>X11 is the antithesis of Unix philosophy. It tries to do a hundred unrelated things (compositing, clipboard, drawing, input, etc...)
And it works. Do you avoid desktop environments since they do everything, emacs which might as well be an OS, or music players that can also rename music too? Is a messenger app something you will never use if you can call or send music or pictures on it? My file manager can rename files, show pictures, rename them, and even open compressed files. Why is the Unix philosophy relevant when most linux systems use systemd?
Do you even follow "Unix philosophy"? Installing a bunch of plugins to make wayland do 100 unrelated things is the same result.
XFCE still has that in it, and there are DE that are pick and choose, but I find it hilarious that having useful features means Unix philosophy is being violated and its and its bad that it has functionality that users enjoy.
> X11 is the antithesis of Unix philosophy. It tries to do a hundred unrelated things (compositing, clipboard, drawing, input, etc...)
Not really, aside from input (which is also optional) all of what you mentioned are provided by separate applications, not X itself - these just work on top of X.
But in general the Unix philosophy isn't some sort of dogma and it never really was. It is more of a guideline and it can be ignored whenever that makes sense - e.g. the Linux kernel itself.
Also if there is any philosophy that X11 has is its "mechanism over policy" one, which is also why it has lasted for so long: it gives you the mechanism to do things but doesn't enforce any specific way to use these things and instead leaves things up to the clients. This is also why you can use a TON of different environments and UI approaches on the same X server, including stuff that the original X designers wouldn't even imagine.
Thank you for putting this into words. Wayland solves problems I never had, while creating new ones at the same time.
I'll stick to Xorg + openbox for as long as I can.
We need a Lennart to say 'fuck it', here's what I want, here's why, and I'm gonna do it. Unfortunately I don't think a whole gui display environment is in the cards for one person.
Wayland is also missing that one cool feature that makes people say: yes, I want that; I need that. And I KNOW I don't want Gnome 3.
>Wayland is also missing that one cool feature that makes people say: yes, I want that; I need that.
Its new! That's good enough for a lot of adopters. Gamers (on linux lol) might care about graphics. Wayland is however feature rich in having more people see it as a less functional software and when I tried it, I appreciated x.org more and more.
Edit: Gnome and wayland give slow mouse movements and can crash if you move mouse too fast.
It has one killer and necessary feature. It's smooth. Have you tried resizing a window under X11 and doing it under Wayland? I have hated those half drawn rectangles caused by X and the app not being synchronized for DECADES. In 2021 I can have a GUI that's almost as smooth as Windows 7 was.
I feel the rift in the Linux world grows bigger between the conservatives (fuck systemd! X11 was alright!) and the progressives (can I have HDR, fractional scaling, and hardware video acceleration on YouTube, please?). I want my computer to be modern and slick and fluid, I'm vain like that.
Yes, Wayland is still a beta, but it's here to stay, like systemd, like flatpak, like pipewire. There was no status quo before, X11 was a beta and crappy in other ways. Not suited for modern hardware. Deal with it. The xorg repo is there for anybody that thinks they can do better than Wayland. The reason why xorg had to be abandoned is a Google search away.
>I feel the rift in the Linux world grows bigger between the conservatives (fuck systemd! X11 was alright!) and the progressives (can I have HDR, fractional scaling, and hardware video acceleration on YouTube, please?). I want my computer to be modern and slick and fluid, I'm vain like that.
I have fractional DPI scaling in x.org, I just don't use it since undocking keeps it on that on my small screen.
I use systemd, pipewire, x.org, and never follow unix philosophy with my desktop environment not because I am some sort of political standard you set arbitrarily, I just use stuff that just works, like most computer users.
> The reason why xorg had to be abandoned is a Google search away.
Its mostly because you can't make it more perfect, but they did!
>After three years without a full release, X.Org 21.1.0 has finally landed with new features and a lot of bug fixes. While the next-generation for all Linux systems will eventually be Wayland, plenty still default to X.Org.
I really dislike how you turn linux into politics, announce it isn't suitable for modern hardware with zero reason, saying x11 (actually x.org was crappy as if the whole thread isn't talking about how much crappier wayland is) and deal with it. Leave your feelings at home.
That is a lot of writing without linking to actual detailed issues you are having. It is complaining while making it near impossible for anyone to help you or figure out exactly what your issues are to try to resolve them.
I read it fine, it removes/isolates a lot of useful features, and doesn't seem better in many real world use cases it is worst, like clipboard, screen warmers like redshift, global hotkeys, and VNC.
I have tried these as addons, and they basically suck, and its complex to change them, and for what benefit? Some smoother graphics? I am on Linux, that is the least important thing. Basically if it doesn't give me real world benefits, I am unlikely to want to switch, and if it gives me more issues and less features for things that matter and isn't a drop in replacement it might as well be a scooter to my car.
> and for what benefit? Some smoother graphics? I am on Linux, that is the least important thing.
This really sums up this side of the argument for me (though it doesn't address the security features of Wayland). If I want to watch an ultra high definition movie, or play a game, rebooting to windows is a miniscule price. Almost all of my work is done on Linux, and I value it because everything can be made to work, usually with little effort. Wayland adds some severe overhead to that work.
https://old.reddit.com/r/VFIO/comments/n3mjj3/native_vs_vm_b... you can also do this. If you want to use wayland without issues GNOME works well if you wanna login to another session, VFIO will give you full windows game support (Win VM will use the GPU in windows driver mode).
For anyone who wants a functional desktop on any DE, x.org is the best, and cannot be replaced currently by wayland in features or software compatibility.
I've tried it a few times, across Intel and Nvidia GPUs. I never went through the trouble of identifying or filing the issues (life is too short), but just off the top of my head, I remember:
- Cursor rapidly changing state for no discernible reason
- Missed inputs, particularly in xWayland
- Drawing issues, where portions of one window would appear and the rest would fail to draw entirely
- Electron apps were hit-or-miss out of the box, but I got most of them working
- Display flickering and seriously messed-up color correction in xWayland applications, rendering a handful of games and apps just completely unusable
It's been a few months since I've given it a run again, but I'm not exactly excited to spend a day figuring out how my display manager functions when x11 works well enough for my uses. Maybe once the KDE bugs get ironed out properly I'll give it another pass.
It's not a GNOME project. You've even listed one DE that supports it and has nothing to do with GNOME. It's just that KDE is late to the party and it's now scrambling to polish their Wayland support for the next 5.24 release, also thanks to Valve sponsoring part of the effort for the Steam Deck.
I'm just not going to use it. X works fine and it will still be working fine in 10 years. I don't care or even know what purported benefits Wayland will bring, because I don't need any benefits over what X is already doing. You're just installing bugs by switching to this thing.
I have a 240Hz monitor, so gnome-shell passes data to xwayland and then to applications at ~220Hz (as seen in the event-freq from https://blogs.gnome.org/shell-dev/2021/12/08/an-eventful-ins...)
So, my expensivish 1kHz (or even 8kHz mice - as these exist) will pass mouse movements with 4ms+ delay and only <240 times per second.
Under Xorg, the xinput proto will pass data at the ~usb polling speed. For my 2kHz mouse, the tool (event-freq) shows ~1700 events / second.
By the way, this ~220Hz is the speed at which gnome-shell passes data to clients (via XWayland or directly). The libinput accepts and passes data at correct 2kHz - and it's only gnome-shell aggregates it under wayland - this can be seen e.g. in the evhz tool (direct /dev/input access) vs event-freq tool (gnome-shell in wayland session, and xinput in xorg session).