Are We Wayland Yet?(swalladge.net)
swalladge.net
Are We Wayland Yet?
https://www.swalladge.net/archives/2019/10/14/are-we-wayland-yet/
376 comments
Maintainer of sway and wlroots here. The Nvidia proprietary driver does not support sway, not the other way around.
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.
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.
I appreciate what you do truly, but It's also perfectly understandable that we consider it a major reason not to use your software and a perfectly fair criticism of the choices you have made. Your rebutal has not changed the main point of the original poster at all, If you want to ignore 70% or more of Linux users that is perfectly your right to do so, but it's also my obligation as a long time Linux user to recommend that people avoid your solution in favor of i3 on X11 or a superior solution such as gnome or kde which understands the basic problems the overwhelming majority of it's user base faces and is willing to work with them regardless of the hurdle.
Nouveau works great with Sway. Users make a choice to use proprietary drivers, they aren't forced into it. They can buy more freedom-respecting hardware, too. It's a choice to reward Nvidia's behavior, and consequently that choice alienates them from our userbase.
Some high-end CG applications do not work acceptably under nouveau. If I must use those applications for my job, and thus must use the proprietary Nvidia driver, then I will. It is NOT my choice at that point, I am effectively forced into it. I wish Nvidia were nicer, but I also have to do my job. And no, using a non-Nvidia video card isn't an acceptable solution either, in some cases.
Nvidia doesn't have 70% share of linux desktop by any chance. If anyone, that would be Intel.
It's not just the Wayland/EGL stuff with Nvidia.
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.
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.
Hence...
> --my-next-gpu-wont-be-nvidia
> --my-next-gpu-wont-be-nvidia
I though I was doing a good deed buying a netbook with AMD CPU, because of their FOSS love and such, then they decided that Brazos APUs aren't worth supporting beyond basic features.
Since then I just decided that no matter what, GNU/Linux is not the platform for anyone that actually cares about desktop graphics programming.
Since then I just decided that no matter what, GNU/Linux is not the platform for anyone that actually cares about desktop graphics programming.
Brazos is 2011-era, right? amdgpu has become a thing since then - AMD now officially supports their GPUs on Linux, including those in most APUs.
Except that it doesn't provide the same OpenGL features and hardware video decoding as fxglr.
So much for "supports".
So much for "supports".
I recently built a new PC and my GPU was a Radeon RX 5700 for exactly this reason.
Way ahead of you here.
And regardless of how https://github.com/RadeonOpenCompute/ROCm pans out, at least you're not sinking skills into a proprietary jail.
And regardless of how https://github.com/RadeonOpenCompute/ROCm pans out, at least you're not sinking skills into a proprietary jail.
After trying Sway recently I read a bunch of github issues when debugging. I was disappointed to find many the comments toxic.
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...
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...
Ugh I also find that really offputting. Worse still is it’s the same guy behind SourceHut. Now I need to think about whether I want to continue to use that since if I need help the last thing I want to hear is RTFM. I always do but that doesn’t mean I don’t miss things and need a pointer :(
To be frank, drew answered me RTFM once regarding one of my sway questions. I found the answer valid, because I couldn't find the manual before. As sad as it is, many projects do not ship a man page, which makes it very difficult to find documentation.
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 :)
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 get it, but when I reach out for help, its because I wasn't able to figure it out myself and I likely put a significant (relatively speaking) amount of time into it. If its in the manual, it means I overlooked it and could really do with a pointer. If I'm just told RTFM, that leaves a very sour taste.
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?
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?
idk, those examples seem justified. The second one was someone ressurecting an old issue with a request for config information that was _in the issue_.
RTFM is sometimes a valid response, and if you're having an issue finding the documentation then that's a bug.
RTFM is sometimes a valid response, and if you're having an issue finding the documentation then that's a bug.
RTFM is never a valid response. At the very least you point the user to the specific section of the manual.
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 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.
In my experience, "RTFM" is often a manifestation of the frustration that the person asking for help hasn't even begun to do the most basic thing to try and help themselves.
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?").
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?").
Well that's what you sign up for when you ask people to use your software.
That foolish sway dev, angering his paying users?
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.
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.
"Ask"? Of all the open source work I've done, I never ask anyone to use it. I put it out there with the hope that others will find it useful. I never go around pushing people to use it.
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.
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.
> I put it out there with the hope that others will find it useful. I never go around pushing people to use it.
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.
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.
I think there is a very clear distinction between asking for help like: 'I have searched for a solution to my X problem in this or that way, but I couldn't find anything.' and 'I don't know how to do X.'
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.
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.
Here's a question:
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.
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.
It's both. Using the insulting term RTFM makes it worse. But just pointing to the manual is also not the right way to do it, at least you have to specify which manual and where. That's the rules we set and they are really the right rules, below this minimal amount of effort you are not giving support. You are just wasting time and offending people.
> 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.
> 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.
> That's the rules we set and they are really the right rules
"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.
"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.
I referenced above the Ubuntu Linux forum. That's where we (=the people running the forum) set those rules, based on general Ubuntu guidelines. So it's a little bit more than just my opinion. But it's my opinion that these rules are always right if you want a successful software project. You can also treat it as an observation if you prefer.
> 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.
> 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.
> if the answer was, "The answer to your question is in the manual; please read it", would you consider that ok?
YES.
YES.
RTFM is always a valid response when you are dealing with a lazy, spoiled society that would rather just call tech support and bother somebody who is sitting on the other side shifting through a stack of manuals in from of them that comes with the product...
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)
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)
RTFM is just a rude way to say "Please search the documentation before asking".
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.
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.
Generally, I agree. However, we're discussing a highly customizable WM. Not GNOME or KDE. You may assume the user is technically adept, and able to read a man page. Telling them to do exactly that is fair (but I agree it can be said friendlier). Silence might be better, but it might also be worse if the reader is awaiting help.
I often ask "stupid" questions, but I do so after having searched the documentation, google and tried everything I could think of trying. Sometimes it really is in the manual and in my frustration I overlooked it. My point is that assuming the person is just lazy is, well, an assumption and may not be true. At least a friendly "its in the manual" tells me I just overlooked it, but an unfriendly RTFM just makes me think why did I even bother wasting my time struggling. I don't have problems with stuff for the fun of it.
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.
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.
> I often ask "stupid" questions, but I do so after having searched the documentation, google and tried everything I could think of trying.
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.
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.
The RTFM conundrum is very simple to solve:
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!
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!
I get it that it comes across as negative, but it is partly a choice. You could assume the person is just very busy. You could assume RTFM just means Read The Fine Manual.
The current meaning of RTFM is well established and it does not contain the word "fine"...
Lots of assumptions and generalizations.
There are countless reasons for why these things happen.
There are countless reasons for why these things happen.
The thing is - nVidia uses shared source for all of their drivers. This is why you always have the newest GPU feature support and performance on their Linux driver - it's the same codebase as it is for Windows and was for macOS.
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.
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.
> It's also not very likely to happen, especially due to poisonous behaviour of kernel maintainers towards nVidia, unwilligness to compromise
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.
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.
Do you think Windows or MacOS make compromise on the way they code their kernel to accomodate nVidia ?
No, it's just a matter of economics.
No, it's just a matter of economics.
Yes, Windows has a stable driver API you can build upon.
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)
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)
Of course, AMD managed, so there’s no technical reason that nVidia cannot.
I didn't say there's a technical reason, I said they want to keep their source code secret, which to me is a reasonable argument.
Well then sway maintainer's reason to explicitly deny support for proprietate nvidia driver is a reasonable argument too.
Definitely, it's his software and he can do whatever he wants, and I'm not criticising him, I'm criticising Linux for not offering a stable driver API. As far as I know they don't even want to allow shims like the one Android Treble introduced. It is not a technical decision, it's a political one.
There is a technical rationale that should be read to understand kernel dev's PoV : https://github.com/torvalds/linux/blob/master/Documentation/...
Refusing to open source their drivers is not a technical decision, it’s a political one.
Except that AMD doesn't have feature parity with Windows driver on open source version and has all the Nvidia driver headaches on closed source version.
I'm not sure what AMD really managed here.
I'm not sure what AMD really managed here.
It doesn’t have “all” the headaches on the closed source version, afaik - it still implements the standard APIs and thus works with systems that were designed to work with every other driver from AMD to Mali, unlike the nVidia proprietary driver.
AMD's open source driver is fully usable for normal usage (including gaming), and in general more performant than the closed source version.
https://www.phoronix.com/scan.php?page=article&item=rx590-li...
https://www.phoronix.com/scan.php?page=article&item=rx590-li...
Still behind the proprietary Windows driver or Nvidia's proprietary Linux driver.
They are not behind their windows driver on OpenGL. And neither for Vulkan, I think. AMDVLK scores a few wins here and there, but RADV is generally more stable, performant, and compatible. Plus being open-source, it is easily extended, like valve is doing with their AC0 experiment [1].
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/...
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/...
Can you share some source of your statement?
MacOS user: what's a driver ?
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.
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 thing is - nVidia uses shared source for all of their drivers. This is why you always have the newest GPU feature support and performance on their Linux driver - it's the same codebase as it is for Windows and was for macOS.
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.
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.
You can have an open source driver without mainlining it. This was what the whole discussion between the Linux devs and AMD was over the AMD HAL. If you want to maintain it yourself, you can do it however you want.
Linux has modules, and had very good support for out of tree modules.
Linux has modules, and had very good support for out of tree modules.
It's easier to switch to Radeon, and ROCm instead of CUDA.
> The thing is - nVidia uses shared source for all of their drivers. This is why you always have the newest GPU feature support and performance on their Linux driver - it's the same codebase as it is for Windows and was for macOS.
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.
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.
It’s pretty clearly nvidias fault. Their proprietary driver doesn’t play well with wayland and they haven’t seemed to care.
Well, they've developed their EGLStream approach and that probably cost some resources on their end so the question is why they decided to go that way at all. It seems like a waste to me to develop something nobody is going to use and I don't see the business reason for this particular development.
afaict the only people who really care about EGLStream are nvidia. And while GNOME and KDE might have the resources to support both API's (much as they don't want to), smaller projects like sway simply don't have the resources to worry about that.
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.
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.
>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.
That would require a single standard for communication with GPUs and the problem is that Nvidia is refusing to implement that standard.
All it requires is a single standard interface for managing buffers, which exists and is named GBM.
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.
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.
Or some kind of abstraction layer.
Even KDE was only able to gain support for EGLStreams after an NVidia developer Erik Kurzinger contributed the necessary changes to Kwin.
As far as I know that was mostly because they refused to even try and not because it was too hard or even complicated.
If one of the kwin developers had nvidia hardware, likely they would have cared enough to try. And if they didn't, how would they test and maintain the nvidia-specific code? Adding an entirely new code path for rendering would be a large support and testing burden that they may not have had the resources to take on.
> If one of the kwin developers had nvidia hardware,
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.
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.
Maybe? I don't know.
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.
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.
So, I find this a bit weird
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)?
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)?
The reason is simple: those using profesional apps are typically >100k/year engineers using apps that cost >10k/year. The developers of these Apps either put in a lot of money into supporting nvidia proprietary APIs, or, they contract nvidia to implement support for them. If you are big enough, nvidia does this for free.
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.
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.
It's chicken and egg problem. Nvidia was major backer of OpenGL, but their drivers were never conformant implementations that allowed a lot of incorrect shaders to compile and run. Yet Nvidia had best developer support so most of commercial apps were developed and tested against their drivers. As result those apps use non-standard codepath that simply dont work on conformant drivers. On top of that OpenGL compatibility contexts are not well documented or tested, but it's not strictly Nvidia fault.
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.
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.
> The author is also quite spiteful about it
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.
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.
No developer wants to deal with bug reports due to a buggy proprietary driver they have no ability to change.
If you don't want to deal with stupid bug reports then you'll have a big problem developing any software that a large group of people interact with.
Yes, but the dynamic changes considerably when you're a one-person team doing it for free in your spare time.
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?
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?
[deleted]
The average user would probably appreciate a driver experience most similar to Mac OS, and such an experience is available on Linux for non-nvidia graphics hardware because other vendors cooperate with standards.
I agree this gives a bad image, but the average user isn't going to use Sway. It doesn't affect most Linux users by far.
It's a symptom of the culture, not the big driver of that culture.
> This would be a good time to mention that sway doesn't support the nvidia proprietary driver
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
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
I have read this and I don't understand why Wayland developers don't want to write an adapter for NVidia's proprietary API. How is it worse than other APIs?
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.
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.
> I have read this and I don't understand why Wayland developers don't want to write an adapter for NVidia's proprietary API.
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.
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.
> If AMD and Intel can dedicate resources to maintain their Wayland implementations with no complains why NVidia can't?
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.
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'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.
"They" being Nvidia here. AMDs amdgpu driver clearly shows the problem is neither Linux nor Wayland or Sway.
> What do you mean "all parties"? They're excluding at least one party - nVidia users.
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.
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.
> significantly trailing
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.
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.
To add to this, the AMD OpenGL windows drivers are notoriously bad, whereas the Linux OpenGL drivers perform closer to DirectX. Performance on that end is significantly ahead.
As someone who has spend a lot of time working on graphics on linux, I can safely say this is nvidia's fault.
Drew's stance on supporting EGLStreams is not unreasonable. It's a "standard" that only nVidia cares about and causes a lot of headache for pretty much everyone.
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.
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.
It leaves out users who do any meaningful gaming beyond tetris or Farmville in the same session.
You could always log in 2 graphical sessions and have one be running x and one sway I presume.
You could always log in 2 graphical sessions and have one be running x and one sway I presume.
You could just use an AMD GPU on Linux. They've had (more than) competitive open source drivers for a few years now, and they play well with all the modern Linux desktop protocols.
I won't be buying new hardware just to use a currently worse functioning alternative whose increased security is wholly hypothetical.
It is something to keep in mind when you purchase your next card. I'll always choose a smooth experience with mainline drivers over 10% more raw power. (And it's incredible how much AMD GPU driver support has progressed over the last few years, going from the total clusterfuck that is Catalyst to everything just working out-of-the-box.)
Clusterfuck? I just installed nvidia-driver and it sets itself up.
Catalyst is AMD's previous driver: https://wiki.archlinux.org/index.php/AMD_Catalyst
Ah my bad, I mixed up with Nvidia. Thank you.
I don't think so. A driver needs to control a device completely so you can't drive sway with nouveau and game on nvidia.
Well, this exact problem is why I won’t be buying an nvidia GPU the next time around. I’ll hang on to my 1080 Ti until AMD has something faster.
Maybe it's about time for Linus to break the fourth wall and flip them off again in the middle of of a university classroom?
I mean it worked wonders the first time, considering that's how we got the Nvidia proprietary driver to begin with.
I mean it worked wonders the first time, considering that's how we got the Nvidia proprietary driver to begin with.
>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.
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.
I remember using their proprietary driver on linux at the turn of the millennium.
All spite towards NVidia is completely deserved for many many reasons.
From what I've read, it seems like Wayland's "controversial design choices" don't stem from developers being inconsiderate of different workflows, but rather from the intention of making a general purpose protocol.
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.
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.
That means the screenshot application is, to some degree, compositor specific. It leaves the door completely open to the outcome that if you want to stream using a Gnome streaming application you will have to be using the Gnome project's window manager. Or the KDE streaming application will require the KDE window manager. Or the 'best' screenshot application will be tied to the XMonad successor on Wayland.
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.
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.
> 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.
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.
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.
The protocol mistake might easily be that they didn't include a security policy mechanism for coordinating Wayland buffers or something similar. It sure looks from the peanut gallery looks like they have a security model (graphical output is completely secret except to the compositor) that is insufficient in practice and users really want applications to be able to snoop on each other when required. That is going to be more difficult to tack on afterwards than it would have been to design in at the start. Security is exceedingly difficult to do after the fact.
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.
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.
> Security is exceedingly difficult to do after the fact.
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.
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.
I think this is a misunderstanding of how screenshots work, and how Wayland has always intended to deal with the issue.
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.
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.
[deleted]
> That means the screenshot application is, to some degree, compositor specific
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).
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).
> 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.
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.
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.
That's the entire point of Wayland. It will be easier to replace Wayland because Wayland isn't a monolith that does everything and the kitchen sink.
there are already a number of screenshot protocols (as TFA explains, slurp and grim can be used for screenshots on sway). the trouble is getting everybody to agree on a single one, or implementing a library to interface with all the protocols, which is the current strategy. https://www.google.com/search?q=wayland+screenshot+protocol
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.
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.
Screenshots, remote desktop stuff, etc, is being built under the Portal system that’s used for flatpak. GNOME and KDE already support this, and it doesn’t depend on flatpak at all.
freedesktop have had success in standardising the Linux desktop. I fail to see why gnome, KDE, etc wouldn't eventually standardise around a common screenshot protocol.
"eventually"
Windows switched to composited desktop with Vista in 2006 and didn't lose any[0] functionality. 14 years later and we're still saying "eventually" when discussing basic features Wayland should have.
[0] Technically it lost a few, the ability to ignore vsync for non-fullscreen applications being the biggest one.
Windows switched to composited desktop with Vista in 2006 and didn't lose any[0] functionality. 14 years later and we're still saying "eventually" when discussing basic features Wayland should have.
[0] Technically it lost a few, the ability to ignore vsync for non-fullscreen applications being the biggest one.
> and didn't lose any[0] functionality
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.
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.
[deleted]
Many things that came out of freedesktop.org are pure garbage. The most prominent example is dbus. Personally I hope they have no success in standardizing anything further.
Do tell. I’ve found dbus hard to understand, but it works reliably here.
There are many ways to do IPC on a unix system. Dbus is a reinvention of IPC in the worst possible way. It requires a daemon to run and it requires every client to be able to parse and generate JSON. The worst thing is that those JSON packets are not even human readable most of the time. Protocols that are running on top of that are also not standardized. If you are lucky KDE and GNOME agree on something. Many times they don't.
D-Bus does not use JSON.
Indeed it uses XML which is even worse!
Only as a description language. The message format is a subset of GVariants.
At closer inspection GVariants looks very similar to JSON though.
Except that it was designed to be read into memory and directly accessed without parsing. A GVariant Array has the form of its elements and their lengths. You can index into an Array in linear time.
I suggest you read up on how D-Bus actually works.
E.g. https://dbus.freedesktop.org/doc/dbus-tutorial.html
Its funny how people shit all over systemd for doing everything and then people shit all over wayland for just doing enough for the task it was made for.
I think the complaining is 10% real concerns and 90% people upset that it is different than it used to be.
I think the complaining is 10% real concerns and 90% people upset that it is different than it used to be.
Wayland is indeed similar to systemd. It requires a monolithic implementation of all features traditionally done by separate programs (e.g. window managers, hotkey deamons, screen recorders, streamers, ...) because it lacks the appropriate protocols. X11 on the other hand provides a platform (thanks the "process not policy" design mantra) for all those separate programs by implementing those appropriate protocols.
Also, people love change if you have actual improvement. I was very happy to switch from sysvinit to runit.
Also, people love change if you have actual improvement. I was very happy to switch from sysvinit to runit.
X11 not being a monolithical piece of software sounds like a cognitive dissonance issue. The codebase is huge, even though they tried to get rid of some stuff recently, such as the printer drivers. But it contains a lot, from networking to graphical widgets, to GPU drivers. All of which is implemented monolithically in one program.
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.
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.
> X11 not being a monolithical piece of software sounds like a cognitive dissonance issue.
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.
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.
Systemd and Wayland are very different pieces of software. It's easy to imagine (in fact I think it's very common) that end-users of Systemd just use it to launch a service which replaces all the logical features of Systemd. (E.g. for an extreme example, a kubernetes cluster.) If systemd doesn't support some feature, it's really fine. Maybe even preferable. You can get it working by some other means.
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.
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.
Zoom is an awful piece of malware. Wayland doesn't need to support zoom, zoom needs to support wayland. With that logic literally every change to an OS is broken because it doesn't run my cli accounting program from 1985.
You're being sarcastic, but I actually agree with the notion that changes to an OS that cause previously-working code to break are in fact bad.
This is, just like the article's take, somewhat a misunderstanding of what "wayland" is.
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.
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.
But the author of this post mentioned a lack of support in apps like Zoom being a dealbreaker. I've also run into incompatibility with TeamViewer. And that is just going to happen whenever these companies get around to it. And if your work requires using such apps, that is just what you need to use.
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.
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.
"I do not use Wayland because Zoom does not support Pipewire-based recording nor any Wayland screen recording protocols" is a fine although very uninteresting conclusion.
Excellent post. Thanks for your in depth insights!
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.)
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.)
[deleted]
My big problem with Wayland is that it doesn't look like it's going to support Window Maker as well as X does, if at all. Well, maybe I should rephrase: Wayland isn't going to be my problem until it supports Window Maker as well as X does, because I won't switch to it until that happens. I'm sure there are more than enough people like me to support a distro, like how there are non-systemd distros, the major appeal of which is that they don't use systemd.
I don't really like Wayland and I think X is better in many ways. There are a few problem which is why I had some ideas about X version 12. One is to ensure the implementation and protocol are separate. Another is proxies to implement security features. Another is support for SCM_RIGHTS and SCM_CREDENTIALS (only for local connections; these are obviously not supported for remote connections, which are still possible, if implemented by the server and enabled by the user). And then, also 64-bit numbers in many places. But a lot of it is like the version 11 protool (without all of the extensions they have added), but with a few differences. (I don't really like much of the freedesktop stuff either; I work without a desktop environment, and programs should not assume the existence of one.) Maybe there is even a possibility to implement these different systems over each other when needed.
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).)
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).)
> But a lot of it is like the version 11 protool (without all of the extensions they have added),
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 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.
I've seen this sort of comment frequently: "it's 2019, why are we still doing n?", as if somehow it should be assumed we have grown out of it.
It's a completely unsubstantiative argument; its effect is to sweep under the rug any justification for the 'old way' of doing things.
It's a completely unsubstantiative argument; its effect is to sweep under the rug any justification for the 'old way' of doing things.
No, it isn't unsubstantiative at all.
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.
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.
> For one very big thing, hardware accelerated rendering didn't exist in 1980.
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.
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.
> Also, no one really cares about network support anymore, because it's simpler and better to just do a screen share.
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'.
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'.
Does Wayland break X-forwarding? That's a huge step backward, if so.
https://wayland.freedesktop.org/faq.html
> 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.
> 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.
These ways already exist: [waypipe](https://gitlab.freedesktop.org/mstoeckl/waypipe/) is fairly complete already.
That's a bummer. ssh -X is a powerful utility.
https://gitlab.freedesktop.org/mstoeckl/waypipe
ssh -X still works and wayland native is waypipe ssh (though one could probably wrap that into ssh -X to make it seamless).
ssh -X still works and wayland native is waypipe ssh (though one could probably wrap that into ssh -X to make it seamless).
> Also, no one really cares about network support anymore, because it's simpler and better to just do a screen share.
I care about network support for GUI applications.
I don't think _whole screen_ shares are either simpler or better.
I care about network support for GUI applications.
I don't think _whole screen_ shares are either simpler or better.
waypipe works with single applications just fine. There are some rough edges but as far as I can tell it already works at least as well as remote X ever did.
Does it support using the client computer DPI like X11 does ? And running apps from a headless system ?
Seems like it https://mstoeckl.com/notes/gsoc/blog.html
Give it a try and let us know.
Give it a try and let us know.
Does Wayland improve the remote desktop story at all? I sometimes drop to X11 forwarding because VNC and X2Go don't really work so well for me. If I think I'm going to need a remote desktop for a while, I'll reboot into Windows and load my Linux installation up as a raw disk VM in VMware Workstation and then rely on Windows's RDP for remote desktop. I'd love to simplify all this.
If anything Wayland makes network transparency worse because there's nothing like ssh -X for it that works out of the box. Another commenter mentioned waypipe, which is a start, but it'll likely be years before it achieves the required ubiquity.
I had good ux with realvnc, maybe novnc, ..
It's been a while, so maybe I'll give that shot again. My experience with VNC is that it's just laggy and really doesn't like it when I connect to a multi-display desktop with a single display laptop. Windows Remote Desktop adapts beautifully with virtually no lag, so I was hoping Wayland adopted something similar.
> Also, no one really cares about network support anymore, because it's simpler and better to just do a screen share.
[citation needed]
Let me guess, you live in a city?
[citation needed]
Let me guess, you live in a city?
Are you implying something about connection quality? Because in my experience X forwarding degrades very quickly when you lower connection quality, much faster than other options.
That depends on the toolkit. GTK first renders everything remotely and then transmits the final pixmap to the server. It also has multiple unecessary rountrips on every event which amplifies the lag even further.
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.
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.
Yes, and I think Xaw is much better, but that is just one reason for such thing.
Xaw is not suitable for modern applications. Essential features like radio buttons or combo boxes are not present. Text input boxes support almost all Emacs command keys but none a typical desktop user would expect and they don't support Unicode. It's a mess.
No need to be rude.
I wasn't being rude (At least I don't think I was? I'm sorry. Tone is difficult to communicate sometimes and my brain is fried) I was just asking if they had any evidence to back up their claims?
If it wasn't intended, then I am the one who should apologize to you! I read it as snarky, but tone is notoriously hard to get across through text. (And I've never been particularly good at figuring it out myself.) My apologies. :-)
So you're advocating a protocol which doesn't work on low-end systems and deliberately breaks workflows.
Also, no one really cares about network support anymore, because it's simpler and better to just do a screen share.
I've used that feature every single day for the last 20 years.
I've used that feature every single day for the last 20 years.
Yes, and it works way better with screen sharing for some content, which is most, nowadays.
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?
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?
I like how he made up the word "unsubstantiative" and you just rolled with it.
If a word accurately conveys meaning to another person, does it matter that it's made up? If you hadn't mentioned it (and I hadn't looked it up as a result), I would have had no idea it wasn't a "real" word.
Well, every word was, at some point, made up. Maybe we should herald the birth of this new word with great rejoicing.
No one made up any words, they just misspelled "unsubstantive" (understandably!).
Made up or misspelled, I just think it's interesting that the error was contagious.
Are you actually familiar with the drawing model of core X?? It is completely obsolete and does not support acceleration of virtually any 2D or 3D rendering construct we take for granted for the past 30 years.
The GP was suggesting “without extensions”. Good luck with that.
The GP was suggesting “without extensions”. Good luck with that.
I am familiar, and I think that it is mostly good; the only thing missing is direct rendering (which would be optional). (And I did not mean entirely without extensions, just to remove most of the stuff.)
(I also think modern fonts don't look nice; I want to use bitmap fonts on the screen!)
(I also think modern fonts don't look nice; I want to use bitmap fonts on the screen!)
[This paragraph used to mention Vulkan, but now I think that is not a good idea and DRI is better. See the replies to this message for details.]
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).
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).
Vulkan really shouldn't be a protocol. What you really want is DRI3/Present extensions, which are fine. But then you still have issues with window resizing and reconfiguration, and the difficulties with COMPOSITE... basically you're asking for Wayland by the end.
Like I said, I don't know much about it. You are probably correct; it shouldn't be with Vulkan. But I think there are some problems with Wayland, and many things in the X protocol is good (although there are also problems with it).
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.
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.
SCM_RIGHTS is already used for FD passing for DRI3. Your thoughts on shm_open are already part of the X SHM extension, which has been around for over 25 years now.
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.
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.
For what it's worth: thank you.
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!
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!
> Lots of people have ideas for an "X12" that turns out to be stuff already supported by the X11 protocol.
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.
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.
Half the stuff in here is already possible in X11. The rest make very little sense.
> - 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:
https://specifications.freedesktop.org/idle-inhibit-spec/lat...
> - 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.
> - 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:
https://specifications.freedesktop.org/idle-inhibit-spec/lat...
> - 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.
You seem to be misunderstanding many of my points. (Maybe that is because I am unclear.)
> 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.
> 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.
You do need real-time time stamps for some parts of a display protocol, since clients should be able to accurately determine when past frames were displayed, and accurately request display times for future frames (subject to the potential for failure because OS scheduling is not hard real-time).
This is especially true for modern displays which have some limited support for variable refresh rates.
This is especially true for modern displays which have some limited support for variable refresh rates.
OK, that is a valid point, but such timestamps are not global and are a separate function in the protocol than what the other timestamps are used for.
Some people mention how Wayland does not allow access to other windows from other clients, and is sometimes good and bad. In my X12 idea, this is independent of the protocol, and the protocol doesn't care. Restricted access may be implemented either by the X server itself or by some proxy, and either way the protocol doesn't care and the client doesn't care. What the restrictions are may also be implementation-dependent and is preferably configurable by the user. The client would send a SCM_CREDENTIALS message to the server; if the server doesn't understand it then it will just ignore it and allow (or deny) access anyways. (It isn't necessarily only other windows that you may restrict access to; you might also sandbox selections in a proxy too, if you want to.) (Note that an implementation which cannot be configured for unrestricted access technically is not compliant with the specification; although merely allowing it to be configured with restrictions does not violate the specification.)
Before I touch on Wayland and X, a brief detour.
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.
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.
Servo is not a browser, it is a browser engine. To quote the Mozilla Research page about it: "Like WebKit, the Servo project is not a complete browser. It is an experimental project that delivers components that can load, run, and display web sites and applications." Given that, it doesn't make sense to talk about users "…switching from Firefox to Servo."
c.f. https://research.mozilla.org/servo-engines/
c.f. https://research.mozilla.org/servo-engines/
I guess it depends on the user, but Wayland is not the same shit for me. The level of jank and screen tearing in X is unacceptable.
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.
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.
Most people don’t care about animation, but getting their work done. Still, I’m rooting for W.
Scrolling, moving/resizing windows, switching windows/tabs.
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.
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.
I have two 4k monitors with Intel gfx one in portrait, and have no issues unless I run vlc full screen and there is a lot of movement in the scene. The other 99% of the time it just isn’t a problem. I’m only reminded it exists in threads like this.
> Most people don’t care about animation
Then why does every popular desktop/mobile OS/app have UI animations?
Then why does every popular desktop/mobile OS/app have UI animations?
Because those are technical gimmicks and nerds are very susceptible to fall for gimmicks. Users? They care about consistency and predictable interfaces that don't change every week. They couldn't care less if a toolkit looks dated. Motif, CDE, Plastique, XP-Style, Aqua, Quartz, Material, it all looks the same to them. Tearing? Users don't see it, because they don't have the fine tuned sensibilities to what technology should do, and how it actually behaves.
Playing a movie produces moving pictures on a monitor? Great!
Tearing? Without telling them, they'll hardly ever notice it.
Playing a movie produces moving pictures on a monitor? Great!
Tearing? Without telling them, they'll hardly ever notice it.
Mobile has way more of what you call "Users" than what you call "nerds" and they all absolutely love fluid animated UIs and spend literally hours a day swiping away at them.
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.
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.
> 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.
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.
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.
Yeah. IMO once you see screen-tearing you cannot unsee it.
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.
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.
This is kind the objective I think. Wayland in most cases (Gnome and KDE) is simply an implementation detail, and Gnome and KDE runs in both X11 and Wayland.
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.
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.
Nobody replying to you seems to catch on that i3 is not the only environment other than KDE and Gnome.
i3 users have sway. Good for them. Now what about every other window manager?
i3 users have sway. Good for them. Now what about every other window manager?
It's worse than that... WM's that people care about will be ported/rewritten (I know I will probably do one). But the "wm" now needs to have much more infrastructure functionality which doesn't really need to be different.
A lot of that is abstracted out od Sway, which aiui is supposed to help alleviate that issue: https://github.com/swaywm/wlroots
yeah, it's weird, a lot of people seem to think Wayland is some back end that you switch out like you would a SQL database. there were people on this site saying switching would take a weekend.
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.
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.
Indeed; I've used wmii for around 10 years now, and its developers have openly stated they will never support Wayland.
wmii has not been developed in the last five years, no wonder it's not going to be ported.
I use some other WMs that aren't actively developed anymore either, for longer than 5 years. Some software doesn't need constant rewrites.
They might want to consider revising that decision because X is going away. If they don't, wmii will go away with it.
X has been going away for longer that the careers of most people on this site.
At this point maybe even longer than a substantial chunk has been alive.
Says who? X.org will be supported for at least the next 10 years as part of RHEL 8. Not to mention the possibility that someone other than Red Hat could continue supporting it after that time.
It'll be in "hard maintenance mode" meaning bug/security fixes only. Anything new and interesting in the graphics space will be Wayland only. I also believe they intend to deprecate and then remove Xwayland from the graphics stack, at least in releases newer than some flag day in the near future, as Xorg itself is only being maintained for the sake of legacy applications.
I can't help but think that this X deprecation talk from RH is just some chest beating to rally the troops behind Wayland, same as we used to hear from Ubuntu about Mir.
That's how you get people to use your stuff when they would otherwise dig in their heels because "what I have is fine", "muh Unix philosophy", etc. It worked for systemd.
Excuse me sir or madam. Firstly, X11 even in its heyday was often criticized as not being very Unix-philsophy-ish. But I don't think you make a very sophisticated argument when you mock criticism by imitating flawed speech.
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.
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.
"What I have is fine" is a perfectly valid reason not to go changing things, IMO.
Ok, this is all true, but none of it is the same as "X is going away".
Most DEs are either already ported to Wayland (Cinnamon, Enlightment), have a porting in progress or plan to port it eventually.
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.
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.
It isn't just window managers, there are also applications that are close to X11, and many of these don't even work in XWayland, because they break wayland's security model. For example screen shot and screen sharing apps. And even if the developers took the large amount of work to refactor to work with wayland, there isn't any kind of standard for privileged access in wayland, so they would need to use different protocols to implement the functionality for each compositor.
I realize no one reads TFA, but TFA is very relevant since it's all about i3 and sway...
I don't know why people assumed that I never heard or used Sway (or that I didn't read the article). I did all three, and this is why I am saying that the transition from i3wm to Sway is kind painful (ok, my fault for not citing Sway in my phrase, however I did think it was implicit that I used it).
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.
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.
I know; I replied to the parent because I couldn't reply to multiple comments about sway at once. Sorry for the confusion
Have you tried sway? It's about as close to a drop-in replacement to i3 as we'll get, I think, and my experience with it has been pretty positive.
https://swaywm.org/
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.
https://swaywm.org/
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.
Unsure if you've seen it before, but I've been using sway [0] as a Wayland-based replacement for i3. Switching the configs took about 15 minutes (and could probably be replaced by a few sed commands). It's been very nice to use all around--snappy, no major issues even with multiple monitors, etc.
[0]: https://github.com/swaywm/sway
[0]: https://github.com/swaywm/sway
> 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
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.
> - 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.
The masses do not use X directly, they use GTK+ and QT. And those moved to Wayland. Window/desktop managers moved (e.g. Gnome) or have been rewritten (e.g. i3 -> sway). Looks like a success to me (marketing side). Frankly, by your writing it looks like Wayland had been proposed today and needs to make a dent.
Most desktop Linux users aren't using Wayland yet. In fact insofar as sway a good chunk of hardware that is well supported under Linux will never work in sway.
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.
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.
I agree with everything you've said. My point was about who needs to be convinced to use Wayland (not the end users). People will naturally get Wayland when they update their distribution and yes, it will take years.
> Aside from the lack of screen tearing, what can we all agree are big wins for the user?
From what I remember, Wayland makes it easier to mix 4K and HD displays without pain.
From what I remember, Wayland makes it easier to mix 4K and HD displays without pain.
From my narrow perspective, Wayland's key feature/bug is that it may break fluxbox, which I have used for >17 yr.
As long as it implements X, I don't mind, but my understanding is that the change is a breaking one.
As long as it implements X, I don't mind, but my understanding is that the change is a breaking one.
Mine are 1) Xmodmap support/migration 2) breaking imagemagick's import (screenshotting) making my shortcut for OCR'ing text on the screen break.
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.
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.
> my shortcut for OCR'ing text on the screen
Would you be willing to share that? Pretty please?
Would you be willing to share that? Pretty please?
I don't have the exact command at hand, but it just uses tesseract. Something like "import - | tesseract <whatever options for language and page format> | xclip". The accuracy is not amazing by any means.
Great question to be asking. I agree users are indifferent, but there are two ways in which this applies:
(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.
(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.
Depends also on the type of distribution audience.
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.
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.
> How do they get people to use it?
call it Firefox v100 and automatically update
call it Firefox v100 and automatically update
I think WebRender (the FF-integrated name of Servo) didn't improve Firefox VR support in any big way. VR was pretty good in Firefox already and WebRender mostly impacts rendering of HTML content like fonts, images, and CSS. The lower level tech that VR depends heavily on is WebGL. The next big jump in that department looks to be WebGPU but that's still in early stages.
[deleted]
[deleted]
Important to note that Sway WM is not Wayland as a whole; I am a happy Sway user, but unfortunately it is not 100% at parity with the experience you will get with GNOME. However, you can always contribute if you have time; it’s fun and the codebase is very nice to work with. You don’t even have to switch to Sway to work on it. (If you are skilled at debugging and use graphics tablets we could use some help trying to figure out some crashing bugs with tablets...)
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.)
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.)
> The fact is, Wayland is the only viable X11 successor
There's at least one other option in the running, Arcan: https://arcan-fe.com/
There's at least one other option in the running, Arcan: https://arcan-fe.com/
I'm a big fan of Arcan (moreso than I am of Wayland), but it's nowhere near as far along as Wayland and I think at this point is still the product of just one person. I think it's fair to call Wayland viable, but I don't think I would say that of Arcan until it's:
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.
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.
Cool, Arcan looks a lot more viable for me than wayland
The discussion in the post, the description of what a technical user had to do to switch, the problems encountered, the X11 problems mentioned (tearing, etc), and the suggestions and workarounds in the comments, should be mandatory reading before someone calls Linux "ready for the desktop".
For some reason Linux discussions are bimodal: in some everybody chimes how perfect everything works, and what peace they found switching to it. In others, like this one here, it's all about all kind of problems, hacky solutions, tinkering with system settings, and so on, and still having serious issues.
For some reason Linux discussions are bimodal: in some everybody chimes how perfect everything works, and what peace they found switching to it. In others, like this one here, it's all about all kind of problems, hacky solutions, tinkering with system settings, and so on, and still having serious issues.
If you like tinkering, you can certainly do so, but there's a maintenance cost to customizations, and if you're not willing to shoulder them, then you should go with something closer to the stock install where the distribution will generally have sorted out things for you.
Perhaps this is the explanation you're looking for?
Actually, I think, and this is perhaps somewhat surprising, that many software developers don't pay terrible much attention to future maintenance costs.
Perhaps this is the explanation you're looking for?
Actually, I think, and this is perhaps somewhat surprising, that many software developers don't pay terrible much attention to future maintenance costs.
My biggest problem Wayland, is no screensharing. (i.e. casting on Chromecast, sharing screen on zoom).
Apparently this because of security. Is this possible to overcome? Is this something can fixed by simply having chromecast/zoom devs implement something? Or will it never be possible?
Good news actually, it's already being worked on. As mentioned, Pipewire is the current leading solution. Upstream WebRTC has experimental support for Pipewire; in Chromium it can be enabled with a flag and in Firefox it can be enabled with a patch or configuration flag (I believe it is supposedly merged, but not sure if stable versions will compile and work with it.)
GitHub is down atm but there's also an xdg-desktop-portal implementation for wlroots which should allow for Pipewire clients to run under Sway (I have not tried this personally, so I have no idea if it actually all works in practice yet.) https://github.com/emersion/xdg-desktop-portal-wlr
GitHub is down atm but there's also an xdg-desktop-portal implementation for wlroots which should allow for Pipewire clients to run under Sway (I have not tried this personally, so I have no idea if it actually all works in practice yet.) https://github.com/emersion/xdg-desktop-portal-wlr
It doesn't sound like it's ready (as of June): https://github.com/emersion/xdg-desktop-portal-wlr/issues/4#...
Correct. All of this is working out of the box in Fedora 31 which ships Wayland by default.
[deleted]
Screensharing is possible but it is not part of wayland. The compositor/DE must implement screen sharing and manage how programs are given permission to this.
Will this require both parties to be running the same compositor?
No, the other end is just receiving a video stream. Unless you are looking for something more advanced which actually renders the desktop on the remote computer which I'm not would work to well if it is even possible in X11
It is already there. I use zoom screensharing on wayland for work and it works like a charm. Better than on X11 where i always had artefacts actually.
I've been using gnome on wayland for a while now, all apps running natively but the electron based ones and it's working perfectly. I have none of the issues mentionned by the author of this post.
I've been using gnome on wayland for a while now, all apps running natively but the electron based ones and it's working perfectly. I have none of the issues mentionned by the author of this post.
Take a look into pipewire.
I've been using Wayland full-time (via Sway) since Sway went 1.0. It's been a pretty straightforward experience. The transition took some elbow grease at first (things like getting redshift working, as the author notes), but the last time I fucked around with my graphical config was months ago. I use a display manager, so the "crashes lead to an exposed terminal" thing doesn't matter so much (I've had a total of two crashes, once when I was putsing with XWayland, video games and multi-head -- and the other when building a since-abandoned alternative to kanshi).
There are some quirks I need to spend a little more time investigating whether they're caused by Sway/Wayland or just my configuration: drag-and-dropping between windows seems to be busted, and right-click context menus that overflow their host window's boundaries aren't clickable outside those boundaries. But I mainly use the keyboard/terminal/TUIs, so I don't frequently drag and drop, and it's easy enough to right click somewhere else when the second issue occurs.
Other than that, for how I use a computer, it's been smooth sailing. I wouldn't say we're Wayland yet for general usage either, but for the group of users who are into tiling window managers, we're maybe Wayland enough for now.
There are some quirks I need to spend a little more time investigating whether they're caused by Sway/Wayland or just my configuration: drag-and-dropping between windows seems to be busted, and right-click context menus that overflow their host window's boundaries aren't clickable outside those boundaries. But I mainly use the keyboard/terminal/TUIs, so I don't frequently drag and drop, and it's easy enough to right click somewhere else when the second issue occurs.
Other than that, for how I use a computer, it's been smooth sailing. I wouldn't say we're Wayland yet for general usage either, but for the group of users who are into tiling window managers, we're maybe Wayland enough for now.
I use i3 (with X11), and the last time I messed around with my graphical config was when I installed the system 18 months ago. Haven't had any issues even close to what you're describing, much less the screen tearing that I have never seen in my last 10 years of linux.
Like I said, getting started took some elbow grease, but as a daily driver on my personal and professional machines, Sway's never once crashed or behaved poorly. I no longer need to tinker with it or worry about it; hence, I believe that for the collection of people willing to hammer at something a bit when they first pick it up, Wayland's in an OK space.
You described several crashes and a number of bugs, above, which is what I was responding to. Even from your generous assessment of Wayland/Sway, it seems like my X11/i3 system is more robust and stable.
You actually mentioned several deal breakers would you recommend stuff to friends that would convince them Linux is weird and broken?
I run NixOS on all my machines and either use Proton or VFIO to boot Windows when I want to game now. No, I wouldn't recommend the way I use computers to friends and family ;). For the Hacker News crowd who are likely willing to tilt at technical windmills once in a while, however, Sway no longer has a high bar to entry, and I use it all day professionally and personally without worrying about it.
I just play native games. This involves clicking the launcher icon on steam.
Do you share your config files publicly?
Not at this stage, but I've got them all in a git repo in Keybase. The problem is that I've had pretty sloppy discipline re: storing secrets in them (... because Keybase makes that less bad), so I'll need to put some effort in to share them.
A good way to think about Wayland is the screen manager brought to you by the people who thought xrandr, Mesa, Cairo, the Linux FireWire stack, and freetype were good things. If you come in with appropriate expectations you’ll be amazed that any of it works at all.
Is you think it over for a bit you’ll realize that the real Linux graphics protocol is Android SurfaceFlinger. Wayland is like five orders of magnitude less popular.
Is you think it over for a bit you’ll realize that the real Linux graphics protocol is Android SurfaceFlinger. Wayland is like five orders of magnitude less popular.
I have had this unpopular opinion since the beginning of the decade: Linux should just adopt AOSP UI, be able to run apps, and that’s it.
The android interface would be hot garbage on desktops/laptops.
Not everyone uses a 12in netbook with only a browser window open.
The fact that Android is successful does not actually make it good and most of the apps are worthless on a large screen whereas there are lots of actual apps for Linux of note.
Not everyone uses a 12in netbook with only a browser window open.
The fact that Android is successful does not actually make it good and most of the apps are worthless on a large screen whereas there are lots of actual apps for Linux of note.
Who is "Linux" ? Who exactly do you think should adopt AOSP UI?
So what stops you from doing just that? (There is ChromeOS, anbox and co)
And Android x86, to take it from a slightly different angle
>One point that I totally forgot about, but is now painfully apparent now that I'm back on X11, is screentearing. On Wayland, screentearing is a thing of the past. Everything was so smooth, flicker-free, and tear-free. Now I need to mess around tweaking compositors to get a nice experience on X11 (i3)… So that's a big plus for Wayland.
This was my big hold up of using Linux as a whole. The screentearing is horrible, and coming from OSX where everything is as smooth as butter, it is an issue. But thankfully, Mint (which I'm on atm) allows the user to turn off vsync, and because I have an nvidia graphics card, I can turn on full-composition, and have my graphics card do vsync, and BAM! smooth as butter. It's an absolutely lovely and wonderful experience.
I don't know what it's like on the AMD or Intel side, but with hardware becoming more powerful and better supported, I don't think the future is Wayland, but instead defaulting to a higher level of gpu acceleration than the default Gnome settings we have today. This removes the latency, the page tearing, and responsiveness issues that X11 has Wayland was created to fix.
This was my big hold up of using Linux as a whole. The screentearing is horrible, and coming from OSX where everything is as smooth as butter, it is an issue. But thankfully, Mint (which I'm on atm) allows the user to turn off vsync, and because I have an nvidia graphics card, I can turn on full-composition, and have my graphics card do vsync, and BAM! smooth as butter. It's an absolutely lovely and wonderful experience.
I don't know what it's like on the AMD or Intel side, but with hardware becoming more powerful and better supported, I don't think the future is Wayland, but instead defaulting to a higher level of gpu acceleration than the default Gnome settings we have today. This removes the latency, the page tearing, and responsiveness issues that X11 has Wayland was created to fix.
> I don't know what it's like on the AMD or Intel side
I recently switched to AMD - that, with a compositor (compton/picom), resulted in a super smooth tear-free experience in X for me.
My experiences with Intel integrated graphics has always poor performance, and bad screen tearing, sometimes screentearing even with compton running.
I recently switched to AMD - that, with a compositor (compton/picom), resulted in a super smooth tear-free experience in X for me.
My experiences with Intel integrated graphics has always poor performance, and bad screen tearing, sometimes screentearing even with compton running.
The biggest hurdle for Wayland adoption is the absolutely brain dead "security model". Commonly used features like hotkey daemons, push to talk, screen recording/streaming/sharing, window management, clipboard history manager or even Wallpapers need to managed by the particular implementation (of there are many) of the Wayland server itself and have mostly no common protocols, at least not official. And when all those protocols after a long process are finally finished I have serious doubts that Wayland will be either less bloated and "messy" or more secure than current X11.
The non-existent X11 security model is not really ideal but at least you could mitigate the problem there with access control hooks and as long as you use trusted software (which is 99.9% the case on a typical Linux system) you can use all the above mentioned features today without having too much headaches.
The non-existent X11 security model is not really ideal but at least you could mitigate the problem there with access control hooks and as long as you use trusted software (which is 99.9% the case on a typical Linux system) you can use all the above mentioned features today without having too much headaches.
Sun shipped a Trusted Solaris with trusted X11 Windows... over TWENTY YEARS AGO.
https://docs.oracle.com/cd/E18752_01/html/819-0869/windowapi...
https://docs.oracle.com/cd/E18752_01/html/819-0869/windowapi...
The non-existent X11 security model is irrelevant considering on most systems anything under a uid can debug something else under a uid. Wayland's security is entirely pointless.
I suspect Wayland will just become a container for an X11 session.
I suspect Wayland will just become a container for an X11 session.
This is not true on Ubuntu 18.04. I had to use sudo or change /proc or something to use gdb on other processes running on my user.
> considering on most systems anything under a uid can debug something else under a uid
Right? Couldn't only security hardened distros like SELinux take advantage of this?
Or I suppose Docker GUI apps?
Right? Couldn't only security hardened distros like SELinux take advantage of this?
Or I suppose Docker GUI apps?
Docker isn't a security layer
Security isn't the only thing Docker offers, but yes Docker on Linux is a security layer.
Please, please, please, people, don't impose your personal choice of font and background color on the rest of us. Faded beige background with light colored font makes this hard enough for me to read that I simply gave up. Yes, I have a particular issue since I'm partly red-green colorblind--but a substantial percentage of people have color perception issues of one sort or another. There's a reason why black text on a white background is so common.
I hear you. Thanks for the feedback. I'm planning on toning down the color scheme a lot now. I'll post further updates on the issue that you or someone else has raised on github: https://github.com/swalladge/swalladge.net/issues/1
The site should work nicely in reader view or through an rss reader which could be a temporary option until I can fix it. Sorry for the inconvenience :/
The site should work nicely in reader view or through an rss reader which could be a temporary option until I can fix it. Sorry for the inconvenience :/
Resolution: tweaked the font colours to be higher contrast and removed custom absolute font-weights. Please let me know if there are other accessibility issues with the site. :)
The font is easier to see now, but the background being as dark as it is still makes the font harder to read than if the background were white or something much closer to it.
Interestingly enough using Chrome on OSX it looked nothing like those screenshots and didn't bother me at all. I am also red green colour blind.
It has everything to do with the chosen font and how font-weight: 300 is displayed. The font-family is set to sans-serif and on my Linux system, it selects DejaVu Sans ExtraLight, which looks like that.
This is actually one reason to use webfonts, since you can be reasonably(ish) sure it looks more or less the same for everyone.
This is actually one reason to use webfonts, since you can be reasonably(ish) sure it looks more or less the same for everyone.
> This is actually one reason to use webfonts, since you can be reasonably(ish) sure it looks more or less the same for everyone.
This seems to be a general conflict between "it should look like the person who made it intended it" and "it should look like I want it to". For instance prescribing fonts and colors gives you a nice uniform look, but causes problems with dark themes or wanting other fonts, not to mention hijacking scrolling for fancy effects. Similarly, clientside decorations make apps like chrome look similar on all OSs, but also out of place on all of them.
This seems to be a general conflict between "it should look like the person who made it intended it" and "it should look like I want it to". For instance prescribing fonts and colors gives you a nice uniform look, but causes problems with dark themes or wanting other fonts, not to mention hijacking scrolling for fancy effects. Similarly, clientside decorations make apps like chrome look similar on all OSs, but also out of place on all of them.
If you're writing a blog post, IMO you shouldn't care about how the site looks, other than it being easy to read. The best way to make it easy to read is black text on a white background and no clutter (the latter, to be fair, is something this site does well).
Yep I think you've hit it. I've removed the custom font-weight so things should display normally with the user defined browser fonts as expected now.
Is it just me or do both of those look blurry? I want to poke my eyes out...
I think websites experimenting with different ways to style themselves is actually very good. The onus should be on the browser to provide you with tools to override those settings for your preference.
> I think websites experimenting with different ways to style themselves is actually very good.
I think websites experimenting with different ways to style themselves is misguided if the purpose of the site is for me to read what the author writes. I don't care what the author's preferred style is; I'm not reading the blog for its style. I'm reading it for its content.
I think websites experimenting with different ways to style themselves is misguided if the purpose of the site is for me to read what the author writes. I don't care what the author's preferred style is; I'm not reading the blog for its style. I'm reading it for its content.
You are not required to specify colours and fonts when making a web page, and I recommend that in most cases you don't; only specify the language and whether or not it is fixpitch/bold/italic/underline/strikeout. Don't impose your width either; let the user use the width of the window (they can resize if they don't like it).
Gnome/Wayland on Fedora works pretty well last time I used it. I eventually had to switch back for a few reasons (mouse over the network had no replacement) but that was almost a year ago I'd bet it was even smoother now.
My work laptop has been on wayland for years now. My desktop was on x11 due to nvidia drivers but now I have an amd card in it so I am back to wayland.
Not quite overall, at least from my perspective.
1. Adaptive sync still needs Wayland protocol support, before compositors can pick it up. It already works on X.
2. Some major features like common frameworks for screen capturing need to be agreed on, in order to avoid reinventing the wheel in tons of incompatible ways. Did everyone agree to use Pipewire, or it's still bikeshedded with everyone trying to do their own thing? I wasn't following this recently.
3. KWin has some major bugs to fix for the Wayland session, like subsurfaces clipping issue.
4. Support for Wacom drawing tablets is still missing in KWin on Wayland.
And so on.
1. Adaptive sync still needs Wayland protocol support, before compositors can pick it up. It already works on X.
2. Some major features like common frameworks for screen capturing need to be agreed on, in order to avoid reinventing the wheel in tons of incompatible ways. Did everyone agree to use Pipewire, or it's still bikeshedded with everyone trying to do their own thing? I wasn't following this recently.
3. KWin has some major bugs to fix for the Wayland session, like subsurfaces clipping issue.
4. Support for Wacom drawing tablets is still missing in KWin on Wayland.
And so on.
What I'm hearing is, by the time Wayland is actually on par with X, feature-wise, it will by time for a whole new rewrite because something else will be fundamentally different in the way graphics are rendered. Windows went full compositor with Vista in 2006, with all the features and then some of its predecessor (except you can't have windows with no v-sync). 14 years later Wayland almost has a standardized way of taking screenshots.
Possibly the part of the problem is, that there is no single owner and no one directs it. Everything seems chaotic, many things are low priority for developers, while in practice they are high priority for users and so on.
I suppose that's the natural consequence of Linux desktop stack being developed so collaboratively. And the fact that desktop itself is so fragmented (KDE, Gnome, etc.) doesn't help either. Resources are spread quite thin.
The major problem with Wayland is, that unlike X which is a unified point of collaboration, Wayland compositors need to do all the work on their own (unless they figure out how to share the effort, which doesn't go too well so far). So problems of fragmentation and lack of resources are only amplified in Wayland case, causing a huge delay in overall progress.
And I'm not saying all the above is a bad thing (some argue choices are good and etc.). But the downsides are obvious.
Personally, I'd prefer developers focusing more on KDE, but Gnome users would likely disagree.
I suppose that's the natural consequence of Linux desktop stack being developed so collaboratively. And the fact that desktop itself is so fragmented (KDE, Gnome, etc.) doesn't help either. Resources are spread quite thin.
The major problem with Wayland is, that unlike X which is a unified point of collaboration, Wayland compositors need to do all the work on their own (unless they figure out how to share the effort, which doesn't go too well so far). So problems of fragmentation and lack of resources are only amplified in Wayland case, causing a huge delay in overall progress.
And I'm not saying all the above is a bad thing (some argue choices are good and etc.). But the downsides are obvious.
Personally, I'd prefer developers focusing more on KDE, but Gnome users would likely disagree.
This is not out of the realm of the possibility. But by the time a new protocol is needed, applications will hopefully be much cleaner if they migrated to Wayland in between (less X-specific hacks, better compartmentalization of features). It would probably be easier to implement interface for backwards compatibility with Wayland than try to emulate the monolithic X (well, Xwayland is X running under Wayland because there's no other choice, so that's a possibility as well).
> 3. KWin has some major bugs to fix for the Wayland session, like subsurfaces clipping issue.
You're probably seeing a Qt bug there, not KWin: https://bugreports.qt.io/browse/QTBUG-54888
You're probably seeing a Qt bug there, not KWin: https://bugreports.qt.io/browse/QTBUG-54888
That's a different one, and it is a problem with KWin:
* https://bugs.kde.org/show_bug.cgi?id=387313
* https://phabricator.kde.org/T10530
* https://bugs.kde.org/show_bug.cgi?id=387313
* https://phabricator.kde.org/T10530
VAAPI support on Wayland is painful.
I've built a kiosk system that requires videos playing in Chrome/ium (cannot use Firefox because also need web-bluetooth support)
Our hardware is Intel NUCs and currently we are rolling these out on Windows OS, but would vastly prefer Linux but hitting so many roadblocks.
Trying to get Intel hardware accelerated GPU video decoding working in Chromium running on Wayland has wasted me days of time with no resolution yet (tried ClearLinux and CentOS 8 and Ubuntu 16).
With Wayland on Intel hardware, only VLC player can make use of VAAPI but Chromium doesn't seem possible, which results in 100% (Celeron) CPU usage trying to view a local video in the browser using video.js player.
I'm going to ditch Wayland (Gnome) and try Xfce on my next attempt.
I've built a kiosk system that requires videos playing in Chrome/ium (cannot use Firefox because also need web-bluetooth support)
Our hardware is Intel NUCs and currently we are rolling these out on Windows OS, but would vastly prefer Linux but hitting so many roadblocks.
Trying to get Intel hardware accelerated GPU video decoding working in Chromium running on Wayland has wasted me days of time with no resolution yet (tried ClearLinux and CentOS 8 and Ubuntu 16).
With Wayland on Intel hardware, only VLC player can make use of VAAPI but Chromium doesn't seem possible, which results in 100% (Celeron) CPU usage trying to view a local video in the browser using video.js player.
I'm going to ditch Wayland (Gnome) and try Xfce on my next attempt.
Are you sure you’re using a build of Chromium with VAAPI support patched in? Support for hardware video decoding in Firefox on Linux does not exist at all, and Chromium does not support it either except in a set of patches which are not included upstream.
yes I am using chromium-vaapi thanks.
[edit] I am about to try Arch Linux (or Manjaro) with Xfce to get Chromium-vaapi working
https://wiki.archlinux.org/index.php/Chromium#Hardware_video...
[edit] I am about to try Arch Linux (or Manjaro) with Xfce to get Chromium-vaapi working
https://wiki.archlinux.org/index.php/Chromium#Hardware_video...
I used to develop something like this (5-6 years ago). By far the best (most stable and performant) solution was the following:
One of the main benefits was that this avoided lots of resource leaks. The plugin pre-loaded mplayer processes and would shut them down after the video finished playing. Transitions were near to seamless (though required some HTML hacks to avoid white flashing).
On our Sandy Bridge machines (small form factor, fanless), we could display 16 1080p videos side-by-side for days and the machine would stay cool. I was so excited when I demonstrated this. The previous interation of this software used the regular <video> (software) implementation and could barely manage a single video without overheating.
Of course, NPAPI was deprecated a long time ago and removed from Chromium more than a year ago I think. The "replacement" (at the time) Pepper API AFAIK didn't allow access to the X window which is needed by mplayer. It was also not compatible between browsers. The plugin I made also worked on Firefox.
Nowadays access to the necessary resources is so walled off that you'd really need hardware acceleration to be native to the browser. There'd be hard-to-avoid resource leaks, so I'd schedule browser restarts at night-time. I've been out of the loop for a while so maybe there's better stuff. I remember monitoring the Chromium repository to see if they would implement hardware acceleration. I recall they had a branch where this was "working" on ChromeOS and supposedly you could force-enable this for general Linux. I tried building this once, but my machine at the time could barely handle building it (took many hours). Once the binary was built, it would crash at startup. I decided it was too much effort to replace a solution that was working perfectly.
- Linux OS (ease of management, installation, introspectability).
- Debian (somewhat stripped down), with custom packages.
- Puppet for node management.
- runit as a process manager.
- Chromium to display videos/presentations.
- (Custom) NPAPI based plugin (shim) that would load mplayer-vaapi (nowadays it would be mpv I guess) to display videos.
One of the main benefits was that this avoided lots of resource leaks. The plugin pre-loaded mplayer processes and would shut them down after the video finished playing. Transitions were near to seamless (though required some HTML hacks to avoid white flashing).
On our Sandy Bridge machines (small form factor, fanless), we could display 16 1080p videos side-by-side for days and the machine would stay cool. I was so excited when I demonstrated this. The previous interation of this software used the regular <video> (software) implementation and could barely manage a single video without overheating.
Of course, NPAPI was deprecated a long time ago and removed from Chromium more than a year ago I think. The "replacement" (at the time) Pepper API AFAIK didn't allow access to the X window which is needed by mplayer. It was also not compatible between browsers. The plugin I made also worked on Firefox.
Nowadays access to the necessary resources is so walled off that you'd really need hardware acceleration to be native to the browser. There'd be hard-to-avoid resource leaks, so I'd schedule browser restarts at night-time. I've been out of the loop for a while so maybe there's better stuff. I remember monitoring the Chromium repository to see if they would implement hardware acceleration. I recall they had a branch where this was "working" on ChromeOS and supposedly you could force-enable this for general Linux. I tried building this once, but my machine at the time could barely handle building it (took many hours). Once the binary was built, it would crash at startup. I decided it was too much effort to replace a solution that was working perfectly.
> only VLC player can make use of VAAPI
And mpv with "hwdec=vaapi" in ~/.config/mpv/mpv.conf
And mpv with "hwdec=vaapi" in ~/.config/mpv/mpv.conf
Here are the issues that I still have (other than that it seems smoother):
- I could not make copy/paste work from a Wayland host to Wayland guest in a Qemu/KVM VM. It seems that the guest utilities like spice vagent only work for Xorg.
- I noticed that chrome/firefox are still relying on X and run in XWayland (at least on my arch setup).
- Fractional scaling make some applications blurry but it seems that they are the ones running in Xwayland.
- I could not make copy/paste work from a Wayland host to Wayland guest in a Qemu/KVM VM. It seems that the guest utilities like spice vagent only work for Xorg.
- I noticed that chrome/firefox are still relying on X and run in XWayland (at least on my arch setup).
- Fractional scaling make some applications blurry but it seems that they are the ones running in Xwayland.
Most xorg drivers have an option to run in tearfree mode.
Another dealbreaker for me (i did the i3 sway journey this summer) is the early stage of remote desktop. With x it is super easy to spin up a nice vncserver. I also miss setxkbmap, xrandr, import etc.
Wayland had some nice ideas and some not so useful ones. I'm waiting for something simple to replace xorg and wayland in the future.
Another dealbreaker for me (i did the i3 sway journey this summer) is the early stage of remote desktop. With x it is super easy to spin up a nice vncserver. I also miss setxkbmap, xrandr, import etc.
Wayland had some nice ideas and some not so useful ones. I'm waiting for something simple to replace xorg and wayland in the future.
Tear free mode has never worked for me on multi-monitor setups. All Xorg drivers have this issue in my experience. Nvidia, AMD, Intel and even the modesetting driver. Wayland seems to magically fix it.
Strange, it seems to work fine for me on 2 FHD monitors at least. Maybe I just don't see it...
Hmm. Perhaps it has something to do with the fact that the refresh rates of my two monitors are not exactly the same.
Any news on remoting Wayland? This article kinda ignores it, but I don't see how it's not a complete showstopper.
The Waypipe Summer of Code project implemented that recently:
https://gitlab.freedesktop.org/mstoeckl/waypipe https://lists.freedesktop.org/archives/wayland-devel/2019-Au...
https://gitlab.freedesktop.org/mstoeckl/waypipe https://lists.freedesktop.org/archives/wayland-devel/2019-Au...
Outstanding. Are they software rendering at the client and shoving raw images? Remote GPU from scratch strikes me as an even bigger job.
Since it’s SOC there was a blog post for it that got posted here. Should be findable with some searching.
> NetworkManager GUI tools were strangely buggy with wayland. It wouldn't always crash, but sometimes the only way I could get it to connect to a wifi network was to quit sway, launch i3, connect with nm-applet in i3, then switch back to sway.
I haven't tried using something else than nmtui, TBH
> Sometimes, Sway would crash while the screen was locked, leaving my previously secured computer at a logged-in tty
Ah! I've had some issues running SysRq+R, then Ctrl+C. The tty intreprets this as my wanting to quit sway :/
I was actually disappointed to find out that screensharing not working was preventing me from using Steam's in-home streaming (or Steam Remote Play, as it's now called). I hope sway can fix that for Xwayland apps at some point.
I haven't tried using something else than nmtui, TBH
> Sometimes, Sway would crash while the screen was locked, leaving my previously secured computer at a logged-in tty
Ah! I've had some issues running SysRq+R, then Ctrl+C. The tty intreprets this as my wanting to quit sway :/
I was actually disappointed to find out that screensharing not working was preventing me from using Steam's in-home streaming (or Steam Remote Play, as it's now called). I hope sway can fix that for Xwayland apps at some point.
For me KDE has offered the best Wayland experience. It's easy to switch between X or Wayland.
I'm using the latest Ubuntu to run an art installation. So far I've been unable to launch GUI apps or take screenshots from a remote SSH terminal under Wayland. I had to resort to adding the commands to autostart & rebooting.
Tried to use Wayland earlier today on Ubuntu 18.04 for fractional scaling support, but sadly there is no support for nvidia drivers. This does not seem well advertised so posting as a PSA to save others from trying to debug the login loop!
To clarify, it does support nvidia through the open source nouveau drivers. It's only the proprietary drivers that aren't supported.
You mean it does not support the drivers that actually work?
It depends what you call working. Nvidia proprietary driver has a broken wayland implementation (a choice that nvidia made), whereas nouveau has a working one.
Better pick AMD or even Intel GPUs on Linux as drivers are much better.
Yes exactly. I don't recommend nvidia.
This is a good reason to select different new hardware but insufficient to get rid of existing hardware.
If most people agree we can worry less in 5-10 years. Unless people work around it during this time frame in which case people can continue not caring.
If most people agree we can worry less in 5-10 years. Unless people work around it during this time frame in which case people can continue not caring.
I've tried wayland around half a year ago, but switched back. Wayland was surprisingly usable, but a couple of features were missing that are essential for me for example color management.
I just cannot get Wayland work on a VirtualBox instance of Ubuntu, with the host being MacOS Catalina on an iMac Retina. The screen just keeps flickering.
I would love it if Wayland would work!
I would love it if Wayland would work!
> Screen recording or sharing apps just don't work. Zoom with XWayland appeared to work, but in reality only shared a blank screen. This was kind of a deal breaker, because sooner or later I will need to use screen sharing in Zoom for work.
Isn't this one of they key points FOR Wayland, though? I thought Wayland specifically stops applications from having access to other chunks of the screen without special permissions?
Isn't this one of they key points FOR Wayland, though? I thought Wayland specifically stops applications from having access to other chunks of the screen without special permissions?
"Doesn't give access by default" is very different from "cannot be made to work".
I'd assume the complaint is about the latter, which is a issue. I can't imagine anyone complaining about the first.
I'd assume the complaint is about the latter, which is a issue. I can't imagine anyone complaining about the first.
Lack of support for screensharing is why I stopped using Wayland.
Last time I tried to migrate to wayland on a hidpi device, scaling wayland 2x would scale all xwayland windows naively by doubling pixels. In particular, this made graphical emacs fonts blurry. Is there a way to fix that, i.e. letting wayland apps scale natively, but scale xwayland apps using the regular X dpi setting (Xft.dpi and the like)?
Emacs may be old and crufty, but unfortunately is my most often used graphical application.
Emacs may be old and crufty, but unfortunately is my most often used graphical application.
The problem with Wayland is the extremely long tail of use-cases that it does not cover (yet).
(For example, I use VNC extensively and it has a lot of issues there still)
(For example, I use VNC extensively and it has a lot of issues there still)
What happened to Mir if Wayland is the only viable x11 alternative?
A cruel friend has suggested everything touched by Ubuntu billionaire founder Shuttleworth turns to manure but I think this isn't so helpful to understand why Mir seemingly died completely? Even GnuHurd hasn't died so dramatically..?
A cruel friend has suggested everything touched by Ubuntu billionaire founder Shuttleworth turns to manure but I think this isn't so helpful to understand why Mir seemingly died completely? Even GnuHurd hasn't died so dramatically..?
Due to the huge PR fuckup that was the Mir announcement, they never gained much traction in the greater community. And a display stack needs a lot of community support across the whole ecosystem: kernel support, kernel drivers, user space drivers, widget libraries, applications etc... none of these parties were willing to support Mir in any way.
Mir is now a Wayland compositor.
> Wayland has xwayland, which somehow provides mini embedded X server(s) for GUI apps that don't support wayland yet. I kept this disabled when switching, going for the "pure" Wayland experience.
this seems like a really limiting decision in deciding how viable wayland is.
this seems like a really limiting decision in deciding how viable wayland is.
[deleted]
Is wayland viable for gaming yet or does it still add an extra frame or two of latency?
Ive been using wayland and sway for about 2 weeks now.
My experience is this.
If it's compiled to run for Wayland. Fan f-in tastic. No hiccups, no random screen tears or visual glitches of any kind. My logs are surprisingly sparse and when there is a configuration issue it's something trivial i overlooked and easily fixed.
Now here is the issue. When it comes to X-Wayland. Well lets just say that my opinion of X-wayland can be boiled down to two major criticisms.
1. It's turning into another X11. I've been trying to get apps that should just work out of the box when running on gtk like Google Chrome. And frankly looking at the bug reports and hack ass solutions to get things like Video Hardware Acceleration to function using X-Wayland... Nightmarish to say the least and glad it's not my job.
2. I think history has shown time and time again with debacles like Apple trying to retain backwards capability for powerpc MacOS or Windows ensuring your archaic MS-DOS application at work doesn't end up need an expensive update.... that any time you try to not throw things away that need to be thrown away, regardless of how sentimental they might be, you always end up a dead hoarder buried somewhere in your house where nobody can find you but they can sure as hell smell you; so they know you are in there somewhere... Where ever the hell that may be.
My attitude when it come's to the critics of Wayland is to say build something better or shut up and just not use it and keep letting X11 make the desktop experience on Linux suck on two fronts.
The first where nobody who is working on it actually knows how the entire thing works except maybe a handful of people. (all of whom are btw wayland core developers).
And the second, where things just don't work like they should out of the box on whichever desktop environment circumstance you may be in. When you have such a complicated API you end up with 50 million different ways 50 million different developers can write bugs into the 50 millionth reimplementation of your system.
There is a reason why Unix was the most ripped off and successful operating system in the world. It's not because it had X11...
My experience is this.
If it's compiled to run for Wayland. Fan f-in tastic. No hiccups, no random screen tears or visual glitches of any kind. My logs are surprisingly sparse and when there is a configuration issue it's something trivial i overlooked and easily fixed.
Now here is the issue. When it comes to X-Wayland. Well lets just say that my opinion of X-wayland can be boiled down to two major criticisms.
1. It's turning into another X11. I've been trying to get apps that should just work out of the box when running on gtk like Google Chrome. And frankly looking at the bug reports and hack ass solutions to get things like Video Hardware Acceleration to function using X-Wayland... Nightmarish to say the least and glad it's not my job.
2. I think history has shown time and time again with debacles like Apple trying to retain backwards capability for powerpc MacOS or Windows ensuring your archaic MS-DOS application at work doesn't end up need an expensive update.... that any time you try to not throw things away that need to be thrown away, regardless of how sentimental they might be, you always end up a dead hoarder buried somewhere in your house where nobody can find you but they can sure as hell smell you; so they know you are in there somewhere... Where ever the hell that may be.
My attitude when it come's to the critics of Wayland is to say build something better or shut up and just not use it and keep letting X11 make the desktop experience on Linux suck on two fronts.
The first where nobody who is working on it actually knows how the entire thing works except maybe a handful of people. (all of whom are btw wayland core developers).
And the second, where things just don't work like they should out of the box on whichever desktop environment circumstance you may be in. When you have such a complicated API you end up with 50 million different ways 50 million different developers can write bugs into the 50 millionth reimplementation of your system.
There is a reason why Unix was the most ripped off and successful operating system in the world. It's not because it had X11...
hooray, finally a wayland criticism article that actually put in some effort instead of "muh unix philosophy". most of these issues are real issues for wayland today, and the author might be right to switch back to X for now. however, I'll try to explain some of the issues:
> I had consistent font rendering issues. There was this painful issue in sway relating to display scaling that caused fonts (among other things) to be missing, fuzzy, or just terrible in general.
yup, still a problem. hidpi doesn't work great on X in the first place, and adding Xwayland definitely makes it worse for X applications. but, once the majority of applications are ported to wayland, hidpi should become much, much better.
> NetworkManager GUI tools were strangely buggy with wayland. It wouldn't always crash, but sometimes the only way I could get it to connect to a wifi network was to quit sway, launch i3, connect with nm-applet in i3, then switch back to sway. Bizarre.
personally, I recommend using either raw wpa_supplicant or iwd with a separate network management daemon (dhcpcd or systemd-networkd). the wpa_supplicant GUI is very ugly and uses weird terminology (what's a "PSK" -- yes, I know what it is, but if you didn't, you'd have to google it), but if you can get over that hump as well as the initial configuration, it's been 100% reliable for me, unlike NM, which usually works but then sometimes silently fails somewhere. I recently switched to iwd, which has been mostly fine, but, like wayland, still lacking features important for some people.
> Sometimes, on my desktop, everything would lock up for 10 seconds or so, the screen would blank, and then come back on and everything would be fine. It appeared to be some issue with the graphics drivers - I don't have that issue on i3, so something deep in Wayland is interacting strangely with it.
I would assume you are using intel drivers and are experiencing a GPU reset. check dmesg, but it's quite possible that a poorly behaved application is causing the trouble.
> Screen recording or sharing apps just don't work. Zoom with XWayland appeared to work, but in reality only shared a blank screen. This was kind of a deal breaker, because sooner or later I will need to use screen sharing in Zoom for work.
yeah, this is definitely a problem. as other commenters have said, ordinary applications aren't allowed to just record the screen, they have to ask the compositor. unfortunately, this has not yet been standardized between different wayland implementations. iirc, gnome has a screen recording api, kde has one, and wlroots has another, and they're all incompatible. my current solution for sway is to use wf-recorder + v4l2loopback, which works fairly well but is a little bit hard to set up. install wf-recorder-git and v4l2loopback-dkms-git, then modprobe v4l2loopback exclusive_caps=1 video_nr=7 && wf-recorder -m v4l2 -f /dev/video7 -c rawvideo --pixel-format=yuv420p. then you'll have a fake camera device which you can select in your streaming application. that works for me on Firefox 70 and Chromium 78, so it should work for Zoom too. the workflow is not as smooth as built-in screen sharing (for one, you can't display two "cameras" at once), but it works well enough for most purposes.
> Sometimes, Sway would crash while the screen was locked, leaving my previously secured computer at a logged-in tty. Not great for security!
this is actually very easy to solve.
solution 1: instead of running sway, run exec sway.
solution 2: instead of running swaylock, run physlock. if security is a high priority for you, this is probably better anyways.
> I had consistent font rendering issues. There was this painful issue in sway relating to display scaling that caused fonts (among other things) to be missing, fuzzy, or just terrible in general.
yup, still a problem. hidpi doesn't work great on X in the first place, and adding Xwayland definitely makes it worse for X applications. but, once the majority of applications are ported to wayland, hidpi should become much, much better.
> NetworkManager GUI tools were strangely buggy with wayland. It wouldn't always crash, but sometimes the only way I could get it to connect to a wifi network was to quit sway, launch i3, connect with nm-applet in i3, then switch back to sway. Bizarre.
personally, I recommend using either raw wpa_supplicant or iwd with a separate network management daemon (dhcpcd or systemd-networkd). the wpa_supplicant GUI is very ugly and uses weird terminology (what's a "PSK" -- yes, I know what it is, but if you didn't, you'd have to google it), but if you can get over that hump as well as the initial configuration, it's been 100% reliable for me, unlike NM, which usually works but then sometimes silently fails somewhere. I recently switched to iwd, which has been mostly fine, but, like wayland, still lacking features important for some people.
> Sometimes, on my desktop, everything would lock up for 10 seconds or so, the screen would blank, and then come back on and everything would be fine. It appeared to be some issue with the graphics drivers - I don't have that issue on i3, so something deep in Wayland is interacting strangely with it.
I would assume you are using intel drivers and are experiencing a GPU reset. check dmesg, but it's quite possible that a poorly behaved application is causing the trouble.
> Screen recording or sharing apps just don't work. Zoom with XWayland appeared to work, but in reality only shared a blank screen. This was kind of a deal breaker, because sooner or later I will need to use screen sharing in Zoom for work.
yeah, this is definitely a problem. as other commenters have said, ordinary applications aren't allowed to just record the screen, they have to ask the compositor. unfortunately, this has not yet been standardized between different wayland implementations. iirc, gnome has a screen recording api, kde has one, and wlroots has another, and they're all incompatible. my current solution for sway is to use wf-recorder + v4l2loopback, which works fairly well but is a little bit hard to set up. install wf-recorder-git and v4l2loopback-dkms-git, then modprobe v4l2loopback exclusive_caps=1 video_nr=7 && wf-recorder -m v4l2 -f /dev/video7 -c rawvideo --pixel-format=yuv420p. then you'll have a fake camera device which you can select in your streaming application. that works for me on Firefox 70 and Chromium 78, so it should work for Zoom too. the workflow is not as smooth as built-in screen sharing (for one, you can't display two "cameras" at once), but it works well enough for most purposes.
> Sometimes, Sway would crash while the screen was locked, leaving my previously secured computer at a logged-in tty. Not great for security!
this is actually very easy to solve.
solution 1: instead of running sway, run exec sway.
solution 2: instead of running swaylock, run physlock. if security is a high priority for you, this is probably better anyways.
Thanks for these comments!
I definitely need to migrate away from NetworkManager; I think you just gave me the motivation to do so. :)
I definitely need to migrate away from NetworkManager; I think you just gave me the motivation to do so. :)
You might find 'nmtui' (Network Manager Text User Interface) more helpful if you prefer an ncurses based interface similar to the GUI nm-applet (but it doesn't work for GUI-only configuration extensions for some VPNs, etc.)
'nmcli' is good for basics, eg:
nmcli == connection summary inc. addresses, routes, DNS
nmcli dev wifi == wifi networks found (inc. specs)
nmcli dev wifi rescan
nmcli con == list configured connections
nmcli con up Connection-Name
nmcli con down Connection-Name
most of the above support intelligent tab-completion including of (space containing) connection names.
'nmcli' is good for basics, eg:
nmcli == connection summary inc. addresses, routes, DNS
nmcli dev wifi == wifi networks found (inc. specs)
nmcli dev wifi rescan
nmcli con == list configured connections
nmcli con up Connection-Name
nmcli con down Connection-Name
most of the above support intelligent tab-completion including of (space containing) connection names.
FWIW I am using nmcli and it work good enough for me.
Iwd is much better for WiFi.
on the lack of clipboard history: https://github.com/sentriz/cliphist this exists and is pretty good.
I lost the faith, guess Joel law of not rewriting things was again upheld.
The thing about scaling is a bit difficult. Sway chooses to render XWayland windows in the lower resolution and scales up, rather than the other way around; I think this should be configurable.
I don't see what would make such a configuration option particularly difficult. Maybe file a bug report requesting it? The scaling difficulties are fundamentally a problem with XWayland so you're left with two problematic options.
> The scaling difficulties are fundamentally a problem with XWayland
Well, sort of. There are fundamental issues with having per-display scaling in X. If you plug in a HiDPI display after starting an application, it's my understanding that there is no standard way to signal that to a window.
The toolkits, or GTK+3 at least, do handle changing the scale at runtime internally, so it's more of a social problem than a hard engineering one.
Well, sort of. There are fundamental issues with having per-display scaling in X. If you plug in a HiDPI display after starting an application, it's my understanding that there is no standard way to signal that to a window.
The toolkits, or GTK+3 at least, do handle changing the scale at runtime internally, so it's more of a social problem than a hard engineering one.
I don't agree with the assumption that we need to ditch X11 entirely. Implementations are different from the spec, and a common complaint I have is that certain implementations are gathering code smells like nobody's business.
You can fix both an implementation and a spec by continued review and revision, while making choices to either remain backwards compatible or breaking that compatibility with newer revisions. I don't think Wayland is a good solution to this kind of problem, despite it being touted as one in many circles I've witnessed.
The competition is nice, though! I have yet to give Wayland a try, but it's on my to-do list some time on a fresh machine.
You can fix both an implementation and a spec by continued review and revision, while making choices to either remain backwards compatible or breaking that compatibility with newer revisions. I don't think Wayland is a good solution to this kind of problem, despite it being touted as one in many circles I've witnessed.
The competition is nice, though! I have yet to give Wayland a try, but it's on my to-do list some time on a fresh machine.
One of the arguments made by the Wayland spec folks (many of whom were involved in Xorg development for many years) is that the Xorg spec is also a major cause of problems with modern Linux graphics[1].
[1]: https://www.youtube.com/watch?v=cQoQE_HDG8g
[1]: https://www.youtube.com/watch?v=cQoQE_HDG8g
I agree with you. X isn't so bad and implementations are different from the spec (see my message about my proposed X12, which makes this more explicit).
X has long been a crufty dusty codebase. Due to a small amount of people that obsess about networking it has stayed alive. Hopefully Wayland hits critical mass and x can finally be old yellered as it should have been twenty years ago
Due to the down votes let me clarify. X sucks
Due to the down votes let me clarify. X sucks
I want things that only work under x that aren't spacebar heating.
How many Linux users have only one computer? The MBP work put on my desk is a toy compared to the thousands of Linux boxes they give me access to.
Summary: yes, unless you use video conferencing and screen sharing software, which is likely to be totally broken (but see Hello71's comment). The author needs to use Zoom, so he reverted to X11.
That's not at all an accurate summary. I'd cover why but really the article is apt and to the point on doing so without summarization IMO.
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.
[0] https://github.com/swaywm/sway/wiki#nvidia-users [1] https://github.com/swaywm/sway/blob/3334d11adc926c0f6d86afc4...