Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active April 28, 2025 23:35
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.

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://git.521000.bestelectron/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 Nov 10, 2023 •
edited
Loading

Don't you think the ancient display server perfectly fits there?

But we're not using it the way we did 30 years ago and it's down to the applications, not the users, to make that decision because all applications using Qt, Gtk, or whatever Englightenment called its widget toolkit are drawing top-level windows client-side and pushing what are essentially VRR video frames of top-level windows to the X server to display because they got fed up with its warts.

Wayland was inspired by how modern desktops have already relocated everything but "terrible, terrible IPC" (i.e. no latency guarantees, too many round-trips per action, etc.) into either the applications or, for composited desktops, the compositor.

Give The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) a watch to hear it from one of the X.org developers himself. (The guy who implemented input hotplug.)

In addition to that, Keith Packard's A Political History of X (linux.conf.au 2020) is worth watching. It gives the history of how X networking came from systems where the applications running on a server talked to semi-dumb graphical terminals over raw Ethernet (no TCP/IP there), and how when X was developed, it was all corporations (Sun, HP, DEC, Bell Labs) and a few people at MIT and CMU. The Internet was not functional enough to coordinate development, some developers were essentially sitting in an office at MIT and paid from a money pool set up by all of these workstation vendors, some other developers were sitting elsewhere and "development was essentially FedEx-based". And while Stallman had come up with the original GPL already, he got on everybody's nerves so much that nobody really was ready to listen to him, there were no open source players in the X ecosystems at all

@zocker-160
Copy link

zocker-160 commented Nov 10, 2023 •
edited
Loading

@phrxmd

Yay, another bug report that is older than this gist.

Yet another response pulling the "works for me" card and claiming something that is proven to be false to be true anyway.

Except it does work properly

Yeah except everything listed does still NOT work.

Screenshot_20231110_235545

  • completely broken theme
  • windows with no title bar (the about window)
  • copying to clipboard does not work
  • auto-type does not work
  • mouse cursor is huge an not they way it should be

I know you will now shift the goal post and claim that it is not the latest version (which does not matter, but this is the one offered in Ubuntu repo) and that is it running Ubuntu and that is it running GNOME etc etc blablabla. None of which matters.

@phrxmd
Copy link

phrxmd commented Nov 10, 2023 •
edited
Loading

@phrxmd

Yay, another bug report that is older than this gist.

Yet another response pulling the "works for me" card and claiming something that is proven to be false to be true anyway.

You did put up a link to a 2019 bug report, where the last comments were from 2021. So be prepared to have it pointed out to you.

Except it does work properly

Yeah except everything listed does still NOT work.

Screenshot_20231110_235103

* completely broken theme
* windows with no title bar
* copying to clipboard does not work
* auto-type does not work
* mouse cursor is huge an not they way it should be

I know you will now shift the goal post and claim that it is not the latest version (which does not matter, but this is the one offered in Ubuntu repo) and that is it running Ubuntu and that is it running GNOME etc etc blablabla. None of which matters.

Well, it's not shifting the goalposts if you point it out yourself - I don't know what version of Ubuntu you're running, but since you have KeePassXC 2.6.6 in your distro repos, it's probably 22.04 LTS (jammy). It's an LTS version, so old versions of packages are the tradeoff for long-term support; you're missing out on bugfixes. Concretely the packaged KeePassXC 2.6.6 is 2.5 years old. 2.7.0 had a fix for copy&paste; it came in March 2022, so probably too late for Ubuntu's 22.04 LTS release cutoff. More recent versions of Ubuntu have more recent versions of KeePassXC, e.g. 23.10 (mantic) has KeePassXC 2.7.4.

Run old software, get old bugs. You would probably also tell that to users of your software who file bug reports against a two-year-old version. Moreover the machine in the screenshot is called ubuntu, so I presume that this is a VM install and not your work machine. In general if you want to showcase through VM screenshots whether bugs are present, it's not a good practice to choose an old LTS version to do it.

That said, let's look at it from a solution-oriented point of view:

  • You are correct that I'm looking at it from my own user experience from running KeePassXC (a Qt app) on a Qt-based desktop. It could be that issues like copy & paste not working, or windows that miss decorations, are or were GNOME-specific. I avoid using GNOME, so I can't say much on that.
  • Regarding the "completely broken theme", KeePassXC comes with its own app-specific Qt theme by default and it looks like what you're seeing. It's not your system theme, so it looks broken to you. KeePassXC lets you configure theming in its settings, you can select either the system theme (I have no idea how good Ubuntu's Qt theming was in 22.04 LTS) or at least select the dark version of the KeePassXC theme, which will already look a lot better.
  • If you're interested in using more recent versions of KeePassXC on your Ubuntu 22.04 LTS install, there is an official PPA that currently provides KeePassXC 2.7.6 also for Ubuntu Jammy. Try that and see if maybe some of the bugs are fixed.

@zocker-160
Copy link

zocker-160 commented Nov 10, 2023 •
edited
Loading

@phrxmd

You did put up a link to a 2019 bug report

Which is perfectly relevant today. Your point?

It's an LTS version, so old versions of packages are the tradeoff for long-term support

I already pointed out that it does not matter, the latest version compiled from source has exactly the same issues. I knew this argument would come, which is why I already addressed it.
It has nothing to do with "tradeoffs" on an LTS distro at all.

More recent versions of Ubuntu have more recent versions of KeePassXC, e.g. 23.10 (mantic) has KeePassXC 2.7.4.

Which has exactly the same issues, there is no difference.

Run old software, get old bugs

Stop pulling this argument ffs, I have addressed this in my post before you answered. The latest version does not fix any of those issues.

Screenshot_20231111_004702

It could be that issues like copy & paste not working, or windows that miss decorations, are or were GNOME-specific

It works perfectly on GNOME x11.

Screenshot_20231111_004517

Regarding the "completely broken theme", KeePassXC comes with its own app-specific Qt theme by default and it looks like what you're seeing. It's not your system theme, so it looks broken to you

Complete bullshit see X11 screenshot, look at the title bar, the mouse, the colors etc. It is completely broken, there are no two ways about it.

If you're interested in using more recent versions of KeePassXC on your Ubuntu 22.04 LTS install, there is an official PPA that currently provides KeePassXC 2.7.6 also for Ubuntu Jammy. Try that and see if maybe some of the bugs are fixed.

Changes nothing, see screenshot above.

Please stop giving explanations that sound believable and seem correct, but are actually just plain wrong.

@phrxmd
Copy link

phrxmd commented Nov 11, 2023 •
edited
Loading

Run old software, get old bugs

Stop pulling this argument ffs, I have addressed this in my post before you answered.

Doesn't make it wrong. It's the first thing you'd say to a user who comes with complaints about old versions of your software.

It could be that issues like copy & paste not working, or windows that miss decorations, are or were GNOME-specific

It works perfectly on GNOME x11.

I was implying GNOME Wayland and in a discussion on Wayland I guess you understood that perfectly well. For extra clarity in the post you quoted I put a link to a 2020 comment (on a Github issue on missing window decotations) where the KeePassXC team said that “[t]hat's a problem with your window manager / compositor.“

Mind you, I still think that's a bug, but it's a bug in GNOME which is a known bad actor when it comes to window decorations, so I'm not getting my hopes too high that they'll fix it. On the other hand maybe they already did — in your LTS VM you're probably running an old version of the compositor as well.

Regarding the "completely broken theme", KeePassXC comes with its own app-specific Qt theme by default and it looks like what you're seeing. It's not your system theme, so it looks broken to you

Complete bullshit see X11 screenshot.

All I see is that the Wayland screenshot shows the light mode of KeePassXC's built-in theme, while the X11 version shows the dark mode version of the same theme. So KeePassXC has not picked up from the compositor that it's running in dark mode. It does that correctly on KWin (just tested it - you need to select View → Design → Automatic if it's not set already). So I suspect that Mutter, or the version of Mutter in your old LTS VM, is not advertising the light/dark mode setting correctly, or that Qt on GTK-based DEs on Ubuntu, or at least on your old LTS Ubuntu, doesn't pick it up correctly. I don't use either Mutter or GTK-based DEs, so I can't say which it is.

Maybe try with a more recent Ubuntu VM, or with KDE Neon (recent KDE on Ubuntu base). That way we would know if it's a distro version issue or a general Mutter issue.

Please stop giving explanation that sound believable and seem correct, but are actually just plain wrong.

Stop getting so worked up and take a chill pill. I could have written a rant about how it's in bad faith to use an old LTS distro in a VM in a discussion about bugfixes, but I didn't. Actually I wrote a few points specifically to help you.

Is copy&paste working now?

Copy link

ghost commented Nov 11, 2023

Stop getting so worked up and take a chill pill

welcome to the internet, Where solutions are seen as aggressions, and nobody can tolerate any opinion other then their own

@flexibeast
Copy link

As simply another data point, i have been successfully using KeePassXC on Gentoo, under both Sway and now Wayfire, since i again checked out the state of Wayland for myself around six months ago. i haven't yet noticed any issues - i'm currently on 2.7.6, the version available in the main gentoo repo - although i don't make use of auto-fill.

(i don't particularly need Wayland; for my use-case, if everything related to Wayland disappeared, i'd happily go back to using i3, which was a great wm for me.)

@IverCoder
Copy link

I'm just gonna drop this here

image

@bodqhrohro
Copy link

bodqhrohro commented Nov 11, 2023 •
edited
Loading

@ssokolow

But we're not using it the way we did 30 years ago

Really? Word is generally the same as 30 years ago. Photoshop is generally the same as 30 years ago. If something changed, it should be changed back to achieve sustainability. Modernity won't last long.

and pushing what are essentially VRR video frames of top-level windows to the X server to display because they got fed up with its warts

That should be changed too. Applications should use simple vector primitives to draw the UI. Otherwise they're just not usable on slow hardware, regardless of the graphical server. And they should not assume the "every frame is perfect ideology", because drawing one frame may take seconds or tens of seconds, and users are not even supposed to wait until it's painted completely, because they may decide before that they don't need the rest to be painted and take some action.

Give The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) a watch

I promised to debunk this video a year or two ago and still didn't. It's full of false assumptions and blatant propaganda.

Talk to the GNOME people, not me.

That's pointless, I already tried to. They're assertive against contributions they're not going to maintain. And not just them, this plague has eaten many modern FOSS projects. Eternal bikeshedding to excuse the laziness.

Which is why you design systems so the lazy way is the secure way. Compare ActiveX Controls in Internet Explorer vs. other web technologies.

It would make sense if web itself was the "lazy way" on slatephones rather than mobile apps. Lazy users would rather install an app, even on a slow and costly connectivity, than open something in browser.
@phrxmd

but between Ctrl+B/Ctrl-C + Ctrl-V

Exposing the password to the clipboard where any process can read it from is totally unsecure.
@zocker-160

completely broken theme

I don't see any issues.

@phrxmd
Copy link

phrxmd commented Nov 11, 2023 •
edited
Loading

@phrxmd

but between Ctrl+B/Ctrl-C + Ctrl-V

Exposing the password to the clipboard where any process can read it from is totally unsecure.

I was kinda waiting for that comment, you did not disappoint :)

First of all you're of course right that the clipboard is not the most secure way to work with passwords. That's why Freedesktop.org has the SecretService standard, but this requires implementation in apps and it was created by GNOME, so this may trigger some people here.

That said, on Wayland the clipboard is a bit more secure in principle because pasting works by sending wl_data_device events to the receiving app. So you need to set up a receiver for that with a valid input serial. And then it's up to the compositor to validate those serials and to decide whether you'll receive those events (e.g. when your app is not in focus). That makes it a fair bit more difficult than on X11 to create an app that sits in the background surreptitiously and logs everything that goes through to the clipboard unnoticed. The compositor could also log these events, or you could have a clipboard manager do that for you, so in principle if there is a malicious app on your system logging clipboard access you could have a way of knowing it in a way you don't with X11. I'm not sure how this access control part of the spec is actually implemented in different compositors (I do know that wlroots at least has a data control protocol for that). Of course this may trigger some other people here who will cry "fragmentation".

Finally, independent of Wayland, apps like KeePass/KeePassXC also have browser extensions for common browsers that lessen the attack surface a bit.

@zocker-160
Copy link

@phrxmd

I was implying GNOME Wayland and in a discussion on Wayland I guess you understood that perfectly well.

Oh yes I totally understood that, but you are making the wrong conclusions. You are blaming GNOME for not implementing an optional Wayland protocol.

I am blaming Wayland for making such critical protocol optional or not even having a protocol in the first place causing all of the problems listed in this Gist.

Thanks to Wayland, applications now only work on a very specific combination of WM, DE and distro, while on X11 it just worked everywhere.

Your argument of "just use specific DE X and WM Y" is exactly what is the nonsense I am arguing against and why Wayland is the problem here.

So I suspect that Mutter, or the version of Mutter in your old LTS VM, is not advertising the light/dark mode setting correctly

Works fine on x11, does not work on Wayland, that is what I see and also what 99% of users will see.

I could have written a rant about how it's in bad faith to use an old LTS distro in a VM in a discussion about bugfixes, but I didn't

Thankfully you didn't, because that argument would be completely pointless anyway. You seem to suggest that using the latest version of everything will fix the issues.

I tell you a secret: it won't.

Actually I wrote a few points specifically to help you.

All you did was repeat nonsense that I have already addressed before you even answered.

All I did was to disprove your original claim that:

KeePassXC works on Wayland just fine, with themes, title bars, and copy&paste

Because no it does not work just fine, themes do not work, title bars do not work and copy&paste does not work either. All shown above.

Is copy&paste working now?

It isn't.

@zocker-160
Copy link

welcome to the internet, Where solutions are seen as aggressions, and nobody can tolerate any opinion other then their own

Welcome to the internet where ppl like @binex-dsk see facts and hard proof using screenshots as "opinions" he cannot tolerate.

Copy link

ghost commented Nov 11, 2023

Saying that a theme is broken seems like an opinion to me. It looks like the light theme of KeePassXC to me, nothing looks bad. You just have to select the dark theme in the config. That's what I have to do on both i3 and sway since I don't have a global Qt config. Nothing necessarily new.

Of course there's probably some GNOMEisms going on here. GNOME refuses to adopt certain Wayland protocols then blames Wayland for breaking userland experience on GNOME. If I remember correctly they used to do some really hacky stuff on X11 that had been in the xserver protocol for years but they refused to use the xserver implementation. Not a first for GNOME :)

Works fine on x11, does not work on Wayland, that is what I see and also what 99% of users will see.

Let's say you make an application, and release version 1.0.0 on LTS distros. A serious bug that negatively affects user experience and is easy to spot occurs on 1.0.0 but is fixed in 1.1.0. LTS distros don't have 1.1.0, so users of those distros then file dozens of bug reports about the aforementioned issue. What would your response be? Mine would be:

This is fixed in 1.1.0, I will try and get this version backported.

Wayland app developers are rightfully saying the same thing. An old version of Mutter doesn't properly support certain KeePassXC features because GNOME can't write any useful software for the life of them. I tried it on rolling-release Mutter and every major feature worked.

Idea: instead of mercilessly raging over a display protocol on the internet, solve the issues you're having and tolerate the fact that others have different experience to you. But that's too much to ask for on a Microsoft run platform.

@IverCoder
Copy link

It seems like y'all are so allergic to software developed by Red Hat. Or just any for-profit companies in general. If Wayland, PipeWire, and XDG Portals were developed by a bunch of computer nerds in their mom's basement instead of companies, this Gist will surely not exist.

The Linux kernel itself is being developed by thousands of developers paid by different for-profit companies, so if you hate Wayland because of Red Hat, well I have some bad news for you.

Copy link

ghost commented Nov 11, 2023

It seems like y'all are so allergic to software developed by Red Hat. Or just any for-profit companies in general. If Wayland, PipeWire, and XDG Portals were developed by a bunch of computer nerds in their mom's basement instead of companies, this Gist will surely not exist.

The Linux kernel itself is being developed by thousands of developers paid by different for-profit companies, so if you hate Wayland because of Red Hat, well I have some bad news for you.

The problems (which this gist is mainly talking about) would exist anyway if it was for or not for profit, where did you get that even from?

you seem to think that just because some nerd made it we wouldnt talk about how bad it is?
that makes no sense.

@probonopd
Copy link
Author

probonopd commented Nov 11, 2023 •
edited
Loading

We are allergic to it only when it is pushed upon us, amking it look like the inevitable only way to do things.

They can do their things, but they should not expect (or subtly force) everyone to do things in their way.

@ssokolow
Copy link

Really? Word is generally the same as 30 years ago. Photoshop is generally the same as 30 years ago. If something changed, it should be changed back to achieve sustainability. Modernity won't last long.

Qt has done client-side rendering since Qt 4. I remember how there was much howling and gnashing of teeth from the GTK+ crowd at how they didn't have the manpower to keep up with that. I can't remember whether it made it in during the GTK 3.x cycle or whether it's a GTK 4 thing, but GTK is going for full client-side rendering so thet can push as much of it as possible onto the GPU.

Really? Word is generally the same as 30 years ago. Photoshop is generally the same as 30 years ago. If something changed, it should be changed back to achieve sustainability. Modernity won't last long.

Let me know when you've got a URL for me to read/watch.

That's pointless, I already tried to. They're assertive against contributions they're not going to maintain. And not just them, this plague has eaten many modern FOSS projects. Eternal bikeshedding to excuse the laziness.

My point is that they're addressing actual threats that have been demonstrated on less niche operating systems. It's not my fault that GNOME is so incompetent at reconciling conflicting user needs.

It would make sense if web itself was the "lazy way" on slatephones rather than mobile apps. Lazy users would rather install an app, even on a slow and costly connectivity, than open something in browser.

I think it's more that platform companies who profit from walled gardens push developers and users to go that way.

Oh yes I totally understood that, but you are making the wrong conclusions. You are blaming GNOME for not implementing an optional Wayland protocol.

I am blaming Wayland for making such critical protocol optional or not even having a protocol in the first place causing all of the problems listed in this Gist.

Wayland makes the concept of having more than just a single permanently fullscreen window optional, because it's also used for things like vehicle infotainment consoles and public kiosks.

Copy link

ghost commented Nov 11, 2023

@phrxmd

but between Ctrl+B/Ctrl-C + Ctrl-V

Exposing the password to the clipboard where any process can read it from is totally unsecure.

I was kinda waiting for that comment, you did not disappoint :)

that's entirely besides the point, you like going off-topic and repeating old arguments that were shot off 2 or so comments ago, dont you?

@probonopd
Copy link
Author

Wayland makes the concept of having more than just a single permanently fullscreen window optional

In other words, a step backward for the desktop.

For embedded use cases that don't need windows, why not just use https://www.libsdl.org/.

Copy link

ghost commented Nov 12, 2023

In other words, a step backward for the desktop.

Because options are bad. 🤣 explains why you hate Wayland.

@probonopd
Copy link
Author

probonopd commented Nov 12, 2023 •
edited
Loading

I just want my desktop to function like it has for the past 4 decades.

Copy link

ghost commented Nov 12, 2023

And the option to disable windowing for full screen apps isn't stopping you ...

@probonopd
Copy link
Author

Well, as long as it supports proper windows with proper server-side decorations and proper window icons just like in X11 that'd be all I'd need.

@IverCoder
Copy link

IverCoder commented Nov 12, 2023 •
edited
Loading

@probonopd

We are allergic to it only when it is pushed upon us, amking it look like the inevitable only way to do things.

They can do their things, but they should not expect (or subtly force) everyone to do things in their way.

You are not being "forced" to switch to Wayland and it's technically impossible to do so because this is free-as-in-freedom software we're talking about. If you think you are being "subtly forced" to switch to Wayland, it is because you are just too lazy to maintain the X11 ecosystem when the big players eventually move on from it. To quote two of my previous comments...

https://www.youtube.com/watch?v=QPTfQOOBB3k

As it stands today we have a wide range of desktops and window managers on X11 but as we move into a Wayland world many are finding the transition very difficult and whilst it may get a bit easier some desktops will simply be left behind

So depressing.

Reason to think twice before abandoning Xorg!

Well, they won't be really left behind as you want to seemingly make it sound like. People like you and other pro-X11 developers will surely continue maintaining and adding new features to X11 DEs. Wayland-only apps that chose to go with the efficient decision of dropping the X11 baggage can just be run under weston or cage, maybe this can be automated by X11 DEs/WMs.

In my opinion, with many smart and resourceful people still backing X11 today, X11 will still be thriving alongside Wayland for decades to come, as a niche but stable thing. "Abandoning Xorg" isn't much of a problem as people want to make it sound like—it will always be maintained for features and compatibility for the years to come. Who cares about Qt, GTK, or mainstream distros completely dumping X11?

Smart people will surely just adapt X.org to fit with the times and make X11-focused distros and DEs. Or make alternatives/forks of apps to focus on X11. You're one of those smart people (you literally invented AppImages) so I'm pretty sure you'll be one of those people continuing to maintain the X11 ecosystem for the decades to come.

I'm just gonna drop this here

image

You want to keep X11 a viable platform even after most other developers drop it? That's your homework. Go make a WaylandX compatibility layer and your own X11 DEs, nobody is preventing you.

@probonopd
Copy link
Author

probonopd commented Nov 12, 2023 •
edited
Loading

If you think you are being "subtly forced" to switch to Wayland

Just found the first application that only works on Wayland and not on X11. That is exactly the breakage that I fear most from Wayland. Basically this means that if I want to use that application, then I am not-so-subtly forced to use Wayland, and in my case, that would also mean to use a different desktop environment with a whole different set of objectives from what I am currently using. Not going to do that. That application will not win me as a customer anytime soon. (It's a commercial one, by the way.)

For this exact reason the message of this gist is so important:

Vendors, don't jump onto the Wayland bandwaggon, alienating everyone else. Wayland is not a replacement for X11, it follows a different philosophy, and it forces desktops to work in certain ways that doesn't fit the philosophy of all desktops.

@bodqhrohro
Copy link

@IverCoder

It seems like y'all are so allergic to software developed by Red Hat. Or just any for-profit companies in general

Germany is full of commies from angeschlossen DDR. The parent of Linus, Nils Torvalds, was a member of Communist Party of Finland and studied in Moscow. The FOSS movement in general is anti-capitalist. No idea what is surprising for you.

The Linux kernel itself is being developed by thousands of developers paid by different for-profit companies, so if you hate Wayland because of Red Hat, well I have some bad news for you.

OP is a BSD lover lol, why do you brag with Linux?

it is because you are just too lazy to maintain the X11 ecosystem when the big players eventually move on from it

The problem of defaults in distributions is more about decision making and lobbying than about maintenance.

@ssokolow

I remember how there was much howling and gnashing of teeth from the GTK+ crowd at how they didn't have the manpower to keep up with that

They'd better not even jump into this bandwagon then. One of key reasons I prefer GTK+2 is its way better rendering performance on slow hardware if compared to GTK+3. Qt4 is not significantly worse for that matter though, so GTK+3 has severe issues in the rendering pipeline.

so thet can push as much of it as possible onto the GPU

They could do that via GLX just as well in order to keep network transparency.

I think it's more that platform companies who profit from walled gardens push developers and users to go that way.

True, but pirates made users resist that push on other platforms. And now it's not as powerful force as before. Antitrust lawsuits are also not as strong as before nowadays, even though EU puts an eye on big companies again.

@bodqhrohro
Copy link

in my case, that would also mean to use a different desktop environment

How? Do applications which only work with Pulseaudio and not with bare ALSA require you to install PulseAudio and route the sound from the rest of apps via it when apulse exists?

@probonopd
Copy link
Author

How?

helloDesktop, and GNUstep do not use Wayland and the way they work is different from how Wayland thinks things should work.

@bodqhrohro
Copy link

helloDesktop, and GNUstep do not use Wayland

They don't need to to run a Wayland client.

@IverCoder
Copy link

If you think you are being "subtly forced" to switch to Wayland

Just found the first application that only works on Wayland and not on X11. That is exactly the breakage that I fear most from Wayland. Basically this means that if I want to use that application, then I am not-so-subtly forced to use Wayland, and in my case, that would also mean to use a different desktop environment with a whole different set of objectives from what I am currently using. Not going to do that. That application will not win me as a customer anytime soon. (It's a commercial one, by the way.)

For this exact reason the message of this gist is so important:

Vendors, don't jump onto the Wayland bandwaggon, alienating everyone else. Wayland is not a replacement for X11, it follows a different philosophy, and it forces desktops to work in certain ways that doesn't fit the philosophy of all desktops.

Quoting myself again...

Go make a WaylandX compatibility layer and your own X11 DEs, nobody is preventing you.

It is not anybody else's responsibility to support users of old technology. They explicitly decided that their software would only be supported for Wayland, but they never made it illegal or technically impossible to run it on X11.

Wayland-exclusive software? Go run it on cage or weston or make a DE that automates and integrates the process. It's not vendors' responsibility to pamper and duplicate efforts just for holdouts like you.

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