6 ms·

> This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day. You two here don't mention any of

> This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day. You two here don't mention any of the reasons. It is hard to discuss this when there are no specifics, so what was needed, and what was not added?

yepguy 10mo ago
The 3 justifications I remember for Wayland were security (isolating windows from each other), multi DPI, and eliminating tearing. All are now features of XLibre.
- sho_hn 10mo ago
  This is all playing a bit fast and loose with the details. The "isolating windows from each other" stuff in Xlibre for example is the Xnamespace extension, which requires a static config file up front and lets X clients within the namespace interact as before. This may have some utility for specific scenarios (dunno, kiosks maybe?), but is nothing like Wayland's default security model. Similarly, enabling TearTree in the modesetting driver and having another backbuffer in the driver is a huge crutch vs. having a proper architecture where the compositor can own presentation timing. For one it makes adaptive sync/VRR a lot trickier. These things are overall not equivalent.
  - uecker 10mo ago
    It isn't clear why any of this would require a rewrite.
mathstuf 10mo ago
Per-display DPI settings. No snooping on input without permission. Awareness of the lock screen (the compositor can know that the lock screen is active and provide alternate keybindings instead of having to configure the lock application as well). Locking is not blocked by context menus being open. I ran XMonad for 15 years, but recently switched to river and am loving it.
- maxdamantus 10mo ago
  > Per-display DPI settings fwiw, Xorg already had this, since you can set the DPI for each display through RandR/xrandr. In both X11 and Wayland it's up to the toolkit to actually detect the setting and rasterise accordingly. Wayland actually went backwards in this respect by using "integer scales" (eg, 1, 2, 3) instead of fine-grained DPIs (eg, 96, 192, 288), so using a scale of 1.5 would result in downscale blur (toolkit sees scale as 2, then the compositor scales it down to 75%), whereas in Xorg you could just set the DPI to 144, and the toolkit could theoretically render at the correct resolution. As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault. Wayland has at least since fixed this in the form of "fractional scaling" [1], but here's [0] an old thread on HN where I complained about it and provided screenshots of the resulting blur. [0] https://news.ycombinator.com/item?id=32021261 https://news.ycombinator.com/item?id=32021261 [1] Doing some quick searching it seems like this is still unsupported in Gtk3/Gtk4, maybe planned for Gtk5? Apparently Firefox has only just added support (December 2025), 3 years after the fractional scaling protocol was released. Seems ridiculous to me that Wayland failed to get this right from the start.
  - deleted 10mo ago
    [deleted]
  - gf000 10mo ago
    > As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault. Well if three independent programs have to coordinate to make it work, then I would state that it do not support it at all.
    - yjftsjthsd-h 10mo ago
      Is that any different from Wayland? I'm not opposed to declaring that Wayland doesn't support mixed DPI, but it is a funny conclusion
    - maxdamantus 10mo ago
      It's the same on Wayland. The client (usually part of a toolkit like Gtk/Qt) needs to subscribe to notifications [0] from the server so it can decide the raster size of the surface it wants to draw to. Qt does this on X11 by detecting when your window moves to a screen with another DPI and resizing/rescaling. I guess the "third" program would be something like xrandr, so the Wayland analogue to that would be wlr-randr (for wlroots compositors), or some other DE-specific tool for configuring screen sizes. Again there's no fundamental difference here. [0] https://wayland.app/protocols/fractional-scale-v1#wp_fractional_scale_v1:event:preferred_scale https://wayland.app/protocols/fractional-scale-v1#wp_fractio...

yepguy 10mo ago

The 3 justifications I remember for Wayland were security (isolating windows from each other), multi DPI, and eliminating tearing. All are now features of XLibre.

sho_hn 10mo ago
This is all playing a bit fast and loose with the details. The "isolating windows from each other" stuff in Xlibre for example is the Xnamespace extension, which requires a static config file up front and lets X clients within the namespace interact as before. This may have some utility for specific scenarios (dunno, kiosks maybe?), but is nothing like Wayland's default security model. Similarly, enabling TearTree in the modesetting driver and having another backbuffer in the driver is a huge crutch vs. having a proper architecture where the compositor can own presentation timing. For one it makes adaptive sync/VRR a lot trickier. These things are overall not equivalent.
- uecker 10mo ago
  It isn't clear why any of this would require a rewrite.

mathstuf 10mo ago

Per-display DPI settings. No snooping on input without permission. Awareness of the lock screen (the compositor can know that the lock screen is active and provide alternate keybindings instead of having to configure the lock application as well). Locking is not blocked by context menus being open. I ran XMonad for 15 years, but recently switched to river and am loving it.

maxdamantus 10mo ago
> Per-display DPI settings fwiw, Xorg already had this, since you can set the DPI for each display through RandR/xrandr. In both X11 and Wayland it's up to the toolkit to actually detect the setting and rasterise accordingly. Wayland actually went backwards in this respect by using "integer scales" (eg, 1, 2, 3) instead of fine-grained DPIs (eg, 96, 192, 288), so using a scale of 1.5 would result in downscale blur (toolkit sees scale as 2, then the compositor scales it down to 75%), whereas in Xorg you could just set the DPI to 144, and the toolkit could theoretically render at the correct resolution. As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault. Wayland has at least since fixed this in the form of "fractional scaling" [1], but here's [0] an old thread on HN where I complained about it and provided screenshots of the resulting blur. [0] https://news.ycombinator.com/item?id=32021261 https://news.ycombinator.com/item?id=32021261 [1] Doing some quick searching it seems like this is still unsupported in Gtk3/Gtk4, maybe planned for Gtk5? Apparently Firefox has only just added support (December 2025), 3 years after the fractional scaling protocol was released. Seems ridiculous to me that Wayland failed to get this right from the start.
- deleted 10mo ago
  [deleted]
- gf000 10mo ago
  > As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault. Well if three independent programs have to coordinate to make it work, then I would state that it do not support it at all.
  - yjftsjthsd-h 10mo ago
    Is that any different from Wayland? I'm not opposed to declaring that Wayland doesn't support mixed DPI, but it is a funny conclusion
  - maxdamantus 10mo ago
    It's the same on Wayland. The client (usually part of a toolkit like Gtk/Qt) needs to subscribe to notifications [0] from the server so it can decide the raster size of the surface it wants to draw to. Qt does this on X11 by detecting when your window moves to a screen with another DPI and resizing/rescaling. I guess the "third" program would be something like xrandr, so the Wayland analogue to that would be wlr-randr (for wlroots compositors), or some other DE-specific tool for configuring screen sizes. Again there's no fundamental difference here. [0] https://wayland.app/protocols/fractional-scale-v1#wp_fractional_scale_v1:event:preferred_scale https://wayland.app/protocols/fractional-scale-v1#wp_fractio...