I would use Wayland, but the most actively-developed tiling window manager, sway, doesn't work with the NVIDIA graphics card I own.
And come to think of it, isn't that a really weird problem to have? On X, the compositor (responsible for actually drawing all the windows on the screen) and the window manager (responsible for deciding how to arrange the windows and what their title bars/borders should look like) can be separate components, so I use i3 to arrange my windows and compton to draw them without tearing.
On Wayland, my impression is that the compositor and the window manager have to be built into the same program, so you run into silly situations where you can run GNOME on your graphics card but you can't run a basic tiling window manager. This also makes it a lot harder to create a new window manager, since you also have to write a compositor and test it on every graphics card.
That last issue could be solved with a reusable library that provided basic compositor functionality for window managers. Except every member of the Wayland community has independently had that idea and written their own, each with a different, incompatible interface and support for different graphics cards. So either we need a meta-library that abstracts away all the different libraries, or we need a standard compositor interface like X had.
The problem is that wlroots is one of several libraries with this goal.
Say I wanted to roll up my sleeves and implement NVIDIA's proprietary interface myself. (Or say in a few years we come up with some new, even better way to allocate buffers or whatever.) On X, I can write a compositor that uses that interface, and it'll work with basically every window manager written since the early 90's.
On Wayland, I could patch wlroots, but then I'll only be able to use window managers based on wlroots. If I want to use a different window manager, I'll need to patch a different library. And depending on how stable wlroots's interface is, I might need to maintain patches for old versions of it depending on how maintained my preferred window managers are.
The Wayland situation is probably fine if you only ever want to use the latest version of the most popular two or three desktop environments. But speaking personally, if I wanted to do that, I'd just run macOS.
>The problem is that wlroots is one of several libraries with this goal.
The only successful one, to be clear. You would be unwise to base your compositor on any of the others (libweston, wlc, swc, etc). wlroots is suitable for basically any use-case.
A downstream compositor which wishes to implement Nvidia support could do so and integrate it with wlroots.
However, there are more reasons than political not to "support" Nvidia. Their alternative has genuine technical problems that would render large parts of wlroots broken.
> Their alternative has genuine technical problems that would render large parts of wlroots broken.
If this is indeed true (and I have no reason to doubt you) then I wish you and the rest of the Sway folks would focus on those issues, instead of the political arguments because from the outside it all looks very petty when you write stuff like "Nvidia doesn't support Sway". Nvidia doesn't even know about you.
I've personally spoken at length with Nvidia graphics driver developers. They know who we are and they know the technical problems. If you have no reason to doubt me, then perhaps you shouldn't.
Are the technical problems documented anywhere where non-NVIDIA-driver-developers can learn about them?
Most of the discussion I've read online argues that to support NVIDIA's solution, everyone would need to add if(nvidia) checks to their code and maintain them forever. But this argument only really holds in Wayland's bizarro-world where all programs that arrange windows must also bake in code that interfaces directly with hardware to draw them on the screen.
Absent any other technical problems, it's hard not to conclude that this is just an attempt to use politics to cover up one of Wayland's poor design choices.
> Most of the discussion I've read online argues that to support NVIDIA's solution, everyone would need to add if(nvidia) checks to their code and maintain them forever.
This is a severe misunderstanding of NVIDIA's solution.
NVIDIA's solutions is so fundamentally different that you'd basically maintain two compositors internally: One that handles every sane driver, and one that handles NVIDIA.
Nothing in wayland is incompatible with NVIDIA's approach. GNOME supports it, and KDE recently gained support. However, the NVIDIA approach exists for only one reason: Because NVIDIA does not want to play along with the open source world, and doing the least amount of work to their proprietary driver.
Unless NVIDIA turns their ship around, supporting NVIDIA is harmful to our community. Although, if they'd just keep up with our standardized APIs, maybe we could somehow accept their ridiculous proprietary drivers which has no place in this decade.
> NVIDIA's solutions is so fundamentally different that you'd basically maintain two compositors internally: One that handles every sane driver, and one that handles NVIDIA.
If Wayland had a standard compositor interface like X has, this wouldn't be a problem at all, would it? You could write your compositor that talks to the hardware using your "sane" interface, and someone else could write a compositor that uses the NVIDIA interface, and users could pick the compositor that works for them and use it with any window manager they choose.
It's only because of Wayland's design that "GPU manufacturer creates nonstandard interface to their driver" is some giant, existential, ecosystem-fragmenting threat to the open-source community.
X11 has a "standard compositor interface", but X11 compositors generally don't talk to the hardware directly, they talk to standard X11 drawing APIs like OpenGL or XRender. What you're talking about is really "Xorg drivers", a legacy from the time when Xorg was responsible for display hardware, and the OS kernel was responsible for every other kind of hardware.
Hardware definitely needs drivers, but these days the Linux community has settled on the model that all drivers should live in the Linux kernel, where they can share common code like "talking to the PCI bus" and security infrastructure. What you're proposing is that, instead of having one driver layer from "standard API" to "hardware interface", there should be multiple redundant driver layers, so that NVIDIA can implement whichever layer optimally balances their desire to support customers with their desire to hide their intellectual property.
That's not a crazy position (NVIDIA certainly holds it, and they're no small fry!) but telling Libre graphics-stack people "you need to make your architecture more complex and do extra work for free, to make this multi-billion-dollar company feel more comfortable" is always going to be a difficult proposition.
> It's only because of Wayland's design that "GPU manufacturer creates nonstandard interface to their driver" is some giant, existential, ecosystem-fragmenting threat to the open-source community.
That's not how I think of it. By analogy, consider POSIX. Every major operating system supports the POSIX interface--all of them, except one that is. But no one goes around calling that one OS a "giant, existential, ecosystem-fragmenting threat to the open-source community."
Essentially, you have to pick a point somewhere in the stack where you define the common interface between the different hardware vendors. The problem is that one hardware vendor, because it's the 800 lb. gorilla who loves throwing its weight around, decided to not implement the common interface, hoping that its weight will force everyone else to adapt. Wayland is unfortunate enough to be in a position where it relies on that common interface being supported, but this isn't the only place that NVidia has decided to try to scuttle cross-vendor compatibility (GPGPU computing is a very notorious case).
I'm not sure what victory is being declared here: is Wayland likely to run on more than a tiny fraction of devices any time in the near future? If not, that "one OS" can take a large part of the blame.
> If Wayland had a standard compositor interface like X has, this wouldn't be a problem at all, would it?
It does. It's called Wayland.
I suspect you might instead be thinking of a standard window manager interface to plug into a compositor, rather than the other way around.
The Wayland approach has been to just make it easier to write a compositor, instead of porting X's complexities and odd design choices.
However, nothing stops you from making a compositor with such an interface. It won't be part of Wayland, but it would be its own spec.
However, this suggestion would be a case of symptomatic treatment. The root cause of complexity is NVIDIA.
> It's only because of Wayland's design
This is not true. It just because Wayland is not X, and NVIDIA only has support for X.
Under X, every driver had its own integration, which was a pain to make, maintain and use.
For Wayland, the community got together to make a generic API that had nothing to do with Wayland, allowing applications (be it a wayland compositor or something else) to not have to think about what they're running on.
NVIDIA, however, is just trying to throw more duct-tape, taking us back to the X era.
You may ask "Why don't everyone just implement EGLStream?" - that is because EGLStream has no merit, and is just the implementation that would be easiest for NVIDIA to implement. Why would we make everything else worse, spending significant time and effort redesigning everything else, all to save NVIDIA a few bucks?
If they have actual concerns, we can solve it as a community, but considering that everyone invested significant time in this project, we are not going to throw it all away and pick a vastly inferior model just so that NVIDIA doesn't have to do anything. NVIDIA is just one GPU manufacturer out of many, and on Linux, a small one.
As for EGLStream problems: Performance and stability are the big ones. Ironically, EGLStream is bad for gaming, as we cannot do direct scanout with it (an optimization where full-screen content gets thrown directly to screen instead of going through compositing).
This would be a great idea if NVIDIA was open to suggestions so that things could be fixed.
However, they mostly refuse to play ball. They did seem to be preparing an alternative suggestion, but they seem to have dropped it entirely in favor of just dumping EGLStream patches on KDE and GNOME, hoping every one else will be forced to follow.
The alternate suggestion would work like EGLStreams. The current Nvidia driver can’t handle any more.
EGLStreams works by having children pass ownership of the surface they want to display to their parent for compositing. This invalidates said surface.
GBM is a coherent model. Handles are passed around to prevent the need for copying, but ownership isn’t transferred.
Nvidia’s driver is a black box, but I don’t think they can do things that way without some significant driver refactoring. Obviously that’s costly, so they’re trying to avoid doing it.
AMD took a gamble when they began their open source initiative. It’s starting to pay off now with stuff like Stadia and the Valve stuff. I feel like Nvidia is going to have to do an open driver eventually. I hope they’ve got at least something in the works that we don’t know about.
I’m not going to suggest replacing Nvidia cards if they’re working fine for what you do. Just look at AMD (or Intel next year) if you start hunting for your next card. Don’t fall into the brand loyalty pit.
NVIDIA writes and maintains their own Xorg graphics driver on top of their kernel driver. NVIDIA is apparently not interested in providing the same courtesy to wlroots.
(I don't know how much NVIDIA has contributed to GNOME and KDE's Wayland compositors)
GBM is a very useful standard if you only ever want to request buffers from drivers that use the Linux kernel's GPU buffer management code and modesetting code. (Preferably only Mesa-based drivers too.) NVidia doesn't use this and probably can't for licensing and other reasons. If you want to talk to any graphics driver that isn't correctly and intimately entwined with the right parts of the Linux kernel, GBM is basically useless. It is not in any way, shape, or form a generic standard for buffer management.
(In principle GBM isn't quite a single-implementation Mesa only standard - third party implementations are possible, though the only one that exists right now is by ARM for their newer Mali GPUs. People seem to have had mixed results with it and I'm not sure it's even intended to run desktop Wayland.)
I'm not super familiar with the details of this stuff -- does this mean that there's basically no hope of any wlroots-based window manager ever working on non-Linux operating systems like BSD?
Most of the BSD variants have some (generally outdated) port of the Linux kernel graphics stack, sometimes even with a wrapper layer to try and make the BSD kernel internals look enough like Linux for it to run unmodified. So it's probably not completely hopeless, but that's mainly because the best shot at getting the graphics accceleration it needs is a straight port of the Linux kernel drivers. (At least for non-NVidia users.)
Intel and AMD maintain open source drivers that have supported this for ages. It's only NVIDIA that still tries to shovel outdated proprietary drivers without support for community developed standards down our throats.
Adding that their proprietary drivers are not particularly good, NVIDIA is not a very popular choice for a Linux machine.
Just remember that it took them almost a decade to add KMS support.
It's an interesting position to suggest that nvidia which has no obligation to support you in any way shape or form is shoveling anything down your gullet by not supporting the standards you prefer.
You could vote with your wallet but there aren't enough Linux users to move anyone's needles as far as gpus.
> but there aren't enough Linux users to move anyone's needles as far as gpus.
Well, for server and ML payloads, we are the vast majority. Things like Google Stadia is certainly enough to move needles, and if AMD ends up able to compete in ML with future products, then we'd be able to make a huge dent in NVIDIA revenue.
NVidia has a different problem too. Every time I want to install one of their cards for computing purposes only (not graphics), the installation procedure starts messing with my display system. Drives me crazy.
Nvidia has excellent support, I think you are conflating Linux with open source. For decades, Nvidia had (and arguably still has) excellent support for the former, without really caring for the latter.
Are you referring to the small decade it took them to support KMS so that their driver behaved even remotely like a modern one?
Or perhaps their marvelous installation methods of running a random script as root that rewrites configuration files, and its configuration interface that likewise also rewrites configuration files in attempts to get multi-monitor setups working that until recently hardly ever worked?
Maybe you are referring to their magnificent support, forcing you to stay on outdated kernels as upgrading would break compatibility and render you without a functioning graphics adapter short of a VGA-resolution framebuffer console?
It could also be their fantastic backwards compatibility, requiring you to keep track of driver series compatible with certain adapters, where every other GPU in existence just works OOB.
I used NVIDIA up until a 2 years back. While you could arguably get things to work, claiming they had excellent support is laughable at best.
I think he refers to the fact that Nvidia's drivers provided excellent OpenGL support for multiple years compared to the absolute dumpsterfire that fglrx was. Before Valve decided to pay attention to Linux and thus prod AMD to improve their drivers, if you wanted anything approaching serious 3D performance on Linux, you had to use Nvidia. Anything else would be a waste of money.
Doing what everyone else does != doing it properly
> I wouldn't call this excellent at all
So far Wayland support is most further in Gnome and even there a lot of features are still missing/broken despite Wayland being well over a decade old at this point. A lot of very basic features (remote desktop, screen sharing, exclusive fullscreen, keyboard/mouse shortcuts) are still in their infancy. Not to mention both Gnome and KDE have implemented their Wayland compositor inside the shell process so now a compositor crash means you lose all your open apps which hasn't been a problem in Linux for decades.
> A lot of very basic features (remote desktop, screen sharing, exclusive fullscreen, keyboard/mouse shortcuts) are still in their infancy.
- remote desktop: good point. Considering that screen recordings work fine, I don't see a technical reason that a Wayland remote desktop setup couldn't work.
- exclusive fullscreen: what do you mean by this? Using Firefox, F11 and Super-F both work in Sway and F11 works with GNOME.
- keyboard/mouse shortcuts: maybe? The fact that a random process can no longer read all of your keystrokes seems like a plus, to me. Otherwise, just add a shortcut to your window manager or DE and run a command of your choice.
- losing all apps on compositor restart: Only an issue with GNOME and KDE. Pressing Super-Shift-C on Sway reloads the compositor and not your apps.
> The fact that a random process can no longer read all of your keystrokes seems like a plus
It is a plus, unless you write software that allows for global keyboard/mouse shortcuts (which I have done). In which case it is just a huge pain in the ass to not have it, and then hearing from some developers that you can just "add a shortcut to your window manager" is incredibly frustrating. It's not like you can trust an average end-user to actually do so, even the ones that do run linux. Then you will get complained at for not having functionality that existed at some point in the past.
Exclusive fullscreen = application runs directly on the screenbuffer, bypassing the compositor. Not just that a window happens to be taking up the whole screen.
Well--no, not in the same way, but it can still be a hint passed along somewhere, to allow the compositor to swap out its root framebuffer for the program's.
Screen sharing is quite important in my workflow. Fellow developers and customers will send me buying Windows or a Mac if all screen sharing applications on Linux stop working. I'm using Slack and Meet. Skype is almost abandoned among my customers.
I would like to see the approach your pronning of "not doing like others" applied to some other protocols like TCP. Networking would be really fun and Internet a great success. The very concept of a protocol is that everybody does the same, the underlying implementation is different.
Wayland and its current limitations have nothing to do with, and does not excuse neither, nvidia's non-compliant implementation.
Funnily enough, this is exactly what I was talking about. Nvidia supported multiple monitors on Linux for decades using TwinView, they simply didn't add support for the open source xrandr for 4-5 years, but even that has been supported for ~7 years now.
> Nvidia supported multiple monitors on Linux for decades using TwinView
And Xorg supported them for decades before using Xinerama. Instead of collaborating with upstream, they just dumped something incompatible and broken, and said "Deal with it".
Multi monitor display worked perfectly for long time, long before "it works on intel, let's call it new standard" crew decided that flat shared framebuffer is the only way to go (apparently because of compositors and nothing else), something that also broke support for multi-gpu and especially heterogenous multi-gpu.
Zaphod mode is still available. nVidia pushed its TwinView solution while everybody else was using either the Zaphod mode or Xinerama. I don't think TwinView on Linux allowed any dynamic configuration. So, when the rest of the world switched to the RandR extension, every graphic card was able to dynamically add/remove monitors while nVidia users were stuck with a subpar solution.
But I mean what's the point of declaring something to be a standard if the important people weren't interested in implementing and supporting it?
Anyone can come up with a standard in isolation. Getting the relevant people on board and able and willing to support it is the useful bit.
Did they say they'd support it? If they never said they did it seems unfair to criticise. Are you going to support my graphics standard that I just made up?
Intel and AMD cares about it. If the Linux desktop market would grow, Nvidia would quickly change their mind.
Now, this market growing is another question...
But for me, nvidia gpu are just not a possibility because they lack good drivers on Linux.
So how do you want to grow Linux market share if you say FU to a significant part of the potential market? Steam hardware survey is pretty clear about AMD:Nvidia GPU ratio.
I don't think so - I see nobody with a desktop computer these days except gamers or people running CAD or modelling who are basically doing the same thing as running a game.
You can think of any number of fantasy scenarios that would make one of the biggest GPU vendors care about your standards, but sadly that is not the world we live in. The world we live in is one where Nvidia has the best game support on the market (far, far better than AMD - let's not even think about Intel here) and therefore anyone who still plays games on a PC will own one of them unless they are some sort of AMD advocate.
At the end of the day, nobody wants to be reading "we don't support this because they're not nice to us". That's going straight back to the linux dark ages of 15 years ago, where you needed to care about all sorts of weird and arcane details to get a functioning desktop system.
It's also significant portion of "people who pay for Linux developer salaries" in the form of few workstation users that use Linux-based software that is often paired with Quadros.
Wherein "death watch" is expected to work without difficulty for the next decade or longer.
They aren't pretending they support Linux, BSD, Solaris, Mac, Windows for a decade after each card is released.
While this was true ATI/amd were shipping garbage that barely worked for a few years. This has only changed in recent years.
We are a few years having one dedicated gpu maker in the fold and are already talking about using your massive 2% marketshare to strong arm the other. You could afford to be more humble and less entitled.
It really doesn't matter to me if Nvidia drops out of the linux desktop market or not. I've never owned their hardware and never will, so it makes not an iota of difference to me.
I'm just observing that Redhat is the trendsetter and if they say X is legacy, that makes it so. Unless Nvidia or Nvidia customers decide to pick up where Redhat is leaving off and pay for developers to work on X, but I sincerely doubt that's going to happen.
Unless Nvidia decides to support the new system, they can't plausibly claim to support the linux desktop. I just hope whatever happens will result in less online whining from linux-using Nvidia customers.
I think having a substantial chunk of potential machines no longer work would be a meaningful difference to the overall actual and potential user base regardless of how you feel personally. I think we should therefore act in everyone's interests.
Who's going to put up the money? Not Redhat, they don't want to pay for it anymore. Will the nvidia users? Will they be willing to pay for their card twice? Will Nvidia pay for the continued development of X, when they already seem to loath spending money on linux?
If nobody picks up the slack, the paths ahead seems pretty clear. Either Nvidia produces a proper driver, or their support for the Linux desktop can be classified as legacy at best. Feeling upset about this situation doesn't change the nature of it.
This is exactly the kind of reasoning that has always stood in the way of real people using Linux. It makes me sad that we've come a really long way towards taking that mindset out of the OS and we seem to be moving back to it again.
You may not like my reasoning, but how is my reasoning wrong? Somebody needs to pick up the slack now that Redhat has no interest in funding X. All you're doing is protesting that you don't appreciate this situation, but that's irrelevant.
It doesn't matter who the ones "suffering" are. What do you expect to do, convince me of the moral necessity of supporting nvidia cards so that I turn back time and devote my life to reverse engineering GPUs and implementing FOSS drivers? That can't happen. I don't have the power to support nvidia cards, only Nvidia has that power, and they seem to have no interest in exercising it. It doesn't matter if you convince me that nvidia card support is more important that curing child cancer; the situation remains unchanged. To change the situation you must convince nvidia, complaining to anybody else about it is a waste of your time.
The point I was trying to make is that your end users are fundamentally the ones suffering. You are not suffering, because you avoid the problem by throwing money at it. Nvidia is not suffering, because you as a community don't matter to their wallet.
The only people who suffer are the people we write software for. Maybe that doesn't matter to you, because you write software only for people like you. That's fair. It matters to me though.
Nouveau drivers are pretty terrible (performance-wise) and didn't support the card that I am using last time I could find any real info about it (admittedly more than a year ago, I use a GTX 1070). This uncertainty is a fact of your life if you use nouveau, which is precisely not what I'm looking for on my main workhorse machine.
This is leaving aside all of the trouble that you have with running Nvidia's ML stuff when you don't use their own driver (impossible, AFAICT).
Both of those things are blocking issues for me, which in turn means that using anything that doesn't support regular nvidia drivers is a no go.
I know it's not the devopers fault that they can't reverse engineer nvidias closed source crap but nouveau has always been garbage. Nvidia should adopt and fix it or at least help.
You can see why Nouveau devs are having difficulties with Nvidia in a Xorg developer confereence talk[1].
1. Relations with NvidiaNVIDIA changes prevent us from releasing a driver
* Signed firmwares accessible publicly but not redistributable
* Reverse engineering of vbios impossible
2. Communication mostly down
* Main contact/dev left NVIDIA (Alexandre Courbot)
* Most important requests left unanswered...
* ... until more complete code than wanted lands publicly innvgpuweeks later
Probably not possible (or at least not trivial at all) due to third-party licensing agreements. AMD/ATI didn't open source their closed driver but instead supported the open source one.
> That last issue could be solved with a reusable library that provided basic compositor functionality for window managers. Except every member of the Wayland community has independently had that idea and written their own
Actually the opposite is true.
Recently everyone is converging on re-using the same compositor library, written by among others sway’s author: wlroots.
I would love to use Wayland, currently I only use it to watch movies without tearing. Anecdotally, everything feels brittle when using Wayland, applications crash... I really hope it matures.
Which video card/driver do you use? I have used Wayland for two years now without any noticeable problems. Before that, bugs in GNOME would often bring the whole graphics stack down.
(This is on amdgpu and later intel. I had a lot of problems with nouveau.)
It's some AMD Radeon with 8G so reasonably beefy. Not sure about the driver, I choose AMD for Linux graphics to not have to think about that I suppose, Nvidia used to be (still is?) a headache on Linux.
>Nvidia used to be (still is?) a headache on Linux.
AMD was worse, the Linux driver had like half the performance of the Windows one. So if you were asking who has better Linux drivers for Linux the answer was NVIDIA (for desktops not latops)
For a bunch of stupid, hysterical reasons, the Open Source X11 server still has all the warts of early-1990s release. XFree86 used the MIT X.Org core dump to implement open X11 on Linux, but outside of certain new things (DRI, XRender extension) it remained stuck in "world is dumb framebuffers with optional bitter" design.
Over time, a lot of useful stuff was broken and supported less and less, then reimplemented in bad way over compositors, instead of having composting Xserver like Xsgi.
Security extensions or even basic security tools (private input grab) got waylaid because toolkits didn't implement them (try running GTK3 on hardware without 32bit color GL or on system that defaults to lower bit depth than 32/24).
Generally, after letting it get more and more broken, the suggestion for big rewrite arrived. Said suggestion often results in something that resembles "devs first graphic stack", with a lot of basic, important features for daily life relegated to "someone will make an extension for it later" or "use D-bus to implement it elsewhere, and who cares about compatibility".
X.org is more horrible and also impossible to maintain. It would have been given the boot over a decade ago except for the fact that AMD/then ATI and Nvidia only supported X and video drivers were incorporated into X directly. There was a big push starting in ~2008 where AMD started open sourcing their drivers. Infrastructure started developing in the kernel where it makes sense instead of in X.
Now we've reached the point where there are almost two parallel stacks - linux's graphics infrastructure; and Nvidia's. The developers don't have any patience for the one holdout against the new system. It is unfortunate for the people buying Nvidia cards because they are now starting to be labeled as 'using the legacy systems'. Presumably there is some reason why they have no choice in their purchases, but the cost of maintaining systems to work with closed source drivers appears to be too high. My views here aren't exactly current - I've stayed a long way away from Nvidia since ~2009 - but they are probably sill somewhat on target.
It is likely that a better designed alternative to Wayland will crop up. It is much easier to compete with than X - there are no drivers that only support Wayland.
Are there any decent high end laptops that use AMD? I haven't seen anything. Not Lenovo. Not Dell. Not system 76 or any other Linux vendors. I prefer one too considering what shit nvidia drivers are. So the Redhat/wayland people are essentially saying all powerful laptops that have a chance of running Linux are already obsolete even ones not released yet? Redhat is powerful but not powerful enough to decide that. Fuck wayland if they refuse to support virtually the entire market for pro laptops. It certainly isn't the future without that. That's just delusional.
Yeah that's what I suspected. Unfortunately mbpros have many other issues with Linux, if they even have drivers at all for the new ones. As far as nvidia they won't budge so Redhat going in on a technology that isn't supported by a large majority of its user base seems a failing on their part to me. Then again, I don't think they care much about desktop Linux so I can see where they are coming from focusing on server products and the minimal ui needed to occasionally run a gui rather than something one could use every day like os x or even windows. So much for the Linux desktop.
> Every GPU vendor but Nvidia supports these APIs.
> About a year ago Nvidia announced “Wayland support” for their proprietary driver. This included KMS and DRM support (years late, I might add), but not GBM support. They shipped something called EGLStreams instead, a concept that had been discussed and shot down by the Linux graphics development community before.
That’s pretty damning for Nvidia. I can see why the developer is so upset. Must be tough working on OSS in that type of hardware environment.
Looks like AMD is the way to go for desktop Linux boxes going forward. Although it looks like both Dell XPS [1] and System76 [2] is still using NVIDIA. Purism Librem uses the Intel i7’s embedded GPU [3]. I’m curious what the ideal Linux laptop is these days…
The ideal Linux laptop is one with just Intel integrated, and no discrete GPU. Honestly, Intel GPUs are decent enough, even if you want to do some mild gaming. Handing two GPUs on a laptop in Linux doesn't have the best support. A lot of the Optimus/Bumblebee stuff is not very well maintained.
True, I don't do any laptop gaming. Intel GPU's seem to be sufficient as long as it can easily power a full HiDPI internal monitor + 4k external monitor... which Librem's Intel 620 GPU is listed as supporting but it looks like Librem's 15 v4 only has an HDMI port and not usb-c/displayport, which limits it to 4096x2160@30Hz instead of 4096x2304@60Hz. So I guess you'd have to look at Lenovo, HP etc for top tier..
Sadly my work uses all Macbrook Pros, which are amazing machines), but I'm scared to install Archlinux on them. The Archlinux Macbook wiki pages are 4yrs+ old.
Don't overestimate the Intel GPUs. My current system uses a 530 which is getting pushed to its limits trying to render the desktop at 60 Hz, either UHD on AC or FHD on battery. Forget UHD on battery, that doesn't even manage to move the cursor at more than 10 fps.
IMO the ideal GPU for a UHD screen would be either an Iris or a Vega 10. But it's difficult to find the former outside MacBooks and the latter with more than an FHD screen.
Just to back this up, I've recently bought a non-touchbar 13" MBP from 2016, and been amazed at the amount of games I've been able to play no issues on the Intel graphics in it.
Can you list some of them? Since my MBP with much faster Radeon 460 is struggling even with new isometric games like Pillars of Eternity 2 or games like Stellaris.
> Looks like AMD is the way to go for desktop Linux boxes going forward.
Problem is: desktop Linux has an irrelevant market share, and the trivial workaround (use intel IGP or go buy and AMD graphics card) do not work when you don't just manage your one PC but actually maintain a system that is produced in series...
And honestly being upset at nVidia leads nowhere. The architecture of Wayland is complete bullshit to begin with and I'm not sure any other graphic stack of competing systems went that way, EVEN for systems that have a single window manager (well, that's most of other systems... -- so the situation is strangely kind of reversed). So hopefully wlroots will eventually improve the situation or something like that, but is it even convenient to build something that does not link the graphics session to the low level graphics stack with that? I hope it is, because if not, that is hopeless... :/
And I've not even talked about extra deps like Cuda, or the general lead nVidia still have in perf/W and/or perf/price (IMO AMD is close, but no cigar)
The X proto was maybe shit, but at least the general approach did not lead to the kind of insanity we are currently seeing. And people discussing the Death of X when Wayland ecosystem is maybe still 5 years away from decent quality and some reasonable feature completeness... (remoting, anybody? anything good enough for Wine?)
It wasn’t just Wayland that used GBM, plus every other vendor supports it but Nvidia and it’s well documented in Mesa.
But I personally don’t care as long as Intel and AMD are available, it’s fine. I see Linux like MacOS, it’s an operating system targeted at a limited set of hardware. As long as you buy within this group 90%+ of the problems with Desktop Linux will go away.
The HP x360 with a Ryzen 2500u is rather good, and can be had for ~$400 on eBay.
It did take a full year for all the bugs to be sorted out (random kernel panics & freezing), these same bugs were problematic in Windows 10 tho. Neither OS had good platform support for quite some time...
Last I checked, sway detects if nvidia.ko is loaded (even if the nvidia gpu has no display) and errors out with some message to the effect of "f you for buying nvidia."
If this check were not here, Nvidia would still not work. This serves to reduce our bug report volume. However, by deleting these few lines of code (or specifying the appropriate command line argument), Nvidia could work tomorrow if they shipped GBM support.
The flag is there for you to override if you think you know better. We don't answer questions or provide support for any use-case with the proprietary driver.
Refusing to run if a particular kernel module is loaded (even if you don't touch it at all) is overstepping. You should at least provide an override flag.
It's implying I have a choice in the accelerators I could rent in a cluster... Yes, it's about using an intel GPU for display and a nvidia GPU to provide local development (latency being the primary reason).
It's just generally taking a reasonable stand ("I don't want to spend my time on Nvidia, especially not for free") into an unreasonable one ("Users who have Nvidia are bad and should be bullied").
> I would use Wayland, but the most actively-developed tiling window manager, sway, doesn't work with the NVIDIA graphics card I own.
May I suggest you buy an AMD GPU next time around; not only because they didn't try to impose their "standard" (which virtually nobody other than them implements, as far as I can tell) without implementing the de-facto standard interface, hurting their customers' access to Wayland to this day... but also because AMD will probably be better value next time you're in the market for a GPU.
> That last issue could be solved with a reusable library that provided basic compositor functionality for window managers.
Sway is based on such a library! (wlroots) However, again, NVIDIA has made it an extra effort to support their GPUs (both in applications and in compositors), and I'm not sure anyone wants to go to extra effort to support a vendor who actively impedes development. By all means, if you want to do NVIDIA's job, be my guest.
I think Sir_Cmpwn has a point in not putting in that effort though.
> May I suggest you buy an AMD GPU next time around
This doesn't help anyone. I bought an expensive Nvidia GPU 6 years ago, when AMD support on Linux was really bad. What do I do, throw out a perfectly good powerful graphics card and spend another $500 to satisfy the needs of some newfangled software which doesn't solve any of my problems?
I've had 6 years to experience the horrors of Nvidia, on multiple machines. I'm never going to buy one of their cards again unless there's a massive change in their leadership. But telling people 'tough luck; basic functionality that your computers have been capable of doing for decades will no longer work because you bought the wrong brand' is simply unacceptable.
> What do I do, throw out a perfectly good powerful graphics card and spend another $500 to satisfy the needs of some newfangled software which doesn't solve any of my problems?
If you want to replace a card which was expensive six years ago, you can spend a hell of a lot less than five hundred dollars to do so. Even a brand-new RX 570, which will outperform a GTX 770 (the highest performance GPU for $500USD or less in 2013), should only cost you about $130USD today. If you're okay with pre-owned cards, you can get better than that for the same money.
> This doesn't help anyone.
It helps people who are in the market for a new GPU, who want it to work well with Linux, especially the cutting-edge stuff.
Even in 2013 though, I think I was able to run Wayland on a discrete AMD GPU (Terascale 2 or 3?) with at least OpenGL 3.3 available; and it worked OK. I don't think AMD got that working more recently than 2013.
I can understand not wanting AMD's cards on the top end as ca. 2013 (since they were not competitive, IIRC), but now they do have competitive offerings, and their support for desktop Linux is incomparably better, which is why I suggest people go with them.
1 the expensive(this is relative) card works fine, do I throw it or donate it without any good reason(switching to wayland could wait IMO until this card is too obsolete)
2 Buying a new GPU is a big investment for some people,those money could be used to replace an old low quality display or other stuff.
No, I'm not missing these points. It's just that nobody except NVIDIA can do anything about that, so I'm suggesting things you could do. If you can't get an AMD or Intel or Qualcomm (unofficial) or Broadcom (or soon ARM) GPU, and you won't (or can't, again because of NVIDIA being antisocial) run Nouveau instead of the NVIDIA proprietary drivers, and you're not willing to port wlroots to EGLStreams, then you simply will not be running wlroots-based compositors on your machine. That's just how it is.
If you bought a 2019 MBP hoping to run Linux with full support for all the hardware, you would be making a mistake; just because I say that it's a mistake, doesn't mean I think you can afford to replace all your computers again once you've made that mistake.
I don't get these replies. I go to specific effort to couch everything I say, I say "next time around", I say "if possible"; and everyone reads it as though I'm somehow out of touch with the fact that not everyone can spend hundreds of dollars on GPUs every year. I know, I'm just saying that steering clear of NVIDIA in the future is an option that will give you a good experience with standard Wayland compositors.
OK, there are a group of people where at the time we bought NVIDIA it was not a mistake, it was the better card for Linux Desktop, at that time AMD open source GPU was bad and the Catalyst proprietary one was terrible in performance, Steam games were only supporting NVIDIA.
Sure when I will need to buy a new card I will again have to check what is the best one for Linux and then I will probably get an AMD card again( I had AMD before NVIDIA on desktop and Laptop and back then it was a big disappointment, including the fact the AMD Catalyst drop support for my 1 year old cheap Laptop)
> AMD Catalyst drop support for my 1 year old cheap Laptop
My advice is: Unless you're running a qualified application on a workstation GPU, do not use Catalyst (or whatever they're calling it this year). It is almost always more finnicky. Mesa has the best performance, and the most meaningful features for OpenGL, Vulkan, and D3D9 for any any GCN 1 or later (and probably r600 or later, but I don't have personal experience with that) GPU. AMD staffs people to maintain Mesa, including for GPUs they do not support their proprietary driver on; and if you're running a fresh/rolling-release distro, you'll tend to have a great out-of-the-box experience with Mesa.
Thanks for the response, my story about Catalyst was very old. I was trying to explain to some new Linux people that AMD was terrible a few year back. So I bought a new laptop and in 1 year Catalyst dropped support for the GPU in that laptop forcing me to only run distributions with old enough Xorg because the open source drivers were bad at that time.
I know that now AMD open source is better and my new computer will probably run an AMD CPU and an AMD GPU but until my current PC gets outdated I will have to continue use my NVIDIA 970 which is still a decent card for cashual gaming
I've never experienced those supposed horrors across multiple operating systems (FreeBSD, Linux, macOS and Windows 7/8/10), the only time I owned an AMD graphics card it was a total disaster, among other things I remember are really bad Linux drivers (proprietary or otherwise). I never had any issues with my current GTX 1080, 4xGTX 2080 workstations or the 2xV100 nodes I have access to.
> I've never experienced those supposed horrors across multiple operating systems (FreeBSD, Linux, macOS and Windows 7/8/10)
You've completely missed the point. The horrors are in compatibility. NVIDIA chooses to make it difficult for their customers to use their hardware with new applications, and they hold back the whole ecosystem. In addition to the topic at hand (Wayland), their release model holds back Linux kernel releases when their driver becomes incompatible with the upstream kernel because it is not maintained there.
If you just want to run whatever boring applications NVIDIA chooses to allow you to run, congratulations! Go enjoy your "experience", and play it "the way it's meant to be played"! :- )
> among other things I remember are really bad Linux drivers (proprietary or otherwise)
> By all means, if you want to do NVIDIA's job, be my guest.
If I wrote an X compositor that supported NVIDIA's proprietary interface, it would work with pretty much every window manager that's ever been written.
If I patch wlroots to support NVIDIA, I'll still only be able to use window managers based on wlroots; I won't be able to use ones that spun the Wheel of Incompatible Wayland Compositor Libraries and landed on Weston, swc, Orbment, or whatever GNOME uses instead.
This is why it was so infuriating when NVIDIA refused to implement the stanadrd interface: they made the ecosystem "fragmented" for their users, and the PR cost of that bears on the compositor writers, rather than NVIDIA.
Having different compositors at the level they're at allows a lot more interesting innovations to be made, and aside from NVIDIA's tomfoolery, it has not caused significant inconsistency. Everyone uses libinput, almost everyone uses colord, and everyone implements GBM.
Wayland is substantially different from X, and the ways in which it is different are good. NVIDIA did the one thing we needed people not to do.
Have you considered that maybe it is the other way around: The standardised solution is inferior and NVIDIAs superior? Given the fact NVIDIA engineers probably know a lot more about modern graphics stacks than some Redhat employee this seems likely.
Some NVIDIA engineers probably know a lot about graphics stacks; charitably I'd say that those ones aren't the ones tasked with insisting on EGLStreams, which lacks a considerable number of crucial features.
To be honest though, NVIDIA engineers do not spend any time engineering graphics stacks at all; they write graphics drivers for stacks that are already largely specified. They're really good at shipping hundreds of megabytes of dirty hack code to patch popular shaders from ISVs to run slightly faster on their hardware, and probably great at writing shader compilers and threaded GL drivers.
Note the first comment there shows that their EGLStreams implementation shipped with vsync broken. EGLStreams seems attractive to NVIDIA because it was easy to implement (incorrectly). The features they talk about enabling on Tegra are not impossible with GBM, it just may involve adding a feature.
I recommend you simply to switch to AMD if you are using Linux and want a high end GPU. That's the only way for you to get a usable desktop with modern features.
Or wait until Intel will release a new GPU next year, it should work well with upstream too.
Nvidia has no interest in making their cards play well with Linux, so just avoid them completely to keep your sanity and don't waste your time trying to work around their mess.
Going forward, DE / compositor developers will support Nvidia use case less and less (due to Nvidia market share taking a further dip on Linux and Nvidia still not upstreaming their driver). So save yourself the trouble already today.
> I recommend you simply to switch to AMD if you are using Linux and want a high end GPU. That's the only way for you to get a usable desktop with modern features.
This is just not true. Gnome with Wayland is one of the most popular and modern DEs and it supports Nvidia's proprietary drivers today.
OP explicitly mentioned Sway (based on wlroots), not Gnome (mutter). Besides, even Gnome can't handle XWayland with Nvidia today. And if you play games, especially in Wine, that's still a requirement.
While Gnome developers bent under Nvidia's pressure, other compositor developers aren't interested in accommodating exceptions for blobs and wasting their resources on that.
TL;DR: just ditch Nvidia and forget about all their horrors. They really have no place in Linux ecosystem today, because of their refusal to upstream their drivers and because of preventing Nouveau from doing it for them.
Well, they don't play as nice as AMD, but they do at least give you working drivers. They do have place for consumers, there are valid use cases for Nvidia on Linux, such as:
3) (significantly) better performance per watt and less noise for high-end cards.
I still prefer AMD for their play-nice attitude with Linux and seemingly better track record on behaviour towards consumers, but Nvidia for the last years have been offering better hardware.
I have run a GT 1030 with a pair of 4K displays for a few months and the performance is terrible (for a desktop usage). I don't know where the bottleneck is (PCI bandwidth maybe) but you should avoid this card. I have replaced it with an RX550 and I don't have any performance problem anymore. It is not passively cooled, but the fan can be stopped from software if you want.
Given all the above, I'd call them "working", not working :)
> top performance available on the market;
Not anymore with new Navi cards. And competition in the Linux market will probably get even stronger with Intel releasing new GPUs with open drivers next year. I.e. there will be no reason to buy Nvidia anymore with all the blob downsides that aren't going to disappear.
For gaming 4K is really a read herring today, and for regular non gaming desktop use case, you don't need strong GPUs even for 4K.
> (significantly) better performance per watt and less noise for high-end cards.
Also not anymore with Navi.
So I'd say things today look pretty bad for Nvidia on Linux, and they'll be gradually losing Linux desktop market, until they will start playing nice with upstream. Time will tell if they actually will. I don't think they care though. And neither Linux users would care to use them.
> OP explicitly mentioned Sway (based on wlroots), not Gnome (mutter)
My parent commenter did not refer to Sway, that's why I rejected the claim that AMD is the "only way for you to get a usable desktop with modern features".
> even Gnome can't handle XWayland with Nvidia today. And if you play games, especially in Wine, that's still a requirement
I'm not sure what you're referring to. I've successfully launched and played Wine games with Nvidia proprietary drivers in Gnome with Wayland.
There is currently no accelerated GLX support when
running a GNOME Wayland session no top of the NVIDIA
drivers, meaning X11 OpenGL applications will use
software rendering.
I can't say I know the details, but I have played CS:GO (non-wine) and Overwatch on Wine without any special hacks with performance indicative of GPU, not CPU rendering. Perhaps it's because they're using Vulkan instead, or the docs are alluding to edge cases that I haven't encountered? I have very little technical knowledge of how it works, but I can say that it is absolutely working.
Or you know, just don't use the linux desktop. Nvidia's drivers are the only ones with a good Vulkan / OpenGL implementation, the other ones are underperforming severely. Nvidia also exclusively develops CUDA, so it basically it the only serious alternative for accelerating scientific workloads. Basically no-one cares what Kernel/Window system developers think as long don't cripple the Kernel severely enough that NVIDIA can't around their nonsense.
This is not about compliance but rather features and performance. When OpenGL was relevant they had by far the largest set of well thought out extensions (mutidrawindirect for example). Their Developer Tools were second to none and they had CUDA as a unique value proposition.
Their blob has no features advantage, and neither performance advantage anymore vs Mesa. While it is known to cheat and violate OpenGL spec to show better results.
I made a comment on this below, X already exists, why can't people live with X/fix X and thus utilize the already existing code vs recreate all the interfaces that X already has?
X is a dated mess at this point. Its core architecture assumes a model for drawing graphics that is more than teo decades out of date. There have been extensions - plenty of them - to drag it along and these have added substantial bloat. Also, some extensions where also awfully half-baked, turning the X11 protocol into nightmare to program against.
Wayland has some good ideas to modernize the stack based on passing GPU buffers between the compositor and applications, so that applications can use GPU acceleration and actual 21st century graphics technology to the fullest. But the non-graphics part of a desktop GUI are hard (e.g. event routing, clipboard, drag and drop, screenshots/capturing...). Wayland suffers from two things in this regard: first, it needs to catch up to a 30 year headstart thatball other DEs have with implememting that. Second, it is artificially hobbling itself by declaring absolutely trivial information privileged like the screen resolution and absolute coordinates of any window on the screen. This is a list of stumbling blocks and showstoppers that have to be worked around.
Indeed. Wayland seems tuned for Red Hat's need to ship a solid desktop that does one thing in one well-supported way. I'm going to miss X's configurability.
Apologies for the dumb question, but I'm looking for a linux desktop soon and some quick googling seems to say yes... but nvidia really doesn't work with wayland?
And come to think of it, isn't that a really weird problem to have? On X, the compositor (responsible for actually drawing all the windows on the screen) and the window manager (responsible for deciding how to arrange the windows and what their title bars/borders should look like) can be separate components, so I use i3 to arrange my windows and compton to draw them without tearing.
On Wayland, my impression is that the compositor and the window manager have to be built into the same program, so you run into silly situations where you can run GNOME on your graphics card but you can't run a basic tiling window manager. This also makes it a lot harder to create a new window manager, since you also have to write a compositor and test it on every graphics card.
That last issue could be solved with a reusable library that provided basic compositor functionality for window managers. Except every member of the Wayland community has independently had that idea and written their own, each with a different, incompatible interface and support for different graphics cards. So either we need a meta-library that abstracts away all the different libraries, or we need a standard compositor interface like X had.