Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • At this point, I'm half convinced that someone with $100k in api spend of Fable tokens can create a better replacement for X11/Wayland, and patch all common open source apps to leverage it.
    by jjcm
  • Probably take more than $100k, X11/Wayland is a bit more complicated than the usual bit of software.
  • Wayland should expired, Wayland is architectural failure plagued with bad design decisions, xlibre is gaining momentum and it is not broken piece of a pile
  • Lol, we don't talk about xlibre here. Announcments and reviews are banned.

    Waiting for dang to argue the 7th time that is not somehow his personal decision to ban xlibre that he's set up a system where a couple of nazis with automated scripts can hide an article which requires his manual attention to put (which he doesn't do)

  • I am not a fan of Wayland. I've not really bought the value proposition; and see also:

    https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d...

    what's more - this seems like yet another RedHat/IBM project which destroys variety and flexibility in favor of their problematic choices, often with a degradation of functionality. systemd, Wayland, GNOME - and of course nothing would run on BSDes, heavens forbid.

    With X11 seeing renewed, independent work via https://xlibre.net - why not embrace _that_ rather than go down the crooked Wayland path?

  • > course nothing would run on BSDes

    Ummmm, Wayland runs on FreeBSD...

    https://docs.freebsd.org/en/books/handbook/wayland/

  • I kind of wonder that too, I'm fine using wayland but it seemed like a huge user hassle for not many benefits (namely independent screen scaling which xlibre now supports). It's a shame xlibre didn't come around sooner, after years of pain wayland support has gotten a lot better, to the point I can more or less use either without issue.
  • i like the idea of wayland but i agree about the loss of flexibility. they seem very concerned about security and make screen sharing very complex now if you stray from the accepted path. systemd complicates this further with logind seat management etc. as a result our companies dev servers where we run a bunch of simultaneous VNCs and independent mate desktop sessions can really only work with X11 for now. There is a way to do it with nested cgroups running n number of systemd instances etc but its a pain and then we would have to use gnomes built in rdp thing which we dont want to use… anyway i actually vibe coded a way to get it working with wayland in containers with a dummy kernel video driver, my own fake logind etc. etc. etc. it was a harrowing experience but fun.
  • > and of course nothing would run on BSDes

    A number of wayland compositors are available in at least freebsd and openbsd (haven't checked on netbsd and dragonflybsd). Wayland is only a protocol. Whoever wants to support it can.

  • HDR, VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration, support for tiled GPUs

    Yeh... we should totally keep to X11.... especially when toolkits start to drop support.

  • > which destroys variety and flexibility

    That's probably the worst argument that you could make against Wayland: there has only ever been a single X11 server in common use on the Linux desktop (first XFree86, now X.Org), but there are tons of independent Wayland "server" implementations (Weston, Mutter, KWin, wlroots, etc.) [0]. Lots of these are written in completely different languages and implement different extensions from each other, so there's way more variety and flexibility with Wayland than with X11.

    The more common criticism that I've heard is that Wayland's variety and flexibility is actually bad, because it makes it harder to add extensions (since you need to implement it in multiple different projects, and not just the single X.Org codebase), and it means that applications potentially have to test against multiple implementations. (I don't necessarily agree with this criticism myself, but it's still a valid complaint.)

    > and of course nothing would run on BSDes

    FreeBSD [1] and OpenBSD [2] both have Wayland support.

    [0]: https://en.wikipedia.org/wiki/List_of_display_servers#Waylan...

    [1]: https://docs.freebsd.org/en/books/handbook/wayland/

    [2]: https://xenocara.org/Wayland_on_OpenBSD.html#running-wayland

  • Given who founded Xlibre (Metux) has some...interesting history (he was banned from the X.org project due to poor code quality and practices [1]) I would say no

    Metux himself also has some "fascinating" takes as archived from other projects such as the LKML [1] and Devuan [2] mailing lists

    [1] https://gitlab.freedesktop.org/xorg/xserver/-/work_items/179...

    [2] https://lkml.org/lkml/2021/6/10/957

    [3] https://web.archive.org/web/20190404153507/https://lists.dyn...

  • Do we really need the editorializing in the title?
  • I really don't like Wayland, I recently (last Friday) had to revert back to X because somehow they messed up enough that in Zoom screensharing during a meeting with XWayland can crash my audio drivers.

    At this point I don't know who it is for, but it's not for users.

  • Try browser zoom
  • A couple of points:

    - Pipewire or Pulseaudio has nothing to do with XWayland, let alone Wayland (Pulseaudio is somewhat legacy and may not be maintained as well as it used to be)

    - Zoom (the last time I checked, a while ago) wasn't really well implemented on Linux (came before xdg-desktop-portal, which has standardised screen sharing across DEs and only really prioritised the GNOME specific extensions.

    - The engineering effort to properly support screen sharing on Linux is a _bit_ more complicated than other platforms as we have many DEs

    - Browser based screen sharing is generally the best option on Linux imho

  • I've been screensharing using the Zoom web application (via Firefox) on Wayland for almost 5 years now, and it's always worked well for me personally.
  • Yeah, I still use KDE with X11 because they somehow messed up their window management with Wayland. My problems aren't even about rendering or any those features, but for some reason kwin_wayland's window management is very buggy. I'm still on 6.6 on the distribution that I use, so I don't know if it's fixed in 6.7, but I doubt it since it is here for a long time. Reported it here: https://bugs.kde.org/show_bug.cgi?id=524083
  • Me too. I really wanted to like Cosmic but the hassles wayland causes with ordinary things like zoom is just not worth it. Plus all the progress with gaming that has been made on Linux, wayland ruins. I’m back to X and get off my lawn etc.
  • I'm not sure that Zoom is the highest quality software. I find it crashy and weird under either X or Wayland.
  • > EGLStream support is removed

    Wait, does this mean Nvidia won't have GPU acceleration for apps under XWayland anymore? Or is EGLStream not what I think it is?

  • Nvidia finally started supporting GBM in 2021. IIUC EGLStream is more vestigial now and can be removed.
  • Nice. XWayland has been a key transitional piece we'll still need for a while.
  • Agree. It sometimes feels like it gets forgotten in the wayland vs xorg divide.

    One of the nice things about flatpak (another contentious topic), is that for GUI apps where it matters I can trivially set whether I want to prefer xwayland vs wayland, and keep compatibility. It's very nice for the few apps that are still xorg hardcoded and with flatseal, or KDE app settings I don't need to mess with setting the environment variables myself.

  • Hopefully forever tbh until a proper alternative to XWayland arrives:

    XWayland is essentially the missing mid-level "Wayland client library" which fills the feature gaps caused by missing extensions of the underlying Wayland implementation and it provides a common and fully featured GTK/KDE-agnostic window managemnt layer. Until the Wayland project releases a client library 'for the rest of us' with a similar intent, XWayland is still very much needed for applications that don't want to or cannot link against GTK or KDE for various reasons.