problematic trait of mine: i actually like the Linux NVIDIA graphics driver. it's always worked really well for me, it's fast, it's got good compatibility with games i run under wine, it handled render offload, hotplug, and hot-unplug of GPUs (less so the latter but to an extent) about as well as you can do with Xorg
nvidia.ko is one of the most singularly reviled things in the broader Linux sphere, maybe even more so than systemd, and honestly i don't think it deserves that level of hate
@whitequark hater opinion: i feel like most of the hate these days is simply because wayland folks refused to work with nvidia and so the wayland desktop was broken for years.

@dotstdy @whitequark well yes and no, NVIDIA were invited to the table, the rest of vendors and community decided on an approach for Wayland that was fine for all of them, then NVIDIA refused to work with the rest and do their own thing instead (EGLStreams, that works only with their driver, is nonstandard, and with many limitations). Then of course because everybody else took the common approach, and they've been playing catchup.

The initial refusal to add proper DRM/KMS modesetting to their driver was what made NVIDIA diverge, and that was way before Wayland, and already then it was clear that this would be the way forward for Linux GPU drivers more than 15 years ago.

“Wayland folks didn't want to work with NVIDIA” is an urban legend.

@aperezdc @whitequark it's not possible for nvidia to use drm apis without rewriting their kernel driver as a gpl module. So no. "Wayland" writ large did not consider that a constraint worth designing around.

@dotstdy @whitequark only that this claim is also wrong, recent versions of the NVIDIA Linux driver can do DRM/KMS modeset, see https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting — and this is not only useful for Wayland; for example any device where there isn't a VGA text console can have an emulated console using graphics modes through the generic DRM framebuffer driver.

Again, the right answer is: NVIDIA wanted to do their own thing instead of having to agree with others, and in the end they're having to play catchup because nobody else adopted their approach. You may like it or not, but that's the facts.

NVIDIA - ArchWiki

@aperezdc what do you mean "recent"? :) https://github.com/aritger/eglstreams-kms-example (the issue wasn't so much kms as the entire rest of the owl)

As pointed out in the top of the thread, one virtue of the nv approach is their driver has ~feature parity with the more important (to nv and customers) windows driver. Anything which requires substantially changing the architecture is introducing fragmentation for their internal development, and in any case will take a lot of time to achieve politically + technically.

GitHub - aritger/eglstreams-kms-example: Example of using EGLStreams + DRM KMS

Example of using EGLStreams + DRM KMS. Contribute to aritger/eglstreams-kms-example development by creating an account on GitHub.

GitHub
@aperezdc it's totally possible to say, well fuck em they can do it our way or not at all, but I think it's a bit weird to then claim that it's all their fault they didn't prioritize your architecture needs over everything their primary customers cared about. And since the pivot takes time it will invariably introduce usability bumps which people will get upset about (regardless of who users ultimately blame)