Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active November 24, 2024 10:16
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.
Download ZIP
Think twice about Wayland. It breaks everything!
Raw
Wayland.md

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.

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.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

@phrxmd
Copy link

phrxmd commented Apr 18, 2022

outdated assertions it contains and that you refuse to change

Just because I want existing software to work doesn't mean my assumptions should be called "outdated". I just happen to value backward compatibility, including binary backward compatibility, very(!) highly. Because I value time very highly.

Come on. Lots of the stuff in your post has been fixed long ago and you leave it in. What's the "backwards compatibility" or "time saving" argument here? Pretending that a bug hasn't been fixed when it has?

Case in point: I'm typing this on KWin Wayland and the global menu works, when according to you it doesn't:
grafik

@bodqhrohro
Copy link

@phrxmd

So what? Not all X window managers support every part of wm-spec either. It's their choice.

Among X11 WMs, only a few tiling ones allow themselves to be non-EWMH-compliant, due to their extreme simplicity. Mutter is far from this simplicity, so this is not an excuse. It's where bigotry and resistance come in.

and your favourite software decides not to accept it, you go and pick different software, or fix it, or fork it, it's the open source way.

Why do you pretend like proprietary software for *NIX systems does not exist? Even the aforementioned issue in the Electron bug tracker probably arose while developing a proprietary application, as I don't see any opensource activity from its author.

And we are talking about the spec, not the software. Do you offer to fork the spec too, and come up with some Wayland++, free from the ideology of paranoid security?

@myownfriend
Copy link

Plus I doubt that in the future when applications come out that only support Wayland or only enable support for certain features that only Wayland has, I doubt you're going to view that as X11 breaking Wayland. Instead you're going to view that as an attack on X11 as well.

"foot" is a terminal emulator for Wayland. It has no X support. X breaks Wayland!

The funny thing is that they're trying to claim that some X11 functionality not working in a Wayland session is Wayland breaking X even though those things work fine in an X11 session. But not only does a Wayland session, via XWayland, have better compatibility with X11-only software than an X11 session has with Wayland-only software, but there's actually some examples of X11 breaking Wayland software in a Wayland session!

Of course, I'm not an idiot, I know that these are software bugs and not actually X or Wayland's fault but I'll mention them anyway. Spotify used Chromium Embedded Framework and inherits Wayland support from that yet Spotify can't launch as Wayland-native client. Why? Because Spotify still looks for some X11 stuff when it launches so it just fails and launches in XWayland anyway. When someone created stub implementations of the X11 bit that Spotify was looking for, it loaded as Wayland-native.

The other example is that Wayland support has been broken on recent versions of Electron. Attempting to launch Electron applications with the Wayland backend causes a segfault and the app never opens. They recently found out that the reason was because it was that they didn't quite separate the X11 and Wayland backends as well they should have and it was making some X11 calls while launching as a Wayland client. Of course, since Electron is open-source, this has been fixed and everything should work just fine in the next Electron release on the 29th.

But yea, two examples of X11 fucking up Wayland clients in Wayland sessions and so far none of Wayland fucking up X11 clients in X11 sessions.

@myownfriend
Copy link

It's where bigotry and resistance come in.

What? What does this have to do with bigotry? lol

And we are talking about the spec, not the software. Do you offer to fork the spec too, and come up with some Wayland++, free from the ideology of paranoid security?

Doors are apparently paranoid security...

@bodqhrohro
Copy link

@myownfriend

What does this have to do with bigotry?

Can you pick a better word for ignoring the real-world use cases as non-significant?

Doors are apparently paranoid security...

Yeah, doors in a solitary confinement prison, where prisoners are not allowed to talk with each other.

@myownfriend
Copy link

Can you pick a better word for ignoring the real-world use cases as non-significant?

Lets look at the definition of bigotry lol

"obstinate or unreasonable attachment to a belief, opinion, or faction, in particular prejudice against a person or people on the basis of their membership of a particular group"

Even if did mean what you thought it meant, you didn't use the word in a way that would make sense for that definition. Maybe you were trying to say we're "dismissive but in reality you're just being dramatic lol

How about you stop trying to evoke real world issues and dramatize a discussion about a compositing protocol? Just say what you're trying to say because you're not good at comparison or simile at all lol

Yeah, doors in a solitary confinement prison, where prisoners are not allowed to talk with each other.

Nope. Just doors lol Wayland clients aren't enclosed in VMs. They have access to the hardware, the file system, system services, and pretty much everything, they just can't mess with other clients unless permitted. It's a policy of hands-off, no cutting, and ask for consent. It's the bare minimum.

@bodqhrohro
Copy link

@myownfriend

on the basis of their membership of a particular group

There is such a group: users who avoid monolith DEs. Right when Wayland was being created, GNOME was undergoing the shift from the modular GNOME 2 to the monolith GNOME Shell. They had seen it as the modern way of things and the future for everyone, and KDE had strengthened this view by following this approach too. Those who didn't join this bandwagon and kept embracing the modularity and interoperability were seen as heretics. Thus no surprise that the Wayland specification was made only with monolith compositors in mind and intentionally abstains from any plumbing between environment components, moreover, its ideologists try to make a clear distinction between applications and environment components, despite it's not that clear in reality.

Wayland clients aren't enclosed in VMs

Pff, so you ignore the fact Wayland is developed in step with Flatpak and portals? I had even brought an example above in the thread, where GNOME developers denied a request for a protocol extension for time tracker needs and suggested that this should be a portal instead, and the xdg-portal developers kicked it back because they couldn't see the use of it in Flatpak (despite the developer of the time tracker didn't even intend to isolate it in Flatpak in the first place!) So it just ended up in a dead lock and mutual incomprehension.

@myownfriend
Copy link

There is such a group: users who avoid monolith DEs. Right when Wayland was being created, GNOME was undergoing the shift from the modular GNOME 2 to the monolith GNOME Shell. They had seen it as the modern way of things and the future for everyone, and KDE had strengthened this view by following this approach too. Those who didn't join this bandwagon and kept embracing the modularity and interoperability were seen as heretics.

Citation needed and will not be provided because you can't cite your own imagination.

Also I can't help but thing you're trying to talk about Mutter not Gnome Shell. Mutter was the compositor that got display server and window manager functionality merged with it when it became a Wayland compositor. Gnome Shell is just what runs on top of Mutter and is pretty small with over half of the project's source code is just language packs. They both work together along with a number of other applications like Nautilus and Gnome Settings to make the Gnome DE though.

Modularity is nice when it works but it's by no means an indicator that something is good.

Thus no surprise that the Wayland specification was made only with monolith compositors in mind and intentionally abstains from any plumbing between environment components, moreover, its ideologists try to make a clear distinction between applications and environment components, despite it's not that clear in reality.

More bullshit about Gnome dictating Wayland even though it was the third compositor with a finished Wayaland implementation.

Pff, so you ignore the fact Wayland is developed in step with Flatpak and portals? I had even brought an example above in the thread, where GNOME developers denied a request for a protocol extension for time tracker needs and suggested that this should be a portal instead, and the xdg-portal developers kicked it back because they couldn't see the use of it in Flatpak (despite the developer of the time tracker didn't even intend to isolate it in Flatpak in the first place!) So it just ended up in a dead lock and mutual incomprehension.

That shows the opposite of what you're saying and unfortunately I can't comment on that specific situation any further because you provided no link.

On top of that, Wayland predates Flatpak and has no requirement for Wayland applications being Flatpaks. Portals are developed as part of the Flatpak repository but have no requirement for them to be used with Flatpaks. It's just a front-end for a bunch of D-Bus interfaces.

The reason that Wayland devs will suggest D-Bus interfaces for some things is because Wayland is for a specific thing and many of the suggestions that they get are better fits for D-Bbus interfaces. The simplest example I can think of for that is global hotkeys.

In terms of functionality, an application that's still doing something in the background is like a service. Whether or not the application is in focus or visible might be irrelevant to it's function. If it's hidden, then it's like it's not a GUI application at all. Position info, damage info, mouse position, and other things all become irrelevant to that application. It's probably not trying to update it's interface because it won't be seen anyway and if it's redrawing something while it isn't visible then it's probably for output somewhere else like the internet or local storage where they'll be interact with the network stack and file system, not the compositor. So if diagrammed out, global hotkeys can be thought of in two ways.

If it's a Wayland protocol it would be done by the compositor so a line would be made from the input stack to the compositor. If a hotkey combination can only be used by one thing specifically then the compositor would eat the input if it matches a registered hotkey, and a single line goes to whatever registered it. If hotkeys can be shared then there would be one line going to the current application more going to any registered ones. It would effectively work no different than having the client communicate with the input stack directly.

By having it be a D-Bus interface, D-Bus would be matching incoming input to registered hotkeys and routing them to the compositor, clients, or other services that registered them. That means the compositor and it's client would be on equal footing in Wayland and X11 sessions. It would also be the first time that X11 actually has a proper way to do hotkeys.

This is also why Pipewire capture can work on Wayland and X11. It has no specific support for X11 or Wayland, just portals which use D-Bus. The position of clients on the screen, which ones are in-focus, and anything that has to do with what display servers, window managers, and compositors do is largely irrelevant to what it's trying to do. It's just getting access to a frame buffer in memory for a client's use.

I did quickly look up time-tracker and Wayland and I didn't find any git links but I think I found what you're talking about. There was someone who works on an application called ActivityWatch who said they asked for a Wayland protocol to retrieve the window title of the currently active application. This is literally a surveillance use-case so it makes sense not to be in Wayland. It should be noted that they don't seem to have asked for this on Wayland's git, they only opened up an issue on the Portals Git. Outside of any requests, Gnome and Wlroots both implemented APIs (a D-Bus API in Gnome's case) to provide that functionality but after the AW discussed it with both a Gnome dev and a Wlroots dev, both suggested that it get turned into a portal implementation that they can both use. That's when the AW developer brought it up to the portal devs.

So, no, the Gnome dev didn't deny a protocol extension nor would a single Gnome dev be able to just add something to the Wayland protocol if they wanted to. That particular Gnome dev had already made a protocol for Gnome that added that functionality and had suggested it get turned into a portal before the AW dev ever contacted him. Tracing things further back, it seems that the Gnome dev worked on that interface by request of another Portal contributor and it was implemented in Gnome as a proof of concept for a portal implementation. The only thing you got right is that there is a push back from the portal side but the request is still open and more people are contributing use cases for it.

@probonopd
Copy link
Author

@phrxmd

I'm typing this on KWin Wayland and the global menu works, when according to you it doesn't

Thanks for the information. Updated accordingly.

@codic12
Copy link

codic12 commented Apr 21, 2022 •
edited
Loading

I don't think Wayland should be unnecessarily criticized, it's a lot of effort to make a protocol which can almost compete with x11, and a lot of effort to write all these compositors (which is, in the X world, a X11 server PLUS a window manager PLUS a compositor.) I appreciate all that effort being poured in.

I think the real reason why people don't want Wayland is because X11 just works. Yes, it has it's architectural downfalls, but a lot of it's problems were solved a long time ago - if you care about security you can simply use nested X servers such as Xnest/Xephyr, or write a server extension if one doesn't exist. I personally think - and this is just my opinion and what I would do, I'm not paying anyone's salary so I encourage you to do whatever you like - that this effort would have been better spent in polishing X11, cleaning up the protocol etc, while not completely breaking backwards compatibility - you could do that with a "X12" server. X11 has a legacy - it has decades of applications, frameworks, desktops, etc created for it. I definitely understand that things cannot remain the same forever, and that change is not always a bad thing. I just think this is one place where a new display server was not needed. Personally I feel it's just the "innovation for the sake of innovation" model which has ruined products like Microsoft Windows. I also do appreciate X's client-server model, both as someone developing for X and someone using X.

But again, this is open source. If you want to use Wayland, feel free to use Wayland. If you want to make your things work on Wayland, feel free by all means. Personally, I'll probably be using X until either wayland matures to a state where it is usable for me, or X completely dies. Probably the latter, because I don't really want to switch from stuff that works with no issues and I've been using for a long time.

@myownfriend
Copy link

myownfriend commented Apr 21, 2022 •
edited
Loading

I don't think Wayland should be unnecessarily criticized, it's a lot of effort to make a protocol which can almost compete with x11, and a lot of effort to write all these compositors (which is, in the X world, a X11 server PLUS a window manager PLUS a compositor.) I appreciate all that effort being poured in.

I appreciate your respect for people working on the protocol and the compositors instead of acting like they're all corporate tools like others in this thread.

I think the real reason why people don't want Wayland is because X11 just works. Yes, it has it's architectural downfalls, but a lot of it's problems were solved a long time ago - if you care about security you can simply use nested X servers such as Xnest/Xephyr, or write a server extension if one doesn't exist.

For a lot of things it really doesn't work though. Stuff like mixed refresh rates just don't work. I'm a newcomer to Linux. I've only been using it for about a year and half and I can't confidently say that I'd be as close to replace Windows if it weren't for Wayland and I've mentioned the reasons a few times in this thread.

I remember when I was using X, I wondering why my secondary monitor wasn't getting a signal and it turned out it was because it was set to 30hz while my primary was at 60hz. I know that a few months ago there was a change to Xorg that was supposed to allow for mixed refresh rates but with a lot of tearing.

When I first installed Ubuntu (my first distro), I was initially blown away by how good the mixed-DPI support was compared to Windows but then I realized I was on Nouveau drivers so it defaulted to Wayland... not that I knew what that meant. After eventually getting Nvidia's proprietary drivers working (which included once instance of me breaking my Ubuntu install), I was extremely confused. I was able to set up 150% scaling on my 4K monitor just like before... but my cursor was about half speed. I tried compensating for that by increasing it's sensitivity and that worked but I that wasn't the only issue. I started noticing that some applications were scaling down instead of up so they were kind of readable on the 4K monitor if I looked closely but not on my 1440p main monitor. I wound up just forgetting about DPI scaling on Linux for awhile and just setting both to 1440p. It made the secondary display blurry, but things worked at least.

Then I tried playing a game full screen and noticed tearing. I looked up a solution and found that it was to force compositing in Nvidia Settings so I did. It fixed it... but only sometimes. It sucked because I was hoping to switch to Linux. I always wanted to try running Ubuntu as my main OS but I couldn't because Adobe doesn't support it. Once I started using Davinci Resolve, which does support Linux, I started thinking about it again. I decided to finally do it after the Xbox app corrupted the file system on my 4TB drive in a way where I didn't lose any files but it couldn't see any of my files. Microsoft couldn't even help with it so I had to do a 24 hour drive recovery just to put everything back on the same drive. Now it looked like, at best, I'd have to keep Linux as just a thing to play with while mainly using Windows.

Anyway, while looking up screen tearing issues, that when I figured out about Xorg and Wayland. I remember watching a Chris Titus video (who I avoid now) where he said Wayland is this new thing that wasn't ready yet and technically worked on Nvidia hardware but not correctly and that people should stick with X. So I didn't think about changing over. I did keep hearing people saying that it fixes all the issues I was having with X though. That's when I figured out that I had been switched from Wayland to X11 when I installed the Nvidia Proprietary drivers. Eventually I was like "Fuck it. I've only been using Linux for like 2 months (I think), if I break my install again then we'll just call it a learning experience. I wanna try it out" and went through the process of enabling the Wayland option on GDM.

I got it running and I tried out one of the other examples where I had noticed tearing in X11, scrolling through Firefox. Nvidia didn't support DMA-buf which is used by Firefox's Webrender backend so the software rendering caused tearing on X11 for me. On Wayland though, no tearing. Then I set up DPI scaling on my second monitor: no mouse slow down like in X11, no apps scaled down, and unlike Windows, there no vertical offset for items going from one screen to the other and no cursor barriers between monitors. It was great. Some applications were blurry on the scaled monitor but I found out that that was because they were XWayland applications and the scaling was handled by the compositor. That was fine though because some applications did that on Windows and I was already running the whole screen at lower resolution on X11 so it was just an upgrade in every way. For Wayland-native clients, they looked sharp on both monitors.

Then I noticed that there was no hardware acceleration on XWayland applications because of the aforementioned lack of DMA-buf so I'd have to pop back into X11 to edit or play games. Then I noticed that, actually, I didn't even complete setup things correctly yet because my whole desktop was using llvmpipe! Honestly I was pretty shocked that a software graphics backend was running so well at high resolutions. For just web browsing or coding, it was actually really acceptable so I did spend a lot of time doing stuff under llvmpipe. Of course, I did fix that within a week and got hardware acceleration back where I could.

Once Nvidia supported DMA-buf, I really didn't have a reason to go back into an X session anymore. There were still Gnome and application bugs that I experience because I was on it's EGL_Streams backend but it was far more usable than X for me. Then when Nvidia supported GBM, things got REALLy smooth and applications compatibility went up. Almost everything that I need works and the things that don't are because of EGL and DRM stuff that Nvidia still doesn't support.

In the past year and half, the Wayland protocol hasn't really seen many changes so all of the issues I was having were because of Nvidia, not Wayland. In that time I was able to slowly shrink my Windows partition and extend my Linux partition. I've since switched to Fedora and I've very comfortable on Linux now and I'm enjoying the experience even though, again, I still have an Nvidia card. Loving Pipewire, too. It, along with Helvum, has made routing audio to my audio interface so simple and clean. Doing the same thing on Windows is a nightmare. I haven't had the chance to use Helvum to route video yet but I'm looking forward to it.

I personally think - and this is just my opinion and what I would do, I'm not paying anyone's salary so I encourage you to do whatever you like - that this effort would have been better spent in polishing X11, cleaning up the protocol etc, while not completely breaking backwards compatibility - you could do that with a "X12" server.

They couldn't though. They tried. They were able to use extension to add stuff like XComposite, XRandr, Xinerama, DRI, and stuff like that but it was all tacked on. They really needed to change the core protocol but that would have resulted in breaking the API. There's even an extension called X Access Control Extension that. I haven't read about it in awhile but I'm pretty sure it allows you to isolate applications like Wayland but from the accounts I've heard of people who used it, it breaks a lot of applications... like even ones that you wouldn't think would be effected by it.

On top of that, X11's general model is very inefficient. You can find benchmarks showing KDE on X without compositing having just as much latency as KDE's Wayland backend which requires compositing. I also recently tried out Ubuntu 22.04 on my Raspberry Pi 400 and the X11 backend couldn't move windows around at full frame rate at 1440p without overclocking the GPU a bit while windows moved around at full frame rate at stock clocks in a Wayland session.

Truth is, Wayland has stuff that was brainstormed for X12. Compositing was going to be required, it was going to be built with security in mind from the get-go, etc. The thing is, that concept of not allowing clients to mess with the compositor or other clients would have effected X12 in the same way. X11 never had proper way to do screen sharing or global hotkeys, it could only do that through exploitation of security holes in the protocol. If it did have proper ways to do those things in place, or if a D-Bus interface to do these things already existed then Wayland would have used them. Wayland already re-used Xorg's drivers, re-used EGL instead of making it's own graphics API, re-used XKB, and didn't create protocols for functionality that was already offered by the kernel. For example, you don't need a Wayland equivalent of XRANDR to apply a LUT to the monitor output if Direct Render Manager already allows you to change that property.

X11 has a legacy - it has decades of applications, frameworks, desktops, etc created for it.

That's why XWayland exists. Unfortunately, clients can't do everything in a Wayland session that they can in X11. For example, X clients can snoop on other X clients but not Wayland clients because the XWayland server doesn't manage them. There's no good ways to create software shims for that functionality either.

As far as toolkits are concerned Qt, GTK, and SDL2 all support Wayland and handle a lot of the worked needed to get 99.9% of applications working as native Wayland clients. If an X application that includes screensharing needs to buy time while it slowly moves to support Wayland though, they can still add Pipewire support and I think it would be able to capture X and Wayland windows as well as screens.

I definitely understand that things cannot remain the same forever, and that change is not always a bad thing. I just think this is one place where a new display server was not needed. Personally I feel it's just the "innovation for the sake of innovation" model which has ruined products like Microsoft Windows. I also do appreciate X's client-server model, both as someone developing for X and someone using X.

I've found articles dating back to 2003 where people were talking about how bloated and slow X11 was. I really don't see it as innovation for innovations sake. I think it's just natural that a protocol that was made for computers from the late 80s without thinking much about how it would be implemented just isn't well-equipped for computers with GPUs, multi-monitor setups, display scaling, HDR, mixed frame rates, etc. If you think about it, X1 came out in 1984 and X11 came out in late 1987. That's 11 versions of X in three years and X11 actually broke compatibility with X10 even though it brought over some ideas it (bad ideas according to Keith Packard). They probably thought they'd be releasing an X12 in maybe late 1989, and didn't think people would still be in use in 2022 a lot of computers and running on top of something called... Linux? Its run has been a lot longer than it was supposed to be and adoption of Linux probably wouldn't have been what it was without it but it's not good enough for today. Just think of anyone who connects there laptop to external monitor for work or, even worse, to their TV, they'd run head-first into all the issues that I had with X.

But again, this is open source. If you want to use Wayland, feel free to use Wayland. If you want to make your things work on Wayland, feel free by all means. Personally, I'll probably be using X until either wayland matures to a state where it is usable for me, or X completely dies. Probably the latter, because I don't really want to switch from stuff that works with no issues and I've been using for a long time.

I'm glad X11 works for what you need it for. It just personally shocks me that I seem to run face first into all of X11's issues in my first months running a Linux OS. Maybe that's because I used a multi-monitor setup. I've talked to a lot of people who dislike Wayland and a lot of don't have multi-monitor setups, do but don't use DPI scaling, or think multi-monitor setups are niche use cases. I've even had someone say that it's my fault for having a mismatched monitor setup. As a colorist, I'm also really excited that Wayland's getting an HDR protocol, too.

@codic12
Copy link

codic12 commented Apr 21, 2022

They couldn't though. They tried. They were able to use extension to add stuff like XComposite, XRandr, Xinerama, DRI, and stuff like that but it was all tacked on. They really needed to change the core protocol but that would have resulted in breaking the API. There's even an extension called X Access Control Extension that. I haven't read about it in awhile but I'm pretty sure it allows you to isolate applications like Wayland but from the accounts I've heard of people who used it, it breaks a lot of applications... like even ones that you wouldn't think would be effected by it.

yes, my argument was just that it requires a lot less effort to implement support for something like that for application developers as well. I also wouldn't consider being able to grab the screen really much of a security hole, personally; but then I make sure I can trust everything I'm running on my system, no matter the display server. There are always security holes.

X can be slow. I think that's just the nature of having messages sent between client and server constantly over a socket connection. This happens for the littlest things; for example, you can grab MotionNotify on root or use XInput2 and then your program will receive events for every single one-pixel movement of the mouse; but the things I can do with that outweigh the disadvantages personally. Also, compositing or not, kwin and mutter are pretty much the worst WMs you can run on any sort of raspberry pi (no offense, both are pretty cool!), they are pretty big resource hogs ;) I don't have a 1440p monitor, but windows move almost equally smoothly (which tbf is not that smooth) for me on my Pi Zero (512 mb of ram!) on my own window manager and sway on 1920x1200. although of course, sway gives me things like translucency; running a compositor on X on the Pi0 does tax the system to pretty much unusable-ness.

I genuinely have, after installing and configuring the right intel driver, never had any problems whatsoever with my laptop and an external monitor, but I've heard lots of stories about it; I guess I'm just lucky.

I'm also glad that, while I don't plan on ever using it, Wayland exists for those that need it. Again, this isn't Windows or MacOS, you have the freedom to do whatever you want - you can absolutely write your own display server with your own protocol, port all the applications and frameworks you need, and use it in a production environment. I'm sure someone will fork X11 one day and try to improve on it more - maybe I will.

Thanks for taking the time to write a nice, long, valid, and civil response!

@myownfriend
Copy link

yes, my argument was just that it requires a lot less effort to implement support for something like that for application developers as well. I also wouldn't consider being able to grab the screen really much of a security hole, personally; but then I make sure I can trust everything I'm running on my system, no matter the display server. There are always security holes.

Also, compositing or not, kwin and mutter are pretty much the worst WMs you can run on any sort of raspberry pi (no offense, both are pretty cool!), they are pretty big resource hogs ;)

Both use more memory than I'd like (especially Gnome Sotware in conjunction with PackageKit.) but I think sometimes the degree to which they're resource hogs can be overblown. There's a guy who I argue with constantly on the Phoronix forums who hates Wayland, loves X, loves Nvidia, uses Fedora, but hates the open source community. Yea, I don't get how all that can be true at the same time, too either. Anyway, he uses a few DEs, one of which is XFCE which has always been Raspberry Pi OS's default DE and I've always heard that was because it's so much less resource intensive than KDE or Gnome. However, in order to get Wayland support, they've been running XFCE on top of Mutter for the last few months... even before they enabled Wayland sessions and nobody seemed to have noticed before they pointed it out.

I don't have a 1440p monitor, but windows move almost equally smoothly (which tbf is not that smooth) for me on my Pi Zero (512 mb of ram!) on my own window manager and sway on 1920x1200. although of course, sway gives me things like translucency; running a compositor on X on the Pi0 does tax the system to pretty much unusable-ness.

I don't have a Pi Zero but I have the original Pi. I'm kinda curious to see what it could handle the newest release of Pi OS assuming it's still supported. I remember everything being lethargic on it.

I genuinely have, after installing and configuring the right intel driver, never had any problems whatsoever with my laptop and an external monitor, but I've heard lots of stories about it; I guess I'm just lucky.

Are you always running them at the same refresh rate and without scaling? Because that could be it. Earlier on in this thread someone mentioned that Intel drivers are the only one that tear on X11... but of course we know that's not true because Nvidia's drivers do, too... also he only said that after I told him that most of the work that Wayland's creator did on Wayland was when he was working for Intel, not Redhat, so he had to throw a jab at Intel there.

I'm also glad that, while I don't plan on ever using it, Wayland exists for those that need it. Again, this isn't Windows or MacOS, you have the freedom to do whatever you want - you can absolutely write your own display server with your own protocol, port all the applications and frameworks you need, and use it in a production environment. I'm sure someone will fork X11 one day and try to improve on it more - maybe I will.

I'd actually be really curious to see what your experience would be like trying to improve on X. If you do that, make sure to keep a blog about it!

Thanks for taking the time to write a nice, long, valid, and civil response!

Thank YOU! I'm happy to write a civil response when I can, but the opportunities have been few and far between in this thread unfortunately lol

@snakedye
Copy link

One thing I don't think many people realize is that ideally the linux "platform" should not be reserved only to developers who only need a terminal to have a decent desktop experience. It should be for everyone. In a world were mobile devices are the dominating, high DPI is the norm and you want everyday people to be able to use system running on Linux, X11 is simply not an viable option.

I think the people who "hate" Wayland and the turn the platforms on Linux are taking are a dying breed. This thread is pretty much proof of it. Boomers living in their bubbles comforting themselves in the delusion that everything was perfect until the Fire Nation attacked.

kwin and mutter are pretty much the worst WMs you can run on any sort of raspberry pi (no offense, both are pretty cool!), they are pretty big resource hogs

I highly doubt. The current "modern" alternative is running picom alongside a WM. Kwin and Mutter are both more capable by a mile to Picom and they don't have to the weird shenanigans Picom does with WMs because they are WMs. Unless you want to run a desktop with no compositor which in this day and age is not an acceptable solution, they are better.

My only nitpick. Also hello @codic12 , it's a bit unfortunate we meet again in this dumpster fire.

@sognokdev
Copy link

@snakedye

I think the people who "hate" Wayland and the turn the platforms on Linux are taking are a dying breed. This thread is pretty much proof of it. Boomers living in their bubbles comforting themselves in the delusion that everything was perfect until the Fire Nation attacked.

I love Wayland and I defended it in many posts here, but I don't think that people who hate Wayland think that "everything was perfect". Several people here have said that improving X would have been better than creating an entirely new protocol. While it may not be true, it shows that X is not perfect from their point of view.

Also, an ad hominem attack is never a valid argument. We don't care whether those people are boomers or not. Their arguments are not less valid because they are X years old rather than Y years old. You don't even really know if their age is significantly different from the age of those who like Wayland.

In a world were mobile devices are the dominating, high DPI is the norm and you want everyday people to be able to use system running on Linux, X11 is simply not an viable option.

That's a real argument, but X could have been improved to support high-DPI displays. Nobody wants to do it, but that doesn't mean it's not the better option.

@codic12
Copy link

codic12 commented Apr 21, 2022 •
edited
Loading

Are you always running them at the same refresh rate and without scaling?

Yes, my setup is nothing special, that's probably why everything has always worked well for me.
That one person on the Phoronix forums sounds pretty hilarious.

I'd actually be really curious to see what your experience would be like trying to improve on X. If you do that, make sure to keep a blog about it!

Definitely!

@codic12
Copy link

codic12 commented Apr 21, 2022

I think the people who "hate" Wayland and the turn the platforms on Linux are taking are a dying breed. This thread is pretty much proof of it. Boomers living in their bubbles comforting themselves in the delusion that everything was perfect until the Fire Nation attacked.

I don't "hate" Wayland, that doesn't mean I have to like or use it either. But I'm not a boomer, I was born in this century and millenium 😉

I highly doubt. The current "modern" alternative is running picom alongside a WM. Kwin and Mutter are both more capable by a mile to Picom and they don't have to the weird shenanigans Picom does with WMs because they are WMs. Unless you want to run a desktop with no compositor which in this day and age is not an acceptable solution, they are better.

Well I was comparing to window managers without a compositing manager. I agree that sadly, picom is pretty terrible in terms of performance. However, I'm not sure why you say running a desktop with no compositor is not an acceptable solution. I don't need a compositor. I don't want a compositor. I haven't been running a compositor for at least a year. And I see no need to.

My only nitpick. Also hello @codic12 , it's a bit unfortunate we meet again in this dumpster fire.

Indeed.

@myownfriend
Copy link

I highly doubt. The current "modern" alternative is running picom alongside a WM. Kwin and Mutter are both more capable by a mile to Picom and they don't have to the weird shenanigans Picom does with WMs because they are WMs. Unless you want to run a desktop with no compositor which in this day and age is not an acceptable solution, they are better.

However, I'm not sure why you say running a desktop with no compositor is not an acceptable solution. I don't need a compositor. I don't want a compositor. I haven't been running a compositor for at least a year. And I see no need to.

I think they mean the general public. There are a lot of things people can technically do without but aren't negotiable features for a lot of people.

One example I can think of is desktop icons. I don't use them, don't like them, and disabled them on Windows. I'll spare you the details why, but I don't see them as necessary and neither do a lot people. Technically, when you have app launchers to launch applications from and file browsers to access your files, they aren't necessary. But their absence from Gnome (without an extension) is inexcusable because they see them as necessary.

Another would be server-side decorations or client-side decorations. There's a lot of discussion about which are better. I prefer-client side for most things but for game windows, I prefer server-side. Truth is that neither are really needed. Davinci Resolve doesn't have CSDs but also doesn't launch with SSDs on Linux but with Gnome Super + Primary Click allows me to drag the window, Super + Middle Click allows me to resize the window, dragging to the top of the screen maximizes it, dragging a maximized window from the top restores it. Super + Secondary Click gives me a dropdown that gives me the following options: Take Screenshot, Hide, Maximize, Move, Resize, Always on Top, Move to Left/Right Monitor, and Close. So while decorations aren't technically needed, I don't think most people would agree.

I haven't been running a compositor for at least a year. And I see no need to.

Just re-quoting for separation.

Compositing is the only way that mixed-DPI scaling can work as well as it does. Neither GTK nor Wayland support more than integer scaling so a compositor enables fractional scaling by taking an integer-scaled client buffers a monitors and scaling them down to an fractional scale. There is work being done on a fractional scaling protocol in Wayland which would allow compositors and applications that support fractional scales to draw to fractionally-scaled screen without scaling down but scaling would still be needed for clients that aren't DPI aware (like XWayland clients currently) and clients that only support integer scales.

It will also always be useful for hide the transition from one DPI to the other. On Windows, dragging a window from a scale to scale results in the window popping to the DPI of the target monitor once more than 50% of the window is on that monitor. In my case, this means if I drag File Explorer from my primary monitor to the secondary monitor then initially the part on monitor 1 looks the right size but the part on the monitor 2 is way too small. Then once more than half is on monitor 2, File Explorer gets drawn 50% larger which makes it look the correct size on monitor 2 but way too large on monitor 1. It's an incredibly jarring effect especially when dragging larger windows over as they can momentarily cover and even clip outside the boundaries of monitor 1 until the window is complete moved to monitor 2

In a Wayland session, Gnome tells the client to draw at higher DPI pretty much as soon as a single pixel is on monitor 2 and just scales it down to maintain it's size on monitor 1. The result is that dragging windows from one screen to the other feels no different than if both screens were the same resolution but of course it's still using all of the resolution of both monitors. Of course because Wayland doesn't currently support fractional scaling, the contents on my 4K screen are technically being drawn at 5K and then scaled down. It sounds wasteful but it's not as bad as in X11.

Because of how X11 handles spanning across multiple monitors, both need to be one DPI. I'd need to use XRANDR to resize them down to different scales. So the contents of both monitors would be drawn at 5K and scaled down by 56% on my 4K monitor and by 75% on my 1440p monitor. You can imagine that always having to set the scale to the highest scale in a set of monitors would become more and more wasteful as you add more monitors. Adding a 720p monitor to my setup would be functionally the same as adding 5K monitor. The other side of that is if I add an 8K monitor to my setup then it would be the same as have a setup with three 8K monitors..

I think this why Wayland and the old X12 proposal both require compositing. You need to account for different clients and monitors supporting different scales and handle all scenarios where the size that a client is drawn at isn't necessarily the size it will be displayed at.

@snakedye
Copy link

@sognokdev

I love Wayland and I defended it in many posts here, but I don't think that people who hate Wayland think that "everything was perfect".

Hate is a very strong word. If you feel that type of way about free software, you are deranged enough to fit that caricature.

Several people here have said that improving X would have been better than creating an entirely new protocol. While it may not be true, it shows that X is not perfect from their point of view.

If you hate Wayland and think that X can be improved why aren't you improving it? This gist is 2 years old and none of these people made a single commit to Xorg. If you really hate Wayland and think it's a nuisance to the point of calling for boycott why aren't you contributing to Xorg so it's never obsoleted. I think it's phony.

If you don't hate Wayland, you are fine.

That's a real argument, but X could have been improved to support high-DPI displays. Nobody wants to do it, but that doesn't mean it's not the better option.

If no one wants to do it, it is the worse option.

@snakedye
Copy link

@codic12

I don't "hate" Wayland, that doesn't mean I have to like or use it either. But I'm not a boomer, I was born in this century and millenium wink

If you don't hate it, I'm not addressing you. You are graced...

I'm not sure why you say running a desktop with no compositor is not an acceptable solution. I don't need a compositor.

Yes, you. I was more talking about 99.9% of people who use desktops or phones. It's like selling a 720p 30 fps monitor, like sure some people could use it but almost everyone will notice that it's straight up worse than anything else they have ever used.

@codic12
Copy link

codic12 commented Apr 22, 2022 •
edited
Loading

One example I can think of is desktop icons. I don't use them, don't like them, and disabled them on Windows. I'll spare you the details why, but I don't see them as necessary and neither do a lot people. Technically, when you have app launchers to launch applications from and file browsers to access your files, they aren't necessary. But their absence from Gnome (without an extension) is inexcusable because they see them as necessary. Another would be server-side decorations or client-side decorations. There's a lot of discussion about which are better. I prefer-client side for most things but for game windows, I prefer server-side. Truth is that neither are really needed. Davinci Resolve doesn't have CSDs but also doesn't launch with SSDs on Linux but with Gnome Super + Primary Click allows me to drag the window, Super + Middle Click allows me to resize the window, dragging to the top of the screen maximizes it, dragging a maximized window from the top restores it. Super + Secondary Click gives me a dropdown that gives me the following options: Take Screenshot, Hide, Maximize, Move, Resize, Always on Top, Move to Left/Right Monitor, and Close. So while decorations aren't technically needed, I don't think most people would agree.

I think there's some misinterpretation on my end or on yours, I was talking about a X11 compositor, which is not needed for desktop icons or any sort of window decorations, client-side or server-side, or really anything but:

  • forcing vsync
  • transparency / shadows / other visual effects

@snakedye could you give one example of something which you think a X compositor is needed for? I'm genuinely curious... I genuinely find the experience to be better than anything I've used, but it's all subjective

@myownfriend
Copy link

myownfriend commented Apr 22, 2022 •
edited
Loading

I think there's some misinterpretation on my end or on yours, I was talking about a X11 compositor, which is not needed for desktop icons or any sort of window decorations, client-side or server-side, or really anything but:

* forcing vsync

* transparency / shadows / other visual effects

Oh! Yes there is a misunderstanding. I wasn't saying that desktop icons and decorations require compositing. It's hard for me to word this but I was using them as examples of things that people don't technically "need" because they aren't "necessary" to get certain functionality but they are necessary from a practical stand point.

Here's a real world example. If you're trying to sell someone on a house that doesn't have a bathroom but there's an outhouse, you're technically not losing any functionality. Anyone living there would still have some place to poo. But how many people are really gonna want to buy that house?

I'm probably still doing a bad job explaining this.

@snakedye could you give one example of something which you think a X compositor is needed for? I'm genuinely curious... I genuinely find the experience to be better than anything I've used, but it's all subjective

"Mixed DPI scaling" and v-sync. I mentioned that neither is as good in X as they are in Wayland or Windows but it's far better than if it didn't have them.

Let me flip that on you. What do you think using a compositor takes away from your experience?

@codic12
Copy link

codic12 commented Apr 22, 2022

Oh! Yes there is a misunderstanding. I wasn't saying that desktop icons and decorations require compositing. It's hard for me to word this but I was using them as examples of things that people don't technically "need" because they aren't "necessary" to get certain functionality but they are necessary from a practical stand point.

Ah, I see. Sorry for the confusion! I understand what you mean.

"Mixed DPI scaling" and v-sync. I mentioned that neither is as good in X as they are in Wayland or Windows but it's far better than if it didn't have them.

V-sync is definitely true, DPI scaling I actually can't comment on because I have no idea about that topic, but I would guess it has no need for a compositor...

Let me flip that on you. What do you think using a compositor takes away from your experience?

Nothing, it's just that too many X compositors feel kind of sluggish on my laptop, which was pretty mediocre when it was released (2012) already. And I admit, Wayland compositors like Wayfire do these things smoother, because Wayland does make that improvement; the client and server code can both be in one application, rather than being sent over local unix domain sockets or however X does it. But when I have too many windows open, I still do see some sluggishness, which is expected from an i5's integrated graphics from 2012. But again, in that aspect, I have to hand it to Wayland.

Xfwm4 and Marco/Metacity do come with relatively performant compositors. And honestly, compiz is still not a bad option. Even kwin and mutter, or even picom, are perfectly fine. It's just that when I have 15-20 windows open (I have a weird workflow) it feels a lot smoother without a compositor, not to mention that there is the memory concern (some compositing WMs / picom can be pretty heavy on memory and CPU). This is weirdly hardware-specific and an issue which is partly addressed by Wayland. And I don't really need a process running in the background for things I don't use anyways.

@myownfriend
Copy link

V-sync is definitely true, DPI scaling I actually can't comment on because I have no idea about that topic, but I would guess it has no need for a compositor...

Doesn't the scaling in XRANDR require compositing? I couldn't find anything that confirmed or denied that. If so then it's oddly more of a requirement for mixed-scales on X11 than it is on Wayland because one monitor's output would always to be scaled down.

Nothing, it's just that too many X compositors feel kind of sluggish on my laptop, which was pretty mediocre when it was released (2012) already. And I admit, Wayland compositors like Wayfire do these things smoother, because Wayland does make that improvement; the client and server code can both be in one application, rather than being sent over local unix domain sockets or however X does it.

It's not the the client and server code are in one application its that the server, window manager, and compositor are all combined. The client still just has it's client code. Part of the reason that compositing in X is slow is because the compositor is separate and the communication between the two adds a lot of latency and X11 already had latency issues.

This was posted already but I think you might find it enjoyable. https://www.youtube.com/watch?v=GWQh_DmDLKQ

But when I have too many windows open, I still do see some sluggishness, which is expected from an i5's integrated graphics from 2012. But again, in that aspect, I have to hand it to Wayland.

Xfwm4 and Marco/Metacity do come with relatively performant compositors. And honestly, compiz is still not a bad option. Even kwin and mutter, or even picom, are perfectly fine. It's just that when I have 15-20 windows open (I have a weird workflow) it feels a lot smoother without a compositor, not to mention that there is the memory concern (some compositing WMs / picom can be pretty heavy on memory and CPU). This is weirdly hardware-specific and an issue which is partly addressed by Wayland. And I don't really need a process running in the background for things I don't use anyways.

Is it probably a memory usage thing? Compositors give each client their own buffer so they're going to use more VRAM but in exchange for that, applications don't need to redraw parts of themselves when they're obscured by another window, the compositor just needs to fetch that part of the application's buffer. You're trading off VRAM usage in order to save your GPU from having to do repeat work which can also save on memory bandwidth.

@codic12
Copy link

codic12 commented Apr 22, 2022

It's not the the client and server code are in one application its that the server, window manager, and compositor are all combined.

By the client I meant the window manager and compositor, which are clients in X terminology. Sorry for the confusion ;)

This was posted already but I think you might find it enjoyable. https://www.youtube.com/watch?v=GWQh_DmDLKQ

Perhaps, I'll be sure to check it out later, but now it's almost 1 AM!

Doesn't the scaling in XRANDR require compositing? I couldn't find anything that confirmed or denied that. If so then it's oddly more of a requirement for mixed-scales on X11 than it is on Wayland because one monitor's output would always to be scaled down.

Don't know about however Xrandr scaling works, but I can definitely change the DPI without a compositor:
image

Is it probably a memory usage thing? Compositors give each client their own buffer so they're going to use more VRAM but in exchange for that, applications don't need to redraw parts of themselves when they're obscured by another window, the compositor just needs to fetch that part of the application's buffer. You're trading off VRAM usage in order to save your GPU from having to do repeat work which can also save on memory bandwidth.

Funnily enough, when developing my window manager, I ran into this problem - when not running a compositor stuff is obscured. I just redraw, which works fine... but yes, I see your point. although you can also "compress" received X events, and redraw only after you've finished receiving them quickly one after the other... which is what it seems the majority of gui applications / frameworks do from my observations. Also often you can repaint one small area instead of the whole window.

@myownfriend
Copy link

By the client I meant the window manager and compositor, which are clients in X terminology. Sorry for the confusion ;)

Oh right! I forgot lol

Don't know about however Xrandr scaling works, but I can definitely change the DPI without a compositor: image

Oh! We don't mean font DPI when we talk about DPI scaling. What we mean is UI scaling on high DPI displays. For example, lets say you have a taskbar that's 48 pixels high. On a 27" 1440p screen, that would be 0.44" high, but if that same interface was on a phone with a 6" 1440p screen, then it would be just 0.098" high. Sure you'd be closer to the phone which make up for some of the loss in size, but that would still be too small. That's where DPI scaling comes into play. With 300% scaling, that taskbar would now be drawn to be 144 pixels high which is 0.29". That's way easier to see on a phone and way easier to hit.

Funnily enough, when developing my window manager, I ran into this problem - when not running a compositor stuff is obscured. I just redraw, which works fine... but yes, I see your point. although you can also "compress" received X events, and redraw only after you've finished receiving them quickly one after the other... which is what it seems the majority of gui applications / frameworks do from my observations. Also often you can repaint one small area instead of the whole window.

Yes, both Wayland and X send damage events so that only a portion of the screen needs to be updated and that's true with and without compositors. It's not just the additional X events that need to be considered each time you repaint though. That application needs to run functions to draw buttons, icons need to be fetched and drawn, and text needs to be drawn. The latter two will likely need some amount of alpha blending too and it's no uncommon for UIs to have a decent amount of overdraw. That's all avoided when you don't need to repaint.

@codic12
Copy link

codic12 commented Apr 22, 2022

Oh! We don't mean font DPI when we talk about DPI scaling. What we mean is UI scaling on high DPI displays. For example, lets say you have a taskbar that's 48 pixels high. On a 27" 1440p screen, that would be 0.44" high, but if that same interface was on a phone with a 6" 1440p screen, then it would be just 0.098" high. Sure you'd be closer to the phone which make up for some of the loss in size, but that would still be too small. That's where DPI scaling comes into play. With 300% scaling, that taskbar would now be drawn to be 144 pixels high which is 0.29". That's way easier to see on a phone and way easier to hit.

I see. I never completely understood UI scaling, as when you increase font DPI do the rest of the elements not scale also?
But clearly I don't know anything about this 😅

@bodqhrohro
Copy link

Just for the matter of holywar.

I usually SIGSTOP greedy apps which actively use the NTFS partition, as the NTFS-3G driver fails to freeze them under a heavy load and prevents the system from sleeping.

Today, I unsuspended the system and SIGCONTed only TelegramDesktop to quickly add a contact and send a message. Surprisingly, despite a lack of a load, it was freezing all the way for tens of seconds and didn't report pings to the WM. The CPU was cold, the Telegram process made 0% load, and iotop-c showed no any disk activity. I suspected it's some multithreading or IPC lock, connected to the process with strace, and observed a confirmation:

@bq:19:43:48:/tmp/dl$ strace -p 3783717
strace: Process 3783717 attached
restart_syscall(<... resuming interrupted read ...>) = 0
futex(0x7f39fd0d8fc0, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f39fd0d9014, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=10320726, tv_nsec=94307775}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Время ожидания соединения истекло)
futex(0x7f39fd0d8fc0, FUTEX_WAKE_PRIVATE, 1) = 0
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\27\0\2\0x\1\0\0", iov_len=8}], 1) = 8
futex(0x7ffc2d32a678, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = -1 EAGAIN (Ресурс временно недоступен)
futex(0x7f39fd11ca18, FUTEX_WAKE_PRIVATE, 1) = 0
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])

So, what's that 7?

@bq:19:55:55:/tmp/dl$  ls -l /proc/3783717/fd/7
lrwx------ 1 bodqhrohro bodqhrohro 64 мая  7 19:56 7 -> 'socket:[1763110736]'
@bq:19:56:05:/tmp/dl$ ss|grep 1763110736
u_str ESTAB      0      0                                @/tmp/.X11-unix/X0 1763111837               * 1763110736        
u_str ESTAB      0      0

Pff. And Compiz benchmark showing nearly 23 FPS ;DD

Copy link

ghost commented May 8, 2022

Much of this is outdated, or is lacking some context, or is plain misleading. Here's a few things:

  • vokoscreenNG has support now: "For Windows and Linux(X11, Experimental Wayland support since 3.1.0 pre alpha)" (https://github.com/vkohaupt/vokoscreenNG)

  • OBS now supports wayland by default (obsproject/obs-studio#2484)

  • Jitsi Meet is broken on browsers that don't support Wayland ("Closing since there is nothing we can do from the Jitsi Meet side. The browser must have support for this.")--different from what was implied above

  • Zoom now has a solution that will be released soon (https://community.zoom.com/t5/Meetings/Wayland-screen-sharing-broken-with-GNOME-41-on-Fedora-35/m-p/53991/highlight/true#M27430)

  • Applications breaking without the Qt Wayland plugin is a feature. You can't run X11 apps on Wayland without XWayland, and the Wayland plugin is there to allow you to run it as a native Wayland app. Simple.

  • A fork of Redshift exists to support Wayland--but there's also gammastep for wlroots.

  • As mentioned in albertlauncher/albert#309, "Wayland does not allow clients to register global hotkeys atm. Use your desktop evironment to bind a hotkey to albert toggle or albert show."

    • Sounds like global hotkeys to me.

  • You can run apps as root, with sudo --preserve-env=XDG_RUNTIME_DIR,WAYLAND_DISPLAY

  • As others have mentioned, global menus seem to work all around.

I'm disappointed at how outdated this is.

Wayland was not intended to be a 1:1 replacement. Guess what? X11 wasn't a 1:1 with X10 either. If developers aren't willing to put in the effort to add Wayland support, don't blame it on Wayland.

Also, what arguments are there against Portals and PipeWire outside of the fact they're related to GNOME? I don't have any other GNOME software installed and it works perfectly for me.

@Monsterovich
Copy link

Monsterovich commented May 9, 2022 •
edited
Loading

Wayland was not intended to be a 1:1 replacement. Guess what? X11 wasn't a 1:1 with X10 either.

Which is irrelevant because X10 existed like ~40 years ago. Do you realize how many applications rely on X11? You can't just throw X11 out the window. X11 will be revisited one day, but certainly not by Wayland-monkeys.

If developers aren't willing to put in the effort to add Wayland support, don't blame it on Wayland.

You know what? We don't care about Wayland. Wayland is going to die and be and be abandoned. Forever. Everyone's happy. Especially me.

Also, what arguments are there against Portals and PipeWire outside of the fact they're related to GNOME?

In X, screen capturing is done with extensions. You can capture the entire screen or a single window. In Wayland, you need a crutch to do this. I don't want to use PipeWire for screen capturing or for sound, even though it is better written than the nasty PulseAudio. Any other sound subsystem over ALSA is a software crutch. We'll have to admit it. Wayland's lack of features and its anarchic ideology makes it necessary to use crutches. Only companies like Microsoft do that. And all sorts of software like Systemd, PulseAudio, pushes GNU/Linux down this path. A path of anarchy and Redhat/GNOME supremacy.

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