Wayland misconceptions debunked
drewdevault.com
drewdevault.com
Nvidia's position, literally, is their GPUs are not Linux compatible. The Linux ecosystem relies on the Mesa stack (Mesa, DRI, DRM, GBM, KMS, etc), and DRM is part of the upstream kernel itself... Nvidia has openly not used any of these APIs.
This is exactly equivalent to Nvidia not using WDDM and DXGI. If Nvidia chose to do that, Microsoft would outright ban them from driver certification (thus the platform entirely), so why is it wrong for Linux and Wayland to do the same?
The Linux community reached out to Nvidia and help them along with Nouveau, and at one point even threatened to sue them. Linus Torvalds has told them that he doesn't care about them if they won't actually participate in Linux, and will continue to break their drivers because they just don't listen.
Nvidia's linux drivers work fine for me, although granted they are hard to install (hard compared to apt install).
And for low end and integrated cards, using Intel or AMD APU is an obvious choice, especially in laptops. Optimus is such a horrible mess, that no Linux users should come anywhere close to it.
My gut feeling says no.
Intel joining the high end GPU market with open drivers might also help speeding things up, including dislodging of CUDA lock-in.
Having a hard stance on Nvidia, which I support, makes no sense if they have no interest in Linux support at all.
No, you are taking a with-us-or-against-us mentality. Users and application developers want things to work as broadly as possible, regardless of the graphics card or driver being used. Whether that helps or hurts various parties regarding Nvidia's closed-source stance is irrelevant.
> Nvidia's position, literally, is their GPUs are not Linux compatible
Citation needed. If this is their position, why would they offer Linux driver downloads? Not supporting something in a way Linux would prefer is not the same as not supporting something.
>This is exactly equivalent to Nvidia not using WDDM and DXGI. If Nvidia chose to do that, Microsoft would outright ban them from driver certification (thus the platform entirely), so why is it wrong for Linux and Wayland to do the same?
Microsoft can get away with this precisely because it sells Windows; it lowers the price to vendors (such as Dell) on the condition that they only use certified drivers. It is entirely possible to run Windows with uncertified drivers. In any case, it is my understanding that this is a licensing issue, and Nvidia would support more APIs if it could do so while keeping the driver proprietary.
It's not so much that they are incompatible. It's that they weren't written for linux. They use the same driver for windows which has been adapted for linux. That also allows them to avoid any sort of derivate work clause that would kick in due to the GPL.
I am a Linux desktop user myself but:
a) The AMD drivers were unusable crap for a very long time, things have improved only thanks to the open source driver (that ATI/AMD did not write, they only contributed specs). Basically 3D and OpenGL in Linux was for years synonymous with "buy Nvidia, it works".
b) I don't understand this "holier than thou" attitudes when Linux desktop isn't even a blip on the radar and pretty much contributes zero to the bottom line of these companies. However, it tends to have the most vocal, noisy and abusive users ...
Instead of being glad that Nvidia actually supports Linux (and FreeBSD and few other free OSes) for ~20 years now (before ATI even had a Linux driver at all!), we heap abuse on them because their drivers aren't to our taste? Would it be better if they cut their losses and stop providing this support? Especially for stuff that doesn't have any alternatives, such as CUDA? And no, Intel integrated graphics really isn't an option for high performance graphics and ATI's open source drivers are quite a bit slower. Of course, if all you need is requiring accelerated desktop so that you can have nice transparency/compositing and accelerated video playing, then you won't see this.
I don't get where did you get the idea about the "lowest common denominator quality driver" from Nvidia. Sure there are bugs and issues (e.g. with suspend) but in my experience the Nvidia graphic drivers were the least troublesome when it came to application support, OpenGL spec + extension support and various bugs. And I have been using 3D drivers in Linux essentially from the very beginning, when the top end hardware meant a 3DFX card or later a Riva TNT. My diploma thesis ran on a 3DFX back in the day ...
That said, it doesn't mean we shouldn't complain when something doesn't work but let's not forget the size of the market. A dose of reality helps - jumping up and down and yelling really really loud to look important doesn't make one so.
They'd lose more if they did that. Do you think the whole world of HPC/ML/scientific computing will switch to windows to use nvidia cards ? The answer to that is no. They'll just move over to AMD. ROCM is coming along fairly well. Or something else will pop up. Don't get too attached to blobs.
This is a lie.
All of the main contributors for the amdgpu drivers are AMD employees. The files in drivers/gpu/drm/amd/amdgpu all have AMD copyrights in the headers.
Quoting the article:
> Actually, Nvidia doesn’t support us. There are three standard APIs which are implemented by all graphics drivers in the Linux kernel: DRM (display resource management), KMS (kernel mode setting), and GBM (generic buffer management). All three are necessary for most Wayland compositors. Only the first two are implemented by the Nvidia proprietary driver. In order to support Nvidia, Wayland compositors need to add code resembling this:
if (nvidia proprietary driver) {
/* several thousand lines of code */
} else {
/* several thousand lines of code */
}
The last group is so vanishingly small. They’re neither a meaningful number of users nor a meaning number of payers.
Linux should do its best to support word of mouth evangelists with the best user experience possible, because even though free software evangelism is definitely viral, retention favors convenience over all other factors when the price is zero.
But this has always been about ego. Jensen Huang thinks he’s the biggest hot shot in the world, and that culture pervades his company. But Linux is going to be around a lot longer than somebody’s game rendering coprocessors.
I’d appeal to humility, not some meaningless details about APIs. Definitely not a business case.
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
Well, maybe Microsoft of 2019 might behave differently, after spending decades in desktop OS market domination, but what's more relevant is how they got there in the first place.
[1] https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
I’m honestly surprised the major distros haven’t gotten together to do this, in a shared fork if necessary. It’s outright embarrassing that this attitude still infects the Linux project.
1. https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...
In practice though, that's likely the least of their reasons not to open their driver. More probably, they just don't want to expose some embarrassing code mess or non compliant cheating in their graphics stack, as well as don't want to allow anyone decide how to use their GPUs without Nvidia dictating them. If they control accelerated driver - they can dictate and demand more money in some use cases from those who want a more permissive driver. All of that has very little to do with intellectual property and more with market manipulation.
None of the distros are going to get behind your fork because all agree with Linux on this matter, rightfully so. Nvidia can fuck off with their proprietary crap, Linux has no intention of bending over for that garbage.
ATI/AMD still has their own proprietary, closed blob driver that is not in the tree - and which actually runs quite a bit faster than the open source one.
$ cd ~/sources/linux/drivers/gpu/
$ git log . | grep "@amd.com" | wc -l
42418
$ cd ~/sources/mesa
$ git log | grep "@amd.com" | wc -l
4817
It doesn't run faster, this is nonsense. I've personally met the AMDGPU driver developers and if you ask them they'll even tell you that basically no one needs AMDGPU Pro. It's not faster, this is bollucks.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
You are probably confusing the situation with nouveau, which is indeed community developed reverse engineered kernel driver for Nvidia.
It is generally slower than Mesa + upstream AMDGPU and has been for more than a year.
Linux needs to get over itself and recognize that it’s part of a larger world, and that its “my way or the highway” attitude is unnecessarily constraining.
The fact that people are coming to you and saying “I’d like to use my Nvidia card with Linux but Linux isn’t supported” does mean it’s a problem—and the problem is Linux’s, not Nvidia’s.
I don't find it embarrassing that Linux maintainers prefer to leave every line of code in the kernel up for improvement, rather than desperately replicating known misbehaviours until a new five-to-ten year waterfall release comes. AMD's drivers work great, I buy AMD because instead of getting upset that they don't get to call all the shots, they put in the work and make peace with the establishment.
NVIDIA would rather throw a pathetic, childish tantrum and blame everyone else for their arrogant position which leaves their customers begging maintainers to comply and work on their own time to enrich NVIDIA.
It works great in MPV, I don't use VLC so I can't comment on that. The major problem right now with video acceleration is that Chromium (or maybe it's my distribution's build of it) seems to have enabled VA-API acceleration, but the Mesa VA-API state tracker (I think, I'd be glad to be corrected on this) I think is missing the API that would tell Chromium which pixel format to expect the decoder's output in; so Chromium assumes that it'll be in a certain format which it turns out not to be, and this leads to hideous corruption.
I suspect that if and when there is any significant amount of HEVC content on the web, this issue will probably be resolved by then. For now there are configuration parameters which can be used to work around the issue by disabling the pixel format Chromium defaults to, and do so just in chromium, but a fix (which will be in Mesa 19) is required for that configuration to work with Chromium (due to its unusual process naming).
I have used the MJPEG UVD decoder through ffmpeg to decode my 4K webcam's output and it works a treat.
I got hit by strange Wayland bugs when distros like Ubuntu and Fedora activated it too early and I'm not looking to make the switch anytime soon, but I wish the project the best and am happy to see it seems to be on a good way.
There is a very high likelihood that when a user complains about Wayland support for Nvidia they mean this:
* user already assumes Nvidia is a bad Linux actor
* user knows Nvidia only supports buggy blobs
* user may even know Nvidia is bad to people trying to unblob the blobs
* user already went through the trouble of doing what it takes to get the bad Linux Nvidia blobs to work to play games on their machines
* user notices that the bad buggy Linux Nvidia blobs fail to work at all with Wayland
* user is understandably even more frustrated than they were before. So they ask you-- a Wayland person-- how can it be even worse for them now when they've already been generating much more complex and power-hungry graphics with their buggy blob than they'd ever do with Wayland.
If you're representing Wayland, this problem is your problem whether you want it or not. Perhaps the answer is to make the protocol worse so the the Nvidia user doesn't remain eternally maximally frustrated. Perhaps the answer is that isn't possible and you're stuck in the same boat as the user. Perhaps it means you start a hunger strike or gather thousands of devs to protest outside Nvidia's headquarters until they improve. I have no idea.
But please don't do that FLOSS thing where all the devs on a project teach each other to sync on, "Sorry Mario, but your princess is in another castle." That pattern becomes it's own problem and can quickly end up discouraging development even from potential devs who don't care at all about Nvidia support.
> Wayland doesn’t support screenshots/capture!
What is the current UX for screenshotting, screencapture, and screencapture with audio for the most featureful DE that uses Wayland atm? Is there a program out there that offers push-button access for these three features (choosing the most sensible default format in each case)?
As the actual person who receives these complaints... this isn't true. Once it's explained, though, the users still stick around and get angry because they made dumb, uninformed choices as a consumer and think it's our fault.
>If you're representing Wayland, this problem is your problem whether you want it or not.
It's not. We can just choose not to solve it. Use X and buy smarter when the next harware upgrade comes around, or wait until your hardware is supported by nouveau if you don't want to upgrade any time soon.
>What is the current UX for screenshotting, screencapture, and screencapture with audio for the most featureful DE that uses Wayland atm? Is there a program out there that offers push-button access for these three features (choosing the most sensible default format in each case)?
I don't really know what the situation is for more noob-friendly DEs like GNOME, but on sway this tool is the i3-equivalent of push-button simplicity:
https://wayland.emersion.fr/grim/
Push-button screen capture isn't there yet.
In terms of sheer bang for your buck, Nvidia's cards have been on top for a while now (there's a good reason cryptocurrency miners have been using them), on Linux their proprietary drivers are the most stable in games - unless your only goal is to run Wayland, it's not exactly a "dumb, uninformed choice".
This seems like a clear problem with Wayland developers mentality if they expect consumers to make purchasing decisions based on their platform alone.
But they have not been on top for a long enough period that cards bought when they were are generally supported by nouveau, and cards bought after should be AMD. On top of this, the reality is that most people don't need top of the line GPUs. Last year's GPUs will run next year's games at max specs.
>Linux their proprietary drivers are the most stable in games
were
If you want to run at 1080p@60hz perhaps, but many people now are going to 1440p, 2160p, 144hz or some combination there of which can easily strain even the latest GPUs.
https://www.gamingonlinux.com/wiki/Games_broken_on_Mesa
This list is monitored by Mesa developers.
These days AMD explicitly recommend using open drivers for gaming.
Creating a product that only works for people who already a) know about it and b) buy their hardware specifically to support it doesn't seem like a good strategy to achieve widespread adoption, which requires converting people who don't currently use or know about wayland.
When you are purchasing Nvidia, you are giving money to Nvidia. If you have problem with some software not working with a product your purchased, contact the people you gave money to for support.
It's gamers, that prefer Nvidia. Nvidia has better optimized driver stack, although they also sometimes play fast and loose.
Not anymore, as long as you are using latest Mesa. Also, Nvidia usage on Linux is gradually dropping. See: https://www.gamingonlinux.com/index.php?module=statistics&vi...
So I agree with position that compositor developers should not waste their time on supporting the blob. If Nvidia are so eager, let them contribute support, like they proposed for KWin.
> This is currently in BETA. There are 8338 registered users on GamingOnLinux. These statistics are gathered using their manually entered data on their profiles. Please update your profile here to make this as accurate as possible.
> As with any survey, this won't be 100% accurate and should be taken with a pinch of salt.
8K users on a site about gaming. Doesn’t include RHEL/CentOS in its distribution chart. Way too myopic of a sample to even declare NVIDIA usage on Linux is dropping. For all we know it could be that new users are signing up that don’t have NVIDIA hardware, it doesn’t show a shift away from NVIDIA.
I know that your comment is about games, but over in the professional CG/VFX and AI/ML spaces, AMD is rarely touched. For both workstations and server racks.
> it doesn’t show a shift away from NVIDIA
It does, as confirmed by many users who choose AMD for their next upgrades. Their choice of Nvidia was due to better performing drivers in the past, which is a non existent difference these days. So they choose to drop Nvidia and get AMD because of much better Linux integration (from kernel to the whole graphics stack and DEs), which is a consequence of AMD drivers being open.
> but over in the professional CG/VFX and AI/ML spaces, AMD is rarely touched
Not from what I've heard. AMD is better for GPGPU due to real asynchronous compute which Nvidia lacks. If anything, AMD hardware is more compute oriented, and Nvidia one is more gaming oriented.
AMD plan to address it with their next architecture (so called "super-SIMD"). But compute hardware support is already good there.
You might refer to CUDA lock-in, and some higher end libraries for AI being CUDA only. That's surely a problem, but not with hardware itself. AMD are working on addressing that as well (ROCm project).
That's why I ended by saying I know that parent comment and site was about gaming, but I wanted to add a bit of extra context. And these 'server' distros are the primary workstation hosts, both bare bones and PCoIP for pretty much the entire CG industry.
> It does, as confirmed by many users who choose AMD for their next upgrades.
It doesn't at all. This graph only shows a very generic view at best. If you wanted to see a shift, you would need a graph of users changing their profiles from NVIDIA hardware to AMD hardware and a separate graph of new users coming in with AMD gear. This is just a conglomerate of information in a single graph, there are way to many inferences that can be made that simultaneously can't be proven without more specific data.
> Not from what I've heard. AMD is better for GPGPU due to real asynchronous compute which Nvidia lacks. If anything, AMD hardware is more compute oriented, and Nvidia one is more gaming oriented.
Source? Working over in CG/VFX myself, NVIDIA is pretty much the only hardware to choose. For rendering, everything is CUDA based. Application support for AMD, not stellar. NVIDIA offers the most stable platform for our use cases so far. Release notes of software literally point out that AMD support is not as extensive as NVIDIA and subject to being unstable.
> You might refer to CUDA lock-in, and some higher end libraries for AI being CUDA only. That's surely a problem, but not with hardware itself.
There doesn't have to be a problem with the hardware, adoption will be zero as long as alternative OpenCL/Vulkan compute based libraries don't exist. I know there's been a long term project of getting OpenCL as an engine for TensorFlow, been a bit since I checked its progress. The OpenCL stack for AMD also doesn't have a stellar reputation for producing consistently competitive results. Phoronix released a strict OpenCL comparison adding the Radeon VII to the mix with ROCm 2.0 and as a developer, it wouldn't give me confidence that compared to CUDA I'm going to be getting the results I'm looking for. NVIDIA has a very mature stack and support with CUDA and its associated libraries. AMD is going to need to be able to supply that for people to ween themselves off of the green train.
Granted for more AI based work, one might look towards the Instinct lineup.
https://www.phoronix.com/scan.php?page=article&item=radeon-v...
If you didn't follow this, it doesn't to you. It does, to those who pay attention and constantly see people switching to AMD and commenting about their reasons. And these reasons are quite obvious really. Nvidia did nothing to improve their integration with Linux (the meain issue is their unwillingness to upstream their kernel driver), while AMD did a lot to improve their drivers. It's only natural to expect Nvidia Linux gaming usage to continuously drop as a result of the above.
> Source?
https://www.techpowerup.com/215663/lack-of-async-compute-on-...
AMD hardware is known to be better for GPGPU for a long time already.
> There doesn't have to be a problem with the hardware, adoption will be zero as long as alternative OpenCL/Vulkan compute based libraries don't exist.
If developers are using some closed source libraries, they are at mercy of those vendors who might be in the pocket of Nvidia. And no one stops open source libraries from not being CUDA only and from using Vulkan and OpenCL for compute needs. Given Vulkan is still rather new, it can take time for libraries to pick it up though for compute scenarios. But it will happen either way. Overall, I don't see good future for CUDA, if it will remain Nvidia only. Same as with gaming, open solutions will catch up, and Nvidia lock-in will crumble.
I'm talking about this purely from a data point of view. I'm referring to the graph, and it has too many holes to be used as a sweeping generalization about the market and Linux users as a whole.
To be clear, I'm not arguing for or against NVIDIA/AMD. I'm just trying to point out the issues with using that graph as definitive evidence of anything.
> Nvidia did nothing to improve their integration with Linux, while AMD did a lot to improve their drivers.
And I applaud AMD for that. They've come a long way. However, (and this is personal opinion based off of experience), I don't see Wayland as being as a particularly massive reason. Wayland is what this thread is about anyways. There are still plenty of people using XOrg that are happy with that and don't run into any issues, myself included. That's not to say I don't support Wayland development and I hope NVIDIA never adds support for it in the future, but it's such a 'young' piece of tech that still requires some more maturing.
> AMD hardware is known to be better for GPGPU for a long time already.
Raw power is only a piece the pie. Some people take issue with that statement, but it's reality.
To the point in your link, Pascal fixes the async problem present in Maxwell.
https://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-...
> And no one stops open source libraries from not being CUDA only and from using Vulkan and OpenCL for compute needs.
And yet they primarily are CUDA only. It's a conscious and intentional decision by the developers of those libraries to start with CUDA and stick to it. And the community not adding OpenCL support shows that AMD hardware isn't even in the space for that application.
I think that we could go back and forth with this, providing counter examples for each point the other brings up. I merely wanted to offer up an enterprise oriented view of the picture, when most people are looking at individual usage.
Graph makes sense if you analyze the context. It's as I said above - increasing number of users are switching to AMD. Just check any thread in Linux gaming forums on the topic of "what should be my next GPU".
> I don't see Wayland as being as a particularly massive reason. <...> don't run into any issues,
It's one of the reasons. There are many issues with Nvidia. Abysmal integration due to lack of upstream driver such as broken vsync, no standard hardware sensors, no PRIME support and so and so forth are all well known Nvidia problems. To address them, Nvidia should either open up their driver, or to support Nouveau to begin with. So far they showed no interest in either of those cases.
> It's a conscious and intentional decision by the developers of those libraries to start with CUDA and stick to it.
That's too bad. Avoid libraries which proliferate lock-in. If their developers don't know any better, find those who do and support their efforts instead. It should be in the interest of actual developers who use said libraries, not to be locked into single hardware vendor.
Maybe, maybe not, but the async compute argument you are making only applies to graphics applications that use compute shaders on maxwell - it doesn't apply to pure gpgpu without graphics.
https://www.phoronix.com/ has a recent benchmarking of absolute card performance[1], and sometimes does performance-per-dollar, as here[2] last year with OpenCL (reporting AMD's FLOPS as cheaper... when ROCm satisfices). I've found the site helpful when tracking bleeding-edge linux support for high-end graphics cards.
[1] https://www.phoronix.com/scan.php?page=article&item=radeon-v... [2] https://www.phoronix.com/scan.php?page=article&item=nvidia-r...
If this is the attitude of Wayland developers, it goes a long way towards explaining Wayland's ten year road of non-adoption.
To illustrate with my own example, I bought a Linux-compatible laptop when I wanted to run Linux on a desktop. That rewarded the seller for effort they put in, reused the FOSS work already performed, and required no demands to be made of volunteers. These things are a two-way street. So, I met them in the middle. Did it again getting a Thinkpad cuz I wanted to try BSD's later this year. Supported all of them.
If trying to maximize adoption, you have to tolerate people's indifference and selfishness. They dont want to maximize sales for anti-FOSS company. So, they're telling that company's customers the issue, suggesting a switch, and having something waiting for AMD buyers.
Since when has FOSS meant that I _can't_ work with proprietary bits? As a user, this is my choice. If software is going to dictate where I spend my money, then I'm less inclined to adopt it. That's not freedom.
I didn't read any "holier-than-thou" sentiment in the parent comment. It's not unreasonable to expect users to think about the things they want to be compatible with when buying hardware.
"I want to be able to use the next version of Windows"... buy hardware that's known to be compatible with the next version of Windows. "I want to use this printer from my iPad"... buy a printer known to be compatible with that model of iPad. "I want to use this printer from GNU/Linux"... buy a printer known to be compatible with GNU/Linux. "I want to use OpenBSD"... buy hardware that's known to be compatible with OpenBSD. "I want to use Ubuntu 17.10"... buy hardware that's known to be compatible with Wayland.
People generally don't understand what linux is, or what a distribution is, or what versions of any of the above are new or upcoming. None of these problems apply to Microsoft, since there are many fewer versions, less fragmentation, and a marketing budget.
Firstly, it's refuting a different point than the one I was making. If the problem were "it's too difficult to determine if hardware is compatible with the distro I want to use," (which is a real problem) then the comment would at least be relevant. But the comment I was replying to said "If software is going to dictate where I spend my money [what hardware I buy], ..."; they were rejecting the validity the claim that they should consider which software they use when making a hardware purchase, which is true for no OS, and no reasonable user expects to be true.
Secondly, you are demanding an impossible task. Because GNU/Linux distros have less marketing budget, and not enough dominance, and can't convince hardware vendors to put a sticker on the box... they need to have better hardware compatibility than Microsoft, and just be compatible with all the hardware? Microsoft has vastly more resources to dedicate to hardware compatibly than just about any other organization, and hardware vendors themselves test their hardware with Windows. Expecting a less-popular desktop operating system to work with more arbitrary hardware than Windows does is unreasonable.
I get that "being able to try it out with the hardware I already own" is a hugely powerful thing. But most users who want to make any other switch accept that they might need to buy some new hardware when doing it. A user switching from a Windows laptop to an iPad as their daily-driver accepts that they may need to get a new printer that's compatible. They may even realize that they have an older iPad, and research the printer they want to make sure it's compatible with their model, and not blindly trust the AirPrint badge on the box. Few users would think that level of due-diligence is unreasonable. Saying "that research is difficult for GNU/Linux distros" is very different than saying "expecting any level of research at all is unreasonable".
Nvidia is going to do what Nvidia is going to do, for their own reasons. Unless you have some hidden inside information you shouldn’t assume they’re doing it in order to hurt Linux or Open Source.
They’ve probably done some evaluation of what they would get out of putting their drivers into the kernel tree versus keeping them to themselves, and decided that it wasn’t worth the work, expense, risk to their IP, etc.
He was saying they're getting plenty of action. They're just not supporting users on specific hardware whose vendor is trying to block such action. It still is freedom. It just doesn't support that specific hardware.
"Since when has FOSS meant that I _can't_ work with proprietary bits? As a user, this is my choice. "
It really isn't if you're just a user. It's the developers' choices that dictate what software you can run on which hardware. Once their choices are made, you choose between what each offers. In this case...
"If software is going to dictate where I spend my money, then I'm less inclined to adopt it."
Nvidia is spending money on software that tries to block you from using free software with it easily. The volunteers developing one of those free packages refuse to build support for an anti-FOSS company putting up obstacles. Instead, they're doing work on companies helping them a bit or not putting up obstacles to their work.
As a user, it would be weird for you to claim to want free software while buying a piece of hardware whose developers are working against that goal. They'll also use your dollars from that purchase to do more activity that reduces your freedom as a user. You're free to choose to buy that hardware but there's no reasons for volunteers, much less those maximizing free software, to be forced to do painful work to support your choice. It's reasonable to say you're on your own if your choices create unnecessary obstacles.
If Wayland developers truly do not care about adoption of their software, then that’s fine. But it means that UI frameworks which do care about adoption will have to continue to support both X and Wayland as backends indefinitely, increasing complexity. That’s okay for now, since removing X support would be a long way off in any case. But if enough years go by without at least a plausible route towards being able to remove it in the future, they may eventually decide to address the complexity issue by dropping Wayland instead.
Compare to something like this:
"We need to provide potential users of Wayland with better information, both to better calibrate their expectations and ensure that anger is properly directed and to help them make more informed buying decisions in the future."
Of fucking course you have a communication problem when your relationship with your userbase is founded on logic like "doing anything other than calling them idiots and ignoring them is useless and we shouldn't surrender to idiocy".
Attempting to run a project based on the opinions of a group of Nvidia devs who (1) don't care about your project and (2) don't care about your goals is technical madness. It took the kernel more than a decade of stubbornness before all the other device driver writers caved and supported decent design. As far as I recall Nvidia is literally the last major device driver who refuses to play ball with open source. If Nvidia users can't use Wayland for driver reasons that is because of Nvidia's choices and there isn't anything the Wayland devs can do without repeating all the mistakes of X.org.
If it takes another decade before Nvidia caves and behaves like a good corporate citizen then that is a decade well spent by the Wayland devs. Long term maintainability will eventually trump short term user issues; just like it did for wifi et al. It is unfortunate Nvidia is making their user's lives hard, but the writing has been on the wall since AMD started open sourcing their driver stack in the 2008 era.
My phone is running kernel 3.10 (the same as rhel7, except without backported fixes), and it isn't going to get anything newer.
The only reason Google and a few big players can ever ship updates is by playing hard with those vendors, and negotiating upgrade paths in advance. Nobody is interested in doing that for the desktop.
Game devs just want to put shinny pixels on the screen, no one cares if it is a blob or not.
AMD is open source and there is hardly any advantage, X routinely crashs, doesn't provide support for the GPUs that were dropped from the rebooted driver, being stuck with fewer capabilities than fxgl.
Hollywood studios are quite happy with NVidia drivers.
But maybe that's okay. With a viable alternative, we can be patient.
On Gnome you can bind shortcuts to copy save to a file or copy to clipboard the whole screen, the current window, or a rectangular screen region. In the latter case, you can drag a rectangle with the mouse to choose the area you want to screenshot. There is a visual indication of the copied region (it blends a white rectangle over it), and the clipboard works with all applications (both Wayland and XWayland).
For screen recording I've used Peek, which is pretty nice, too.
You're absolutely, completely, 100% correct. In this scenario it is the Wayland developer's problem - wanted or otherwise - that the user is incredibly frustrated. Like most frustrated people, the user chooses to blame what seems like a reasonable target who coincidentally isn't them. Such as Wayland!
This anger and frustration is something that Wayland devs unquestionably have to deal with. It's just perhaps possible that the choices made by NVidia driving this completely reasonable frustration might not be something Wayland devs have to own.
Again, you're completely right. Unhappy users are going to blame Wayland devs. There just might be some room for subtlety.
Linux is trying to force its unique “all drivers are open source and in our tree” view of the world on everyone. Linux could stop doing this and start guaranteeing stable interfaces.
If stable interfaces are available and Nvidia doesn’t use them, then it might be reasonable to call them “a bad actor.”
Assuming that a stable kernel API would just make things better ignores the potential downsides. I don't recall the name of the talk, but someone did comparative research into BSD kernel security and found that backwards compatibility was a significant source of bugs and that OpenBSD has benefited greatly from their aggressive removal of such code.
There's no reason to doubt that this holds true for Linux as well
The Gnome UX is pretty nice, see my sibling comment.
Interestingly, this is more of an indictment of Wayland than anything in the article that's being "debunked". I don't dispute that it is difficult work, but you'll have to choose between making a viable X replacement, and dying on this particular hill.
Thanks for your work on wlroots and other software I've enjoyed. I imagine I'll be switching to sway soon as well. There was something preventing me from adopting it yet but I can't remember what it was. I believe it was on the roadmap though.
I'm glad you posted this article because my new year's initiative is to donate to a couple dozen FOSS projects and you definitely deserve some of that.
Thankfully, Nvidia makes Linux drivers, otherwise I would have to (gasp) use Windows as my development machine. Unfortunately, Wayland doesn’t work. I love Wayland and its clean API, but I can’t use anything else except Nvidia, because there is no CUDA.
And fine: if you have a difference of opinion, just use X.
Hardware that is wrong, because the (market dominant) company behind it, does not make a open-source driver?
I mean, you do realize, that Open-Source is sadly not the norm and rather something very odd to traditional industries?
So to people who do not worship the GPL(or even heard of it and just want their software to work), you might be a bit offputting. Which might not be the way to increase the significance of Open Source. Which is a bit sad. Because I love OS and yes I know about the GPL etc. - but even I am put of by that arrogance and ignorance. So I am not saying you need to support X or whatever, but maybe do not direct your hate of Nvidia to the users of Nvidia. Maybe they are even new to this. Because those would then just shake their head and go away, (back to windows). Hurray.
> [...] if using hybrid graphics where the primary is Intel and the secondary is nvidia, sway would continue to work (just without nvidia monitors) and the user would never see the log message. Then they're likely to create issues related to outputs not working, causing us to invest time in troubleshooting it, only to find that they are using nvidia and never saw the warning."
So yes, you can run sway with the nvidia module loaded, just please unload it and test again before you report bugs.
> So yes, you can run sway with the nvidia module loaded, just please unload it and test again before you report bugs.
> If you are using the nvidia proprietary driver for any reason, you have two choices:
>
> 1. Uninstall it and use nouveau instead
> 2. Use X11+i3 and close your browser tab
>
> If `lsmod | grep nvidia | wc -l` shows anything other than zero, your bug report is not welcome here.
I don’t want to settle for Intel GPU, because I have a clearly superior GPU available (Nvidia). I don’t want to settle for X, because I have a clearly superior API available (Wayland). I have a 4k OLED display, because if it is there, why settle for something worse? I realize that enthusiasts are rare, but it’s us who help iron out the bugs for the newest hardware, and it is sad to see such an alienating attitude from fellow cutting-edge developers.
The comment that Sir_Cmpwn was replying to litterally said "Nvidia is absolutely the only option, and it is everything else that has to adapt to it." Now that is the harmful attitude. Because you use Nvidia for CUDA doesn't mean that you need to use Nvidia for graphics. If you do choose to use Nvidia for graphics (despite a clear compatibility warning from the community), you shouldn't demand the graphics people to bend-over-backwards and "[have] to adapt to [Nvidia]."
And you, coffeecat, don't seem to demand that.
Pipewire approach looks the best for screenshots and video recording. I hope all Wayland compositors will settle on it.
> Secondary clipboard support <...> wp-primary-selection
I guess the standard is very recent. Last time I tried, KWin didn't support it yet.
> We fought long and hard over this and we now have a protocol for negotiating client- vs server-side decorations, which is now fairly broadly supported, including among some of its opponents.
A major problem with Mutter remains. Mutter developers don't want to depend on GTK for whatever reason, but so are SDL, mpv and other non-GUI applications and toolkits developers. The result are ugly looking windows for such cases in Gnome.
> You have to step up, though: no one working on Wayland today seems to care.
It's a problem with Wayland in general. The end user gets the short end of the stick, since with removal of some functionality that was in X, some use cases are cut off. But there is no one player like with X server. Tons of compositors are developed by different people. So even raising the issue let alone coming to some consensus takes a very long time.
I'm not saying Wayland isn't the way to go, just pointing out it's a very hard transition.
> Wayland doesn’t support Nvidia!
How is the progress of using Vulkan for Wayland compositors and avoiding the whole EGLstreams mess?
I see this: https://github.com/KhronosGroup/Vulkan-Docs/issues/294
But it's not clear from it whether now there is a way to avoid using GBM or EGLstreams.
Following your edit: yes, the new standard protocol for primary selection is very new. But everyone supports the GTK protocol and the transition will not be visible to users.
Dude, so many edits: "But there is no one player like with X server" -> this player is wlroots
Oh my god man, stop editing your comment: "How is the progress of using Vulkan for Wayland compositors and avoiding the whole EGLstreams mess?" -> hard to say now, it's very very early.
> this player is wlroots
One of the players still, since for example KWin isn't using it. I.e. it unfortunately came too late to unify the situation.
GTK is 100% designed to be a (Wayland/X/Windows/Mac) client. Shoving it into the display server is bound to end in disaster.
KWin have no problem using Qt, so I don't buy the disaster argument in general for such solutions. But may be GTK is a lot worse.
There's no avoiding GBM or EGLstreams, if you want a compositor, that can get a OpenGL/VA-API/whatever handle (as opposed to pixmap in system RAM) from the client and be able compose it on GPU (as opposed to being rendered by client by whatever means it wants, maybe transferred to system RAM, and then by compositor back to the GPU).
Then I suppose Nvidia should finish their proposed common memory manager, which looks stalled now.
On the subject of leaving the responsibility of taking screenshots to the Wayland compositor:
"for simple things using the compositor's screen shot tool is fine. But what if I don't like the screenshot tool for my compositor of choice? My experience with the GNOME screenshot tool (granted this was pre-wayland) was that it wasn't as good as, say, shutter, which has a lot of options, let's you easily crop and edit the screenshot from inside the screenshot tool etc. And then swaygrab doesn't even (currently) have an option to capture a rectangular region."
There are some other things "Why I'm not going to switch to Wayland yet" mentions which are important to me, like Wayland's lack of color picker tools and xdotool functionality.
The parent article says:
"Wayland doesn't have network transparency! This is actually true! But it's not as bad as it's made out to be. Here's why: X11 forwarding works on Wayland. Wait, what? Yep: all mainstream desktop Wayland compositors have support for Xwayland, which is an implementation of the X11 server which translates X11 to Wayland, for backwards compatibility. X11 forwarding works with it! So if you use X11 forwarding on Xorg today, your workflow will work on Wayland unchanged."
So why wouldn't I just use xorg to begin with?
Overall, Wayland just seems immature to me, and not a viable competitor to Xorg, which has had all of this functionality for decades. As an Xorg user, I really struggle to come up with compelling reasons to switch.
[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...
I addressed this in my article, please read it. And you can select a rectangular region on sway today, using tools which are portable across many Wayland compositors.
>So why wouldn't I just use xorg to begin with?
You can, no one's stopping you.
RDP on Windows works amazingly, it's really like having your remote machine at your fingertips (as long as network holds).
On GNU/Linux on the other hand, most solutions are hacky or cumbersome or non-standard or a linear combination of the previous adjectives.
I really wish I could have truly good remote desktop support on GNU/Linux.
There's also just regular old rdesktop, which seems to work pretty well if you're mostly connecting to Windows servers.
X2Go was cool and worked well, but support for various distro was a bit unclear (only Ubuntu? can't remember, that was like four years ago) as unclear was on which condition you could actually resume your session and how (what if I disconnect unexpectedly? how do I list my current sessions? Is there audio in/out forwarding? clipboard sharing?). The website homepage failed to address many of these questions, ultimately failing to answer the question "can I actually rely on this thing?".
You can't have a graphical, user-oriented, server and tell the user to "hey, just use a shell script and a control binary, and then hook a hotkey into your window manager and make it run that script". That's just not how user friendliness works.
Try to find a common ground between Wayland being secure and Wayland being practical.
Though Compositors may share libraries as well, and a unifying library might very well be developed for this.
I never had a problem, and if you upgrade the next time, check the hardware compatibility and buy what you need. Till then, just run a X stack.
https://github.com/doitsujin/dxvk/issues/806
If games are using SDL, you can also select Wayland using SDL_VIDEODRIVER=wayland. But there are some glitches still. I tried doing it for example with ScummVM, and it produced double cursor.
> All three are necessary for most Wayland compositors. Only the first two are implemented by the Nvidia proprietary driver.
Ok. But what about nouveau? Is nvidia supported using the open-source drivers (the only ones I will use) or are these drivers too lacking?
Are the wlroots developers completely disregarding nvidia-support over issues only found with the proprietary drivers, or are there actual unworkable nvidia issues regardless of driver used?
But nouveau has trouble supporting the newest cards currently, since Nvidia seems to try their best to make their lives hell.
So it should work with most of the setups until you’re trying to reach a certain performance threshold.
I’m not sure what scenarios are being invisioned here, but isn’t that absolutely something a nefarious app could do, because the app will be run as you, and you have write access to your bashrc?
As an example, since it’s fresh in my memory, if the folks who put dodgy cryptocurrency stealing code into npm packages had instead put this keylogger in there, that would have worked right? You run npm install, npm runs as you, the package runs as you, the package updates your bashrc.
Looks good ! Do you think fancy animations and tiling could be done (wobling, fading and swiping effects when switch from one pane to the other, etc.)?
I think sway is prety nice as it is but I would love to see a few things to make it feel "modern"
- round borders
- simple drop shadows
- a way to add small effects when opening/closing/selecting windows.
Anyway, I'm pretty happy on the current state, so thanks for the amazing work :)
https://www.youtube.com/watch?list=PLb7YRKEhWEBUIoT-a29UoJW9...
Something like that (notice how the resize is smooth and not instantaneous, which allows your eyes to follow movements but the left and right align are instantaneous and feel like something hit you from nowhere since you can't track the transitions with your eyes): https://streamable.com/wb36p
$ (kubuntu 18.04LTS default install, not tweaky tweaky) loginctl show-session 3 -p Type
Type=x11
https://bugzilla.redhat.com/show_bug.cgi?id=1399093
To be fair I remember video playback was waaaaaay smoother with wayland than X last time I tried. But this kind of bugs happened to me last year. I don't have time anymore for distribution tweaking, either the current LTS works or I pick up something else (that's why I don't mind running x or wayland these days: whatever works is okay).
I don't see how Wayland can succeed without supporting Nvidia. Yes, they'll have to write several thousand more lines of code, but if you're going to make a desktop environment in 2019, you're going to have to put in that effort to support the graphics card that most people have. It would be great if Nvidia had better Linux support! But they don't and washing your desktop platform's hands of the issue just makes the whole project DOA.
Are there any competitors to Wayland that don't take a hard-line stance against supporting the most popular and most powerful graphics cards in the world?
Also: it's possible to have a definition of success which excludes users of the proprietary driver. We don't have the same value system.
>the [...] most powerful graphics cards in the world?
Citation needed? And the highest of the high end graphics cards are excessive vanity most of the time, you don't need the tip-top to play any modern game at any settings you want.
This is a very dismissive attitude that embodies the problem with Wayland. Millions of gamers absolutely do need that acceleration they paid for, it's not "vanity".
> We don't have the same value system.
I just want a usable Linux desktop that leverages the hardware in my machine. The "values" here seem to be: we acknowledge the extra work required to support mainstream graphics cards, we just don't want to do it and it's really your fault as a user for buying it/asking us to support it.
>it's really your fault as a user for buying it/asking us to support it.
Yes, I'm soooo sorry that I don't want to do free work to help you prop up a company that lives to make me suffer as a developer...
I'm clearly exagerrating here but I hope the point is made. Like the article says, just keep using X, I don't care.
If you are wondering why people are pissed about wayland, its precisely awful attitudes like this that sweep aside their real concerns and use cases with broken ideas that don't work, have never worked, and likely never will work.
Don't expect people to be on board when you so blatantly don't care about their needs.
You can keep using X with Nvidia. It's not my problem.
There is a ton of dishonesty underlying your arguments, and you sure as hell don't do any favors for Wayland, or how people perceive it when you use dishonest bs like this.
I don't have a horse in this race because I still do all my gaming on Windows (literally the only reason I still have a win10 license), but I think this is generally true. Up until last year I was playing current titles on a GTX-660Ti on high settings (not ultra) and was getting very reasonable performance. I now have a 1070 and a 4k monitor and it can play all the titles I own on ultra settings in 1440p @ 60 hz. It can't really push ultra in 4k @ that refresh rate, but I think people who need those settings are a pretty small minority at this point. It's important to remember that the market for desktop computer games has taken a back seat to the console market for a long time. Many, if not most, current AAA titles are developed for consoles first, and consoles are all running hardware that is a couple of years old at this point. Anyway, keep up the good work!
Yes, Nvidia are not great when it comes to OSS, but like it or not, for doing real work in ML, scientific computing, or video and photo editing, Nvidia with CUDA is simply a much better experience and much more broadly supported.
While I don't think it should be the job of wlroots/sway to fix Nvidia's less than ideal driver chain, I think it is important to remember that a lot of people get a lot of productive work done on with Nvidia cards and would love to get rid of some of the pain of X while still being able to use their high end GPUs for both work and graphics.
It seems fairly clear with with MacOS focusing less and less on high end machines, there is a gap for high end unix workstations and hopefully desktop Linux can fill that gap, but right now that likely means Nvidia support... I think the best answer is just to buy amd and market forces will get Nvidia to change, but that still doesn't mean everyone can just go that path right now to get their day job done.
Fine. If you do these things, stay on X.
>While I don't think it should be the job of wlroots/sway to fix Nvidia's less than ideal driver chain, I think it is important to remember that a lot of people get a lot of productive work done on with Nvidia cards and would love to get rid of some of the pain of X while still being able to use their high end GPUs for both work and graphics.
I honestly just don't care. They should boycott Nvidia and find something else to do with their time if they really want better support from Wayland. I'm not going to bend over for Nvidia. Ever.
The people who demand change are wrong too, I am super happy people like you are doing what you do, otherwise this OSS thing really would never work.
But to be clear, while I think your stance is completely reasonable and justified, it is just a hard pill for some people to swallow. That doesn't mean that those who are jerks about it are justified, but it also doesn't mean that those who raise concerns, that those concerns aren't warranted.
It works beautifully with sway. Less so with KWin for me at least, although apparently NVIDIA are doing some work to fix that.
Reclocking support on recent GPUs is also a problem for anything that wants full performance - they really need to sort that out. I get that this is hard to do.
This whole situation is just really annoying and it must be immensely frustrating to be on the end of a lot of the complaints especially when the position of the sway developers not wanting to essentially write it twice just for NVIDIA support is totally reasonable.
As someone who hasn't bought a GPU in several years, but might be in the market for one soon, I have to wonder: what the heck is going on with Nvidia?
I remember back in the day, on Linux, they were the graphics card to get if you wanted the highest performance, and could get their proprietary drivers working reliably (I never could). But now they seem to be alienating even closed-source partners.
As someone who thinks any GPU made in the past 5 years is more than good enough, avoiding the Nvidia driver situation (on every platform) would be worth the slight performance loss of getting literally any other card.
Well, they should get their act together and work with the rest of the community instead. In KDE, people working in KWin said that they will not support NVIDIA for Wayland, unless NVIDIA itself steps in, proposes a change, gets it approved, and maintains it.
That's what they ended up doing so far, although the change hasn't been merged anywhere yet AFAIK.
FYI: most people have Intel GPUs. More than both AMD and Nvidia combined (Somewhere around 70%, AMD around 13% and Nvidia around 17%). Intel and AMD are supported, ergo for most people it works just fine. It could work with Nvidia too, if Nvidia were cooperative.
If so, I'm interested in how we can expect consistency; and eg. moving the window of an unresponsive application.
This could well be a misconception, which is why now seems a decent time to ask.
These seem to be good qualities of X. Wayland has been a number of years in the making, so I have somewhat lost track of my source of this information.
Edit: Apologies, I did read the fine article. It appears I must have skipped a section.
The core Wayland protocol doesn't do these things by design, but that doesn't mean end-users can't do them on Wayland compositors which support these use cases in the places that they're designed to be supported.
Which is why they shouldn't care that the core Wayland protocol doesn't implement it. These use cases WORK!
Somebody has actually done this!
Erik De Rijcke put together Greenfield [0], which is a Wayland compositor that relays surfaces with H.264 or JPEG over WebRTC. It is exactly as cool as it sounds, and it seems like it actually might work pretty well. It's the sort of thing that could be standardized, with a bit of work.