HW accelerated Xwayland rendering for Nvidia merged
gitlab.freedesktop.org
gitlab.freedesktop.org
Using Qt apps under Gnome on Wayland can break in weird ways (e.g. in one case I saw popup menus opening in weird places or disappearing entirely). Meanwhile, because window decorations under Gnome are client side, the behaviour is weird and inconsistent (double-click on a Gnome titlebar and it maximizes, but double click on a Qt app titlebar and it doesn't).
So maybe switch to KDE? Unfortunately, the idea of a "primary" display simply doesn't exist in KDE on Wayland, which is a major regression for multi-monitor setups. And that's setting aside that KDE on Wayland still crashes on a very regular basis.
Under Gnome I've also seen apps like Guake that simply don't work properly due to either bugs in the compositor or limitations in the Wayland protocol (I'm still not sure which), so you need to find workarounds in those cases.
In general this leads to distros not enabling Wayland by default in clients and toolkits, even if Wayland is the default display server. For example, on Debian (testing), both Firefox and QT require special environment variables to be set depending on your setup. If you don't set them, those applications just use Xwayland and you lose things like fractional scaling. Force the use of Wayland and you end up with a lot of the issues I mention above.
Wayland is really coming along. When it works, it's smooth as butter and works great! Heck, I'd love to use it if only for fractional scaling support. But a lot of things are still very broken and it's still gonna take a while for things to mature.
You could put different windows on particular screens or just punt everything to the desired primary monitor.
This functionally is also available in i3wm/sway as for_window and as a stand alone application under x called devilspie2.
The idea is that things like the status bar, top bar, dock, etc, appear on the primary monitor unless configured otherwise.
Similarly, new windows preferentially open on the primary monitor.
This is existing functionality on all of these desktop environments.
In a multi-monitor setup, you designate a monitor as the primary monitor and the desktop automatically "does the right thing" even if you remove and reattach the primary display.
KDE on Wayland loses this functionality. The primary monitor is whichever monitor is detected first with no way to control it through configuration. The only workaround is to disable your secondary screen and then re-enable it, and you have to do that every time the desktop launches or the display configuration changes, which is a deal-breaker if you dock/undock regularly (or when the display server crashes).
Might there be hacky workarounds that partially fix some of these issues? Maybe. But it's a major functional regression and I'm not willing to invest that effort (especially, again, given the stability issues).
BTW, Gnome on Wayland preserves this functionality. But unfortunately, as I mentioned, Qt + Gnome leads to a whole host of other issues.
In my opinion primary monitor is conflating 2 settings that perhaps ought to both exist in an easier to use that windows rules.
Open new windows on ____ selected from monitor with mouse cursor, same window as focused application, a selected monitor with the default being same monitor as focused application.
Always show panel in place of any other bar yes/no. Unchecked by default. You can have a panel on each monitor and put things of your choosing in each panel or even have a panel on top and below on the same monitor if you like. So what happens if you have a panel on your primary monitor 1 and also on your secondary monitors 2 and 3? Say you unplug the laptop and monitor 3 becomes the only monitor.
The most obvious and simple thing would be to show the same things on all 3 including showing a taskbar for the windows just on that particular monitor so that when you undock you can still do the same things. Windows does this for example the only difference is which bar has the tray.
The most theoretically correct would seem to be allowing you to set different bars for different configurations but this would be complicated and perhaps little used.
What I've suggested would be to give you the ability to set a primary bar that is always displayed hiding any secondary bars that normally appear on that display.
But there's already a built-in feature in KDE/X11 for this. It's just broken in Wayland. It's a feature regression, plain and simple.
I'm not saying these things can't be resolved! They probably will be, eventually. I have every confidence that some day, KDE on Wayland will restore this now-missing feature.
I'm simply saying, through my personal laundry list of bugs and regressions, that Wayland is a long way off from ready for prime-time due to a wide range of issues that go well beyond the oft cited, very well-trod issue of the lack of screen sharing.
That's it.
And I genuinely look forward to the day those gaps are closed and I can use Wayland full time!
I just have a feeling that won't be until 2023 at the earliest.
Personally I expect windows to show up on the same monitor as the currently focused window or the cursor and having it pop to a primary monitor would be from my perspective a defect. I would have to test but I think that outside of gnome this is actually how the majority of linux environments work out of the box.
You don't have set a windows rule in the settings gui just to use your computer. You have to set a windows rule in the settings gui for your computer to work in the fashion that you prefer. That you regard this setting as essential doesn't mean that it actually is just that you strongly prefer it.
Come on, Wayland was released 12 years ago! And it still has all kinds of problems that don't make it qualify even for beta software. I'm highly skeptical that Wayland will ever be as useful as X11 is right now.
Wayland, itself, is just a protocol. The display servers are just the display servers. But then you have Gtk and Gnome, Qt and KDE, software like Firefox and Chrome, etc. All of those have to updated as well, and while Wayland the protocol, the display servers, and a lot of the suite of infrastructure around it is in pretty good shape, the toolkits and clients and so forth all still need a lot of work.
And you only need to look at the Python 3 transition to see how hard it is to shift a whole ecosystem.
So I'm willing to cut the Wayland guys some slack. But it does mean there's still a ways to go, yet, before things are ready for prime time.
The folks involved in designing the Wayland protocol seemed to have shed a lot of key features in the name of simplicity or security, forgetting that the solution actually has to meet real, human user needs. Those needs include things like screenshots and screensharing, global hotkey binding, etc, etc.
To address that, we now have a range of extension protocols, which is creating fragmentation. The CSD-vs-SSD debate is a perfect example.
Things are slowly coalescing--PipeWire is maturing, for example, filling some key gaps--but it's taking time and meanwhile IMO the ecosystem continues to be too immature for broad adoption.
Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Maybe someone will figure out a good way to do this but I wouldn't hold my breath. You're better off writing a compositor extension to do what you want.
The CSD-vs-SSD debate isn't anything new, there were apps that used CSD before wayland, and there were X11 window managers that didn't draw any window decorations. There is fragmentation there but it's caused by the apps, you won't fix that one without rewriting all of them to have the same policy on decorations, probably that means redesigning all of them to use the same widget toolkit and designs.
Is this feature standard on every OS in use by human kind today? Is this feature requested by most users and not having it pisses off most users? Is this feature available on the system that Wayland aims to replace?
Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.
I don't know of any way an Ethernet device can be truely secured, perhaps it should be disabled until a solution is found. I couldn't care less about a system that is more secure if it massively interfere with day to day usability.
Of course a custom extension can also be created for this use-case, in which way the compositor can allow/deny access for keypresses to specific windows. But to be honest a central hot-key manager where apps can register new bindings (and with compositor managed multiple bindings resolution instead of the ad hoc way under X) would be a great target.
None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases, or worse, to make those use cases someone else's problem (e.g. screen sharing), thereby creating fragmentation in the ecosystem due to a lack of standardization.
After all, it's pretty rich to blame Gnome or KDE for "[deciding] to do something different" when Wayland was very deliberately designed to offer no standard for how to do the thing in the first place.
I'd actually prefer it was unintentional, as that would imply simple oversight. If it was intentional, that implies deliberately bad design choices that have gotten us to the semi-broken place we are right now; a place we're only finally getting out of as other people (e.g. the PipeWire folks) step in to cover up the spike-filled holes that Wayland has left behind.
You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. The fragmentation here is because it's taken a lot of effort to redesign these core components. Ideally this would all be done already, but it takes time.
Given that Wayland was first released in 2008 and the first commit to the PipeWire project was in 2015, I'm quite confident at this point that you're rewriting history to support your position.
As they should've done with the many other features that are missing from the base protocol because some designer somewhere decided it was "beyond the scope of the project".
We even have a pattern for this in the way HTML5 was developed.
I swear, it's like the Wayland folks were absolutely hell-bent on repeating the mistakes of the browser world circa 2000. The only question, now, is which project will end up the IE5 of the Wayland compositor world...
I'm being serious here, I legitimately don't understand what you're pointing out. Yeah I too wish everything I was planning on 13 years ago turned out perfectly, things don't work like that though. And if you ask me, the thing that's most comparable to IE5 is the Xorg server.
Amazing how nothing is ever the fault of the people leading the Wayland project.
> Any implementor always has permission to do their own thing, that's the point of making a second implementation. Putting something in a spec somewhere doesn't make it mandatory or guarantee it will be implemented.
Ahh, now I've got it!
So what you're saying is that, in essence, since your claim is no one follows it, one must conclude that in fact there is no spec!
And given that everyone I've come across who's involved with Wayland has said "Wayland is just a protocol", and given protocols are defined by specs, if the spec doesn't exist, then neither does Wayland!
Neo would be proud.
> I'm being serious here, I legitimately don't understand what you're pointing out.
I can't think of anything that more succinctly describes what's wrong with how Wayland has been developed over the last 13 years.
Well, except there is no spec, so I guess nothing was developed at all? I dunno...
>I can't think of anything that more succinctly illustrates what's wrong with how Wayland has been developed over the last 13 years.
I don't understand why and I wish you wouldn't do this, this is leaning into flame war territory. If you can explain your point to me in a way I understand, then I'm ready to listen.
The entire point of a spec is to help drive interoperable implementations. If that's not the goal, then it has no purpose and it might as well not exist.
The core of Wayland is supposedly a standardized protocol and these various projects seemed to do just fine implementing against that core spec. There's a reason I can run a Qt Wayland app on Mutter or vice versa.
Evolution and development of that spec can be done in a collaborative way that takes into account the various needs of those projects, such that the standard can evolve in a way that furthers the whole ecosystem.
That the Wayland folks instead throw up their hands and just say "write a compositor extension" demonstrates their unwillingness to do the actual hard work of building an ecosystem, which is creating consensus and driving adoption of common features.
Is this hard?
Yes.
What they are doing is hard, and it's deeply naive bordering on irresponsible to engage in a project of rebuilding the entire display server ecosystem without recognizing the need for coordination and diplomacy across the open source world.
I look at the history of this and all I can think is that this is a group of people who have failed to learn the lessons of the past. Groups like the X11 and HTML5 standards bodies, the IETF, and so many more have demonstrated how to build a consensus-oriented specification that enables and encourages interoperability. Yet, to hear you speak of this, that must be a figment of my imagination because apparently that's impossible.
If you ask me, people only notice the ones where it takes a while to reach agreement. Just look at the PR we're commenting on, it took nvidia several years to come around and implement dma-bufs. Sucks but it happens. No one ever seems to pay attention to all the other areas over the years where there was consensus.
From the perspective of someone happily using X11 at the moment, Wayland (or whatever your preferred term for "the loose association of compositors, protocols, extensions, and nonstandard hacks making up the Wayland ecosystem" is) looks like a failed attempt at building an ecosystem with proponents who are now trying to push it on everyone else in an effort to get the rest of the open-source community to solve the problems they created.
Every compositor is doing their own thing, application and framework developers need to implement basic functionality in one of several different ways depending on which DEs/compositors/WMs they want to support, some stuff has no replacement at all, and we're going to have to throw out the entire X11 world in exchange for... smooth DPI scaling and vsync? Really?
I honestly want to switch to Wayland - some of the stuff I've read about the X11 codebase is terrifying - but the cost of doing that, throwing out the entire desktop world, and giving up legitimate use-cases as "you shouldn't want to do that" is just too high, and the benefits are minimal. I'd honestly be happy to switch, but the whole ecosystem feels like it's a decade or two from being ready to go.
A lot of the hate Wayland gets stems, in my view, from the way it's been pushed on people. Users who aren't invested in the ecosystem and just see people pressuring them to switch to a loose collection of half-finished software that doesn't properly replace what they already have.
A protocol should never, never, ever be defined in any way by its implementations. The entire purpose of a protocol is to abstract away the common interface such that it is entirely implementation-agnostic.
Indeed, you might say that a protocol prescribes exactly the intersection of all implementations.
That's a better way to put it and that's more what I was getting at.
How did they manage to get through the project without addressing this point, and make it even worse, by offloading stuff like "screenshots" that was taken as a given to the nonstandardized compositor layer?
I'd also have wanted to see much more of a "one true widget library"-- so Wayland!GTK or Wayland!Qt are just thin wrappers on top, which would ensure you get any native theming or customizability/accessibility tweaks cross all your software for free.
The wayland protocol is multi-layered, with the core being deliberately only used for displaying content in recrangles properly. That’s it. But it also allows for querying the capabilities of the compositor with versioning, making extensions possible. There was a recent Show HN submission with this site: https://wayland.app/protocols/
The not-yet-core extensions doesn’t create fragmentation, actually there is a decent cooperation behind the 3-4 major compositor “backends” on everything, and ultimately they all settle on the same thing. Also, it’s a bit generous to say that fragmentation is somehow the fault of Wayland, when it has always been a problem in linux desktops.
Also, why do you think adding screen recording into wayland would have been great? It is a complex problem with audio syncing, not-necessarily display-related programs accessing streams and the like, so it seems relevant only on a surface level. Pipewire is the good layer to handle it. And prebaking some API without pipewire being ready would have been just stupid. It is/will be supported everywhere (there is a portal frontend already for gnome, sway and I believe plasma as well).
This to be part of a monolithic identical system where different distros are only different in terms of default software installed and logo and the entire os is read only and not user serviceable.
Look up rethinking how we put systems together by leonart poetering and comments from gnome devs about disabling theming to improve brand awareness or arguing about the folly of letting users muck up their work with the horror of extensions.
Android and iOS and Browsers these days already have figured out something for those kind of things - they ask for permission.
https://www.x.org/wiki/Development/Documentation/Security/
The X.Org Foundation released 7.2.0 (aka X11R7.2) on February 15th, 2007.
The Wayland devs themselves say "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X." https://wayland.freedesktop.org/faq.html#heading_toc_j_5
They just didn't want to.
https://www.freedesktop.org/software/XDevConf/x-security-wal...
(Wayland's "buffer exchange and update models" won't provide security on their own without any improvement on the input side)
That is the root of the problems IMO. The thing is, this design decision had made the ecosystem a lot harder to grow than X11/xorg.
But seriously, the "competition" between these compositors is awesome. This is like web standards again. Testing your client across different compositors reveals bugs (either in them, or in your client) and everything evolves together in standard ways. With the single Xorg server, everything got completely ossified, if anyone wanted to rewrite a full "production ready" X11 server they'd have to be bug-compatible with Xorg.
X11 also ran fine in 1995. Granted, I think fvwm2 was probably state of the art for window managers at the time. From '95 to almost '97 or '98 I stuck pretty much in 80x25 or 80x40 text console. Not because X11 didn't work, but more so because xterm really sucked and the only apps you would use in X11 anyway were Netscape, Gimp or xv (image viewer). Gtk+ also did not exist, so everything was ugly Motif or Tcl/Tk.
Oh, and... there was always talk of replacing X11. Even in the '90s. People have been talking about replacing X11 nearly as long as X11 has been around, sadly.
Hardware has just improved enough that we don't need to care.
This isn't wayland vs X11.
X11 is terrible for other reasons, but let's not give wayland credit for hardware improvement.
X was actually okay in 1996 on the proprietary Unixes with their proprietary graphics card and proprietary monitors. (At least on HPUX, Solaris, and Irix). Linux and the *BSDs had some catching up to do primarily in hardware support and autoconfiguration. But they did so quite rapidly.
Also, it is questionable at best to state that Wayland compositors doesn’t work. Gnome is quite stable and with pipewire everything just works. Sway is similarly a stable software.
Random example: in Sway, Chrome and all Electron apps have blurry text on displays with scaling other than 1.0. Every time I try “wayland” (or whatever term you would prefer I use), there is some show stopping bug like this.
I feel like the conversations here usually go like this, with people just talking past each other:
A: “X11 is going away, time to switch to Wayland!”
B: “Okay, but last time I tried it, it didn’t work for me because <list of reasons>”.
A: “No no no, you don’t understand, that’s not Wayland’s fault, it’s a compositor issue.”
B: “Well, whatever the issue is, I’d like to keep using X.”
A: “But X is going away! It’s deprecated!”
That’s literally because of X. Both of them run by default in XWayland, but chrome do have wayland support already (but has to be enabled), and electron also have since being built on chrome, but most versions out there are not built with that version I believe.
Also, noone says you SHOULD change. Feel free to use whatever you want. But saying wayland suck, when you didn’t even use goddamn wayland for evaluating it just “sucks”...
I don’t care — that was the whole point of my comment.
> Also, noone says you SHOULD change
Yes they do! People are saying all the time that X is deprecated and going away, and we need to switch to Wayland.
If other people want to use Wayland, it of course doesn’t bother me; I just hope it never becomes the standard and pushes out X, which works fine for me.
You can continue to run on eg. Linux 3.* if you so wish. And X is a stable software, it will continue to work reliably in the foreseeable future, even without active maintenance.
Did you read the comment I was responding too? It had already conflated the two. However, in the spirit of not being petty, I ignored the conflation and decided to address the real issue, that implementations of Wayland are not stable after 12 years, while X was actually stable after about 8.
Same on sway. I think the relevant bug report is this [1] but there is no traction and the patch doesn't really work. Qt5 is probably not going to receive any attention now too, so I'm not holding my breath.
Upd: well, that problem doesn't seem to be fixed there, still no constraints are set on the kde/5.15 branch
The main issues I encounter are about screen sharing. At the moment it does not work for wayland apps (i.e. wayland apps don't show up in the share this). Supposedly there is a way around it, but I've not yet needed to investigate. The other issue is OBS not working (I guess also because of screensharing). And the third issue is some weird bug in Zoom, where if I open the participant or chat window, it becomes extremely laggy. So much so that I can't really type in the chat window because there is such a strong lag, that I finished typing before the word appears. Similarly the video feed becomes choppy.
One other issue was that Pycharm was having issue opening some menus/windows but that seems to have been fixed now.
Definitely a Gnome issue.
I actually listed a range of issues. Some are in Gnome. Others are in KDE. Yet others are in the toolkits (e.g. the Qt popup menu problem). And still others are in the applications themselves (e.g. Firefox has a whole menu of Wayland-specific bugs).
https://bugreports.qt.io/browse/QTBUG-87303
https://bugreports.qt.io/browse/QTBUG-87332
If KDE patches actually make menus work okay, that's great. I've been wondering how KDE deals with the bugginess of the wayland QPA, turns out the answer's simple and not KDE-exclusive, nice.
upd: seems like no popup constraint adjustment is set on the kde/5.15 branch. Hopefully there are other improvements though…
I don't care for "smooth" or "every pixel is perfect" so to me the trade-offs are all negative.
https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
As a happy Openbox user, I'm planning on trying Waybox first I think. Waiting for the next Debian release though.
To do this in Wayland I imagine we'd need to have Emacs act as the compositor and that sounds a bit too crazy... Or perhaps some kind of a proxy-compositor could be used that could be fully driven by Emacs using an rpc protocol. Is there such a thing out there?
[1]: https://nyxt.atlas.engineer/article/technical-design.org
* Snapshots
* Portability
* Isolation
Just a few things i could come up with as valid reasons someone would want to do this.
* Compartmentalization
* Layered defense
* Windows is not allowed to touch my bare metal
* Having development images for work, play, etc.
* Easy migration
* Configuring multiple separate environments from one control node
* Accessing my virtual machines over the wire using QEMU on my laptops
* Being able to take a system crash without losing other running contexts.
* Maintaining host-level logical volume management and snapshots while guests retain a simplified partioning layout, with separate images for easy migration of `/home` and `/usr/local`
* Advanced firewall configurations
etc.
The very conservative nature of Ubuntu packaging really holds back things getting fixed in my opinion. It’s hard to have a feedback loop when the biggest desktop distro ends up being super far behind. I get why but I would love an opt-in “rolling release” repo for Ubuntu, as silly as that seems
Ubuntu desktop, default desktop and config.
Because Linux desktop is already fringe. If you use uncommon options on a fringe OS, you're going to spend lots of time debugging problems. I just like my tools to work.
I'll be sticking with X11 until wayland becomes the default in some future LTS release.
I have read of the supposed benefits of Wayland, but from what I can percieve, the cons (too numerous to mention, but mostly breaking a billion useful things that X has had for some time) seem to out weigh the pro. Yes, the pro. Fractional scaling.
I don't like actively cheering for something to fail, but I really don't get it. X11 is in no way broken enough to justify such a huge change, and I'm concerned that the KDEs and Gnomes of the world are going to ramrod the thing through regardless.
Wayland is a necessary part of security, but not sufficient.
Linux only grants permission to keyboard/mouse events to root or to display “owner”, which is the one who requested it on a given tty.
* Using ptrace(2) to hook into your running processes and grabbing key data that way
* Adding a LD_PRELOAD around your application launcher (via your .bashrc or some other auto-exec script) to have it intercept key events for your application
* Downloading and mounting a FUSE filesystem image with the /dev/input device nodes owned by your user ID instead of root.
* Use one of the multitude of privilege-escalation CVEs on the Linux desktop to gain root, and keylog you that way [1].
Come back when you understand the problem.
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privi...
How does X help here?
That there exist SELinux plugins does not mean that XACE itself depends on it. Like, try reading the actual documentation instead of regurgitating FUD: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...
It's also outside the scope of a desktop environment or window manager to ship plugins to the X server. Hence another reason why they had to go with a new protocol that makes it easier to implement their own server...
I stopped reading at this point. If you're not going to read the documentation, then you can kindly go crawl back under your rock on /r/linuxmasterrace.
Yes people could develop new plugins that integrate with some other security mechanism, but they haven't, in part because the hooks are so out of date, and in part because, you know, that requires building another security mechanism. The access hooks are not a security mechanism, they allow you to integrate with some external MAC.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Someone is trying to get multi-touch support merged, but is waiting for a review.
Mostly the issues could be hacked around. But let’s be absolutely clear with this: it is hacking around the issue.
Problem: tearing, solvable with double buffering, maybe.
Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program. Solvable by running a mini X11 instance for each program.
Problem: Xorg is a network system, meaning it is very inefficient. (Imagine using TCP to talk to your SSD)
Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features. Especially as the client may not be on the same machine as the server.
Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.
> Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.
This may seem like it's irrelevant for the user. It isn't. Lots of things us users want are much easier and more attractive for developers to add to the clean slate design that is Wayland.
For example: When I switched, an unexpected bonus I experienced was that my touchpad's behavior got orders of magnitude better. So I googled around a bit, and it turns out that almost all touchpad improvements just happen to occur on Wayland because the people who are interested in that aren't interested in wading through the X swamp in order to implement their stuff. (I mean, have you looked at the X code? Oh dear, oh dear, it's a daunting thing!)
This is something I don't understand about Wayland. How is it possible that something that is supposed to be much easier and more attractive for developers after TEN+ years of development still has so many issues ?
I see it as a “failing” of the bazaar way of development, linux can’t just say we now use this API. So there is an inherent not enough user on the new API to bother porting, and due to not enough user it is not as streamlined/stable, and you have a vicious circle. But I have to say the issues with wayland are heavily overstated, and I think it is out of this cycle, and is getting quite a bit of steam.
I've never even had a reason to want to run it.
But I'm sure it'll be great, any day now.
It just seems Wayland's combination of technical requirements and political entanglements make it a sort of Zeno's Project, doomed to asymptotically approach peoples' expectations and desires, but never reach them.
So? The same has been the case for desktop Linux in general, for 2 decades.
Some of us have been running Linux desktops for over two decades. Nothing more fun than setting Modelines manually for your VESA card:
Linux Desktop is Great. Wayland is still in the process of becoming great (I think it's making good progress too)
Wine sucked and there was less software existed but it was perfectly possible to do the normal tasks one did with a computer.
Edit: I guess it was a 486 in a 386 motherboard. Windows was definitely slower at 75MHz than Linux at 25MHz though:
http://ps-2.kev009.com/sandy55/Interposer/386_upgrade.html#R...
Reference: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPl...
I am quite sure that there is something wrong with your system if your X clients run through the IP stack by default.
I'm running Openbox/Xubuntu on a 4K monitor, doing some awesome equivalent-of-4-monitors work, then playing all the steam games I want with the Proton and the decent AMD GPU, all under X. "Font size is a little weird sometimes" is my only gripe?
Put differently, I understand "hacking around the issue" criticism in theory -- but if you applied that sort of purity to, say, web programming -- step one would be, okay, first get rid of Javascript, an idea that I really do like in theory, but I know it's not happening.
I don't care if xorg runs as root and I don't need to run an instance of xorg per application I simply install software from trusted sources and haven't managed to get malware between 2003 and now. I also didn't have issues with tearing in 2003 and I don't now.
Generally speaking QT and GTK and other toolkits must concern themselves with the details of X others concern themselves with QT or GTK as they would under wayland. It is extremely likely that all players in the overall ecosystem who never had to specifically worry about X in many years have had more issues, work, and tears from wayland development than they would have had for the remainder of the next century with X.
This is nearly entirely about presenting a saner stable base to improve the work for a tiny number of people actually developing the graphics stack in Linux to build upon and unfortunately they made poor design decisions at the start that have led to it taking 12 years and still not being ready for prime time in some ways.
After doing the necessary research to understand the topic you could construct another post about the shortcomings of X that is actually factually correct but it would still be beside the point. Wayland would still be a poor work that squandered a lot of the opportunity of a clean slate despite its authors being in perhaps the best position possible to do so. In 20 years Linux if it exists on the desktop will be a weird opaque overengineered system that works when it works and is impossible for an end user to understand why it is misbehaving when it doesn't.
On the bright side due to package management the windows solution of pave over the install and start over could probably be configured to automatically reinstall all your software for you!
The X server is maxed out, or as a core maintainer said, you can only apply this many lipstick to a pig. It is fundamentally broken. But the X api is not, it will be supported forever in terms of XWayland. Which is a net win, we get proper graphics, and apps will be backward compatible.
The Wayland developers disagree with you:
https://wayland.freedesktop.org/faq.html#heading_toc_j_5
"It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X."
They themselves say they could have fixed X. They just didn't want to. And now they've predictably just made a new mess.
Just watch it.
Take the whole part about "X terrible IPC" and slow startup time as an example. It's portrayed as if slow startup time is an inherent flaw of X due to blocking IPC calls. However he forgot to mention, that non-blocking calls had been there for years and big projects like Qt were using them exclusively instead of the blocking Xlib calls. Then he goes on to say that Chromium's startup time is so slow because at minimum it waits half a second for replies from the X server. So let's get some current numbers on a T420s for starting up Chromium and immediately closing it:
Weston + Chromium (Wayland mode): 731.3 ms ± 39.4 ms
Sway + Chromium (Wayland mode): 688.2 ms ± 22.7 ms
Sway + Chromium (XWayland): 667.2 ms ± 16.6 ms
X.org + i3 + Chromium: 661.3ms ± 17.2 msSo either his numbers don't apply anymore and X.org is not a bottleneck anymore, or Wayland became a similar bottleneck, or his numbers never made sense in the first place, especially since he never bechmarked the Wayland part.
Edit: On GNOME Shell Chromium also starts slightly faster with X.org with 0.6 - 0.7s and > 0.7s in Wayland mode.
*updated benchmark results with the actual results from hyperfine (10 runs each)
The whole point of the talk was that when a compositor is used (which should absolutely be used because with increasing resolutions tearing will just get more visible), X has pretty much a useless role in the whole situation. That is, you’ve got yourself an architectural problem. Which is no surprise, X had been here forever. But maybe it should no longer the be the abstraction we build our graphics on.
So it doesn't seem to have any significant influence either.
Breaking user's applications isn't actually a virtue.
And also perfectly possible with X11 because the pitch information is exposed via the Xrandr extention
> Problem: tearing, solvable with double buffering, maybe.
Solved since ages. Just enable Tearfree in your Xorg.conf. That also shows how great X11 really is. It allows you the choice to turn it on or off. Because Tearfree comes at a cost of latency.
> Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
OpneBSD solved that two decades ago. Also it perfectly possible on Linux to run X11 as non-Root.
> Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program.
This is a feature not a bug. The security paradigm is blacklisting (which means sandboxing untrusted apps) instead of whitelising (which means locking everything up and only allow the compositor to do stuff). Since the vast majority of Software on FOSS system is trusted X11 is the far superior solution here.
> Problem: Xorg is a network system, meaning it is very inefficient.
X11 runs even on 386's and beats Wayland in every performance metric, especially latency. After 13 years of development only some compositors come close to X11's performance.
> Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features.
Backwards compatibility is a major feature even 40 year old Software runs on current Xorg which is an impressive feat. As for the "hardware features": DRI3 uses the exact same buffer sharing mechanism as the major Wayland compositors do. Wayland offers zero advantage in exploited Hardware features. On the contrary X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
> Overall, wayland is a good clean slate, it’s been in development a long time.
It is a clean slate, but a very bad one. The wrong philosophy ("every frame is perfect") and the wrong abstractions ("everything in the universe is a buffer made of RGB values") make it a major step backwards in computer graphics on Unix/Linux.
This is absolutely not a good solution. Even if you audited all your software enough to consider it trusted (which is unlikely if you're not a purist - see IDEs, browsers, widevine, Docker ...), it does not guarantee anything is secure. Anything that receives input from the outside might be vulnerable to an RCE. If you're running it under a different user or in a jail, the impact is limited - unless it can access your X server, in which case it can simply log everything you type and escalate.
Jailing an app is basically impossible under X. Yes, you can use Zephyr, but you're not going to be able to watch a video there and you're WM integration is going to be miserable as well. And realistically you'd really need to jail most apps.
X11 might work for a lot of things, but blacklisting is absolutely not a superior approach.
Indeed. But looking at the state of the average Wayland compositor right now I trust all of my X11 software more than I trust Wayland. Especially when X11 and most clients have been battle tested for up to 35 years.
Besides that, you can also use Xpra for sandboxing which has better desktop integration.
Only the "Windows" kind of scaling where the app works in non-scaled, real pixels and does everything by itself. Not the "Apple" kind of scaling that Wayland supports, where you have logical pixels backed by 2x/3x/… the physical pixels. (Like many things Apple does, this was invented for good reasons. Positioning a window to be on both a 1x and a 2x monitor just works with that kind of scaling, without the app ever having to consider the displays it touches.)
> Solved since ages. Just enable Tearfree in your Xorg.conf.
That's a driver-specific hack that kinda maybe works sometimes. Sometimes you need to juggle compositor options combined with that and nothing works anyway.
> X11 runs even on 386's and beats Wayland in every performance metric, especially latency.
Any composited X11 desktop is slower than a Wayland one, with the Xorg server acting as a bloated IPC broker in between the compositor and the client.
Yeah, you can get really low latency if you just don't composite at all. Go back to Windows 95 if you think that's acceptable :)
> X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
I'm sure pretty much all production Wayland compositors use the cursor layer. wlroots for sure does. (But I don't think it's a big deal under heavy load, there the problem is the display server even processing the mouse events at all first.)
Weston goes further and can use HW layers for actual surface compositing when possible. wlroots is going to gain that power soon-ish with libliftoff.
> The wrong philosophy ("every frame is perfect")
Again, feel free to use Windows 95.
For anyone used to current commercial desktop and mobile UIs, any imperfect frames are unacceptable, artifacts like tearing make your system look like a complete joke. Apple computers didn't show imperfect frames since the early early 2000s PowerPC era. Not matching that is a complete shame.
This is not fractional scaling. Fractional scaling has to be done by the application itself (even on Wayland).
> That's a driver-specific hack
It is not a hack. It is a solution and a very good one because DDX drivers can make use of vendor specific 2D acceleration and therefore achieve much better latency with the tearfree option on X11 than Wayland ever will where everything runs through the 3D pipeline by default.
> Any composited X11 desktop is slower than a Wayland one
If you enable Tearfree you don't need a compositor if the driver works properly. Of course X11 compositors with fancy blur effects have bad performance. I always turn them off.
> Go back to Windows 95 if you think that's acceptable :)
Why don't you switch to Android? Android already does everything that Wayland fans want and better.
> I'm sure pretty much all production Wayland compositors use the cursor layer.
I get severe mouse stuttering on high CPU or GPU load. A problem that was solved on X11 20 years ago. I have no idea what wlroots really does but it does it definitely wrong.
> Go back to Windows 95 if you think that's acceptable :)
The value of X11 is the ecosystem and platform it provides. If you want Linux with a compositor switch to Android. There you also have your sandboxing and whatnot. Don't turn the Linux Desktop into a Phone OS. As Desktop OS I genuinely prefer Windows 95 over Android.
> Apple computers didn't show imperfect frames since the early early 2000s PowerPC era.
Ever used OS X on those? They are barely usable because of severe lag and stuttering. But yeah the frames were so perfect that most people decided to switch back to MacOS 9 to do real work.
No, fractional is handled by applications just rendering at 2x and getting downscaled to 1.5x or whatever.
Yeah, the "Windows" way looks sharper on fractional, but the "Apple" downscaling is easier to handle and it looks fine – there were iPhones that did everything like that.
> DDX drivers can make use of vendor specific 2D acceleration
Ah, I remember Intel's various native 2D accelerations (UXA, SNA) – each with its own unique horrific bugs (artifacts all over the screen, all text turning into junk), all eventually sorta deprecated in favor of glamor (OpenGL) with the generic modesetting driver.
There's not much to 2D accelerate with modern applications that all do their own rendering. Compositing acceleration is possible in a vendor-agnostic way via KMS planes and we'll have that in wlroots.
> Ever used OS X on those? They are barely usable because of severe lag and stuttering.
I have an iBook G4 :) Leopard runs perfectly smoothly. Yeah, the very first generation of hardware when OS X was just introduced wasn't ready. The next one was.
It's even more fun when your realize no GPU in the last decade has shipped 2D acceleration capabilities. Wayland uses 3D acceleration because that's what GPUs offer, because that's what the other platforms exclusively offer now.
The “good old days” of unencrypted Internet, where everyone could see your cookies, are no longer acceptable; the same is true of X11.
With X11, if you copy a password from your manager, you must assume all running apps now know it and transmitted it to a malicious server. There’s no way to tell.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
With X11, everything displayed on the screen is compromised. Also, all inputs, keyboard and otherwise.
With Wayland, each app only sees their own pixels.
With X11, screen locking is pure hackery that doesn’t always protect the locked pixels and… login password.
Traditionally, you are meant to trust that process boundaries on Linux are sacredly secure, which is why Spectre was a big deal. But in practice, that is only true under Wayland.
In Wayland, you make the extension, then you patch every compositor, every toolkit and every application.
In X11, you make the extension, then you patch the X server, Xlib, XCB, every window manager, every toolkit, and every application.
https://www.freedesktop.org/software/XDevConf/x-security-wal...
”With Wayland, each app only sees their own pixels.”
Out of curiosity, if this is true, how are screenshots / screen recorders implemented? Do they require some special permissions? And if this is the case, why wouldn’t any app be able to acquire these special permissions?
There are solutions to this, which allow finer grained access to screen recording in future, but there are a couple of competing standards right now.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
Can you elaborate?
This sounds implausible, wishful thinking since key bindings are managed by individual applications. Whoever holds the clipboard must trust the application that claims to have received a paste command from the user. I don't see anything that could prevent spoofing without just blocking clipboard access entirely or making the usability a lot worse.
In Wayland, the compositor has special standing. For instance, KWin will only allow the currently active window to paste.
There is more information here: https://phabricator.kde.org/T4449#192501
At a meta level, this is probably the most frustrating thing about Wayland: all of its benefits could be realized in the X context itself, even the getting rid of legacy baggage (deprecate parts of the protocol leading up to the definition of an X12).
People actively chose not to do this and instead delayed progress by at least a decade.
Ideally, Wayland would have just served as a tech demo to guide the evolution of X. But as a community, we give too much credit to people working on shiny new things.
You're not using TCP for local X, it's all Unix domain sockets and SHM. Hard to get any faster on Linux.
One could certainly implement feature emulation to preserve backward compatibility with evolving hardware. Or just deprecate feature, X over network was pretty much broken for a long time.
Not saying Wayland isn't an improvement over X but a lot of supposed limitations of X are often misrepresented and exaggerated.
A conservative rewrite, that amends those things experience has shown were mistakes but were always retained for compatibility, is rare, since the impulse to rewrite is revolutionary in nature. A rewrite is treated as an opportunity to remake the world in a new image (with a new set of mistakes to uncover).
It needn't be a prompt users will quickly be prompted to click yes to it could easily be an option in settings or at communicated at install time.
There will be stumbling blocks as with any new technology, especially one that interrelates with so many systems but Waylands core architecture seems to be solid.
Personally, I’m still using I3 and don’t see many immediate benefits to switching over to Sway (the Wayland fork of I3). I am cheering Wayland on though and making the switch is somewhere on my todo list. What other path forward is there for desktop Linux?
Minor clarification: Sway is an i3-compatible wayland compositor written from scratch, not a fork.
If everything that uses X11 today can be used on top of XWayland without any modification and without performance loss, this means that a lot of pressure stemming from the need to switch to speaking Wayland instead of X11 is lifted in a certain sense.
Or am I missing something?
Second, it ended a pile of hacks upon hacks.
Those two reasons have to be added on top of the other benefits of Wayland (or any other modern re-arch of X).
This is always the case when there is some widely used legacy tech, but it shouldn't stop us from trying to move forward, or we'll never get better things.
I've personally switched to using wayland on my main laptop and am very happy with it. I was using X before and was getting incredibly bad screen tearing when using i3, I tried every recommendation I could find (double buffering, running a compositor, etc) and nothing helped, but Sway on wayland fixed it for me and its been running flawlessly for the last 9 months. I have no plans of going back to X anytime. The only thing I use X for is playing Windows games with Proton (which this HW acceleration change might even fix, if the laptop had an nvidia gpu, but alas, it does not).
Wayland means moving backwards. It has the complete wrong philosophy and abstractions. If "sway" runs flawlessly for you you are not doing much with your computer at all. I can't work without my fine tuned synaptics driver configuration and without my over the years grown and perfected scripts using xdotool, dmenu, xsel, xcape, xcalib and many other tiny but useful x-tools.
> fine tuned synaptics driver configuration
My touchpad, touchscreen and apple magic trackpad work great for me, so this isn't a problem for me.
And why do you think you have sufficient knowledge on the topic to assume that? I do assume you have not read the source code of the X server, isn’t it a bit “cocky” to state such a statement, which is in opposition to what the actual X maintainers say, who actually created wayland? It’s not like a project from nothing, it was created with the shortcomings of X in mind.
[citation needed]
Secondly, this isn't the first time I've had people point to this same video. It doesn't actually say what you claim it says. It says the creator of Wayland worked on X (though actually his core focus was DRI2, which btw, is not X), and the one individual speaker in that video worked on X a long time ago (specifically his focus was on keyboard input).
Their claim is more "X is redundant" than "X is hopeless". They're wrong, of course, the video makes absurd claims like "nobody uses core X11". Maybe they don't since they work in niches, but in the real world, plenty of people do... and that's the part of the X server nobody actually complains about. Even Wayland are perfectly OK with that part! (See retaining it in XWayland. When these wayland devs complain about Xorg their focus is usually on the driver side. Well, hate to break it to them, drivers are always ugly. See the link we're commenting on, if Wayland actually works on all the devices Xorg works on, it'll be just as ugly.)
Also, there have been another HN post with “X is abadonware” or similarly titled, which was written by another X maintainer. But feel free to check the mailing list as well looking at activity.
I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless.
But even if you do, the compositor only does one job: layer graphics. Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. Wayland either fragments this (saying it is all the compositor's problem or punts it to dbus or something), or ignores it (they feel about useful things the way I feel about compositors), and will likely reinvent it eventually anyway.
And btw, what about X is unnecessarily complicated? I love the way the presenter claims the specs are impossible but I managed to implement them and so did a bunch of other people. So apparently it isn't actually that hard. and btw they aren't actually all that different than similar functionality in different operating systems, aside from things like asynchronous chunking... which is a good thing, since you don't want to block your UI event loop anyway! So it is what good programs ought to be already doing.
Have you tried watching a video in full screen?
> But even if you do, the compositor only does one job: layer graphics
Yes, and this small little detail is not solved by X, but Wayland.
> Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc.
And it will live on in the form of XWayland. And I do dislike needlessly dropping backward compatibility, X’s APIs are globally broadcasted, and can’t really be retrofitted to an only server-client communication, so it makes sense to “reinvent” it.
> I love the way the presenter claims the specs are impossible but I managed to implement them
What part of it? I doubt you included the now removed printer part and the million other things the X developers had to cut out with hard work. And as I said, XWayland is made explicitly for this high level API of X, it is not going anywhere.
And I’m not sure what you mean by asynchronous chunking. You mean tearing? You do have to synchronize somewhere.
Nah, I've actually never used a computer since 1995. What is this "yoo-tubes" thing all the kids are talking about nowadays anyway?
You do realize that X applications can use DRI too right? And vsync when they swap buffers? This is trivially easy.
The only time I've ever seen glitches is if I tweak a couple config options with the intention of causing it, run a poorly-behaving program, and then resize it rapidly up and down. That'll cause a flicker.
> X’s APIs are globally broadcasted
No, they're not. I imagine you must think thinking of one client deliberately selecting the input of another client's window, which is allowed (unless the client is untrusted, e.g. an application from a `ssh -X` session - yes, X does support "untrusted" connections and restricts their access, and has since like 2007), but that's still not broadcast per se; you only receive a copy of the message if you specifically requested it.
> What part of it?
Drag and drop, clipboard, docking, window manager hints; here I was referring to the extension specs used for IPC with the X server.
And it is really pretty cool what you can do with this. If you run two applications on separate computers, you can drag and drop stuff between them and it just works.
That's the asynchronous chunking I referred to, again this was in the context of "unnecessarily complicated IPC". There's a size limit and acknowledgement protocol in transferring things like drops and pastes and your program is never supposed to block on those cases, rather go back to the full event loop. This is a bit more complicated to program, but it has several benefits, even on non-network cases (like say pasting a gigabyte on a Windows box) - you can stay responsive to the user while working in the background, show progress bars and cancel buttons, etc.
(Now if you're on the same machine btw the spec says to optimize some of these things and, for example, transfer a filename instead of file contents and let them read it themselves. The youtube video is half-correct when he says X isn't network transparent. Actually, a surprising amount of things are, like you can often run (old-style) OpenGL programs on remote hosts even if the author didn't plan on that! But if you want best results, you do need to have local machine optimization branches. If local machine, use shared memory instead of buffer transfers. If local machine, send file name instead of contents on drop event. Stuff like that. I also personally do things like if remote machine, disable mouse motion events unless a button is held down, just so save on bandwidth, though of course that's not a big deal anymore, but the core protocol does make that trivially easy to do!)
wrt tearing - which again I virtually never see on X (I have to go out of my way to trigger it!) so I really don't know why people complain about that so much - again you can vsync easily with glx and double buffer easily in any program. There's even a XSync extension you can use to help with these, even across clients: https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html (note the date on that: 1991. It isn't like this stuff is new.)
Also, regarding network transparency. As you note, most apps are no longer network transparent, and remote window streaming can be much better solved with modern compressions/encoding. It doesn’t have to be part of the core protocol, the latter should only concern itself with displaying rectangles on the screen. Everything else can be built on top of it.
Also, while in itself not a good argument, both MacOS and windows use a compositor since forever.
If message boards like HN are where you're getting this impression, just beware of sample bias. Remember that everyone on Fedora and/or KDE has been running wayland for literal years. That is a lot of users, and not enough complaints to make them consider reverting.
Fwiw here's my counter anecdata:
I'm on arch with swaywm, meaning my system is in no way "out of the box". I have gone back to X from time to time, and... it drives me crazy. Everything is blurry, it takes an hour off my battery time, and it FEELS laggy and unresponsive. Oh, and the experience of installing anything involves 5 extra packages (automatically included, at least) to work around X stuff. God help you if you want to configure an input method; it goes through AT LEAST 2 layers. For some input methods (touchscreens, i'm looking at you), you have brittle hacks like one layer is just reading the debug log of another. Anyway every settings change you make requires restarting your whole WM, and probably fiddling with several 3rd party tools to understand and make it easier... no thanks.
Even when I could only screen share between xwayland apps, and I really tried to go back, I couldn't stomach it. The wayland experience for me is just so much better across so many dimensions. I can only imagine what it's like for my friends who use OOTB setups and aren't even aware they're on Wayland.
Oh it absolutely is. The entire design of X11 is broken and a barrier to how applications & drivers actually work.
There's a reason that literally everyone else switched away from an X11-style model to a Wayland-style one. That is, MacOS, Windows & Android are all Wayland-style compositor designs. This was the major transition that Microsoft did from Windows XP to Windows Vista.
This is part of the reason that things like video playback in browsers on Linux is just awful. What browsers (or really any modern UI stack) want is just a system compositor that speaks buffers and transactions. Transactions are important to synchronize composition changes and content changes - for example, when you scroll a webpage with a video in it. It's better for power if the video is in a system composition layer, as then it can use a hardware overlay plane instead of being GPU composited (reduces power consumption). But then you need the browsers updated rendering of the scroll position to be synchronized with that composition update. This type of capability is standard on all major platforms at this point.
You can do this everywhere, except on X11. Possibly doable with extensions, but at that point your "extensions" are "completely change everything about the base X11 design & promises" as X11's base design & promises specifically don't provide anything like this.
X11's fundamental design is completely wrong & backwards. That's why a clean slate is necessary. Yes this migration is painful (see Windows Vista), but if it was actually pushed it would be a short term pain and the ecosystem would come out the other side healthier than it started (see Windows 7)
Nvidia still have some way to go with their driver policy, but them contributing in an attempt to become a normal citizen of the Linux ecosystem is a sign that the "fuck you" days may finally be coming to an end which, as the owner of a laptop with an Nvidia chip, gives me a sense of relief.
As far as I know this is all still based on their non-standard EGLstreams platform, but they are working on a Vulkan allocator that supposedly fixes the issue and some contribution activity indicates that they may finally support GBM, which would make Nvidia cards "just work" without any special treatment, which I would of course prefer.
EGLStreams is the actual Khronos standard (https://www.khronos.org/egl) as such existing on Windows, QNX and others.
EGLStreams doesn't exist on Windows, as Windows doesn't have any EGL at all. Similarly while EGL is used on Android, Android doesn't support EGLStreams and probably won't as the functionality already exists & EGL is on the way out long-term as Vulkan adoption picks up.
With all that said, EGLStreams is probably also not going to get adoption on most platforms as it's pretty terrible & inferior to what most platforms already have. Which is, on most platforms you can work directly with buffers instead of being forced into a specific point to point pipe (Android's HardwareBuffe or iOS/Mac's CVPixelBuffer)
On more embedded scenarios that I’ve worked on (Qt w/ EGLFS), it’s quite popular too.
That being said, I'm now enjoying wayland. Gnome apps already supports wayland natively. The rendering is smooth, no tearing and no issues. I think the transition to Wayland will be faster than many here are predicting.
Your 6700 XT might not be fully supported, but my 5500 XT is and was been causing kernel panics since I bought it one year ago. I got tired of posting the same drm bug report as reference but it's one of the 3 most commented and open for a couple years now.
It's painfully obvious that the Linux driver team at NVIDIA is underbudgeted and completely ignored, so I'm happy Wayland comes for them as well and I can continue to use their high end cards and not be relegated to tried-and-tested-and-painfully-old AMD cards on Linux, at least until they sort their day 1 support for new cards.
Haven't compared it against windows, because haven't felt the need. I'm sure some functionality/perf is missing though.
I had thought Wayland was not ever likely to be supported by nVidia, but something clearly has changed.
Wayland can't possibly replace X11, it's got a fundamentally different (I'd even say broken or even malicious) design. If anything, some Wayland compositors may emerge as dominant desktop environments, but this would be a dark day for power users, if it would mean not being able to switch to an actually friendly design, as currently offered by Xorg.
Also nvidia still provides drivers for 18 year old hardware for x under solaris
If you want the current version built this year for Linux instead of the legacy version you will have to move up 2010 hardware though.
I find it quite amusing that proponents of insert technology here seem to come in 2 stripes.
A) Those who believe new thing is superior and think you ought to try it
B) People smugly stating that you must move to new thing because the other options are going away see wayland systemd gnome.
It reminds me of a supervisor at a telecom support center who gleefully explained that the new system would hang up on people who kept mashing zero on the automated phone menu that preceeded getting to a person to make you go through it.
He didn't understand that people didn't want to use the new automated process because in general such systems are crappy and confusing.
Edit: To be clear breaking user space is when a change happens in the kernel level wherein software that used to work no longer works because the public interface presented differs. If you have evidence that this is actually going to happen other than your own misunderstandings please link it.
The gist of it is that breakage is OK if the userspace isn't open-source and that new uAPIs come around every few years due to the rapid pace development of GPUs.
I worked on Chrome OS graphics for years on and one of my earliest projects was to bring DRM/KMS (then a newish interface) to the Cirrus display card (an ancient card that QEMU happens to emulate).
Anyways, if the kernel developers decided they wanted to invent a brand new uAPI that does graphics, I wouldn't at all be surprised if new GPU drivers only implemented the new uAPI if their target userspace programs all use the new uAPI instead of an older uAPI. Nothing in userspace is "broken" because it will seem to the old uAPI using userspace as if there is no driver for the new GPU.
If one calls the _ syscall with parameters a b and c it won't suddenly require a 4th or demand they be in a c b order is literally what makes X11 continue working against newer kernels. Providing new functionality wherein if you don't call foo before calling _ with a b and c it fails to perform its function would be functionally the same as changing the order of parameters it would be breaking user space.
I don't see how you could possibly lawyer yourself past that, I don't see that the adults in the room who have to support customers in rhel 8 through 2029 can do anything but keep doing minimum work to keep x and the kernel playing nicely. I don't see how nvidia is going to go from supporting hardware for 10-18 years even on niche hardware to dropping support for X so quickly. I also don't see how you can meaningfully talk about the kernel dropping support for X without basing your discussion on actual kernel developers who logically would talk about kernel foo will be the last to support X probably years before it actually happens. I'm totally sure that python 2 -> 3 took over a decade after it was a completely suitable replacement but we will totally manage to replace X before its replacement is fully baked and the kinks worked out.
In short the whole premise is completely and totally premature wishful thinking by people who want their own way. I'll pour one out for X when its actually and in fact dead.
Or just look at a technical video about it: https://www.youtube.com/watch?v=GWQh_DmDLKQ
I don’t see these conteos regarding linux, especially goddamn desktop with the minuscule user share. It is literally a hobby thing for some graphics enthusiasts without any sort of money. Yeah sure, red hat or whatever..
Oh, and this whole affair has the obnoxious side-effect of stirring up all the /r/linuxmasterrace dipshits into a feeding frenzy that spills over onto HN, where they scramble over themselves to spam everyone who dares disagree with the same half-assed links and excuses.
Do you think that the majority of the debian team that voted democratically multiple times on the issue voted purely because... Red Hat? Come on, it is ridiculous. I hope you are not as blind when it comes to real-life politics, because denying reality to this degree is dangerous.
Accusing the other side of an argument of being deluded doesn't foster useful discussion.
It depends on dbus not systemd and that is replaceable module.
* expected by users of X11, Windows, or Mac
* expected by power users
* needed by the visually impaired
And it is also the reason why the Wayland ecosystem is destined for horrible fragmentation of interfaces, features and implementations.
Another consequence is that the X11 model of having the possibility of easily making a window manager to one's liking is not possible with Wayland, as compositors are monstrous beasts compared to window managers.
I also wrote about all this in some of my previous comments, e.g. there was a large thread here: https://news.ycombinator.com/item?id=24886074
EDIT: there's another perspective to this that I didn't express very well, so here are some quotes from Arch BBS:
By user neosix:
> You can't send keystrokes, move mouse, move windows, you can't even get active window. And all that because of security?
> But guess what it's not safe walking down the street, something can kill you, so let's just stay in the house and never go out again :)
By user Trilby:
> While I place a very high value on security and well designed software, the strategy of saying "you shouldn't want to do that" is not a sane policy. Yet this has been the approach of wayland from the start. Can you have a system panel? No, you should not want to have one. Can you have one client talk to another client? No, you should not want to do this. Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive: here, watch a cat video.
Emphasis mine.
In my experience it's actually the simplicity of building window managers in X11 that's misleading. It's easy to get something up and running that lets you move windows around, but to build a full desktop that does everything you'd expect is a giant task, and X11 only really gets in the way of that.
Exactly, "not a Wayland problem". That's the problem with Wayland, nothing is a Wayland problem.
> Make a service its own daemon with a dbus interface or something like that
I don't know if I should cry or laugh at this.
> look in other places
There's a contradiction here. How do you expect to avoid fragmentation if adding additional protocols alongside Wayland is required? I mean, obviously there won't be just one protocol. This idea is actually a common joke, there's even an XKCD on the topic.
Yes you can, wlroots has an extension for that, that will work on every “niche” wm based on it. You could not really get a system panel to work on plasma and gnome as well on X.
> Can you have one client talk to another client?
It is way too vague (generally, what does it have to do with the display manager? Pipes, IPC, dbus), but if it means something like drag’n’drop, it is supported.
> Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive
This is just utterly stupid.
Exactly my point.
> * expected by users of X11, Windows, or Mac
Windows & Mac have been in a compositor-only world for over a decade now. They are firmly in a wayland-style world, not an X11-style one. Android, too, has only ever had a wayland-style world.
The only thing that exists like X11 is X11. So nobody on Windows or Mac will be expecting anything like it.
I'm asking because it seems like no one relying on Nvidia card for number crushing and who want Wayland seem to have opted to just get a second card.
Unfortunately due to the misdesign of Wayland each graphical environment must write code to more directly interface with hardware instead of that being a layer above that. This means in current context it is vastly easier if NVIDIA bends on this issue however they also have the least incentive because most of their money isn't earned on the Linux Desktop.
People seem to suppose that somehow hardware vendors owe Linux users support and support in the fashion that would be desirable as if somehow not supporting the standards that others do is somehow wronging those developers and users but a private company in fact doesn't owe said developers or users ANY support of any kind.
Intel and AMD, the arch-rivals they are, coexist and collaborate on the kernel stack and Mesa. Even embedded companies join in (see Broadcom hiring Eric Anholt to make V3D a thing for the RPi4, even Qualcomm vaguely supporting Freedreno and Arm starting to show some kind of interest in Panfrost IIRC). Microsoft is in for virtualization and GL-on-D3D.
None of these vendors "owe anybody anything" yet they've joined the party. Turns out sharing is beneficial for everyone.
It has nothing to do with wayland, it is due to linux not wanting to provide a stable API for drivers, deterring binary blobs (successfully). As for whether this latter thing is good or bad is subjective.
Nonetheless, X itself is broken, it could not have been done otherwise.
It seems that Nvidia finally is moving away from the GBM madness.
“There are many distinct software components in desktop ecosystem. There are tools like Mesa for rendering (and each of its drivers), the Linux KMS/DRM subsystem, buffer allocation with GBM, the userspace libdrm library, libinput and evdev, and much more still. [...]
libinput Like libdrm abstracts the DRM subsystem, libinput provides the userspace end of evdev.”
One would think that A. D. 2021 a program implementing one abstraction upon another abstraction wouldn’t have to care about the actual hardware it’s running on.
But in the actual fact we have GUI programs containing quirks for graphic chips, and userland programs deeply concerned with what kind of filesystem they are writing to.
https://www.phoronix.com/scan.php?page=news_item&px=Xserver-...
Is that true?
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
On NVIDIA/Windows, the recommended setting for lowest latency is VSYNC+GSYNC enabled.
https://blurbusters.com/gsync/gsync101-input-lag-tests-and-s...
I spent the whole Friday evening and night trying to figure out, why my Mouse does not work plugged into a USB port on my Thunderbolt 3 Dock connected to my laptop with a Nvidia GPU.
Turns out it was Nvidia’s driver fault all along. This happened now so often to me, that for the next times I will just always first look whether the Nvidia driver has some bug, before I try to figure out something myself.
The most likely answer is next version or the one after that depending on how they'll do the release (Ubuntu just released so there are a few months available for the next version in their 6 months schedule, it'll definitely be in the next LTS).
Source: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...