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

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

Copy link

ghost commented Nov 10, 2023

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.

Even a CLI password manager is stupid, just use paper and be secure about it.

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.

That's interesting because it worked completely fine for me on sway. wlroots probably implements this protocol.

@ssokolow
Copy link

ssokolow commented Nov 10, 2023 •
edited
Loading

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.

Even a CLI password manager is stupid, just use paper and be secure about it.

O_O

I have a different hard-random password for every site I visit. You can't muscle-memory that into being efficient and far too many sites don't allow anything long enough to get equivalent entropy out of a passphrase.

Also, history has shown that your approach doesn't work in the real world with real people. That's one of the reasons there's the push for 2FA and Passkeys and such. We spent decades fighting to get people to choose secure passwords and protect them better and it didn't work.

A password manager with auto-type is a hack to get humans to stop using the same one or two passwords everywhere.

@bodqhrohro
Copy link

@binex-dsk

Storage is cheap, functionality is not

That's a consequence of a temporary economical misconception when the work of developers somehow became much more costly than actual limited natural resources, which don't refill themselves, unlike humans do. It causes most of the shit which happened with the software industry in recent years.

@zocker-160

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

The problem is that they depend on your choices as a developer, so you exploit your skill-wise supremacy over bare users to instill your decisions onto them. Justly, power users decide themselves how does the software behave by the means of configuring it in ways which involve no programming skills. That was the status quo before FOSS outshined proprietary freeware and developers ran into thinking pattern that users should patch software themselves if they don't agree with something, and that those are users who should be grateful they're allowed to use software at all, not vice versa.

if the user decides to hide it

It's not how it works. It's opt-in, not opt-out. Computers don't have any software by default, so you shouldn't assume end user operating system includes anything. You could say the same way people with disabilities decide to become such, even if they were born like that. (AppImage is highly agnostic for that matter, BTW, as well as binaries produced by the Golang compiler).

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.

This issue is so widespread that it's futile to ask every software developer around to do something with that. It should be resolved fundamentally. On the level of GUI toolkits, at least. As of now, even stock Flutter widgets are often not fully tabstoppable, and new fancy Rust-based toolkits designed for GPU acceleration lack a11y at all. What are we even talking about then?

Wayland put in a nonsensical arbitrary limitation for no reason

Lack of means is not a "limitation".

@phrxmd

He hasn't been contributed code to Xorg in two years

Yes, Keith has lots of other projects, and comes back to X11-related software sporadically in bursts. That's perfectly normal for true FOSS made on enthusiasm.

@ssokolow

and see things like "Native American" as something pushed on them by middle-class white people without asking what they thought of it

In fact, they're not even "native" for the matter they had invaded this territory in the past, just like white and black people did it later. With the only difference they seem to have done it the first. Nevertheless, it doesn't justify them eradicating kelenkens and many other species. Humans as a species are terrible.

The taskbar can style them and hook up user input however it wants

Yup, somewhere in the discussion on SNI successor I expressed a wish to implement a TUI SNI host.

install a FUSE filesystem

FUSE is easy to implement app-wise. All it needs to "install" is libfuse itself, and the kernel FUSE driver.

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

Well, people manage to create thousands of comments even on YouTube somehow, even though it's totally messy for the task. I wonder how does it work in human psychology. Humans don't normally eat poop just because it's much easier to obtain here and now than going to a shop for an actual food. (Dogs do!) Yet they prefer software they have at hand even if it's totally unsuitable for the task, just because they don't want to know anything else. Furthermore, e-commerce grows around eating poop, people start monetizing eating poop, stream eating poop, and advertise other poop while eating poop. This society is sick and should be fixed somehow.

Y'know what, in 80s, after some colleague of my parent visited a capitalist country, they pranked other colleagues with a plastic poop. Commodities like that were unimaginable in USSR, given how immoral and useless they are. I did already told that story, right?.. And now in PRC TikTok was made, but only to corrupt laowais, while for PRC itself they have more morally regulated Douyin.

@lukefromdc

I can get by with less bandwidth just as most of the world uses less gasoline than Americans do

Pff yay, US is probably the only country in the world where you can see the "poor" coming for free food on cars (!!!)

@fgclue

maybe because x11 is most used on linux?

Java SE is mostly used on Windows, should it be done Windows-centric?

@mikkorantalainen

One must consider Wayland a new display architecture and as a result, it requires GPU drivers that support the new acceleration interfaces

Why should a display server assume some GPU is present at all, and rely on it? Even if it's "new"? That's not an excuse. Yeah, desktop CPUs nowadays normally have an integrated CPU, but GNU/Linux runs on a way broader set of hardware.

requires trashing the TLB caches to avoid Spectre-class security vulnerabilities

Spectre basically revealed that CPU "improvements" during the last ≈30 years were generally a scam, and that we should revert to the CPU power which was relevant this time ago. And use efficient non-bloated approaches relevant for the software of the time. Don't you think the ancient display server perfectly fits there?

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 modular architecture made the modern diverse set of independent window managers and X11 compositors thrive. This is the UNIX way. Making everything tight and monolith counters the UNIX way. It was never about highest performance possible. Just look how bloated Emacs is, it was like that way before neo-luddites started complaining about Java, Web and Electron bloatware, and it still remains such.

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

Just to make it run games well? How about serious people who don't play vidya games at all? Why would they need that? Why would fullscreen games need to be run in the graphical session at all, instead of a separate TTY? Don't think in terms of graphical operating systems where there is no such an option please. It was already mentioned above it causes unwanted side effects even there, like messing with screen resolution.

Somebody else takes care of the window decorations and user interface

Yeah, just push the responsibility away to someone other. How mature.

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

Or it never gets high enough quality, and eventually becomes replaced with something better, like PulseAudio. You won't even notice how the new generation of CADT kids drops the old toy and starts messing with the new one.

@bodqhrohro
Copy link

bodqhrohro commented Nov 10, 2023 •
edited
Loading

@binex-dsk

Because a password manager shouldn't use a GUI

Indeed, I don't trust any kind of software for that at all, and process passwords with a dedicated machine, which I manually re-type passwords from.
@ssokolow

Wayland's security model is specifically designed to prevent auto-type (it's an attack)

Let's stop any surgeries. They require making wounds artificially, which is a security threat and poses a health risk (people often die of operations actually!)

We spent decades fighting to get people to choose secure passwords and protect them better and it didn't work.

Because nobody gives a shit about security, as @Monsterovich mentioned. Take that as given. You cannot enforce people to care about it in a non-authoritarian way. The more you push security onto them, the more creatively they fight back in order to compensate for their ease and laziness.

Copy link

ghost commented Nov 10, 2023

I vote we let the morons who don't care about security suffer, and only support paper passwords.

The software world would be much better if we didn't have to deal with idiots. Then Wayland would be 5 years more mature, password managers wouldn't be a thing, and we didn't have to close 5 issues every hour of someone not realizing you have to click a button to make something work.

@bodqhrohro
Copy link

The software world would be much better if we didn't have to deal with idiots

Indeed, I don't understand why computer usage doesn't need a license like car driving does. Using a computer (connected to the Internet, at least) is already becoming more dangerous than driving. Some moron uploaded a video showing tanks passing by a shopping moll, and a few weeks later it was destroyed with missiles. Also think how many users make their computers passively engaged in botnets.

@ssokolow
Copy link

ssokolow commented Nov 10, 2023 •
edited
Loading

FUSE is easy to implement app-wise. All it needs to "install" is libfuse itself, and the kernel FUSE driver.

And yet libfuse2 != libfuse3, which has been causing Appimage problems.

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

Let's stop any surgeries. They require making wounds artificially, which is a security threat and poses a health risk (people often die of operations actually!)

Talk to the GNOME people, not me. I'm in the "let us do this after prompting the user for permission" camp.

Because nobody gives a shit about security, as @Monsterovich mentioned. Take that as given. You cannot enforce people to care about it in a non-authoritarian way. The more you push security onto them, the more creatively they fight back in order to compensate for their ease and 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.

I vote we let the morons who don't care about security suffer, and only support paper passwords.

Unfortunately, now that they're all connected to the Internet, they're a big source of the botnets attacking us.

@phrxmd
Copy link

phrxmd commented Nov 10, 2023

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.

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

In the meantime, it's not 2019 any more, but 2023, and KeePassXC works on Wayland just fine, with themes, title bars, and copy&paste. I use it all the time:

keepassxc-wayland

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

Except it does work properly. The only thing still missing is autotype, but between Ctrl+B/Ctrl-C + Ctrl-V and the browser extension (that allows KeePassXC to prompt me if I want to share the password or not) it's good enough for me.

@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

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