Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active April 27, 2025 19:14
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

@ssokolow
Copy link

ssokolow commented Nov 7, 2023 •
edited
Loading

Resource forks were always in a key=value format, with four-letter key. What the document is saying is “data is what the data fork is for, don't use the resource fork for storing data.” (“Do not use it to open ‘another data fork.‘”) As always, when a manufacturer issues a warning against doing something, it's because people are doing it :) It probably didn't help that Apple weren't 100% consistent with this themselves for things like fonts, which would contain data in the resource fork.

That's not what I'm getting from it.

"Don't use the resource fork of a file for non-resource data. Parts of the system (including the File Manager and the Finder) assume that if this fork exists, it will contain valid Resource Manager information." sounds like it's saying "You have means to shove stuff that isn't valid Resource Manager format into the resource fork. Don't."

"PBOpenRF was provided to allow copying of the resource fork of a file in its entirety, without Resource Manager interpretation. Do not use it to open "another data fork."" reinforces that by saying "PBOpenRF is the thing that allows the resource fork to be read/written as a blob without well-formedness enforcement."

I guess Apple decided not to go that way because if you serialize your resource and data forks into a packed file format by default every time you put a file on a server or a non-Apple filesystem, other people lose access to the unserialized data content of your files, at least if they don't use a Mac. In 1984 that was not a problem, because few people were sharing files between Macs and other systems, but eventually maintaining interoperability arguably became more important.

I still think that's solvable. For example, any file with no resource fork could be serialized to resource-fork-less channels as a bare data fork (what they were already doing regardless of resouce fork presence/absence), and they could have a database of file type codes that should always be a bare data fork, pre-populate it with the most common formats that are also meaningful to open on non-macs (eg. GIF), and then encourage application developers, to use the new APIs to add formats they support to it where appropriate.

Heck, if they published a free AppleSingle library for non-mac applications to interchange with mac files, they could wind up in an SQLite-esque situation where AppleSingle it is de facto standard format for structured files on all platforms and wouldn't Apple like having that leverage over the industry.

@HappyGoFishing
Copy link

I just hate gnome devs. not wayland. nuff said.

@Thaodan
Copy link

Thaodan commented Nov 7, 2023 via email

@fgclue
Copy link

fgclue commented Nov 8, 2023

X11 sucks guys wayland better5 2874.

@probonopd
Copy link
Author

You solve the IPC problem by the same mechanism you already do your IPC, outside of the display server. You're not going to like this answer.

So, Wayland takes away Atoms and replaces them with... nothing, leaving the exercise to find a suitable replacement to application and/or desktop environment developers?

Copy link

ghost commented Nov 8, 2023

Classic windows argument. "Let's centralize everything!" Exactly why X11 died out. 🤣

@ssokolow
Copy link

ssokolow commented Nov 8, 2023

An argument can, however, be made that, if Wayland is going to be responsible for creating and defining windows, then Wayland should also be responsible for providing a means to attach key=value metadata to those windows.

Sort of like how ID3 goes inside the MP3 file, not as a sidecar file.

@Monsterovich
Copy link

Classic windows argument. "Let's centralize everything!" Exactly why X11 died out. 🤣

Just one of those cases where centralization and generalization is a good thing. Whereas fragmentation is an indicator of an immature architecture.

@phrxmd
Copy link

phrxmd commented Nov 8, 2023

An argument can, however, be made that, if Wayland is going to be responsible for creating and defining windows, then Wayland should also be responsible for providing a means to attach key=value metadata to those windows.

Do you know many examples of other windowing systems apart from X11 that allow you to attach arbitrary metadata to rectangles on the screen? After all the need for that in X11 came out of a specific 1980s problem in network communication.

@bodqhrohro
Copy link

@lukefromdc

First of all, in the US, when the word "Indian" is used without context, it's very often an obsolete term for Indigenous/Native American/First Nations people

Here too.

by US standards

Doesn't count, average US standards are enormously high. There's a reason people dream of getting a green card and living on welfare, after all.

wealth is not necessary to enjoy a 100% ad-free Internet

You don't encounter severe net neutrality violations, right? Like, free traffic for selected Big Evil Co. services, and paid for the rest?

Those services, especially if talking about Meta and Alphabet, are "officially" filled with ads. Driven by ads. That's why they afford "free" services in the first place: because they are monetized by means of using users (useds in RMS terminology) as gears of capitalism. I have no idea why did you even mention ad blocking, it's completely unrelated. In Facebook, the boundary between ads and content has blurred beyond recognition long ago. If you want to "block" ads, you want to make the service basically useless (so there would be no BigBrother-driven single feed, which is why users come there for in the first place).

US
EU

Stop being focused on civilized countries please. The world is much bigger than that, and the majority of planet's population lives beyond them.

@fgclue

X11 is literally older than Linux

And? X11 is common for much more UNIX-like systems than Linux. Why are you even focused on Linux that much at all?

it works

That's enough. In your words: shut the hell up and don't touch things that just work. There are lots of much older software used for serious industrial purposes, not as pet projects for CADT kids.

googlethatforyou

Don't advertise FAANGs please. Such advises should be search engine agnostic.
@uncomfyhalomacro

Like everyone noticed, the Xorg developers are taking their hands off on X11/X and the current situation is that they are focused now on Wayland

That's a rotten Wayland propagandist mantra.

Keith Packard is one of key developers of X.Org, and isn't involved into any Wayland compositors.
@binex-dsk

This is exactly why everybody uses Flatpak.

Flatpak has a major downside of needing a lot of space on the system partition (and needs lots of traffic and a stable connection to download runtimes). Appimages can be kept even on a pen drive to be run on live systems. Exactly how portable .exe files for Windows are.
@zocker-160

because I often used that icon to show different states of an application

What if users of your application prefer to not display window icons at all? That shouldn't be an only way of indication. In similar way, smelly apps rely on tray icons, and thus are unusable exclusively from keyboard.

Second I do have control over it on Windows and MacOS.

You don't, I might hide window icons there just as well.

No I simply support what the majority uses

Then why the heck are you bragging with your social darwinism in front of a minority?
@ssokolow

That's desktop integration too and there's precedent in that double-clicking an MP3 with no embedded cover art and having it play in MPV will result in music/podcast playback that can only be stopped by killing the process

You could ask the same way why ANY CLI/TUI app has no representation in the graphical environment and has no tools to be operated with other than a task manager. I find this split to separate worlds of CLI/TUI and GUI a fundamental problem of the whole way fd.o desktop is built, and a reason it should be fundamentally rethinked over concepts native to UNIX-like systems. And no, I don't find mandatorily launching a separate terminal window for every such an app an acceptable solution.

re-runs itself inside a wrapper which will invokes necessary commands like xdg-desktop-menu to add the icon and then clean it up whether or not its child exits cleanly

Brrr, reminds me the kludges Total/Double Commander use to open files from archives. No, thanks, I find FUSE a much more usable solution. Could work the same way for AppImages actually, so they mount something actually browsable by users, rather than a black box.

Any damn game has access to the same XRandR APIs that are used to permanently change display resolutions, so any game which changes the resolution when it fullscreens is likely to confuse the WM and crush all my windows onto my center monitor.

I'd say that's expected behaviour from Windows. Oh, and users shouldn't painstakingly arrange icons on their desktops, for the same reason.
@OGrigorios

Nice shitpost, but this is github not 4chan

Indeed, people don't seem to realize enough it's a platform regulated by Microsoft and not actually suited for prolonged discussions at all.
@phrxmd

In 1984 that made sense

It still does. Mixing file contents with metadata and making files different sorts of incompatible containers to come over this issue is far from a good solution. And nowadays we actually have some kind of filesystem metadata on all major platforms (NTFS streams, xattrs, and the resource forks you mentioned), while simplistic legacy filesystems like FAT32 and UDF are gradually coming into oblivion. But this spread of containers allowing to keep metadata in the file content instead of filesystem metadata somehow became so settled down that it's not even questioned anymore.

Copy link

ghost commented Nov 8, 2023

Flatpak has a major downside of needing a lot of space on the system partition (and needs lots of traffic and a stable connection to download runtimes). Appimages can be kept even on a pen drive to be run on live systems. Exactly how portable .exe files for Windows are.

and they function 100x better for 2x the storage space. Storage is cheap, functionality is not. I'm not using probonopd's shitty piece of "software" to save 5MB on my system. I'll take the 10MB that work.

@zocker-160
Copy link

zocker-160 commented Nov 9, 2023 •
edited
Loading

@bodqhrohro

What if users of your application prefer to not display window icons at all?

Then that is their choice, which is perfectly fine with me. Where is the problem?

That shouldn't be an only way of indication.

Who said that it was? I didn't. And even if it was, it is not my problem, if the user decides to hide it.

In similar way, smelly apps rely on tray icons, and thus are unusable exclusively from keyboard.

Again as I said earlier, this is also not my problem. So far I haven't gotten a single bug report from users, that the application is not usable with keyboard only. So from that I conclude that it is a non-issue.

You don't, I might hide window icons there just as well.

Which is perfectly fine. I have no problem with that.

Then why the heck are you bragging with your social darwinism in front of a minority?

Why so aggressive? Did I hurt your feelings?

So to summarize:

I have no problem with the user wanting to hide the icon, that is fine by me.

I however do have a problem with users reporting the icon missing or not updating as they expect on Wayland, because Wayland put in a nonsensical arbitrary limitation for no reason.

@phrxmd
Copy link

phrxmd commented Nov 9, 2023

Like everyone noticed, the Xorg developers are taking their hands off on X11/X and the current situation is that they are focused now on Wayland

That's a rotten Wayland propagandist mantra.

Keith Packard is one of key developers of X.Org, and isn't involved into any Wayland compositors.

He hasn't been contributed code to Xorg in two years, his last activity on the Xorg Gitlab were a few comments eight months ago.

@ssokolow
Copy link

ssokolow commented Nov 9, 2023

First of all, in the US, when the word "Indian" is used without context, it's very often an obsolete term for Indigenous/Native American/First Nations people

Here too.

Funny thing is, I remember watching a video recently about how a lot of indigenous people in the U.S. actually prefer "Indian" as a blanket term when talking generally about people from a variety of different tribes and see things like "Native American" as something pushed on them by middle-class white people without asking what they thought of it.

(As a Canadian, that surprised me. Last I checked, First Nations was the preferred blanket term here for people who are neither Inuit nor Métis.)

Flatpak has a major downside of needing a lot of space on the system partition

https://docs.flatpak.org/en/latest/tips-and-tricks.html#adding-a-custom-installation

What if users of your application prefer to not display window icons at all?

Did you read the comments on the proposal? The purpose of different icons is as an aid (i.e. optional) to telling the different parts of the application apart. That shouldn't be an only way of indication.

In similar way, smelly apps rely on tray icons, and thus are unusable exclusively from keyboard.

XEmbed tray icons, sure. Modern StatusNotifierItem-based tray icons are rendered by the taskbar and are basically just taskbar items which may or may not have an associated window and an associated custom context menu, The taskbar can style them and hook up user input however it wants.

You could ask the same way why ANY CLI/TUI app has no representation in the graphical environment and has no tools to be operated with other than a task manager. I find this split to separate worlds of CLI/TUI and GUI a fundamental problem of the whole way fd.o desktop is built, and a reason it should be fundamentally rethinked over concepts native to UNIX-like systems. And no, I don't find mandatorily launching a separate terminal window for every such an app an acceptable solution.

My point was that they're cherry-picking where their rationale applies and where things get grandfathered in.

I wouldn't want a forced terminal window either, but it'd be nice to have a tray icon which presents a menu of tasks that were launched visually but never presented a window, where the DE can hang "is playing audio icons" and "send SIGINT (Ctrl+C)" menu items and such.

Brrr, reminds me the kludges Total/Double Commander use to open files from archives. No, thanks, I find FUSE a much more usable solution. Could work the same way for AppImages actually, so they mount something actually browsable by users, rather than a black box.

I don't feel like requiring potential developers install a FUSE filesystem, or requiring an Appimage be built, just to test-run builds in a git checkout.

In essence, your "Brrr" is the intended reaction. I'm implicitly threatening that, if they don't provide .desktop-less way to set window icons under Wayland, they're going to see developers like me using ugly hacks to work around their vision of how The Perfect World™ should work.

(To be honest, I'm more likely to just hard-code "XWayland or nothing" semantics for Wayland support, as some applications like LibrePCB already are.)

I'd say that's expected behaviour from Windows. Oh, and users shouldn't painstakingly arrange icons on their desktops, for the same reason.

...and it's why I run my Wine games in a virtual desktop window and initially launch my Linux games in Xephyr so I have a chance to switch them into windowed mode before they can muck things up.

This is the stated reason that Wayland exposes a "fullscreen this window" API to unprivileged applications, but no "change resolution" API.

Indeed, people don't seem to realize enough it's a platform regulated by Microsoft and not actually suited for prolonged discussions at all.

It's a pastebin that just happens to support comments. What do you expect?

But this spread of containers allowing to keep metadata in the file content instead of filesystem metadata somehow became so settled down that it's not even questioned anymore.

To be fair, this isn't the first time this has happened. UNIX's "files are just bags of bytes" design was running counter to the structured file access APIs of other OSes of the time.

@ssokolow
Copy link

ssokolow commented Nov 9, 2023

An argument can, however, be made that, if Wayland is going to be responsible for creating and defining windows, then Wayland should also be responsible for providing a means to attach key=value metadata to those windows.

Do you know many examples of other windowing systems apart from X11 that allow you to attach arbitrary metadata to rectangles on the screen? After all the need for that in X11 came out of a specific 1980s problem in network communication.

Other windowing systems allow you to get a globally unique identifier for foreign windows. Wayland limits that to very specific niches for security reasons. Also, other windowing systems generally run on platforms where they're part of a unified platform API like Win32 or Cocoa with a unified vision for how things should work.

@lukefromdc
Copy link

lukefromdc commented Nov 9, 2023 •
edited
Loading

@bodqhrohro , I have no use for the big ad supported services and their paid for, non-neutral fast lanes at all, just as a bicycle commuter in Germany does not need the autobahn or toll highways. Needless to day, that German cyclist doesn't pay more for avoiding highways, they pay less, needing only repair parts. No gas needed for the cyclist, no ads imposed on the user of Mastodon instead of Facebook.

I do not use Google or Meta products at all (nor any subscription or TV services), have no accounts with any of them, and thus net neutrality violations affect me simply as slower service on all of the sites I actually use, same as driving on a sometimes congested road having express toll lanes you never use and don't have or want a transponder for.

If a cell phone company cuts deals with the big video sites to cap resolution to lower paying customers without their app, I am not affected because the servers I use don't have a business relationship with them, only w their own ISP. They avoid the toll lane for lack of a transponder in this case. I may "get less" but I do not pay more, With no TV, Netflix, or video ads, I can get by with less bandwidth just as most of the world uses less gasoline than Americans do. Netflix is the ten thousand pound SUV of bandwidth hogs.

As for zero-rated services, I've never used one. One ISP I dumped a while back included one but I ignored it. Their data was the most expensive I ever used and I caught them trying to install CarrierIQ on top of that, so I dumped them as fast as possible. I was only on them due to a temporary shortage of SIM cards in DC after a prior carrier changed networks and all their SIMS stopped working for data. I had to dump-and-replace and so did everyone else, so SIMS ran out.

@uncomfyhalomacro
Copy link

@bodqhrohro

Don't advertise FAANGs please. Such advises should be search engine agnostic.
@uncomfyhalomacro

I don't disagree on that but I want corpo overlords to sue us https://en.wikipedia.org/wiki/Google_(verb) :(

google actually are really cagey about google as a verb because if it is a verb they lose trademark in some countries eg japan

But im going to leave this discussion now. :D

@lukefromdc
Copy link

lukefromdc commented Nov 9, 2023 •
edited
Loading

I just hate gnome devs. not wayland. nuff said.

I work on MATE and I do NOT hate GNOME devs, I just prefer a different UI so that's what I work on. There are still some brillient programmers at GNOME, even if what they want to do for a UI and what I want have diverged. Diversity is a plus not a minus, as people don't get forced to use things that don't work for them. Seems to me it's backend diversity, not frontend diversity, that creates headaches for packagers of 3ed party packages. An issue with say, header bars showing in MATE doesn't mean the package won't work, it's just a visual mismatch. Having NO decorations in GNOME on wayland is more serious, as in this case a backend isn't being properly supported. It's GNOME that pays the price for that though, we end up with applications that work on everything, and which work on everything except GNOME. Their problem not ours, and their decisions to make.

@fgclue
Copy link

fgclue commented Nov 9, 2023

@lukefromdc

First of all, in the US, when the word "Indian" is used without context, it's very often an obsolete term for Indigenous/Native American/First Nations people

Here too.

by US standards

Doesn't count, average US standards are enormously high. There's a reason people dream of getting a green card and living on welfare, after all.

wealth is not necessary to enjoy a 100% ad-free Internet

You don't encounter severe net neutrality violations, right? Like, free traffic for selected Big Evil Co. services, and paid for the rest?

Those services, especially if talking about Meta and Alphabet, are "officially" filled with ads. Driven by ads. That's why they afford "free" services in the first place: because they are monetized by means of using users (useds in RMS terminology) as gears of capitalism. I have no idea why did you even mention ad blocking, it's completely unrelated. In Facebook, the boundary between ads and content has blurred beyond recognition long ago. If you want to "block" ads, you want to make the service basically useless (so there would be no BigBrother-driven single feed, which is why users come there for in the first place).

US
EU

Stop being focused on civilized countries please. The world is much bigger than that, and the majority of planet's population lives beyond them.

@fgclue

X11 is literally older than Linux

And? X11 is common for much more UNIX-like systems than Linux. Why are you even focused on Linux that much at all?

it works

That's enough. In your words: shut the hell up and don't touch things that just work. There are lots of much older software used for serious industrial purposes, not as pet projects for CADT kids.

googlethatforyou

Don't advertise FAANGs please. Such advises should be search engine agnostic. @uncomfyhalomacro

Like everyone noticed, the Xorg developers are taking their hands off on X11/X and the current situation is that they are focused now on Wayland

That's a rotten Wayland propagandist mantra.

Keith Packard is one of key developers of X.Org, and isn't involved into any Wayland compositors. @binex-dsk

This is exactly why everybody uses Flatpak.

Flatpak has a major downside of needing a lot of space on the system partition (and needs lots of traffic and a stable connection to download runtimes). Appimages can be kept even on a pen drive to be run on live systems. Exactly how portable .exe files for Windows are. @zocker-160

because I often used that icon to show different states of an application

What if users of your application prefer to not display window icons at all? That shouldn't be an only way of indication. In similar way, smelly apps rely on tray icons, and thus are unusable exclusively from keyboard.

Second I do have control over it on Windows and MacOS.

You don't, I might hide window icons there just as well.

No I simply support what the majority uses

Then why the heck are you bragging with your social darwinism in front of a minority? @ssokolow

That's desktop integration too and there's precedent in that double-clicking an MP3 with no embedded cover art and having it play in MPV will result in music/podcast playback that can only be stopped by killing the process

You could ask the same way why ANY CLI/TUI app has no representation in the graphical environment and has no tools to be operated with other than a task manager. I find this split to separate worlds of CLI/TUI and GUI a fundamental problem of the whole way fd.o desktop is built, and a reason it should be fundamentally rethinked over concepts native to UNIX-like systems. And no, I don't find mandatorily launching a separate terminal window for every such an app an acceptable solution.

re-runs itself inside a wrapper which will invokes necessary commands like xdg-desktop-menu to add the icon and then clean it up whether or not its child exits cleanly

Brrr, reminds me the kludges Total/Double Commander use to open files from archives. No, thanks, I find FUSE a much more usable solution. Could work the same way for AppImages actually, so they mount something actually browsable by users, rather than a black box.

Any damn game has access to the same XRandR APIs that are used to permanently change display resolutions, so any game which changes the resolution when it fullscreens is likely to confuse the WM and crush all my windows onto my center monitor.

I'd say that's expected behaviour from Windows. Oh, and users shouldn't painstakingly arrange icons on their desktops, for the same reason. @OGrigorios

Nice shitpost, but this is github not 4chan

Indeed, people don't seem to realize enough it's a platform regulated by Microsoft and not actually suited for prolonged discussions at all. @phrxmd

In 1984 that made sense

It still does. Mixing file contents with metadata and making files different sorts of incompatible containers to come over this issue is far from a good solution. And nowadays we actually have some kind of filesystem metadata on all major platforms (NTFS streams, xattrs, and the resource forks you mentioned), while simplistic legacy filesystems like FAT32 and UDF are gradually coming into oblivion. But this spread of containers allowing to keep metadata in the file content instead of filesystem metadata somehow became so settled down that it's not even questioned anymore.

maybe because x11 is most used on linux?

@fgclue
Copy link

fgclue commented Nov 9, 2023

LOL!!!!!! this argument is almost 4 years old. y'all have such a sad life

@dec05eba
Copy link

dec05eba commented Nov 9, 2023

You solve the IPC problem by the same mechanism you already do your IPC, outside of the display server. You're not going to like this answer.

So, Wayland takes away Atoms and replaces them with... nothing, leaving the exercise to find a suitable replacement to application and/or desktop environment developers?

True, which is why even gamescope uses X11 atoms. You need to create a new wayland protocol to do every single small thing

@probonopd
Copy link
Author

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!

@fgclue
Copy link

fgclue commented Nov 9, 2023 •
edited
Loading

<Person> got so mad that he deleted my comment. Reason to think twice before not having a life and staying inside all day. It's not healthy.

@IverCoder
Copy link

IverCoder commented Nov 10, 2023 •
edited
Loading

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.

@mikkorantalainen
Copy link

mikkorantalainen commented Nov 10, 2023 •
edited
Loading

One must consider Wayland a new display architecture and as a result, it requires GPU drivers that support the new acceleration interfaces. Nvidia hasn't bothered to implement this and because their drivers are closed source, nobody else can do that either.

Let that sink in: it's not that Wayland doesn't support Nvidia, it's the other way around. Nvidia only provides and supports Xorg drivers. And you cannot fully use the hardware without having fully working drivers for said hardware.

I think that in long run Wayland is the only way forward unless Xorg subsumes one of the compositors because the current architecture where application (x client) has to transmit data to X server using X protocols (one context switch), then X server transmits the data to compositor (second context switch), compositor does its stuff and then transmits the data back to X server (third context switch) which actually renders the image. This whole setup has 3x context switches (and those are serialized and cannot run in parallel!) required compared to Wayland which only needs one. Because context switch overhead is getting bigger and bigger with modern CPUs (relative to the overall computing speed of the CPU), getting rid of the extra context switches is really important because every context switch requires trashing the TLB caches to avoid Spectre-class security vulnerabilities.

Currently the only way to run a game in Xorg with low latency (that is, avoid context switching overhead) is to always explicitly disable / kill your X compositor before starting a game (or other software requiring low latency output) and after stopping using the application, re-enabling the compositor. Note that if the application doesn't implement it's own replacement to variable frame rate control or vsync, you'll experience screen tearing artefacts when X compositor is not running, so you cannot multitask without rendering artefacts with high performance on Xorg. The closest you can get to low latency + high performance on Xorg is to use intel GPU with TearFree config which gets correct rendering with very small extra latency even if you don't run compositor at all. And even that doesn't work with variable frame rate output, though, as far as I know.

Disabling global stuff like the compositor to get acceptable latency for a single app is not a sensible plan for the long term solution.

An example of the stuff that you can do in Wayland but not in Xorg is gamescope: https://github.com/ValveSoftware/gamescope

So basically your options are either to integrate some compositor into the Xorg and set the features and limitations of said compositor in stone, or switch to Wayland. Wayland has a lot of requirements for the compositor because it's basically doing this same stuff (display management is in the same process with compositor) and to make that task a slightly easier, Wayland dropped a lot of features that Xorg had due historical reasons. Wayland behavior depends on your compositor because that's the design they opted for to allow future improvements in compositors.

None of this actually requires CSD (which I hate with passion) but Wayland decided to practically require CSD always to make the wayland compositor simpler. ("Somebody else takes care of the window decorations and user interface.")

And claiming that Xorg supports running applications with different credentials (e.g. some GUI applications running as root and the rest running as user mode apps) isn't actually true either. Sure, you can technically do that but it's not safe. This is because the X protocol considers every window similar to each other and e.g. specifically any of those user mode apps can listen to the keyboard of the root owned processes and send keyboard or mouse events to said root owned window. You basically have to trust all concurrently executed X clients if you run any root owned X client at the same time. Note that you can also take full screen captures without root credentials so the attacker could also see (with human eyes or AI vision system) all the output available to the user of the process running as root.

Here are some resources to better understand the lack of safety in X between applications running with different credentials:

The important thing to understand is that this unsafe behavior cannot be fixed without breaking the X protocol because the issue exists at the protocol level. The example above uses xtest extension but that's only to make the demo easier to create, not because only xtest protocol were the only problem. And if I've understood correctly, switching everything to Wayland is considered technically easier solution than trying to fix the X protocol!

Yes, a lot of programs starting with "x" assume they are running on Xorg and will fail in various ways when you try to run those on Wayland which is not an X server at all. You can run xwayland as an additional helper process to try to make those programs work as much as possible but that should be considered an emulation layer, not a replacement for Xorg. When Wine has native Wayland support, its performance should be practically identical to xwayland and old X programs and win32/win64 programs would have roughly equal amount of emulated layers before rendering into GPU memory and output pixels on your monitor.

In hindsight, I think it would have been better to improve Xorg incrementally instead of switching to totally new implementation. That is, the assumption that switching everything over is easier than fixing the X protocol was not probably the correct assumption. Xorg could have implemented some kind of compositor plugin system where it would have supported switching compositors but running those in the same process with the X server to avoid context switch overhead. However, even that would have required breaking the X APIs that allow unsafe control and data leaks between X clients running with different credentials.

TL;DR: Wayland is currently like systemd, it has a reason to exist and once its implementation quality gets high enough, it will be better than the old tech. For both, however, the current implementation quality is not high enough to warrant the switch in most cases, but for systemd most distros have already switched anyway!

@Monsterovich
Copy link

Monsterovich commented Nov 10, 2023 •
edited
Loading

@mikkorantalainen

This whole setup has 3x context switches (and those are serialized and cannot run in parallel!) required compared to Wayland which only needs one.

This is the kind of idiocy that can be equivalent to "Wayland does it faster because there are no features there". Xorg is done just right, so there is proper screen recording without crutches, access of windows to each other, etc. The fact that there are multiple contexts is normal, because Xorg has more complex framebuffer handling than Wayland, where they try to put everything into one application (spaghetti architecture).

Currently the way to game in Xorg with low latency (to avoid context switching overhead) is to always explicitly disable / kill your X compositor before starting a game (or other software requiring low latency output) and after stopping using the application, re-enabling the compositor

Because the compositor isn't necessary at all in full screen scenarios, and V-Sync adds latency. In the picom compositor there is an option uredir_if_possible, which disables compositing and releases video memory when you run the application in fullscreen mode.

Wayland has a lot of requirements for the compositor because it's basically doing this same stuff (display management is in the same process with compositor) and to make that task a slightly easier,

Not just a compositor. All of this is just anti-pattern and it increases the probability of a server crash and generally removes interchangeability between DE components and all this for the sake of a tiny increase in performance.

And claiming that Xorg supports running applications with different credentials (e.g. some GUI applications running as root and the rest running as user mode apps) isn't actually true either. Sure, you can technically do that but it's not safe.

Another security nerd. Nobody gives a sh*t about security. Otherwise Xorg would have had features for permissions and other stuff (like XACE Spec) a long time ago.

Wayland is currently like systemd, it has a reason to exist and once its implementation quality gets high enough, it will be better than the old tech.

Even Systemd wasn't as architecturally ugly as Wayland. So it's weird to compare them to each other.

Copy link

ghost commented Nov 10, 2023

Another security nerd. Nobody gives a sh*t about security.

More soy raging! 🤣 Beautiful.

Tell that to any service that stores any sort of sensitive info.

@zocker-160
Copy link

zocker-160 commented Nov 10, 2023 •
edited
Loading

Tell that to any service that stores any sort of sensitive info.

Ah you mean like keepassxc for example?

keepassxreboot/keepassxc#2973

  • completely broken theme
  • windows with no title bar
  • copying to clipboard does not work
  • auto-type does not work

Answer from maintainer

We disabled it [Wayland] for the time being as it appears to be rather broken at the moment.

or keepassxreboot/keepassxc#9392

You cannot use Auto-Type when KeePassXC is running under Wayland. You have to either start KeePassXC on an X11 server or change your entire desktop env to use X11.

Looking through the issues with Wayland tag suggests that it is still quite broken to this day.

The developers are rightfully frustrated:

Quite frankly, this issue should be closed as "Won't fix" or locked until this mess is fixed in Wayland.
Originally back in 2013 Wayland was meant to cut out the "useless" middleman, ironically now we end up with even more useless middlemen just to deal with basic stuff like negotiating shortcut registering

Now you need to explain how a password manager not working properly due to Wayland garbage "security" reasons is increasing security in any way 😂 .

Copy link

ghost commented Nov 10, 2023

Now you need to explain how a password manager not working properly due to Wayland garbage "security" reasons is increasing security in any way 😂 .

Because a password manager shouldn't use a GUI, and the developers don't know how to write GUI software. :) A while ago I wrote a password manager (both GUI and CLI options), these features worked fine for me. That's the developers fault. :)

@ssokolow
Copy link

Now you need to explain how a password manager not working properly due to Wayland garbage "security" reasons is increasing security in any way 😂 .

Because a password manager shouldn't use a GUI, and the developers don't know how to write GUI software. :) A while ago I wrote a password manager (both GUI and CLI options), these features worked fine for me. That's the developers fault. :)

As a programmer, that statement makes me think you...

  1. Are irrelevant, because you're dismissing a non-trivial niche of users who don't want a CLI password manager and need to manage passwords for uses beyond which a browser extension would cover.
  2. Are either arrogant or ignorant, because Wayland's security model is specifically designed to prevent auto-type (it's an attack) and, last I checked, there wasn't a solid, easy-to-implement, cross-desktop-standardized way to achieve it via accessibility APIs.

In short, [citation needed].

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