6 ms·

Would be interesting to know also the current status of Wayland development in NetBSD, since the last blog post about it was quite a while ago.

by xvilka 2y ago

deleted 2y ago
[deleted]
shrubble 2y ago
I came to the conclusion a while back that Wayland just doesn't matter very much. As long as Chromium and Firefox plus the GUI mode of Emacs works under X11, that is all 90% of users need/use.
- hapless 2y ago
  I doubt it I really, truly suspect Wayland is the future We have had like one hundred X11 replacements between 1990 and now, and at least half a dozen have caught on with the open source community What makes Wayland different is that it has attracted multiple vendors supporting it. Most notably IBM/Redhat, Intel, AMD, and, to a lesser extent, nVidia. I am posting this message from an X11 environment, because I need X11 for a lot of things, home and work both, but, I can at least imagine a world where Wayland is the new default. That is not something I could say about the last hundred attempts to replace X11. Edit: Again, this is just a suspicion. A notion. I neither hope for Wayland's success nor failure. I just keep my finger to the wind.
  - Kwpolska 2y ago
    Wayland might be the future (though I'm personally a bit skeptical). It is already the default on many distros. At the same time, X11 is very unlikely to just stop working or disappear, since there's really no good reason to kill it.
    - hapless 2y ago
      My skepticism should be quite obvious: I am still posting through an X11 system. But, Wayland is far and away the best and most serious attempt to replace X, ever, in thirty years and more. If there is gonna be an X11 replacement, ever, Wayland is the most credible attempt in decades
      - vundercind 2y ago
        Agreed that it’s made the best show of attempting, but Wayland’s only got about nine years before it’s as old as x11 (the protocol) was when the Wayland showed up. If it’s gonna mostly displace x11… man, it’s sure taking its time. It’s older than xfree86 was when the xorg fork occurred.
        The_Colonel 2y ago
        > If it’s gonna mostly displace x11… man, it’s sure taking its time. Yes, and I'm fine waiting 5, 10, or 20 years. It's natural that such major shifts take a long time in an already mature ecosystem.
      - raffraffraff 2y ago
        I'm also using X11, even though I've attempted to switch to Warplanes twice and had to switch back due to screen sharing and remote desktop being trash or just breaking after some update or other (most recently, browser). It's a work machine and I simply can't waste an hour fucking around with it. Aside from those issues which are deal-breakers in work, there's a bunch of minor annoyances I won't go into, thrust not deal brakes but they're "there". With X11 everything I need just works. I'm on a bleeding edge distro (OpenSUSE Tumbleweed) so I'll probably try it out on a weekend every few months to see if it's better. But in fairness I did that before, made the switch and then lost screen sharing after some random update...
        petepete 2y ago
        Screen sharing was the final hurdle for me. I switched to running Slack in a Chrome tab and it works better than it ever did on X11 for me. I've used it on both my work computers for a few years now and it's been totally solid.
    - deleted 2y ago
      [deleted]
    - eternityforest 2y ago
      X11 will stop working if things stop supporting it. Stuff might eventually decide to render directly to Wayland only APIs or something. I'm actually not a very big Wayland fan, I prefer the single implementation model rather than all the different implementations of Wayland. But I'd rather have just only the Wayland fragmentation mess, instead of the Wayland mess plus also X11, so I'm glad Pi OS and Ubuntu(Right now the only distros I pay much attention to) have switched.
    - legulere 2y ago
      Security is a good reason to kill it.
    - skriticos2 2y ago
      Well, the main reason why Wayland even exists is, that the X11 maintainers got fed up with a design from a time when graphics cards were not even a thing yet and decades of patchwork. They wanted to move on to something that has way less technical debt. Sure, X11 won't go away anytime soon, but finding people who actually want to work and maintain that codebase will be more than a little difficult.
      - bandrami 2y ago
        This article is literally about a team that is actively maintaining the codebase
        bluGill 2y ago
        Likely the only team that isn't trying to spend all their time on wayland and touching x11 only when forced.
        bandrami 2y ago
        No, they mention that they work closely with the OpenBSD team, which maintains an explicit fork ("xenocara") that maintains the NetBSD ABI. It was OpenBSD that added wsdiplay and wsinput, which are frankly better in a lot of use cases than Wayland.
  - guappa 2y ago
    wayland's main purpose is to isolate ~~malware~~ proprietary software running in a container, which Xorg doesn't allow (unless of course you run nested servers). It wouldn't be too bad of a goal if it had feature parity, which it still doesn't have.
    - welterde 2y ago
      X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.
      - nolist_policy 2y ago
        Eh even if you secure the X11 API itself, the Xorg server still is a 33 year old (!) c codebase.
        guappa 2y ago
        Linux is 33 years old as well. Let's stop using it to be secure?
        jdiez17 2y ago
        Linux is not as secure as most tech people would assume at first glance. The monolithic kernel with all device drivers in ring0 is, let's just say, not the best approach if one were writing a new OS from scratch. It is mostly "secure" due to it being used in practically every server and billions of devices, so there is an active maintainer community around it. Xorg has none of that.
        welterde 2y ago
        It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.
  - deleted 2y ago
    [deleted]
  - j16sdiz 2y ago
    I hope not. The core wayland protocol have so many missing piece and many extension are not standardized nor well defined. This is basically killing the interoperability between UI toolkit for non-trivial cases.
    - postepowanieadm 2y ago
      Good enough for Gnome.
      - yjftsjthsd-h 2y ago
        Well.... yeah? GNOME doesn't care about interoperability; they're the ones known for ex. suggesting that applications remove features for other desktops because GNOME doesn't use them ( https://trac.transmissionbt.com/ticket/3685#no1 https://trac.transmissionbt.com/ticket/3685#no1 ).
- kragen 2y ago
  games, blender, audacity, gimp, mpv, eclipse, prusa slicer,...
  - cies 2y ago
    IntelliJ IDEs. They are working on it though: https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland-support https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland... https://wiki.openjdk.org/display/wakefield/Known+problems+and+solutions https://wiki.openjdk.org/display/wakefield/Known+problems+an...
- gtirloni 2y ago
  If I use X11, I have to live with screen tearing, which Wayland doesn't suffer from.
  - p_l 2y ago
    Unless your application use GPU for rendering and you have more than one GPU involved, or have GPU driver that doesn't implicitly serialize events behind the scenes (as it should NOT), and your display stack has not yet migrated to experimental extension that patches Wayland with actual support for synchronized rendering (explicit sync). If any of the above applies, tear-free behaviour is accidental, because Wayland protocol design fucked up synchronization primitives from day 1.
    - hawski 2y ago
      Could you expand on what is wrong with the synchronization primitives in Wayland protocol?
      - p_l 2y ago
        tl;dr the core protocol only lets you inform the compositor that the surface object is "ready" - which turns out to work effectively only for software drawing, or waiting possibly entire frame for your image to show up on screen. That's if you're careful about calling "commit" on the surface only after whatever GPU draw calls you executed on it finished and the surface has been fully rendered to memory. Turns out it somewhat works even if you're not properly careful because a lot of drivers (especially Mesa) had unspoken, implicit serialization happening in the drawing pipeline. One issue is when you have more than one GPU (common on higher-end laptops). Even when you're rendering application surfaces on one GPU, they will often have to be synced to another GPU's memory to render them, because it's common to have some video outputs on iGPU and some on dGPU (example from my 2023 laptop: internal screen is behind mux that allows either GPU to exclusively write, but USB4 DP is iGPU exclusive, and separate USB-C DP is dGPU exclusive). But with increased use of asynchronous rendering APIs (OpenGL AZDO patterns, Vulkan) and with variable refresh rate screens becoming more common (even if you don't have physical one, RDP/waypipe/etc are possible users for that) you can find out a situation where compositor will start drawing a window using a surface that is not yet fully rendered, bringing back tearing. It also means it's harder to properly utilize VRR in cases where applications render at different speeds (which is fine - not everything has to render at highest possible FPS), possibly locking you down to slowest rendering element. So, the new extension, available if you ride latest patches on linux (the final part missing is new nvidia beta driver release, but not because nvidia lagged on the issue - nvidia apparently spearheaded it because their driver internals had no implicit synchronization), compositors are able to synchronize their rendering at the GPU level, getting fence objects for DRM buffer based surfaces. Meaning compositor can attempt to prevent drawing an unfinished surface, nor will application have to add extra waits in its display code.
deleted 2y ago
[deleted]

Would be interesting to know also the current status of Wayland development in NetBSD, since the last blog post about it was quite a while ago.

by xvilka 2y ago

Would be interesting to know also the current status of Wayland development in NetBSD, since the last blog post about it was quite a while ago.

deleted 2y ago

[deleted]

shrubble 2y ago

I came to the conclusion a while back that Wayland just doesn't matter very much. As long as Chromium and Firefox plus the GUI mode of Emacs works under X11, that is all 90% of users need/use.

hapless 2y ago
I doubt it I really, truly suspect Wayland is the future We have had like one hundred X11 replacements between 1990 and now, and at least half a dozen have caught on with the open source community What makes Wayland different is that it has attracted multiple vendors supporting it. Most notably IBM/Redhat, Intel, AMD, and, to a lesser extent, nVidia. I am posting this message from an X11 environment, because I need X11 for a lot of things, home and work both, but, I can at least imagine a world where Wayland is the new default. That is not something I could say about the last hundred attempts to replace X11. Edit: Again, this is just a suspicion. A notion. I neither hope for Wayland's success nor failure. I just keep my finger to the wind.
- Kwpolska 2y ago
  Wayland might be the future (though I'm personally a bit skeptical). It is already the default on many distros. At the same time, X11 is very unlikely to just stop working or disappear, since there's really no good reason to kill it.
  - hapless 2y ago
    My skepticism should be quite obvious: I am still posting through an X11 system. But, Wayland is far and away the best and most serious attempt to replace X, ever, in thirty years and more. If there is gonna be an X11 replacement, ever, Wayland is the most credible attempt in decades
    - vundercind 2y ago
      Agreed that it’s made the best show of attempting, but Wayland’s only got about nine years before it’s as old as x11 (the protocol) was when the Wayland showed up. If it’s gonna mostly displace x11… man, it’s sure taking its time. It’s older than xfree86 was when the xorg fork occurred.
      - The_Colonel 2y ago
        > If it’s gonna mostly displace x11… man, it’s sure taking its time. Yes, and I'm fine waiting 5, 10, or 20 years. It's natural that such major shifts take a long time in an already mature ecosystem.
    - raffraffraff 2y ago
      I'm also using X11, even though I've attempted to switch to Warplanes twice and had to switch back due to screen sharing and remote desktop being trash or just breaking after some update or other (most recently, browser). It's a work machine and I simply can't waste an hour fucking around with it. Aside from those issues which are deal-breakers in work, there's a bunch of minor annoyances I won't go into, thrust not deal brakes but they're "there". With X11 everything I need just works. I'm on a bleeding edge distro (OpenSUSE Tumbleweed) so I'll probably try it out on a weekend every few months to see if it's better. But in fairness I did that before, made the switch and then lost screen sharing after some random update...
      - petepete 2y ago
        Screen sharing was the final hurdle for me. I switched to running Slack in a Chrome tab and it works better than it ever did on X11 for me. I've used it on both my work computers for a few years now and it's been totally solid.
  - deleted 2y ago
    [deleted]
  - eternityforest 2y ago
    X11 will stop working if things stop supporting it. Stuff might eventually decide to render directly to Wayland only APIs or something. I'm actually not a very big Wayland fan, I prefer the single implementation model rather than all the different implementations of Wayland. But I'd rather have just only the Wayland fragmentation mess, instead of the Wayland mess plus also X11, so I'm glad Pi OS and Ubuntu(Right now the only distros I pay much attention to) have switched.
  - legulere 2y ago
    Security is a good reason to kill it.
  - skriticos2 2y ago
    Well, the main reason why Wayland even exists is, that the X11 maintainers got fed up with a design from a time when graphics cards were not even a thing yet and decades of patchwork. They wanted to move on to something that has way less technical debt. Sure, X11 won't go away anytime soon, but finding people who actually want to work and maintain that codebase will be more than a little difficult.
    - bandrami 2y ago
      This article is literally about a team that is actively maintaining the codebase
      - bluGill 2y ago
        Likely the only team that isn't trying to spend all their time on wayland and touching x11 only when forced.
        bandrami 2y ago
        No, they mention that they work closely with the OpenBSD team, which maintains an explicit fork ("xenocara") that maintains the NetBSD ABI. It was OpenBSD that added wsdiplay and wsinput, which are frankly better in a lot of use cases than Wayland.
- guappa 2y ago
  wayland's main purpose is to isolate ~~malware~~ proprietary software running in a container, which Xorg doesn't allow (unless of course you run nested servers). It wouldn't be too bad of a goal if it had feature parity, which it still doesn't have.
  - welterde 2y ago
    X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.
    - nolist_policy 2y ago
      Eh even if you secure the X11 API itself, the Xorg server still is a 33 year old (!) c codebase.
      - guappa 2y ago
        Linux is 33 years old as well. Let's stop using it to be secure?
        jdiez17 2y ago
        Linux is not as secure as most tech people would assume at first glance. The monolithic kernel with all device drivers in ring0 is, let's just say, not the best approach if one were writing a new OS from scratch. It is mostly "secure" due to it being used in practically every server and billions of devices, so there is an active maintainer community around it. Xorg has none of that.
      - welterde 2y ago
        It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.
- deleted 2y ago
  [deleted]
- j16sdiz 2y ago
  I hope not. The core wayland protocol have so many missing piece and many extension are not standardized nor well defined. This is basically killing the interoperability between UI toolkit for non-trivial cases.
  - postepowanieadm 2y ago
    Good enough for Gnome.
    - yjftsjthsd-h 2y ago
      Well.... yeah? GNOME doesn't care about interoperability; they're the ones known for ex. suggesting that applications remove features for other desktops because GNOME doesn't use them ( https://trac.transmissionbt.com/ticket/3685#no1 https://trac.transmissionbt.com/ticket/3685#no1 ).
kragen 2y ago
games, blender, audacity, gimp, mpv, eclipse, prusa slicer,...
- cies 2y ago
  IntelliJ IDEs. They are working on it though: https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland-support https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland... https://wiki.openjdk.org/display/wakefield/Known+problems+and+solutions https://wiki.openjdk.org/display/wakefield/Known+problems+an...
gtirloni 2y ago
If I use X11, I have to live with screen tearing, which Wayland doesn't suffer from.
- p_l 2y ago
  Unless your application use GPU for rendering and you have more than one GPU involved, or have GPU driver that doesn't implicitly serialize events behind the scenes (as it should NOT), and your display stack has not yet migrated to experimental extension that patches Wayland with actual support for synchronized rendering (explicit sync). If any of the above applies, tear-free behaviour is accidental, because Wayland protocol design fucked up synchronization primitives from day 1.
  - hawski 2y ago
    Could you expand on what is wrong with the synchronization primitives in Wayland protocol?
    - p_l 2y ago
      tl;dr the core protocol only lets you inform the compositor that the surface object is "ready" - which turns out to work effectively only for software drawing, or waiting possibly entire frame for your image to show up on screen. That's if you're careful about calling "commit" on the surface only after whatever GPU draw calls you executed on it finished and the surface has been fully rendered to memory. Turns out it somewhat works even if you're not properly careful because a lot of drivers (especially Mesa) had unspoken, implicit serialization happening in the drawing pipeline. One issue is when you have more than one GPU (common on higher-end laptops). Even when you're rendering application surfaces on one GPU, they will often have to be synced to another GPU's memory to render them, because it's common to have some video outputs on iGPU and some on dGPU (example from my 2023 laptop: internal screen is behind mux that allows either GPU to exclusively write, but USB4 DP is iGPU exclusive, and separate USB-C DP is dGPU exclusive). But with increased use of asynchronous rendering APIs (OpenGL AZDO patterns, Vulkan) and with variable refresh rate screens becoming more common (even if you don't have physical one, RDP/waypipe/etc are possible users for that) you can find out a situation where compositor will start drawing a window using a surface that is not yet fully rendered, bringing back tearing. It also means it's harder to properly utilize VRR in cases where applications render at different speeds (which is fine - not everything has to render at highest possible FPS), possibly locking you down to slowest rendering element. So, the new extension, available if you ride latest patches on linux (the final part missing is new nvidia beta driver release, but not because nvidia lagged on the issue - nvidia apparently spearheaded it because their driver internals had no implicit synchronization), compositors are able to synchronize their rendering at the GPU level, getting fence objects for DRM buffer based surfaces. Meaning compositor can attempt to prevent drawing an unfinished surface, nor will application have to add extra waits in its display code.

deleted 2y ago

[deleted]