7 ms·

So far there is no viable replacement around that is "more adequate for the job" (Wayland is fundamentally flawed at the concept level). So Xorg will stick arou

by sprash 5y ago

So far there is no viable replacement around that is "more adequate for the job" (Wayland is fundamentally flawed at the concept level). So Xorg will stick around much longer probably decades.

kaba0 5y ago
How would Wayland be fundamentally flawed?
- sprash 5y ago
  Wayland makes the wrong abstractions and does not offer vital functionality usually needed on a Desktop system. As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.
  - xxpor 5y ago
    Why are objections like this not solved with things like wlroots?
    - folmar 5y ago
      wlroots are not used by the two main desktops, so to get basic features like screenshots you need to support 3 different ways already.
      - kaba0 5y ago
        Wlroots is an implementation of wayland protocols — if gnome and plasma implement the same protocol according to specification, you only have to write code to that protocol, once.
        yjftsjthsd-h 5y ago
        Right, but that protocol isn't in wayland proper and isn't standardized, so GNOME and KDE and wlroots all have different takes.
        dralley 5y ago
        Right, but the point is that the protocol doesn't need to be in Wayland proper, so long as it's standardized somewhere. And it is. https://flatpak.github.io/xdg-desktop-portal/portal-docs.html https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
      - boudin 5y ago
        You're mistaken, that's not the role of wayland. If you're looking into an universal way to takr screenshots, screesncast, etc..., you're looking for xdg-desktop-portal. There'is implementations for wlroots, gnome, qt, and others.
        wing-_-nuts 5y ago
        >You're mistaken, that's not the role of wayland. A side note, but I really hate this ideology of 'x does one thing' outside of command line tools. This is a display server we're talking about. It should be able to enable normal desktop usage. Maybe not everything but core features like brightness control, screen sharing, screenshots, etc. Otherwise every wm that comes along is going to have to reinvent the wheel. There are tons of really great window managers out there, where the authors have looked at all the work it will take to get running on wayland, and have simply thrown their hands up in frustration. It seems to me the only people that really benefit from the switch to wayland are the wayland devs themselves.
        xxpor 5y ago
        All I know is as a user, Wayland lets me have reasonable HiDPI support (where 2 monitors can have different scale levels). And I can't on X.
        dralley 5y ago
        Wayland is not a display server, it's a display protocol. There is no "display server" in the architecture.
        wing-_-nuts 5y ago
        I, as a user, do not give a rats ass if it's a protocol or server. I don't want to lose functionality just because some group of devs prefers to do a rewrite of something. I've used gnome wayland, and sway. It's pretty damning that so few other window managers support wayland due to the sheer difficulty of the task.
  - craftinator 5y ago
    > As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots. As someone who tried to do this... Ouch. Things like this are why X will still be around in 15 years.
    - markstos 5y ago
      Wayland as a `screencopy` protocol and the `wlroots` library packages it for other compositors to use. Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? Ref: https://wayland.app/protocols/wlr-screencopy-unstable-v1 https://wayland.app/protocols/wlr-screencopy-unstable-v1
      - craftinator 5y ago
        > Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? In general, when your diagnosis to a problem is "the people using my product are all just too lazy to use it right", the problem is almost always that your product is the problem.
      - folmar 5y ago
        Not really - to quote the page you reference: > "Warning! The protocol described in this file is experimental and backward incompatible changes may be made. and the compositors were there way before 2018, so it's a bit too much to expect them to jump on the protocol.
  - tosihakkeri 5y ago
    Based on what you just wrote, it sounds to me that you might be assuming the wrong abstraction yourself.
  - kaba0 5y ago
    Wayland as a display protocol (correctly) started out with a tiny core, which can display the content of a window, and manage available extensions by version. This has grown out to be a really great abstraction, where later multiple implementations can decide on new protocols/extensions to support. And they have already done plenty of such extensions, and they are compatible with each other. Remember, these are protocols. There is no need to implement them yourself, they can be made into a library, like wlroots, and you can build your compositor on that base, without any repetition. Also, multiple implementations only mean that there won’t be implementation-specific quirks. As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue perfectly, and it is indeed working correctly for like a year already, with screen share even in proprietary apps like teams.
    - enriquto 5y ago
      > As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue If I understand the OP correctly, this sort of philosophy is deeply troubling to some people. For simplicity-oriented folks, trivial things should be trivial, as a matter of principle. If some trivial thing becomes slightly less convenient so that complex stuff may be possible, this is an unacceptable compromise; or at least a very worrying one. When taking static screenshots requires an entire "project" that is "just ready this year" , the threshold of unacceptability is long surpassed. I get that wayland folks do not share this worldview and they want to do the right thing, even at the expense of sacrifying things that were previously easy. But, to other people, this rubs them in a very wrong way.
      - kaba0 5y ago
        wlroots does implement a very simple screenshot protocol, the reason I didn’t mention it was that it is not cross-wayland-implementation. But there is nothing inherent in wayland that would prevent this functionality — they just try to find a good abstraction they all can stick to (as these APIs will likely be used for a long time), and gnome and plasma people have a different view on that. (Also, if we have a complex program that does all the things we need and a simple program+the complex one, we will have more complexity in the latter case so the previous one may be preferred)
  - bitwize 5y ago
    > As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. Or, compositors can use these wonderful things we have called dynamic libraries, and simply link against implementations of that desktop functionality, such as wlroots -- which implementations, by the way, will be far less crufty and ad hoc than the equivalent X11 solution! Much of the reason why X is the way it is is because back in the day, Unix lacked dynamic libraries in general, so in order to share an implementation of, say, graphics primitives, the best way was to write a server that implemented them and have clients communicate with that server. Now that we have dynamic libraries, we can share a single implementation of graphics rendering across multiple programs, and still have all the speed advantages of doing all the rendering client side!
  - bitwize 5y ago
    I'm sure the architects of Xorg have a much better idea of which abstraction to use and why it's superior to Wayland. Oh wait, the architects of Xorg designed Wayland! X11 is a dead end. Its authors have deprecated it and offered an upgrade path: Wayland. Time to make like Elsa and let it go.
    - a1369209993 5y ago
      > the architects of Xorg Xorg was designed decades ago. The architects of Xorg are dead, retired, or overwritten with their stupider future selves; you're talking about maintainers.
      - marcodiego 5y ago
        Xorg was not designed. It organically evolved.
        a1369209993 5y ago
        ... Okay, that's fair, but not really my point.
wing-_-nuts 5y ago
>Wayland is fundamentally flawed at the concept level Expand?
- sprash 5y ago
  The biggest problem of Wayland is that it has the wrong philosophy ("Every frame is perfect") and the wrong abstractions ("Everything in the universe is an array with RGBA values"). If your foundations are flawed like that you are doomed from the start. What remains is a very expensive and cumbersome way of blitting bitmaps.
  - margalabargala 5y ago
    Presumably the designers of Wayland do not think that this philosophy and those abstractions are so fundamentally flawed. Could you explain why these concepts are so flawed, for those of us to whom it is not immediately obvious?
    - sprash 5y ago
      For some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames. Also displays have different pitch values, subpixel arrangements, color spaces, etc. A line from A to B might look completely different on different monitors. By offering only RGB arrays as abstraction Wayland pushes the the need for care of those differences down to clients which is a mistake. Additionally a Desktop system in general is much more than a bunch of bitmaps blittet together. Applications need to interact and such functionality has to be tightly integrated into the compositor with standardized protocols otherwise it will be impossible to have such functionality. Taking screenshots, drawing to the root window or knowing about coordinates of windows from other programs are some examples.
      - kaba0 5y ago
        > For some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames Oh and what gives, wayland just has an extension for this use case! HDR is work in progress, there is nothing unchangeable in Wayland that would disallow different buffer types.
pengaru 5y ago
> (Wayland is fundamentally flawed at the concept level) That's a mighty big hand you're waving.
hsbauauvhabzb 5y ago
As a consumer/power user with a fairly bespoke window manager I’m worried that the minimalist approach to wayland will fragment functionality depending on compostor / DE. Wanna use Firefox? gotta use gnome compostor for that! Chromium only works on KDE compostor, etc. Is this a misguided fear, or do you anticipate it moving that way?
- nani8ot 5y ago
  I think these worries are unfounded atm, because compatibility is good for most applications, even though there are some tools specific to a compositor (e.g. waypipe for wlroots based compositors). For the case of minimal window managers, there is wlroots, which is designed to be used to write a compositor. The first line of the wlroots repo[1] states: »Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.« And there are at least three[2] actively maintained compositors based on wlroots. Sway being the most popular, the one for which wlroots was initially developed for. I believe that there won't be too many incompatibilities, because there are 3 (4, including weston) wayland compositors developed (Gnome's, KDE's & wlroots based), all three of them having their own use cases. Using protocol extensions only useable on one compositor would limit the app to a subset of Linux Desktops (and mobile), so if possible, most apps won't use them. PS: I just remembered one case of fragmentation: Activity Watch, a tool to keep track which apps are used how long and to track idle times, won't be able to support Gnome (mutter), because Gnome dev's won't implement the necessary freedesktop protocol extension. Sway (and KDE?) does, so it works on them. One solution would be to write a Gnome Shell extension, but yeah, it's not as easy as on X.org (reason being privacy, in this case). [1] https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots [2] https://arewewaylandyet.com/ https://arewewaylandyet.com/

by sprash 5y ago

So far there is no viable replacement around that is "more adequate for the job" (Wayland is fundamentally flawed at the concept level). So Xorg will stick around much longer probably decades.

kaba0 5y ago

How would Wayland be fundamentally flawed?

sprash 5y ago
Wayland makes the wrong abstractions and does not offer vital functionality usually needed on a Desktop system. As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.
- xxpor 5y ago
  Why are objections like this not solved with things like wlroots?
  - folmar 5y ago
    wlroots are not used by the two main desktops, so to get basic features like screenshots you need to support 3 different ways already.
    - kaba0 5y ago
      Wlroots is an implementation of wayland protocols — if gnome and plasma implement the same protocol according to specification, you only have to write code to that protocol, once.
      - yjftsjthsd-h 5y ago
        Right, but that protocol isn't in wayland proper and isn't standardized, so GNOME and KDE and wlroots all have different takes.
        dralley 5y ago
        Right, but the point is that the protocol doesn't need to be in Wayland proper, so long as it's standardized somewhere. And it is. https://flatpak.github.io/xdg-desktop-portal/portal-docs.html https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
    - boudin 5y ago
      You're mistaken, that's not the role of wayland. If you're looking into an universal way to takr screenshots, screesncast, etc..., you're looking for xdg-desktop-portal. There'is implementations for wlroots, gnome, qt, and others.
      - wing-_-nuts 5y ago
        >You're mistaken, that's not the role of wayland. A side note, but I really hate this ideology of 'x does one thing' outside of command line tools. This is a display server we're talking about. It should be able to enable normal desktop usage. Maybe not everything but core features like brightness control, screen sharing, screenshots, etc. Otherwise every wm that comes along is going to have to reinvent the wheel. There are tons of really great window managers out there, where the authors have looked at all the work it will take to get running on wayland, and have simply thrown their hands up in frustration. It seems to me the only people that really benefit from the switch to wayland are the wayland devs themselves.
        xxpor 5y ago
        All I know is as a user, Wayland lets me have reasonable HiDPI support (where 2 monitors can have different scale levels). And I can't on X.
        dralley 5y ago
        Wayland is not a display server, it's a display protocol. There is no "display server" in the architecture.
        wing-_-nuts 5y ago
        I, as a user, do not give a rats ass if it's a protocol or server. I don't want to lose functionality just because some group of devs prefers to do a rewrite of something. I've used gnome wayland, and sway. It's pretty damning that so few other window managers support wayland due to the sheer difficulty of the task.
- craftinator 5y ago
  > As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots. As someone who tried to do this... Ouch. Things like this are why X will still be around in 15 years.
  - markstos 5y ago
    Wayland as a `screencopy` protocol and the `wlroots` library packages it for other compositors to use. Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? Ref: https://wayland.app/protocols/wlr-screencopy-unstable-v1 https://wayland.app/protocols/wlr-screencopy-unstable-v1
    - craftinator 5y ago
      > Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots? In general, when your diagnosis to a problem is "the people using my product are all just too lazy to use it right", the problem is almost always that your product is the problem.
    - folmar 5y ago
      Not really - to quote the page you reference: > "Warning! The protocol described in this file is experimental and backward incompatible changes may be made. and the compositors were there way before 2018, so it's a bit too much to expect them to jump on the protocol.
- tosihakkeri 5y ago
  Based on what you just wrote, it sounds to me that you might be assuming the wrong abstraction yourself.
- kaba0 5y ago
  Wayland as a display protocol (correctly) started out with a tiny core, which can display the content of a window, and manage available extensions by version. This has grown out to be a really great abstraction, where later multiple implementations can decide on new protocols/extensions to support. And they have already done plenty of such extensions, and they are compatible with each other. Remember, these are protocols. There is no need to implement them yourself, they can be made into a library, like wlroots, and you can build your compositor on that base, without any repetition. Also, multiple implementations only mean that there won’t be implementation-specific quirks. As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue perfectly, and it is indeed working correctly for like a year already, with screen share even in proprietary apps like teams.
  - enriquto 5y ago
    > As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue If I understand the OP correctly, this sort of philosophy is deeply troubling to some people. For simplicity-oriented folks, trivial things should be trivial, as a matter of principle. If some trivial thing becomes slightly less convenient so that complex stuff may be possible, this is an unacceptable compromise; or at least a very worrying one. When taking static screenshots requires an entire "project" that is "just ready this year" , the threshold of unacceptability is long surpassed. I get that wayland folks do not share this worldview and they want to do the right thing, even at the expense of sacrifying things that were previously easy. But, to other people, this rubs them in a very wrong way.
    - kaba0 5y ago
      wlroots does implement a very simple screenshot protocol, the reason I didn’t mention it was that it is not cross-wayland-implementation. But there is nothing inherent in wayland that would prevent this functionality — they just try to find a good abstraction they all can stick to (as these APIs will likely be used for a long time), and gnome and plasma people have a different view on that. (Also, if we have a complex program that does all the things we need and a simple program+the complex one, we will have more complexity in the latter case so the previous one may be preferred)
- bitwize 5y ago
  > As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. Or, compositors can use these wonderful things we have called dynamic libraries, and simply link against implementations of that desktop functionality, such as wlroots -- which implementations, by the way, will be far less crufty and ad hoc than the equivalent X11 solution! Much of the reason why X is the way it is is because back in the day, Unix lacked dynamic libraries in general, so in order to share an implementation of, say, graphics primitives, the best way was to write a server that implemented them and have clients communicate with that server. Now that we have dynamic libraries, we can share a single implementation of graphics rendering across multiple programs, and still have all the speed advantages of doing all the rendering client side!
- bitwize 5y ago
  I'm sure the architects of Xorg have a much better idea of which abstraction to use and why it's superior to Wayland. Oh wait, the architects of Xorg designed Wayland! X11 is a dead end. Its authors have deprecated it and offered an upgrade path: Wayland. Time to make like Elsa and let it go.
  - a1369209993 5y ago
    > the architects of Xorg Xorg was designed decades ago. The architects of Xorg are dead, retired, or overwritten with their stupider future selves; you're talking about maintainers.
    - marcodiego 5y ago
      Xorg was not designed. It organically evolved.
      - a1369209993 5y ago
        ... Okay, that's fair, but not really my point.

wing-_-nuts 5y ago

>Wayland is fundamentally flawed at the concept level Expand?

sprash 5y ago
The biggest problem of Wayland is that it has the wrong philosophy ("Every frame is perfect") and the wrong abstractions ("Everything in the universe is an array with RGBA values"). If your foundations are flawed like that you are doomed from the start. What remains is a very expensive and cumbersome way of blitting bitmaps.
- margalabargala 5y ago
  Presumably the designers of Wayland do not think that this philosophy and those abstractions are so fundamentally flawed. Could you explain why these concepts are so flawed, for those of us to whom it is not immediately obvious?
  - sprash 5y ago
    For some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames. Also displays have different pitch values, subpixel arrangements, color spaces, etc. A line from A to B might look completely different on different monitors. By offering only RGB arrays as abstraction Wayland pushes the the need for care of those differences down to clients which is a mistake. Additionally a Desktop system in general is much more than a bunch of bitmaps blittet together. Applications need to interact and such functionality has to be tightly integrated into the compositor with standardized protocols otherwise it will be impossible to have such functionality. Taking screenshots, drawing to the root window or knowing about coordinates of windows from other programs are some examples.
    - kaba0 5y ago
      > For some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames Oh and what gives, wayland just has an extension for this use case! HDR is work in progress, there is nothing unchangeable in Wayland that would disallow different buffer types.

pengaru 5y ago

> (Wayland is fundamentally flawed at the concept level) That's a mighty big hand you're waving.

hsbauauvhabzb 5y ago

As a consumer/power user with a fairly bespoke window manager I’m worried that the minimalist approach to wayland will fragment functionality depending on compostor / DE. Wanna use Firefox? gotta use gnome compostor for that! Chromium only works on KDE compostor, etc. Is this a misguided fear, or do you anticipate it moving that way?

nani8ot 5y ago
I think these worries are unfounded atm, because compatibility is good for most applications, even though there are some tools specific to a compositor (e.g. waypipe for wlroots based compositors). For the case of minimal window managers, there is wlroots, which is designed to be used to write a compositor. The first line of the wlroots repo[1] states: »Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.« And there are at least three[2] actively maintained compositors based on wlroots. Sway being the most popular, the one for which wlroots was initially developed for. I believe that there won't be too many incompatibilities, because there are 3 (4, including weston) wayland compositors developed (Gnome's, KDE's & wlroots based), all three of them having their own use cases. Using protocol extensions only useable on one compositor would limit the app to a subset of Linux Desktops (and mobile), so if possible, most apps won't use them. PS: I just remembered one case of fragmentation: Activity Watch, a tool to keep track which apps are used how long and to track idle times, won't be able to support Gnome (mutter), because Gnome dev's won't implement the necessary freedesktop protocol extension. Sway (and KDE?) does, so it works on them. One solution would be to write a Gnome Shell extension, but yeah, it's not as easy as on X.org (reason being privacy, in this case). [1] https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots [2] https://arewewaylandyet.com/ https://arewewaylandyet.com/