[Topgamer7]

Trying to get a 1070 set up w/ 2 monitors on a laptop with hybrid graphics is a nightmare. 1 display driven by intel, 1 by nvidia. Cannot get both screens working without 2 Xscreens. Xinerama wouldn't work w. proprietary drivers. Nouveau has like no support for like 1050 up.

Wanted to try out SwayWM, but they don't work around how nvidia handles things in comparison to what everyone else does.

Works in Ubuntu, but could not for the life of me get 2 monitors working in Arch.

[orbifold]

Maybe just maybe this is not the fault of Nvidia but due to the fact that large parts of the Linux ecosystem are fragile, time consuming to configure and break if you look at them in the wrong way. Professional linux distributions like Ubuntu paper over a lot of that fragility, whereas in Arch Linux you can easily burn days getting basic functionality to work (multiple sound cards come to mind) only for it to break with the next update. And yes I speak from experience, I used Arch Linux ~5 years basically for the fun of doing everything by yourself, because Ubuntu felt too restrictive and opaque.

[sangnoir]

> Maybe just maybe this is not the fault of Nvidia but due to the fact that large parts of the Linux ecosystem are fragile, time consuming to configure and break if you look at them in the wrong way.

How it works with open source drivers is that you main-line your drivers so that the kernel maintainer maintain the drivers for you, for free. Choosing to keep your drivers closed source means committing to keeping your drivers up-to-date with changes in the kernel, or writing an open-source shim that does that. Which approach is more "fragile?"

[orbifold]

I'm sorry but this is not how it works. No-one maintains your drivers for free. The contributors to drivers in the Linux kernel are usually employed by the companies that make the product. In addition they might have to deal with subsystem maintainers that treat their part of the code base as their personal fiefdom. Just follow the hoops that the AMD developers had to jump through so that their driver components got accepted into the kernel. Basically they were told they were doing it all wrong and should really be using abstractions already in place, which were probably developed by Intel in order to get their graphics stack to work (https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...). Imagine being treated like that while you also need to support two much larger platforms (consoles, windows and ideally a simulation backend for hardware development). Nvidia wisely decided to develop one driver stack to cover all of these platforms, while as far as I know AMD split their effort for a long time. Nvidia also had by far the highest quality OpenGL implementation in place (not sure about Vulkan).

Graphics card drivers happen to be very complex beasts, somewhere along the stack they do need a compiler for multiple custom and often proprietary architectures, which most definitely no-one will maintain for free for you. There is a huge incentive to keep most of the code platform independent and only maintain a minimal kernel specific component. This part of the code base is a comparatively trivial part, essentially the kernel should get out of the way as much as possible. The kernel specific abstractions like KMS are examples of such comparatively trivial things.

[sangnoir]

"Maintain" was too broad for what I meant: I should have said they'll future-proof your driver. Any future changes to the kernel won't break your mainlined driver - this is what you get for free, not defect fixes or other types of refactors. What you get for free is your driver working with all future kernel releases at the time of release; unlike Nvidia's drivers which lag kernel releases.

[llukas]

> How it works with open source drivers is that you main-line your drivers so that the kernel maintainer maintain the drivers for you, for free.

Not sure what do you mean by "maintain for free". Full coverage testing is not free.