4 ms·

It is actually one of the big, unfixable, conceptual problems of Wayland that all the effort is duplicated in each compositor. The Wayland concept pushes out mo

by corty 6y ago

It is actually one of the big, unfixable, conceptual problems of Wayland that all the effort is duplicated in each compositor. The Wayland concept pushes out most of the work to the DEs. That of course will result in tons of predictable inconsistency, incompatibility, bugs, delays, consolidations and general pain. Wayland devs are then generally in the lazy "worksforme, use sway (or whatever)" position while the user (of some other compositor) will be out there complaining to yet another maintainer duplicating yet another feature badly. Lather, rinse, repeat. Wayland is bad design, and it shows in the users' and maintainers' attrition.

tapoxi 6y ago
But isn't this the point of wlroots?
DCKing 6y ago
I honestly think this complaint is completely bogus. This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations. The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] ! The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't. [1]: https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots
- spion 6y ago
  Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places). What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.
  - alisonkisk 6y ago
    Config file converters are completely outside of the wheelhouse of the graphics team. Anyone can step up and build those without any graphics programming knowledge.
    - spion 6y ago
      No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.
      - cycloptic 6y ago
        The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.
        spion 6y ago
        At least between-app DPI inconsistency was not a thing before this. Now its a thing, added to the stack of configuration problems.
        cycloptic 6y ago
        If you support multiple DPIs then that will always be an issue, regardless of what display server you're using.
        spion 6y ago
        Not if the protocol allows the exchange of desired DPI/scaling.
rbanffy 6y ago
> It is actually one of the big, unfixable, conceptual problems of Wayland Why not have a shared implementation?
- R0b0t1 6y ago
  Because then you end up with something like X11, which we already have. The codebase could be re-engineered, sure, but a lot of people championing Wayland tend to see this duplication of effort as good for some reason, and at least last I engaged with them did not like the idea of a "new X11." Personally I think something like that is an inevitability.
  - rbanffy 6y ago
    > which we already have. It'd still solve a lot of issues that X can't.
  - Spivak 6y ago
    Because the Xorg mono-culture was bad. There was no ability to write other X11 display servers from the spec alone. You either did what Xorg did bug for bug or apps broke. By having many different implementations all speaking a common protocol you make it harder to calcify the behaviors of any one implementation and ensure that the spec is what apps code against. People seem to like that we have many browser implementations but when it comes to display servers it seems like they want Chrome to rule them all.
    - R0b0t1 6y ago
      That's fine, I know. But acting like Wayland is feature complete when it obviously isn't is pretty ridiculous. Instead of solving hard problems the Wayland maintainers are acting like you're stupid to want to have the features solving the hard problems enables.
      - Spivak 6y ago
        I think Wayland is about as feature complete as it's gonna get at this point. Mutter, Kwin are still working on adding features to support workflows that relied on the loosey-goosey nature of Xorg. Like Xorg never had "support" for global hotkeys or screen sharing. It's just that programs were allowed access to all inputs and the screen buffer. Designing a system where only some programs are allowed to do that isn't trivial.
Spivak 6y ago
Wayland isn't bad design, at least not in the way you're describing it. I feel like there's some confusion about what Wayland actually is. It's a document that describes how surfaces ("windows") should talk to a compositor ("display sever"). That's it. In a parallel universe Kwin and Mutter would be X11 display servers and we would have all the same issues. Nothing is stopping the existence of a single extensible compositor to rule them all and be the base on which every DE/WM is based but it hasn't happened yet. When people talk about "pushing stuff to the DE" what they mean is the Wayland project aggressively scoping the Wayland protocol to drawing surfaces and handling input events. They're not trying to become a generic desktop message bus for everything an application might want to do -- that's literally what dbus is.
spion 6y ago
This is absolutely right, and wlroots is not a fix once you already have 2 implementations Once that ship has sailed, what you want instead is a shared method of providing configuration. The goal is to have all 3 implementations read configuration (like DPI scaling etc) from one place. That way the user won't have to configure common things in 3 places to get any semblance of apps looking remotely close to eachother.

by corty 6y ago

tapoxi 6y ago

But isn't this the point of wlroots?

DCKing 6y ago

I honestly think this complaint is completely bogus. This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations. The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] ! The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't. [1]: https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots

spion 6y ago
Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places). What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.
- alisonkisk 6y ago
  Config file converters are completely outside of the wheelhouse of the graphics team. Anyone can step up and build those without any graphics programming knowledge.
  - spion 6y ago
    No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.
    - cycloptic 6y ago
      The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.
      - spion 6y ago
        At least between-app DPI inconsistency was not a thing before this. Now its a thing, added to the stack of configuration problems.
        cycloptic 6y ago
        If you support multiple DPIs then that will always be an issue, regardless of what display server you're using.
        spion 6y ago
        Not if the protocol allows the exchange of desired DPI/scaling.

rbanffy 6y ago

> It is actually one of the big, unfixable, conceptual problems of Wayland Why not have a shared implementation?

R0b0t1 6y ago
Because then you end up with something like X11, which we already have. The codebase could be re-engineered, sure, but a lot of people championing Wayland tend to see this duplication of effort as good for some reason, and at least last I engaged with them did not like the idea of a "new X11." Personally I think something like that is an inevitability.
- rbanffy 6y ago
  > which we already have. It'd still solve a lot of issues that X can't.
- Spivak 6y ago
  Because the Xorg mono-culture was bad. There was no ability to write other X11 display servers from the spec alone. You either did what Xorg did bug for bug or apps broke. By having many different implementations all speaking a common protocol you make it harder to calcify the behaviors of any one implementation and ensure that the spec is what apps code against. People seem to like that we have many browser implementations but when it comes to display servers it seems like they want Chrome to rule them all.
  - R0b0t1 6y ago
    That's fine, I know. But acting like Wayland is feature complete when it obviously isn't is pretty ridiculous. Instead of solving hard problems the Wayland maintainers are acting like you're stupid to want to have the features solving the hard problems enables.
    - Spivak 6y ago
      I think Wayland is about as feature complete as it's gonna get at this point. Mutter, Kwin are still working on adding features to support workflows that relied on the loosey-goosey nature of Xorg. Like Xorg never had "support" for global hotkeys or screen sharing. It's just that programs were allowed access to all inputs and the screen buffer. Designing a system where only some programs are allowed to do that isn't trivial.

Spivak 6y ago

Wayland isn't bad design, at least not in the way you're describing it. I feel like there's some confusion about what Wayland actually is. It's a document that describes how surfaces ("windows") should talk to a compositor ("display sever"). That's it. In a parallel universe Kwin and Mutter would be X11 display servers and we would have all the same issues. Nothing is stopping the existence of a single extensible compositor to rule them all and be the base on which every DE/WM is based but it hasn't happened yet. When people talk about "pushing stuff to the DE" what they mean is the Wayland project aggressively scoping the Wayland protocol to drawing surfaces and handling input events. They're not trying to become a generic desktop message bus for everything an application might want to do -- that's literally what dbus is.

spion 6y ago

This is absolutely right, and wlroots is not a fix once you already have 2 implementations Once that ship has sailed, what you want instead is a shared method of providing configuration. The goal is to have all 3 implementations read configuration (like DPI scaling etc) from one place. That way the user won't have to configure common things in 3 places to get any semblance of apps looking remotely close to eachother.