Their standard, EGLStreams, is only implemented by their proprietary drivers, so in order to test that codepath we'd have to use a famously broken and undebuggable driver, which we're not interested in - and make no mistake, we get our hands dirty in the drivers all the time. Their standard also has serious technical problems - lots of really important features simply are not possible to implement based on the proprietary driver. We can't export buffers to clients, overlay planes don't work, buffer presentation timings are impossible... Supporting this driver would be a massive overhaul and would probably make the good drivers worse.

Sway is a volunteer project, we are under no obligation to put in free work to support a GPU vendor which has no interest in playing nice. It's total bullshit that anyone would think to blame the small group of volunteers who have offered up thousands of hours of our free time to the community, for free, when the real blame lays in the hands of the multi-billion dollar company which refuses to pony up docs and cryptographically signs their firmwares. Everyone else plays ball and works with upstream on open source drivers.

They've been called 'the worst company to work with' by the Linux kernel devs and are locking their GPUs down with signed firmware. Nouveau driver development is no longer possible for GM20x and newer GPUs because of this.

> --my-next-gpu-wont-be-nvidia

Since then I just decided that no matter what, GNU/Linux is not the platform for anyone that actually cares about desktop graphics programming.

So much for "supports".

And regardless of how https://github.com/RadeonOpenCompute/ROCm pans out, at least you're not sinking skills into a proprietary jail.

I’ll stick with i3 and probably look for something different in the future.

The examples that were easy to find again; https://github.com/swaywm/sway/issues/1207#issuecomment-2984...

https://github.com/swaywm/sway/issues/829#issuecomment-32683...

Sway has quality man pages, and I very rarely have to find someone else in a chat room or fire up the web browser to find answers. I can understand the devs' frustration: they spent a lot of time writing those up, so have people use them.

Give someone an answer, you'll help him for the day. Show him the man, you'll help him for life :)

I understand that devs have to deal with a lot of "dumb" questions, but that doesn't mean they have to be rude. As someone else said, silence would actually be better in this case, but a better response would be something like "hey, that's in the manual, in the blah section" because its not rude, it affirms that it is, indeed, in the manual and gives me a pointer where. Even without the last bit, it would be better. Part of good support is to acknowledge that the person has a problem, even if you can't help. If you don't want to provide support for an open source project (as in the case of the linked issues) then don't respond or at least set up a replacement to turn RTFM into something a bit more human.

> I found the answer valid, because I couldn't find the manual before.

How did RTFM help you find the manual if you didn't find it before, aside from affirming that there is, indeed, a manual?

RTFM is sometimes a valid response, and if you're having an issue finding the documentation then that's a bug.

It's this philosophy that made the ubuntu support forums the most agreeable (and pretty much most popular), at least for a while. You can RTFM people, but then you show that you hate your users, and they will leave.

Not only the people asking, but also others reading it. Like this example shows very well. This bad comment not only made d0ugal search for a different project, but also made sure I won't use it, and worsened my opinion of the author considerably.

It's extremely wearing having to deal with people with a problem who have apparently put precisely zero effort into figuring the problem out on their own.

"RTFM" isn't always a useful response, but I have sympathy with people who express it and its friends ("Have you read the manual?", "What have you tried to do to solve this problem before asking for help?").

RTFM is not going to make for happy users, but volunteers for free projects have the luxury of being able to ignore disgruntled users. If they don't want to maximise their user count then they have the luxury of being able to do whatever they like up to and including not having a bug tracker and literally hurling abuse at people who ask them questions.

We aren't entitled to professional and comprehensive support just because the project happens to look well run.

No one is entitled to anything, including free support. Many open source developers provide free support, but don't have the patience to deal with users who won't even do the bare minimum to help themselves.

Which is fair. A lot of FOSS devs, however, do. And then they still try to pull "it's free" as an excuse for a poor product.

If you feel like neither of them deserves a RTFM, I think you have a very entitled view of being a user, and personally I will never want you as a one for the software I write.

RTFM is a perfectly justified answer to people that consider that a developer's time in replying to their problem is less valuable than their own in searching for a solution. Exceptionally more so when the answer is an "apropos" or "man" page away. The least thing a user can do is to spend a fraction of the developers' invested time into finding solutions on their own.

Is it the category of response, or is it just the simple "RTFM" that turns you off? That is, if the answer was, "The answer to your question is in the manual; please read it", would you consider that ok?

Arguably the latter answer is the exact same thing in content as "RTFM", but it's easily more polite and doesn't have the same negative baggage.

If you're ok with the more wordy answer, then you're really just objecting to the negative tone and lack of politeness, not the amount of information given by the answer.

> This bad comment not only made d0ugal search for a different project, but also made sure I won't use it, and worsened my opinion of the author considerably.

Just a final note: many open source developers consider that a feature, so I doubt you'd sway most of them with this argument. As in, they're doing this in their spare time, and don't want that spare time to be squandered by people who don't even give them the courtesy of reading the provided documentation. (This is why, if you have read the docs and are still at a loss, you should say so: "How can I do X? I read through the man page and searched the wiki, but I wasn't able to figure it out". Framing your request this way shows that you aren't just a lazy leech who is wasting the developer's time.)

Having more users is only great if they aren't a support burden. A company can afford to hire scores of first-line support and afford to pay for support-desk platforms that automatically help triage and suggest answers to common questions. Most single-person and small-team open source projects can't do that. And users should not feel entitled to free support for software they haven't paid for. Sure, it would be great if people could always be courteous and friendly despite stress and overwork, but everyone has their limits.

> Just a final note: many open source developers consider that a feature, so I doubt you'd sway most of them with this argument

See the reaction in this comment thread. Developers rarely do only one project. One might not care whether or not someone uses the free Window Manager, but if the negative impression carries on to other and commercial projects there was harm.

"We" who? That's just your opinion, not some universal rule.

> Developers rarely do only one project. One might not care whether or not someone uses the free Window Manager, but if the negative impression carries on to other and commercial projects there was harm.

Perhaps, but I think we should let developers make the decision for themselves as to how to support (or not support) their own software that they work on for free in their spare time. If providing bad support hurts them in other walks of life, that's still a choice they may decide to make.

> Perhaps, but I think we should let developers make the decision for themselves...

That's not a useful route to discuss, and frankly a bit annoying. No one is forcing devs to do anything. If you think discussing the consequences and why that behaviour is harmful is making it impossible for devs to make decisions for themselves - that will sound harsher than I mean it - you shouldn't engage in such a discussion.

YES.

What surprises me are people who have the patience to wait for somebody else to tell them why their app broke, when it's much quicker dealing with problem just by going straight to the source. (pun intended)

If the amount of typed characters is the issue, I assume developers are more than capable of using system-wide text-expansion.

In any case, even silence is better than "RTFM". If you're not in the mood to give a civil answer, take some time off. No one will notice.

Two days ago, I tried to get a vim plugin working. After trying the instructions over and over for about an hour and a half, I finally gave up and opened a ticket with a question that probably looks pretty lazy and dumb to someone experienced with it. Did I get an RTFM? No, it turns out there actually WAS a bug (actually, a bug and an undocumented setting). I almost didn't post out of fear of being called lazy or whatever and just give up on it, but it turns out there actually was a problem. They fixed it and I'm now a happy user and the positive experience makes me more likely to report future bugs, tell others about the tool or even contribute if I can. An "RTFM" would have driven me away forever.

Then when you ask, demonstrate that you've done so.

"Hey, how do I do X? I read through the docs, googled, and tried everything I could think of but I'm still stuck" is likely to get you a decent answer.

If you're going to ask someone working for free to give you free support, the least you can do is demonstrate that you've done your homework. The unfortunate reality is that many users do not do this and just want someone else to hand-hold them through everything.

I agree that it'd be nicer if developers would remove "RTFM" from their lexicon, and, even if it provides no more information, go for something politer, like, "the answer is in the manual; please read it". But people get tired, people get frustrated, people have a bad day. And some people might do it deliberately to push away users who they think will be an unproductive time-suck for them. As someone benefiting from someone else's free labor, you are entitled to nothing. Suck it up and do your best to show that you're not a leech and that you'll do your part to support yourself, only asking for help when you've exhausted the usual avenues.

1. Install texpander (https://github.com/leehblue/texpander)

2. $ vim ~/.texpander/RTFM

3. Paste this text: "Please search the documentation before asking and opening issues." Press ESCAPE, followed by ":wq<return>"

4. Add a handy keybinding to "texpander.sh"

5. Problem solved! Now you can RTFM all day long without bothering anyone!

There are countless reasons for why these things happen.

Linux community on other hand wants nVidia to restructure their driver just to fit Linux model and essentially lose the source parity or publish the source completely. It's not an invalid request, because nVidias APIs don't really fit into Linux kernel design and userspace APIs. It's also not very likely to happen, especially due to poisonous behaviour of kernel maintainers towards nVidia, unwilligness to compromise and nVidias refusal to add more resources to refactor the driver.

Please, there is nothing to compromise about.

Nvidia doesn't want to work with the kernel community. They don't want to document how their driver works. They don't want people to look at how their driver works. They don't even want people to develop alternative drivers for their cards.

Nvidia earned 100% of the bad blood existing between them and the kernel community. They are even worse to work with than Qualcomm. Should give you an idea of how bad they are.

No, it's just a matter of economics.

Linux does not, because they want all drivers to be inlined (included in the kernel) and open source. nVidia does not want to release their trade secrets, so they don't want to open source their drivers.

(No idea about macOS)

I'm not sure what AMD really managed here.

https://www.phoronix.com/scan.php?page=article&item=rx590-li...

Last I heard, people were installing Linux to use the AMD OpenGL drivers to play emulators (it might have been Cemu, actually ran trough wine).

[1]: XDC2019 slide deck https://xdc2019.x.org/event/5/contributions/334/attachments/...

I thought these were hardware companies.

Seriously though, one of the pleasurable things about using macOS is that you don't have to worry about hardware compatibility. Because there is none, outside the small list of parts officially supported by Apple itself. There are some NVidia cards on that list, yes.

Sure this is almost true, but not quite - there is obviously Linux specific code to support X11 and VDPAU that isnt in the Windows driver, for example. Of course, NVIDIA can decide to not support open drivers, or not support Wayland in their closed drivers, and as a consumer I can choose not to buy their products.

Linux has modules, and had very good support for out of tree modules.

The same is true of AMD, they share most of their display configuration code (in the kernel) and userspace code between a set of drivers on Windows, Linux, and macOS; they just also publish documentation and redistributable firmware, and maintain a second very-high-quality driver in Mesa, and due to the availability of documentation and that Mesa GL driver, there is a second Vulkan driver (RADV) which is also excellent.

I think one of the biggest failings of wayland is that it requires so much duplication of effort between different compositors. Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card.

That would require a single standard for communication with GPUs and the problem is that Nvidia is refusing to implement that standard.

Wayland doesn't care how you draw your buffers, and a custom EGL library as they already do, while gross as hell, is not at all a compatibility problem.

So what your are saying is that NVIDIA could have just sent them a crate full of low end $50 dollar hardware and been done with it? I find that rather unlikely, or rather as an end user I prefer to think that there wouldn't be that much drama over what amounts to nothing.

But, either way, having two completely separate graphics code paths means a much larger maintenance burden than one. Even with hardware to test on, I'd consider it perfectly reasonable to decide to only support one, especially if the odd company out is one with a history of not playing ball with the community.

Nvidia's platforms are a large part of industrial embedded, on which the users have no option but to use EGLStream.

The nvidia driver doesn't play well with some basic apps, but it plays extremely well with games and other professional apps running on Linux (the whole reason for nvidia to put up a driver)?

It doesn't matter if AMD sells the exact same GPU as nvidia, because when you then switch BLAS for cuBLAS, the nvidia GPU becomes 100x better than AMD.

And that's just libraries, there is also tooling, engineering support, and well, software in general. Nvidia invests a lot of money on making sure that their GPUs come with a great proprietary AMD-incompatible software stack, and in integrating this stack with anyone developing products using GPUs.

I've worked on a couple of national supercomputers using AMD hardware, and AMD pays for ~1 AMD engineer full-time that works on improving the applications that run there. Nvidia pays for a couple of engineers that manage and tune the cluster for you, and a bunch more that work on peoples applications. Easily, 10x more engineers than AMD.

Even if AMD were to build better hardware, no sane industry person would pick them up over nvidia due to all other services nvidia offers.

In case of Wayland it was was opposite. It was developer by everyone, but Nvidia. Open source graphics stack developers found a way that work best for their hardware and supported it for decade. Recently Nvidia tried to join the parry while extending it with own incompatible addition that no one else needs. Obviously many open source proponents dont give a damn about their closed drivers so they only going to support primary APIs.

Sadly this is more or less the norm and in my eyes the source of the large disconnect between people who believe in things like "linux desktop is for everyone" and actual average users. Nobody wants to read a long principled rant when they're looking to actually use their computer.

Companies that build software can afford to hire dedicated people to deal with particular hardware configurations, and usually make revenue-based decisions on what to support. One-person shops only have what they have.

Why does nvidia get the pass here? They've decided not to support the standardized graphics driver interface that Wayland needs to work. They certainly have the money and developers to do so if they wanted to. Presumably they've made a decision not to based on (lack of) expected revenue.

Why would you begrudge an unpaid volunteer to make a similar decision about what to support in their own software?

It's rather nvidia proprietary driver that doesn't support standard Wayland protocols and thus doesn't work with Sway not the other way around.

See this for details: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html

Also, porting proprietary drivers for Linux must be a pain because there is no driver API and you cannot just release a closed-source driver and forget about it, you have to open source it and maintain it forever. No wonder manufacturers don't want to bother with this.

If you're NVidia user you're justified to feel bad about this entire fiasco but remember protocols exist so that everyone implements their own part and users can mix-and-match and it works together.

If AMD and Intel can dedicate resources to maintain their Wayland implementations with no complains why NVidia can't?

> why Wayland developers don't want to write an adapter for NVidia's proprietary API

Because they could use the time spent on maintaining NVidia proprietary API adapter writing open-source software that will benefit all parties.

nVidia shares the driver with Windows, AMD/Intel don't. So AMD/Intel always give you a driver that's significantly trailing the Windows versions on features and stability (you can read a lot about this on Dolphin blog for example) while adding more maintenance costs.

> Because they could use the time spent on maintaining NVidia proprietary API adapter writing open-source software that will benefit all parties.

What do you mean "all parties"? They're excluding at least one party - nVidia users.

"They" being Nvidia here. AMDs amdgpu driver clearly shows the problem is neither Linux nor Wayland or Sway.

Please elaborate more. I'm writing this from my Dell XPS 9575 with Vega M GL under Fedora 30 and I haven't encountered a single problem in GPU-accelerated applications and games with official open source drivers.

I mean all parties that implement the standard protocol. It's rather nVidia that's not interested in giving their users a chance to use properly Wayland not Sway developers "excluding users" by not doing free work for nVidia.

However, yes, the naming of that flag is a red flag. It tells me "this developer thinks that because you use their software they are entitled to tell you how to use your computer", which is an attitude I cannot abide.

You could always log in 2 graphical sessions and have one be running x and one sway I presume.

I mean it worked wonders the first time, considering that's how we got the Nvidia proprietary driver to begin with.

Could you elaborate a bit? I don't buy nvidia hardware and don't follow them at all these days, but I very well remember using the proprietary driver back in 2008 or so. At the time, it seemed to me to be the only well supported high-performance graphics driver.