NVIDIA doesn't support GBM, which is the standard for buffer allocation. Use nouveau.
>The last issue could be solved with a reusable library that provided basic compositor functionality for window managers.
This is pretty much what wlroots is.
>The last issue could be solved with a reusable library that provided basic compositor functionality for window managers.
This is pretty much what wlroots is.
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 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.
Except the single largest GPU vendor, yes.
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.
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.
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.
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.
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.
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.
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).
we did do that, and they were, but for the most part, for the moment (at least) we've won - so it's no longer on the tip of our tongue
"POSIX Has Become Outdated"
https://www.usenix.org/system/files/login/issues/login_fall1...
So no, Windows isn't the only one that doesn't care.
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).
Is there a list of ranking anywhere?
I vaguely have an idea of probably Intel is first then AMD second.
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.
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.
At the end of the day, X, GNOME and KDE have all figured out how to work with NVIDIA binary drivers, but wlroots has not.
(I don't know how much NVIDIA has contributed to GNOME and KDE's Wayland compositors)
If Nvidia don't support it, how much of a useful standard can it really be?
(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.)
FreeBSD 12.0 has Linux DRM 4.16 code (April 2018), while -current has Linux DRM 5.0 code (March 2019).
OpenBSD -current (next release) has Linux 4.19 DRM code (October 2018, LTS), with initial AMDGPU backports from 4.20 (AMD Picasso & Raven 2 support).
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.
You could vote with your wallet 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.
GBM works just fine, they've simply chosen not to support it.
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.
Furthermore lag time for supporting newest kernel normally lags what 30 days?
In brief what you are describing is self inflicted wounds.
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.
- 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.
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.
Wayland and its current limitations have nothing to do with, and does not excuse neither, nvidia's non-compliant implementation.
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".
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?
Except gaming is not that "niche":
1.35 billion PCs worldwide - https://www.statista.com/statistics/610271/worldwide-persona...
47M active daily and 90M monthly users for steam https://www.pcgamer.com/steam-now-has-90-million-monthly-use...
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.
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.
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.
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.
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 solution has been presented, and they reject it.
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.
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.
1. Relations with NvidiaNVIDIA changes prevent us from releasing a driver
* Signed firmwares accessible publicly but not redistributable
* Reverse engineering of vbios impossible
* Main contact/dev left NVIDIA (Alexandre Courbot)
* Most important requests left unanswered...
* ... until more complete code than wanted lands publicly innvgpuweeks later
Or even better, just open source their own driver