I encountered a real fun bug where a game on linux crashed and a ghost of the game remained on the monitor even after it was connected to a different computer and power cycled, it remained for days. Some really interesting cascading bugs there.
That's not a software bug, that's an image retention issue with your monitor. If it was that severe then it probably got into a state where it was sending severely invalid timings to the TFT LCD array, DC biasing it, which causes long-term retention and may even cause permanent damage if done for too long.
Software isn't supposed to be able to cause that. That's on your monitor.
I _think_ it was every other frame, and I am fairly sure that it was a software/driver issue. It had never happened before, it has not happened since, and it started immediately when starting the game and the symptoms got progressively worse and triggering the mild symptoms happened every time I started the game.
What I convinced myself of after a few minutes being sure I wasn't hallucinating was that the graphics driver was pushing out malformed data in some way or the other which was triggering bugs in the monitor hardware/firmware, which is easy to believe are plentiful. It would be an interesting project to try to track down and replicate the bug.
That reminds me of the spookiest bug I've ever encountered: once, when resuming a Dell laptop from suspend at work, it showed a Windows desktop. Said laptop had been running Linux exclusively for several months (but it had previously been used with Windows). Interacting with the laptop made the expected xscreensaver unlock screen appear, and everything worked normally afterwards. The only explanation I could come up with was that, somehow, a snapshot of the Windows screen had survived intact in a corner of the framebuffer which the Linux driver didn't touch, even after months of power off/on and suspend/resume cycles, and a bizarre driver glitch made it visible in that particular resume cycle.
I agree, if it weren't for the fact that they give zero shits about Wayland support. I'd be totally fine with them staying closed source as long as they kept up with the standards.
What are you talking about? Wayland is supported on DEs that wanted to support nVidia chips.
Meanwhile projects like Sway have a direct "Go to hell if you use nVidia, we won't let you run this code." It's bizarre that you blame nVidia for this.
It's possible to create a Wayland compositor that works with the proprietary nVidia drivers, but it requires using nVidia-specific interfaces because nVidia refuses to support the same interfaces for non-GLX, non-X11 hardware acceleration provided by every other Linux graphics driver.
It's hardly surprising that a lot of Wayland compositor developers would rather not put in a ton of extra effort to add a special case for one particular set of proprietary drivers, which they would then need to maintain and support separately from the common code path.
To tell the whole story, the NVIDIA argument is that they want cross platform standard interfaces (EGLStream), which would use the same code the Windows driver uses, but the Linux world is pushing for Linux-only interfaces (EGL)
That may be, but the fact remains that nVidia is pushing an interface that no other Linux drivers currently support, for reasons that really only benefit them. The Linux kernel team has never been particularly supportive of middleware layers designed to promote common drivers between Linux and other operating systems, and for good reason—it impedes the development of optimized, native Linux drivers.
The only way I see nVidia succeeding here is if they clearly demonstrate that EGLStreams is a technically superior alternative to GBM, not just for their own hardware but in general, and also contribute the changes needed to support EGLStreams for all the other graphics drivers currently using GBM so that applications don't need to deal with both systems. As long as the EGLStreams code path can only be exercised in combination with the proprietary nVidia drivers it will remain a second-class citizen and projects would be well-advised to avoid it. (Drew DeVault goes into more detail[1] in his objection to the inclusion of EGLStreams support in KWin, which I agree with 100%.)
Or they could just acknowledge that this is a Linux driver, not a Windows driver, and implement the standard Linux GBM interfaces like everyone else even if that means less shared code.
It’s “””supported”””. It’s apparently very buggy and very difficult to debug. Sway lets you run it after you set a flag making it very clear that if something is broken you may not report a bug since the developers are unable to reasonably fix it.
Most Linux distro will also prevent you submitting a bug report for a kernel issue if you have a tainted kernel.
wayland doesn't work at all so if you have a 4k monitor and a non-4k monitor and an nvidia card, you're basically just fucked, because you can't selectively scale things
I have. I needed a prerelease kernel for a new driver but nvidia had not released a binary for the new kernel yet so I was unable to use anything but the open source nvidia driver.
Not to mention that nvidia uses proprietary configuration options even in Xorg.conf. A multi-monitor configuration which works fine in nouveau (or really any other driver) refuses to work with nvidia, because if you use the binary driver you have to set bizarre metamode options to make it work.
