4 ms·

>And second system syndrome too probably In my opinion, Wayland has avoided this by deliberately being simpler than X11. > I'm using $DISTRO because I trust t

>And second system syndrome too probably In my opinion, Wayland has avoided this by deliberately being simpler than X11. > I'm using $DISTRO because I trust them enough to not package spyware/malware in their repos >but holy hell my OSS desktop is not a proprietary smartphone OS loaded with random closed-source apps from god knows who that tries to steal my data for profit I think it is not reasonable for you to ask them to never plan for a day when that could happen, if that is what you are suggesting anyway. >You'd assume there's an equivalent tool for Wayland Not if you were aware of the current issues with Xrandr and why it is a poor target. >But mumble mumble security, you cannot do that, so we got the same f#+ing situation as with screen recording again, every WM/compositor comes up with their own solution to something absolutely trivial. GNOME/Mutter have a dbus-API, wlroots-based ones have "wlrandr" via some protocol extension, KWIN I didn't even bother checking. But it's only 15 years since the project started right, why should something trivial as this have been settled upon yet? It is absolutely not trivial, and there are security/usability issues with it. To do this "the right way" would be more or less duplicating the entire KMS API into every implementation. Even XRandr is still missing features compared to that, so it is not an adequate solution either.

zozbot234 4y ago
> In my opinion, Wayland has avoided this by deliberately being simpler than X11. Wayland is not really simpler than X11 unfortunately. The core protocols are very poorly documented, and a lot of practically important stuff is left to be implemented in unspecified ways by the compositor. Like a lot of freedesktop.org stuff historically, it's hard to tell what's prototype-quality from what's actually ready for daily-driver production use.
- Crysstalis 4y ago
  >Wayland is not really simpler than X11 unfortunately. I would say it is. All the things you said are also true of X11 and are worse there, which is another reason why it has been so impractical to develop additional X11 servers, and why everybody always just used X.org despite its shortcomings. And by the way, freedesktop.org has for the most part merged with X.org now. It is the same group of people doing the same work.
- seba_dos1 4y ago
  > The core protocols are very poorly documented, Any examples? I found it much easier to grasp than X11. I have worked on libraries that have both X11 and Wayland backends and X11 code was always an impenetrable pile of workarounds that could break from looking at it, while Wayland code was usually relatively simple and easy to understand.
fps_doug 4y ago
> I think it is not reasonable for you to ask them to never plan for a day when that could happen, if that is what you are suggesting anyway. Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage. Wayland was everything but. With X11 the ship has sailed in that regard, but if you start over, don't create something that doesn't even offer these features in the name of security and then let the community come up with 10 different solutions to the same problems in the most uncoordinated way possible. > Not if you were aware of the current issues with Xrandr and why it is a poor target. xrandr works exactly fine for setting up your screens. You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way. It's a great example for a trivial real-world tool that should just exist. > It is absolutely not trivial, and there are security/usability issues with it. To do this "the right way" would be more or less duplicating the entire KMS API into every implementation. Even XRandr is still missing features compared to that, so it is not an adequate solution either. This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those. Done. X11 does it, Windows does it, macOS does it.
- Crysstalis 4y ago
  >Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage. This is exactly what Wayland has done though. Few have a reason to run command line tools to change the screen configuration, real world usage is to use a GUI as is common on every other graphical OS. >You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way. A major problem here is because of the way the API works, technically any X11 client can do that at any time. The tool may seem trivial but the way it is implemented has great potential for misuse. It does not even have to be malware for this to cause problems, for example a typo in a random script could seriously screw up your screen. Or another common problem in X11 is with applications setting the resolution to something weird, crashing and then leaving the screen in a weird state. >This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those. If this was second system syndrome, then it would be in the kernel, not in X or Wayland. Because the kernel is where all the new KMS features happened. Again, the display server is not actually driving this feature. They are relaying information to and from KMS, which is the actual API that configures the screen.

zozbot234 4y ago

> In my opinion, Wayland has avoided this by deliberately being simpler than X11. Wayland is not really simpler than X11 unfortunately. The core protocols are very poorly documented, and a lot of practically important stuff is left to be implemented in unspecified ways by the compositor. Like a lot of freedesktop.org stuff historically, it's hard to tell what's prototype-quality from what's actually ready for daily-driver production use.

Crysstalis 4y ago
>Wayland is not really simpler than X11 unfortunately. I would say it is. All the things you said are also true of X11 and are worse there, which is another reason why it has been so impractical to develop additional X11 servers, and why everybody always just used X.org despite its shortcomings. And by the way, freedesktop.org has for the most part merged with X.org now. It is the same group of people doing the same work.
seba_dos1 4y ago
> The core protocols are very poorly documented, Any examples? I found it much easier to grasp than X11. I have worked on libraries that have both X11 and Wayland backends and X11 code was always an impenetrable pile of workarounds that could break from looking at it, while Wayland code was usually relatively simple and easy to understand.

fps_doug 4y ago

> I think it is not reasonable for you to ask them to never plan for a day when that could happen, if that is what you are suggesting anyway. Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage. Wayland was everything but. With X11 the ship has sailed in that regard, but if you start over, don't create something that doesn't even offer these features in the name of security and then let the community come up with 10 different solutions to the same problems in the most uncoordinated way possible. > Not if you were aware of the current issues with Xrandr and why it is a poor target. xrandr works exactly fine for setting up your screens. You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way. It's a great example for a trivial real-world tool that should just exist. > It is absolutely not trivial, and there are security/usability issues with it. To do this "the right way" would be more or less duplicating the entire KMS API into every implementation. Even XRandr is still missing features compared to that, so it is not an adequate solution either. This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those. Done. X11 does it, Windows does it, macOS does it.

Crysstalis 4y ago
>Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage. This is exactly what Wayland has done though. Few have a reason to run command line tools to change the screen configuration, real world usage is to use a GUI as is common on every other graphical OS. >You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way. A major problem here is because of the way the API works, technically any X11 client can do that at any time. The tool may seem trivial but the way it is implemented has great potential for misuse. It does not even have to be malware for this to cause problems, for example a typo in a random script could seriously screw up your screen. Or another common problem in X11 is with applications setting the resolution to something weird, crashing and then leaving the screen in a weird state. >This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those. If this was second system syndrome, then it would be in the kernel, not in X or Wayland. Because the kernel is where all the new KMS features happened. Again, the display server is not actually driving this feature. They are relaying information to and from KMS, which is the actual API that configures the screen.