For me at least, this is a dealbreaker as I don't always get to choose the systems I get to use and I'd like to use the same config/wm everywhere if I can help it and if I sometimes have to alternate between i3 and sway then that won't do for me.
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.
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;
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.
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.
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.
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).
: 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.
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.
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.
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.
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.
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.
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?
You could always log in 2 graphical sessions and have one be running x and one sway I presume.
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.
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.
Being general purpose means that things like screenshotting capabilities are not the protocol's concern and should be implemented in the upper layer(s) instead.
In that case, this general purpose approach seems to me like the right way to tackle the problem, since we won't need a different protocol for use cases that fall outside the traditional desktop paradigm. You can just use Wayland and implement your own business code on top. There'll be a de-facto standard way to do graphics on Linux, no matter your use case.
Correct me if I'm wrong about this. I'm not a Wayland expert (I have many articles and books in my to-read list).
I'm excited about Wayland for the simple reason that I hate screen tearing.
Wayland is a good experiment, and the community may well go with it because X11 is atrocious and Wayland is a viable alternative. But call a spade a spade, they dropped the ball with that design decision. It isn't a big deal.
The practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as well. The required negotiation for that to happen is taking/going to take years and delay Wayland adoption. If they'd designed that at the same time as an optional part of the Wayland protocol it would have saved time and confusion.
Linux fragmentation is a real thing, but if the community is going to take multiple years to reach a consensus on the right way to approach screenshots, that does at least somewhat suggest to me that leaving it out of the base protocol may be a good decision. My understanding is that the point of Wayland is to be a semi-permanent solution to the problem of X11. Any mistakes we make in the protocol will haunt us for decades, not just years.
That concern makes me more likely to err on the side of reaching consensus before core logic is implemented, even though I admit that the fractured nature of the Linux community is likely to make process take a lot longer. I'm not saying that nothing should be standardized, just that if it looks like there's disagreement over implementation, it might be a good idea in this specific case to bias towards delaying a final decision.
Maybe they did consider all this and have a plan. But I havn't seen anyone write a "this is how you target arbitrary compositors with your toy screenshot program" article yet.
This is an odd application of that idea to me. In my experience it's not to terrible to punch holes in a system after the fact. Exceedingly difficult is patching the holes in a project that starts as Swiss cheese.
First of all, note that as with any window system, application buffers are not the final version of what you see on the screen. A normal desktop has wallpapers, transparency, task bars, multiple windows and window occlusion.
This means that apart from a few special cases, only the compositor knows how the full scene currently looks, and is the only entity capable of producing a buffer containing the entire thing.
For this reason, the only way to do screenshots is to have a way to ask the compositor for one. This is the case for any windowing system, and nothing related to buffer management will change that.
> ... that they didn't include a security policy mechanism for coordinating Wayland buffers
Depending on what you mean, this is either slightly or very untrue. Basically, when you try to present to screen, a client takes a buffer (which is private) and commits it to a surface. This temporarily borrows it to the server.
Should the server wish to share the buffer, this is when this would be done. Before doing so, the server would enforce any security restrictions as necessary. This is how all client-to-client communication happens in wayland: With the server as mediator, when it permits it.
A screenshot of a window or direct-scanout application could be implemented by simply having the server further borrow the buffer to a recording application, with appropriate restrictions in place.
> users really want applications to be able to snoop on each other when required.
I don't understand why you would think that this is a problem under Wayland. They only difference is that while X11 implicitly allows everyone to snoop on everything without any way to control it, snooping in Wayland is explicit, and servers can prompt users to permit it per application. Or not, it's up to the server.
This is not the intention under Wayland. Wayland protocol development is geared towards compositors implementing protocols for experimentation, and then basically "upstreaming" the result. Even before upstreaming, compositors share work (e.g. wlroots implemented at least one kde-specific protocol, that has now been superceeded by the resulting upstream work).
Also, all Wayland protocols are advertised in the registry, so applications don't do "I'm on KDE, so...", and instead just use the protocols available. It is therefore not a problem if KDE implements a GNOME protocol, for example. It'll just work.
Screenshot and recording will be a shared protocol, but due to wanting a proper protocol with goodies like damage tracking for performance, it's a little bit more work than you would think. We certainly don't want X's "dumb" approach—we want something faster and safer (that is, functionality guaranteed without tearing or fun stuff like that).
So we are going to reinvent X extensions from scratch? By the time that is finished we will have enough legacy bloat that people will call for the next replacement.
but, IMO, this is a good thing, and the only way it could have worked. if every single conceivable protocol was added to the initial specification, then wayland would never have been released. even if it was, people would complain even more about it being "bloated" and "non modular" and "not following the unix philosophy", whatever that means.
Windows switched to composited desktop with Vista in 2006 and didn't lose any functionality. 14 years later and we're still saying "eventually" when discussing basic features Wayland should have.
 Technically it lost a few, the ability to ignore vsync for non-fullscreen applications being the biggest one.
Apart from stability.
Jokes aside, this has nothing to do with the protocol as much as the fact that there are vast differences in how an open source project is developed vs. how Microsoft develops.
A lot of Wayland development was initially funded by Samsung, which mainly focused on usecases for their smart devices. They then shut down their entire OSS department, so that workforce is out.
Now, finally redhat seems to be gearing up a bit, with GNOME Wayland being default on Fedora, and sponsoring Wayland work on things like Firefox.
But, even then, things are powered by what people want and care about, rather than just trying to tick every previous feature box available.
I think the complaining is 10% real concerns and 90% people upset that it is different than it used to be.
Wayland on the other hand, it really does need to do everything well. If Zoom won't run in Wayland, needing to launch X11 to run Zoom means Wayland is broken.
Also, people love change if you have actual improvement. I was very happy to switch from sysvinit to runit.
Wayland does specify only two thing: how to exchange buffers between applications, and agree on protocol extensions.
Then, you can make the inner workings as many pieces as you want. The "no window manager" is a fallacy. You could decide to write a compositor that offers a protocol to manage the windows. I'm pretty sure you can more or less do that today if you use sway.
The one thing Wayland doesn't do is specify the 1000s of things X11 was doing, most of which are hacks upon hacks on interfaces that were not designed for the stuff people are doing with.
But it isn't. Have you ever tried to use X11 without any window manager? You can't! In the best case you can type inside a terminal that is not moveable or resizable. X11 can not function on its own, hence it can't be monolithic.
Just because it is bloated doesn't mean it is monolithic. And most of the bloat is old graphics drivers which are not installed on your system anyways.
I'm not really liking X11 either. Just like I switched from sysvinit to runit I would be happy to switch from X11 to the next best thing. But Wayland is not it.
The protocol is flawed on so many levels but most importantly because it does not provide the necessary interfaces required for normal, functional desktop and degrades them to "implementation details" (or in your words "1000s of things"). Just blitting bitmaps is not sufficient for a working desktop system. The biggest pain point is access control policy, which Wayland completely ignores.
A wayland environment basically has 3 "levels":
- Wayland core ("wayland")
- Wayland shared protocols ("wayland-protocols")
- Other protocols
Core only concerns itself with nitty-gritty necessities, like how wayland communication actually works. You cannot create a window with wayland alone.
wayland-protocols is where you'd find "xdg-shell", the protocol needed to manage windows on a normal desktop. Protocols here are optional, but are still a collaborative effort.
However, protocol development starts locally, in which case it starts being compositor specific under its own namespace (e.g. "kde"). If it gains traction, other compositors may implement the protocol as is. At some point, a shared protocol draft will be made under one of the "higher" namespaces, like "xdg" or "wp". KDE's idle protocol was widely implemented before a common one was developed from it, for example.
Screen recording is an example of something not yet shared. Wlroots-based compositors like sway fully support it, but details to improve the situation is still under development. An example of such development is to ensure that damage bubbles up to the screen recorder, allowing it to only process screen areas that are reported to have changed.
So, screenshotting is not something implemented in the "upper layers", but something that is currently specific protocols, that will at some point become an (optional) shared protocol.
It is also important to note that Wayland works through a protocol registry, with clients always knowing all protocols available, and using whatever they need if it is supported. GTK and Qt does all this for you, but there is no "If on KDE, do this", rather "I have a protocol that gives me this functionality".
It has always been—and still is—my impression that those considering wayland design "controversial" have simply misunderstood it, such as by thinking that it disallows screenshots and recording. Rather, it is designed to provide control over these things, and to do them right.
I have been using Wayland through sway for the past year. I can confidently say that anything I did under X, Wayland does way better. Multi-DPI, plug-n-play screen support without any hassle, tear-free low-latency rendition, etc. Knowing what is not done yet, I could provoke problems if I wanted to, but nothing interferes with my day-to-day operations.
I would prefer some kind of WebRTC-based screensharing solution, but I don't know of any that are preferred and many people just think of WebRTC as a security nightmare, and I haven't seen much momentum with it.
Are there any Wayland resources for even more technical information you'd recommend?
For the record I use sway for months and can also report that the experience has been great (including hotplugging multiple monitors over Thunderbolt etc.)
For example, with text rendering. Font path setting is not part of the core protocol (although there may be a XSET extension which can do this on some implementations), nor does the protocol specify font formats (PCF is recommended, but the protocol doesn't actually care so you can implement different formats if wanted). Characters are still sixteen bits, although to allow optional support for some more modern features, there are two flags you can specify when loading fonts: EnableLigatures and EnableAntialiasing. Servers that don't understand these flags can ignore them, and fonts that don't support them would also ignore them. EnableLigatures waives the requirement that a sequence of characters is the same as each of those characters put next to each other, and EnableAntialiasing waives the requirement that text is painted in the specified background and foreground colour only. (EnableLigatures is required to correctly render Unicode text with the X core text rendering system (if the server implements support for Unicode fonts, which is of course optional). Of course you are not required to use the core text rendering (previewer programs should not use it, for example), but if you do, and your program uses Unicode, then this will be needed. In effect, a surrogate pair is treated like a ligature at the protocol level (how it works in the actual implementation may differ, and is independent of the protocol).)
It’s hard to tease out, but it sounds like you’re advocating for the state of the art drawing model of 1980 in 2019. I don’t think this is going to fly except for a very niche audience.
It's a completely unsubstantiative argument; its effect is to sweep under the rug any justification for the 'old way' of doing things.
For one very big thing, hardware accelerated rendering didn't exist in 1980.
Also, no one really cares about network support anymore, because it's simpler and better to just do a screen share.
Then why the hell isn't it being used by GTK/Cairo nor Qt in production code. Oh yes, there are OpenGL(-ES) backends in both. But by far and large they're doing all their rendering on the CPU and then blit over to the graphics system. This is BTW the main reason for Wayland coming to be in the first place: The observation that the X server has been "reduced to a blitting engine" (if your world view is so narrow to cover only GTK and Qt).
And then they're draining the baby with the bathwater… Wayland is how old now, 9 to 10 years, and it's still far from usable for production. IF you compare that with X11, after 10 years it didn't have just a barely working server and some example application. It was a thriving ecosystem with multiple desktop environments, toolkits, loads of production applications and you could just run them all arbitrarily in the same environment.
Only last Friday I was working on a custom windowing library (something in the same vein as GLUT, SDL or GLFW, however with a focus on "desktop" programs with traditional GUIs instead of things like games) and whenever I start working with the Wayland side of things it turns into a severe headache. Wayland is an actively developer hostile (and I'd even wager to say user hostile, too) ecosystem. For example, because in Wayland there's no concept of windows, and whatever a window is, is left to the compositor, you can't even properly implement something like dockable windows. The best hack I could come up with was via the drag'n'drop mechanism that Wayland then does specify.
IMHO Wayland is a prime example for the sunken cost fallacy hitting hard.
Actually, some of us do make use of X11 network transparency on a regular basis. Running an X11 program on a remote CPU, but having its window appear on the screen of the machine I'm sitting in front of, is quite a useful feature. And one that I make use of quite regularly. And it is most definitely not the same as a 'screen share'.
> Is Wayland network transparent / does it support remote rendering?
> No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
Note that the next two paragraphs do discuss how network transparency could be built, by clients, on top of Wayland.
So it depends on how you define "does wayland break X-forwarding":
If defined as Wayland, the new server, yes. Because network transparency is not built in to Wayland the new server.
If defined as Wayland, the ecosystem, well, there appear to be ways to do it by adding it back in.
ssh -X still works and wayland native is waypipe ssh (though one could probably wrap that into ssh -X to make it seamless).
I care about network support for GUI applications.
I don't think _whole screen_ shares are either simpler or better.
Give it a try and let us know.
Let me guess, you live in a city?
On the other hand xlib toolkits like xathena widgets run blazingly fast even over modem style connections because all the drwaing happens server side and only a limited amount of drawing commands are transmitted over the network.
I've used that feature every single day for the last 20 years.
Take for instance a big 3D game. It is much more bandwidth-efficient to compress the frames and send that over than to send the 3D models, textures and transformation matrices over the net. We still don't have PCIE Gen. 4 bandwidth for networking.
Okay, this is an extreme example. But most apps (just take Firefox as an example) send bitmaps over X forwarding anyways. I use Xpra for these, but waypipe should work a lot better, in theory (less round-trips, etc). Of course, it's better if the graphics toolkit is install at both ends and can render the stuff locally (which was the intent with X). AFAIK a few support that, I wonder if rdp doesn't specify something to negotiate its use on a per-client basis?
The GP was suggesting “without extensions”. Good luck with that.
(I also think modern fonts don't look nice; I want to use bitmap fonts on the screen!)
Also, on server implementations that support SCM_RIGHTS (the core protocol would have some way to check), it would be possible to pass a file descriptor opened with shm_open() to the client and share memory that way, if the client and server are on the same computer. In this way, direct rendering is more efficient than it is with the X11 core protocol.
I said a lot like the version 11 core protocol, not exactly like it; in what I am thinking there would still be many differences, although many things are similar (because I think much of it is good).
OK, I looked, and I think you are right; DRI is better. It would work with what my ideas are (and I think SCM_RIGHTS would be used for this purpose too). Handling resize though would just be you can continue to render a picture of the old size and it will be cropped (or if made larger, the X window background will be displayed in the part outside of the DRI picture), or else it may handle the resize event to close the DRI handle and open a new one with the new size if needed.
The protocol would still be independent of the implementation, though. But because DRI involves system-dependent features, this means that the use of DRI is not fully defined in the core protocol. However, that shouldn't be a problem.
Lots of people have ideas for an "X12" that turns out to be stuff already supported by the X11 protocol. Not enough people know about the true problems with X11, or have ever asked us Linux developers think about what needs fixing (hi, I'm a long-time Linux graphics contributor and co-wrote a large part of the Wayland spec). X11 extensions have not been a major problem in 25 years.
Whenever I find myself reading about X11's history my conclusion is always that you guys are heroes. A small group of people keeping an ancient behemoth alive, dealing with plenty of legacy of the kind that drives people to quit jobs.
And when you finally decide you've had enough and go for a rewrite... people shit on you and everyone suddenly knows better.
Again: thank you!
That is true, although many of them are messy in X11. One of these is that the protocol and implementation are tied together more than they should be (one of these problems is server configuration requests, which I think do not belong there). Some of my ideas are:
- Timestamps. The way timestamps work in X11 is messy. A better way is 64-bit timestamps with an unspecified rate; what is specified is that timestamps are monotonic; i.e. if any two requests/responses/events use timestamps, the later one is guaranteed to have a larger number as its timestamp. (However, timestamps might not always increase when the server is grabbed; this is implementation-dependent.)
- Font path configuration. This should not be part of the core protocol; it improperly exposes the directory structure and the font formats. (I do suggest a XSET extension, which is optional, and what settings they set and how are implementation-dependent; the "xset" command would pass its arguments (except -display) to the server, which returns the text which will be the response. This makes it completely general, but a separate specification would provide guidelines for consistency, although not strictly required.)
- Screen saver configuration. I would have the core protocol has only two things dealing with screen savers: the screen saver event, and the suppress screen saver flag in window attributes. If the suppress screen saver flag is set on any mapped window, then the server should suppress the screen saver. Other than that, how the screen saver is implemented (if at all) and what it does is implementation-dependent, and probably configurable by the user.
- Mouse cursor shapes. My proposition allows the server to substitute its own full colour cursor of arbitrary size and opacity (and maybe even animation) when a client requests a font-based cursor shape (either the standard X cursor font, or some others, depending on what the implementation supports), unless the user disables this feature. Whether or not this is implemented is implementation-dependent, and it is completely independent of the protocol. (Whether or not you get the same image as you would by loading the cursor font with EnableAntialiasing and rendering that character, is also implementation-dependent.) (Substituting cursor shapes is probably not a feature I would use (I like the standard monochrome cursors), but some users will like it, especially those with very high resolution displays.)
- Bells. The core bell request should instead be like XkbBell() (although none of its variants (such as XkbDeviceBell and XkbForceBell etc) are possible). The only thing the server is guaranteed to do is to send a bell event if any clients care; what else it might or might not do is implementation-dependent and would probaly be configurable by the user to some extend. (For example, it may be configurable to suppress the audible bell if the bell event is requested by any client.)
- Allow different screens to have their own keyboard, or to share. Same is true of the mouse, and there may even be more than one mouse per screen (this is to support touch-screens; I don't like touch screens, but some people like it). Clients that don't care can ignore the field which specifies which mouse the event is.
- Use only one endianness rather than two in the protocol, for simplicity. The first byte is "X"; this also enables the possibility (but not the requirement) that a server implementation might support both X11 and X12 clients using the same socket, since you can distinguish between them.
- Some additional standard mouse cursor shapes (in addition to the ones in X11). The cursor font and "Fixed" font are the two "highly recommended" fonts to include in the system. (Some of my suggested new standard cursor shapes include: XC_arrow_plus, XC_arrow_minus, XC_magnify, XC_magnify_plus, XC_magnify_minus, XC_chaos, XC_invisible, XC_stop, XC_no_smoking, XC_xterm_lazy)
- The -retro option should be the default.
> - Timestamps. The way timestamps work in X11 is messy.
Well, yeah. Distributed timekeeping is messy. Clients can already retrieve the server's timestamp and keep a rough approximation of what's going on (I wrote a server time estimator for GNOME/mutter). Not sure how you'd fix it. Wayland replaced timestamps with serials.
> - Font path configuration.
Are you familiar with XSETTINGS? It was supported for many years in the toolkits, and got basically no traction.
> - Screen saver configuration. I would have the core protocol has only two things dealing with screen savers: the screen saver event, and the suppress screen saver flag in window attributes.
If you want to propose this as a specification, you're more than welcome to do so -- some sort of EWMH hint like _NET_WM_INHIBIT_SUSPEND or similar. Write up a spec and mail it to wm-spec-list. But you'll probably be told about to use the existing screensaver inhibit spec instead:
> - Mouse cursor shapes
A client can already arbitrarily get and set the cursor image for a given cursor name with the XFixes extension, including setting RGBA32 cursor images.
> - Allow different screens to have their own keyboard, or to share.
XInput 2 supports multi-seat just fine.
> - The -retro option should be the default.
Not sure why this requires a whole new protocol version, just compile your X server with it on by default, or configure your display manager to set it.
> A client can already arbitrarily get and set the cursor image for a given cursor name...
That is not what I am suggesting at all. My suggestion is: The client only specifies a monochrome cursor, possibly from a font; the server MAY substitute a (possibly animated) RGBA32 (or other colour type) image (for a font-based cursor) IF the user has enabled that feature in the server configuration file.
> Not sure why this requires a whole new protocol version...
Indeed, that is independent of the protocol. I just think it is more useful, is all.
This is especially true for modern displays which have some limited support for variable refresh rates.
Let's assume Mozilla finishes servo (their browser in Rust). Let's also assume:
- It's faster than Firefox.
- It's safer than every other browser out there.
How do they get people to use it? Those two are not enough. To the user:
- It's different.
- Firefox feels plenty safe.
This is a real problem and Mozilla faces it now. As a result, they're focusing on what they can do with servo which no browser has done before, like superb VR support. In short, they need features to gain users and they recognize that. Marginal gains are not enough to encourage an entire product switch.
Back to Wayland. Aside from the lack of screen tearing, what can we all agree are big wins for the user? I haven't tried it yet (for this reason), but everything I've read suggests that it could be safer, it could be faster, it could bring some more new features, but mostly it's the same shit.
The masses, and this definitely includes the GNU/Linux using masses, need more than the same shit to change because change is tough. They are going to need something killer from Wayland, or another competitor, before they give up on X.
I think it’s amusing that that opinion is so common given how bad X is. Mac OS X was developed in the nineties and has a jank-free hardware-accelerated compositor. Windows vista also had one, as well as every windows version after that.
I am certain that I’m not the only end user who notices the difference between smooth animations on those other OSs and what you see on X.
Wayland may be incomplete but it’s obvious that it solves some of these issues.
It's usually a driver configuration issue if you have tearing.
None of these need to be animated and even if they are not animated they can be disconcertingly janky under X. Tearing is even worse/more obvious if screens are rotated into a portrait orientation.
Then why does every popular desktop/mobile OS/app have UI animations?
Playing a movie produces moving pictures on a monitor? Great!
Tearing? Without telling them, they'll hardly ever notice it.
Users might not consciously call out screen tearing but they absolutely can tell when something runs smoothly. Just look at the reviews for iPhone vs Android devices in the early days when Android felt more like X11 with jank, frame drops and redraw glitches.
Then look how much time and money year on year Google spent fighting that jank. Money well spent.
And the irony is, that early iOS used animations to hide latencies when changing application state. These animations were the cause, why it was considered so smooth.
Then having a tear-free desktop is going to be something you strive for.
I upgraded every part of my setup which I needed to, just in order to be able to run Wayland (via sway), and I have to say I absolutely think it's worth it.
The end result is, hopefully, less bugs, more security and more performance, however most people wouldn't care anyway (and I think most people doesn't care, for example Fedora uses Wayland by default).
For us using window managers like i3wm the history is different. However in i3wm I am very close to the X11 so there is almost no abstraction, this is why the transition is more painful.
i3 users have sway. Good for them. Now what about every other window manager?
the xmonad dev for example has stated it's flatly not possible to "refactor" the project to use wayland... which means i'm not using wayland.
I'll continue to use X because I don't find it very broken. That's a problem for you?
I do however have a problem when open source introduces dependencies on buggy software written by aggressive narcissists, so yeah, I'm in the anti-systemd camp, or, put myself there when it started hanging a bunch of my Debian machines at boot when they made the switch. Pulseaudio was similarly garbage.
For WMs, it is more uncommon since they're so coupled with X11 specifics that this makes porting harder. However I don't really think it is a problem, if you want to continue using your WM it is fine, it is not that X11 is going away either way.
I have tons of scripts that does specific things and are heavily coupled on how X11 works. I need to port them to Sway first.
it wasn't exactly a drop-in replacement for me, but with a bit of modification I was overall pretty pleased with it, and subjectively it did feel faster.
> - It's faster than Firefox.
> - It's safer than every other browser out there.
> How do they get people to use it
> Those two are not enough. To the user
If Mozilla wanted to take the route of switching people from Firefox to a new browser, they would presumably do it by gradually stopping development of Firefox. This is basically the strategy that Microsoft is taking with Edge, with the obvious difference being that it's a browser that comes pre-installed on a common OS, although I'm not convinced that the strategy would need to be fundamentally different.
That being said, as sibling responses have noted, I think the strategy that Mozilla has been taking has been to just move over components into Firefox itself when they're ready. This has already been done with a few important components, and it seems to be working fairly well.
For it to take over it must be shipped by default by all major distros and people need to have time to upgrade after it becomes the default.
This means switching to Debian 10+, any recent Fedora, Ubuntu 20.04+.
Based on this one would expect the majority of users to be using it by 2025
Sway isn't i3 rewritten it's not even the same developers. I3wm is its own active project with their own developers that will continue indefinitely.
From what I remember, Wayland makes it easier to mix 4K and HD displays without pain.
As long as it implements X, I don't mind, but my understanding is that the change is a breaking one.
It seems Wayland isn't going to be the default in Ubuntu 20.04 LTS, but if it wasn't for the risk of Wayland I would be on the non-LTS releases. At least Guix exists now so staying on LTS (released every 2 years) isn't that bothersome in terms of easily avoiding out-of-date software.
Would you be willing to share that? Pretty please?
(1) They aren't going to go out of their way to switch from X11 to Wayland. Many users don't even know (or care) what those two things are. Or they do but they don't see the required effort as justified.
(2) Users also aren't going to out of their way to change the default that their Linux distribution supplies. Not unless there are issues that are bad enough to warrant expending that effort. If it defaults to X11, they'll use X11. If it defaults to Wayland, they'll use Wayland.
The major risk I see to Wayland adoption is if distros play it wrong and default to Wayland before it's ready for prime time. If that happens, then users will get a bad taste in their mouth, and their indifference will get replaced with a preference against Wayland. And it will be hard to erase that preference because even if you fix all the issues, they will still remember that time when they tried it and it caused them problems.
Fedora has been defaulting to Wayland for several releases now. RHEL 8 also defaults to Wayland.
However, these distributions are probably not used by users, who consider their spacebar heating critical to their workflow.
call it Firefox v100 and automatically update
Regarding screen capture: wl_roots actually supports this, but WebRTC doesn’t support the wl_roots protocol for it. I’ve been told Pipewire should solve this problem eventually.
Edit: accidentally wrote Waypipe instead of Pipewire. (Waypipe is cool too, though.)
There's at least one other option in the running, Arcan: https://arcan-fe.com/
a) generally usable as a daily driver; and
b) maintained by enough people that there isn't a single point of failure.
Right now I'm still on X.