6 ms·

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 fr

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.

roenxi 7y ago
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.
- Hello71 7y ago
  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 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.
- ChrisSD 7y ago
  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.
  - sprash 7y ago
    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.
    - mixmastamyk 7y ago
      Do tell. I’ve found dbus hard to understand, but it works reliably here.
      - sprash 7y ago
        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.
        andrewshadura 7y ago
        D-Bus does not use JSON.
        sprash 7y ago
        Indeed it uses XML which is even worse!
        compressedgas 7y ago
        Only as a description language. The message format is a subset of GVariants.
- danShumway 7y ago
  > 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.
  - roenxi 7y ago
    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.
    - glennpratt 7y ago
      > 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.
    - deleted 7y ago
- josefx 7y ago
  > 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.
  - imtringued 7y ago
    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.
- arghwhat 7y ago
  > 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).
- vertex-four 7y ago
  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.
deleted 7y ago
[deleted]
baroffoos 7y ago
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.
- sprash 7y ago
  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.
  - MayeulC 7y ago
    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.
    - sprash 7y ago
      > 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.
arghwhat 7y ago
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.
- Boulth 7y ago
  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.)
msla 7y ago
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.

roenxi 7y ago

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.

Hello71 7y ago
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 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.
ChrisSD 7y ago
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.
- sprash 7y ago
  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.
  - mixmastamyk 7y ago
    Do tell. I’ve found dbus hard to understand, but it works reliably here.
    - sprash 7y ago
      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.
      - andrewshadura 7y ago
        D-Bus does not use JSON.
        sprash 7y ago
        Indeed it uses XML which is even worse!
        compressedgas 7y ago
        Only as a description language. The message format is a subset of GVariants.
danShumway 7y ago
> 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.
- roenxi 7y ago
  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.
  - glennpratt 7y ago
    > 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.
  - deleted 7y ago
josefx 7y ago
> 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.
- imtringued 7y ago
  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.
arghwhat 7y ago
> 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).
vertex-four 7y ago
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.

deleted 7y ago

[deleted]

baroffoos 7y ago

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.

sprash 7y ago
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.
- MayeulC 7y ago
  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.
  - sprash 7y ago
    > 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.

arghwhat 7y ago

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.

Boulth 7y ago
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.)

msla 7y ago

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.