The thing that sticks out like a sore thumb to me, and which I've been unable to solve, is that apparently it's not possible to configure trackpad scroll speed. At all.

From what I was able to gather, Wayland/libinput say they shouldn't be responsible for handling it and instead window managers should[0][1], meanwhile gnome says wayland/libinput should handle it[2] and ultimately - several years later - it's still not possible to in pretty much any Linux distro that uses Wayland(?)

When I switch to my Linux laptop to test things, my trackpad is bonkers and I have to move my finger in like 1mm increments because otherwise I'd scroll like 10 pages in Firefox. It's infuriatingly frustrating.

[0] https://gitlab.freedesktop.org/libinput/libinput/-/issues/18...

[1] https://gitlab.freedesktop.org/wayland/wayland/-/issues/87

[2] https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...

It's possible in both KDE and Sway.

GNOME is probably worst DE imaginable. After 20 years, they still don't have thumbnails in filepicker and even dropped preview side pane in GTK4. I can't even.

Years ago with Ubuntu and ElementaryOS, I could change it in the system settings GUI.

Today, with Wayland now default, I can't change it at all when running Ubuntu or ElementaryOS.

You can say this is a GNOME problem, or a distro problem, or whatever. But at the end of the day, I installed two of the most popular Linux distro's out there and my scrolling is literally unusable - and I can't fix it without apparently installing an entirely different desktop environment or a patched version of libinput.

You chose GNOME , the answer is you are not the target of the GNOME project, they target people with weak minds that would instantly faint if they see a configuration screen with options. So you are using it wrong, with GNOME you bend your mind and body to work as the GNOME self proclaimed UX experts think things should work.

If you decide you want options try KDE, but you are free to complain about GNOME, it will be a waste of time, reality and rationality do not affect people with giant EGOs in power at GNOME.

GNOME's problem is not the lack of configuration options, but lack of empathy. They stubbornly refuse to address (sometimes, even acknowledge) their own users' problems.

> If you decide you want options try KDE [...]

You don't solve this problem with more options. You solve it by understanding your users' needs.

I want a desktop that just works. KDE's promise is I can make it work if I can keep tweaking it; GNOME's promise is it should work if I'm willing to accept the compromises. Both of these options suck.

I have been using Linux/Unix on desktop since the nineties, and while it has come a long way, it feels like that last 10-20 percent will never happen. It's that part that needs a manager with a large stick/carrot willing to make (informed) decisions and enforce them.

I would agree that this is also a problem, so GNOME has many problems. But IMO is the big EGO s in charge that cause this lack of empathy.

I will disagree that you can get a Desktop that is perfect for everyone, Kubuntu or whatever KDE distro could do a survey and come with the most popular configuration by default but for sure it would be something like

What value you prefer for X ?

- 45% prefer A

- 25% prefer B

- 15% prefer C

- 5% prefer D

- the rest prefer E, F, G or H

so at best you have 45% happy users and 55% of users that need to change an option , but if you are an extremist of no options then you screw the 55%. And this is what GNOME did, they told their users that don\t like the feature removal or changes to leave.

This is not the goal. The goal is to not suck. Design by survey is what got us here.

But "suck" is some subjective thing, you will find a giant number of GNOME fans that will tell you how great GNOME is, how intuitive it is, and how you just need to give up your own preferences and embrace their UX guru ideas and it will not suck.

It seems that many people are in the "I don't want to think for myself camp" . unfortunately people in my family are also in that camp, never question if maybe there is a way to customize things to make the software more comfortable, they bend their body and minds, causing even distress to follow the defaults.

Something that obviously suck for us is normal for a GNOME user, in GNOME land there is only 1 way of working and if you don't like it you are asked to move on. many tried but you can't change those guys minds this is why there are tons of GNOME forks and probably no KDE fork.

Personally - I think KDE 3.5 (yes I'm that old) was near perfect. As of 4.x, they were prioritising adding the ability to freely hand-rotate desktop widgets (who the actual f8ck wants a skewed widget!?) over performance and stability. I could live with a useless feature, but I couldn't continue to run it on a computer with 256MB of memory, which was all I could afford back then. I can't remember what I switched to at the time, but I never came back.

This is not true, we are not all the same. For example my eyes are bad, and one is worse, so I prefer one side of the screen more, I want to put my important stuff like notifications on my good side, I do not need a pretend UX guru to tell me how to have my notifications and hard code them. I also prefer to change the keyboard layout around so I can do most used keyboard shortcuts comfortable with just my left hand. I don't care that the majority things the keyboard layout should look like, I am more comfortable in my way where a GNOME user will not even consider that it could be possible to customize the keyboard layout or change keyboard shortcuts, some big ego dude decided for them.

Let's assume you are right and defaults could be good for 99% but IMO are great only for 40%, I want great, not good or OK, but I don't want to force my preference on others , just wish others won't remove functionality because it is used by less then 50%.

EDIT: I think I might have misunderstood your point and my reply was offtopic, I assume that GNOME big EGO designer checks the touchspeed setting on his laptop, decides what is best for him and hardcodes it in, in their mind GNOME is usable and if you somehow disagree they will tell you to move on, they will never admit anything, they want to push out all the people that disagree with their vision and keep only the ones on the exact sam page with them on all the possible points.

But don’t blame it on wayland what isn’t its fault.

But also I'm not super clear on how libinput fits into the picture, I think there used to be some Synaptics-specific integration in certain places that I never went back to, to confirm the differences (switched to libinput several years before, and I've completely forgotten since what I was trying to solve back then).

Anyway, I ended up writing a mostly-personal-anecdote below, that would likely not help, so you can probably skip it (if you do want to try anything, KUbuntu and https://neon.kde.org are both on top of Ubuntu, and there's other distros, but I've not kept up with any distro I might recommend)

---

I tried Ubuntu (w/ the GNOME default) once (back in KDE 4 times IIRC) and the lack of almost any flexibility felt like I was stuck in a sandbox (a literal one, like from when we were kids, not that it's easy to remember that far back).

The only other time I felt like that was when a friend gave me their old iPhone (6 IIRC?) "to see what it's like" and I had to give up trying it out because both the OS, and the few apps I could find (for its max supported iOS version), had random chunks of features missing (tbh I should've jailbroken it, then it'd just be one more piece of hardware I have no immediate use for - but I digress)

KDE is far from perfect (switched to Wayland recently, and been tracking a few QoL leaps in the next couple releases), but I can at least try to tweak it - same goes for using NixOS or ZFS tbh (not going to even defend those, but I have done both Gentoo-like shenanigans, and randomly RAIDed a dual-SSD laptop, respectively, quite painlessly despite not preparing for it from the start, and the weirdness budget is personally paid for a thousandfold).

Meanwhile I run into e.g. GNOME apps using libadwaita nowadays needing environment variables (that appear deprecated?) to apply the KDE gtk integration theme so they don't stick out like a desaturated winamp skin.

I've never felt like "power user" applied well to myself, like I'm not doing the equivalent of weight-lifting for computers, never want to be doing sysadmin if I can avoid it, I just want to have enough control to make things seamlessly neat for myself.

Opinionated defaults are great in the same way you'd set up a house for a marketing reel, but if I actually buy it, why would I have to deal with a landlord telling me I can't paint the walls or move/replace some furniture to maximize my comfort?

The "personal" in "personal computing" is supposed to be the same as the one in "personal property", and so I'd have similar expectations of "can screw with it without asking for permision" for both (modulo real estate being seen as an investment, and building codes, etc. - should've picked a smaller example than a house, oh well).

To stretch the house analogy further, just like I have leased (some corporation's) private property as office spaces, I would be fine to doing the same (also for business reasons) with e.g. a cloud platform (most likely through GHA, whenever they announce the paid tiers) - tho be fair to everyone, this applies far more to walled gardens than opensource software like GNOME.

Also, to be clear about the "sandbox" thing: sandboxes (and/or ideally more objcap systems) are great, and I think that the XDG Portal work is incredible for what it allows: the apps are getting sandboxed, the user getting more power over them.

Even without Flatpak (which I keep meaning to try out), I was happy to see e.g. the KDE Wayland screenshare dialog outright has an option for "create virtual screen" (which can further be configured in the KDE settings, and e.g. partially overlapped with a physical monitor, etc.). If the app was in charge, they would barely enumerate some of the windows correctly, let alone provide new virtual screens.

All the while there are ZERO GUI apps or other capabilities I'm using that I didn't already use 15 or 20 years ago.

Eying a return to Mac OS which at least doesn't feel like you're treated as guinea pig by dicks with attitudes. Linux notebooks seem barely good enough for uninspired enterprise work on bloated IDEs and Docker/other container crap only there because said dicks couldn't agree on a set of (really old) lib versions and gui toolkits.

  > middle-click gets in the way a lot and can't be switched off,

  > not-so-great app switching

  > FF crashing

  > insists on chromium as default browser

  > apps or other capabilities I'm using that I didn't already use 15 or 20 years ago

When I click a link from Thunderbird (weirdly as it sounds when Thunderbird is a Mozilla app) it opens chromium; dialog to set FF as default doesn't change this.

I need to retest and maybe reconfigure app switching from a (vertical) dock as you say; just doesn't feel fluent as it is.

Occasional FF crashing should probably be addressed at Moz. Maybe it's because FF on gnome gets more usage and testing. Btw, does SuSE (or Manjaro) still have a global-menu patch for FF because kubuntu (understandably) doesn't maintain such patches?

When this occurs, clicking links results in no browser windows opening. At this point I run `killall -9 firefox` and oddly, in that very moment, the link I clicked will open up in Chromium.

No idea why this happens.

That's a hardware issue. If I press Q I am sure it will not be registered as ctrl+alt+Y for example.

  > Half of the time I want to press right-click or even left-click on the
  > touch pad it actually registers as middle-click

I guess I can remap middle-click to left-click using the wayland equivalent of xinput from a shell script or something. The apparent-FF-crash story described by johnmaguire and eddyb sounds very much like another thing I believe is happening on my notebook. Between these fuckups and the general alienation going on in Linux land (wayland, snaps/flatpack, systemd) I've got to say I'm not enthusiastic to go through those chores and teething probs just to get the same-old gui apps like Inkscape and GIMP (plus FF/Thunderbird) running, so right now I'm leaning to go back to Mac OS more than ever (used Mac OS on and off from 2003 to 2016).

(note that the preferred abbreviation is Fx, not FF)

Firefox tends to very much like its shared memory buffers and crashes with SIGBUS if they run out: https://bugzilla.mozilla.org/show_bug.cgi?id=1245239

How much shm is enough depends on both the browser's rendering engine and the display engine, but apparently 1.5GB shm use isn't out of the ordinary. You won't find any references to shared memory (or even general out of memory messages) if Firefox crashes in this way, so it's just another thing to keep an eye on.

Abbreviations is never something up to the original creator to dictate. And "fx" is alredy commonly used for effect.

Next you will tell us that it's actually called Plasma Desktop and not KDE.

It is built on an Ubuntu base and is almost like Kubuntu, except I think it is set up by people in the KDE community.

For me the difference felt enourmous.

I am using KDE (aka Plasma5) in Wayland mode, on NixOS unstable.

I would not recommend NixOS, just like I mentioned, and I didn't really want to get into the weeds of why, but while Nix is something that more people should try out if they're already familiar with unfortunate asymmetries (e.g. "git's data model is really nice" vs "git's CLI has sharp edges and some workflows the data model implies are entirely unserviced") and/or like to play around with experimental unpolished software, I would maybe avoid it until they actually come up with a "more declarative"/"less computational" flavor for 99% of usecases.

I've used openSUSE in the past, and while YaST2 might be less relevant now, it was shocking how much similar things were outright lacking back then (a lot of this was pre-NetworkManager to be quite fair).

A lot of people like Arch, and if Debian/Ubuntu package management doesn't get in the way I suppose KDE Neon might be nice? (I keep forgetting KDE's Discover exists, it might also help with not dealing with package management directly)

---

> FF crashing

Quite ironically, if it is https://bugzilla.mozilla.org/show_bug.cgi?id=1743144 that's technically a gtk limitation (not only does it lead to the FF main thread having to poll gtk often enough to keep the Wayland connection from breaking, but when it does break it calls `_exit` so Firefox can't even do crash reporting, and they refused a patch to address this), and it can also happen for Chrome (which also uses Wayland through gtk AIUI).

If you want to check if it is the case, you can look in the logs (e.g. through `journalctl -o with-unit -r`) for "error in client communication".

> middle-click gets in the way a lot and can't be switched off

Are you talking about the feature controlled by System Settings -> Input Devices -> Mouse -> "Press left and right buttons for middle-click"? (that is, if you intentionally press both buttons, does it trigger middle-click?)

AFAIK that's off by default, but I am on a different distro and running KDE/Plasma 5.25.4 and maybe it changed at some point, or maybe it's specific to touchpads? (which I sadly can't test because I only have an older Nvidia laptop, that can't use the Wayland-compatible drivers, or rather I would have to switch to nouveau first and deal with that etc.)

> insists on chromium as default browser

I've had issues with this in the past, some apps provide their own configuration instead of going through XDG mechanisms, or at least have suboptimal defaults.

I would check the settings of the apps which cause chromium to start, and maybe play around with Flatpak/forcing the use of XDG Portal, but that might be too much to ask.

which gets weird, when they push on you things like:

- opening WiFi-portals in whatever crap browser your distro ships with GTK. Executing random JS code in the process.

- make XWayland startup absolutely inconfigurable and hardcoded in C (or was it Vala) and for whatever reason MAKE IT LISTEN ON ABSTRACT SOCKETS (which no Xconfig anywhere else does)! (problem here: if any user-namespace container shares your network namespace and you do a naive xhost +SI:localuser:user - it works for any container, because abstract sockets are not stowed away in the filesystem).

At least the first issue I'd like to report, but don't know how and where...

Which in turn is the biggest problem with wayland. We are fragmenting the ecosystem with every window manager dealing with shared problems in their own custom way, because wayland only takes responsibility for a tiny fraction of the common things that every window manager does.

After enough time some best practices do solidify into standards, but it wasn’t overnight in X either, and first and foremost it wasn’t made with that in mind. Wayland has protocols which are queryable and provide a very good way of implementing more and more standard ones from the experimental “fragmented” ones, and I don’t see much problem with this model in practice either.

Part of what drives me nuts about Wayland is they could have learned these lessons from X's history and actually had it in mind. Instead, they threw it all out without learning a thing.

They absolutely chose to do the protocol with enhanceable protocols, something greatly missing from Wayland, so I don’t think your criticism is fair here.

The fact that developing a new compositor with wayland basically required wlroots to be even feasable for a one-man project is concerning enough. The amount of stuff you have to handle is insane compared to writing your own x-wm.

And developing a new compositor also does not require wlroots. Originally there was libweston, wlroots is just another option.

We could call it X-Wayland

Sway made it initially but others are using it too. https://gitlab.freedesktop.org/wlroots/wlroots

You may be interested to learn about wl-roots though. It's a project that I think originated from sway, and it aims to provide most of the low-level plumbing for writing your own Wayland window manager/desktop environment.

If you want to do something even slightly off the happy path, GNOME is the worst Wayland experience. Because of ideology (and in the name of security), they refuse to implement features and extensions that users and app devs need.

Example: No support for server side decorations. Instead, their solution is to force app devs to use client side decorations.(https://gitlab.gnome.org/GNOME/mutter/-/issues/1836)

This is just an issue that I have run into; there are more. Even ignoring wlroots and KWin, users coming from Windows and macOS except features like this.

Practically, for small apps that don't really have their own style (or games that are just one big opengl window) it's much better to rely on the window manager to provide a titlebar that somewhat fit in with the rest of the system. This is what users expect when coming from Windows or macOS.

Instead, apps like kitty just provide a godawful stopgap titlebar for GNOME users, because implementing good CSD is outside the scope of the project.

I agree. And yet I also still use GNOME. I just really like the GTK aesthetic. And you'll have to pry dash-to-dock from my cold, dead hands.

https://github.com/home-sweet-gnome/dash-to-panel

It forces every single DE that will use it to reinvent same thing. There is no good reason to do that, just a lot of duplicated effort. You will not want to have different mouse behaviour when you use different WM. Having it pluggable is fine, even desired, but pushing it on every DE is just waste of effort and just bumps the bar required for any DE to move to wayland.

> GNOME is probably worst DE imaginable. After 20 years, they still don't have thumbnails in filepicker and even dropped preview side pane in GTK4. I can't even.

For me it peaked somewhere in 1.x, 2.x was prettier version of it, after that they completely lost me. And their constant dumb arrogance with assuming what their users want is just cherry on cake of shit. And the "fuck the compatibility, just change APIs will nilly" attitude they got after 2.x

Should Web Standards mandate the use of a given JS implementation because it hinders the creation of new ones?

Also, the million+1 “de” under X are more like skins, there is absolutely no reason for them to exist in that form, they could just build on top of another wayland compositor.

This latter is pretty much a library to build your own de with minimal code up on top.

All these conversations end up kinda pointless because of a sort of "it works on my machine[desktop environment]".

Really disappointing to see this very lazy and trite criticism upvoted. If you look in KDE Plasma or Sway, you can also find plenty of missing features and bugs. You can find those anywhere.

It’s a small(-ish) issue but people often share it as a good example of their frustration with the way Gnome is managed - the bug report has been open for years, there has been several patches proposed, but they’ve always been either rejected or ignored with no discussion. My personal (and similar) pet peeve is that typing in the window will trigger a search instead of selecting the file matching the key like in every other OS.

[0] https://gitlab.com/warningnonpotablewater/libinput-config

I can't thank you enough for pointing this out. Now (finally) my scrolling is acceptable on Fedora 36.

See https://www.reddit.com/r/Fedora/comments/qn0o9w/adjust_touch... for some further fedora specific instructions, but also read the instructions of the repository.

Do you also know a possibility to stop inertial/kinetic scrolling on two-finger-tap / rightclick? (left click works, but since I scroll with two fingers, it would feel much more natural on rightclick)

[0] https://wayland.freedesktop.org/libinput/doc/latest/faqs.htm...

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1568722

But for now the ONLY thing that bugged me on fedora is (partially) fixed, I'm so happy.

It's the same argument that the libinput author makes about why libinput doesn't implement kinetic scrolling, and that it's the job of the toolkit. Only the toolkit knows what's appropriate there.

For reference, the kinetic scrolling rationale goes like this: say you start a scroll movement in one app, and then it continues scrolling after you lift your finger off the touchpad. Then you alt-tab to another app. If libinput implements kinetic scrolling, then scrolling will start happening in the newly-focused app, until the kinetic scroll decays down to zero. That's definitely not what you want, and libinput can't fix that problem, because it doesn't know anything about windows or focus.

Granted, scroll speed isn't exactly the same thing, but I could imagine that a toolkit/application could want different scrolling speed in different contexts, which libinput would have no understanding of.

But that's exactly the problem with the Wayland architecture, isn't it? Input handling, window management and composition are so closely entangled that it shouldn't be spread over several unrelated libraries.

pretty sad to see that absolutely nothing has changed.

It’s why I’m now a mac user.

It’s certainly not entirely because of the attractiveness of the problem itself.

Also, in my experience XWayland programs seem to exhibit overly sensitive scrolling, while native Wayland is fine (noticed this mainly on Firefox). Perhaps X scrolls by line, while Wayland natively supports pixel-based scrolling?

The scroll behavior is highly configurable on Firefox' side: check out some of these about:config flags (if this is still of interest),

    mousewheel.acceleration.factor
    mousewheel.default.delta_multiplier_x
    mousewheel.default.delta_multiplier_y
    mousewheel.default.delta_multiplier_z
    mousewheel.min_line_scroll_amount

    cat > /etc/X11/xorg.conf.d/40-libinput.conf << EOF

    Section "InputClass"
        Identifier "Touchpad Settings"
        MatchDriver "libinput"
        MatchIsTouchpad "on"
        Option "NaturalScrolling" "true"
        Option "Tapping" "true"
        Option "TappingDrag" "true"
        Option "TappingDragLock" "true"
    EndSection

    EOF

    man libinput

I think the problem is that most UI tools like gnome settings do not expose the full range of possibilities because it's too much effort.

[EDIT]

Ouch, so i'm wrong, there is no equivalend in wayland. I know wayland has no concept of a display server but this really sucks for configurability [0]:

> For Wayland, there is no libinput configuration file. The configurable options depend on the progress of your desktop environment's support for them; see #Graphical tools.

This means there is no built in way to configure libinput without your DE/WM supporting it or other tools like libinput-config as the sibling comment points out.

[0] https://wiki.archlinux.org/title/Libinput#Configuration

Even Chrome OS scrolls a single line at a time. It feels so wrong…

[0]: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4508

At that point, I just use macOS to just get work done without fiddling or googling cryptic errors for just using the trackpad or hunting down and googling why either GNOME, Wayland, LightDM, Dbus and LibInput and the video driver(s) decided to have a fight and crash the desktop.

The most I did is to tweak which input goes where on arand

It can only go down from here. I'm not touching Wayland with 100ft pole

X client and server are usually the same machine, but they don't have to be. While on the road, you can use your notebook to open a Gimp session on your home machine and edit an image stored there. That is, the Gimp runs on your home machine while your notebook has the GUI.

This is a lot to give up for cool compositing effects...

I'm not an expert, but my understanding is that the whole X11 is network transparent thing worked great when apps used the X11 drawing primitives. These days a significant number of X11 apps just render _everything_ (often including window decorations) "server-side" as bitmaps and then send them over the wire to the client to composite them. Essentially the X11 wire protocol has become a bitmap pipe.

Wayland does the "bitmap pipe" thing more efficiently than X11.

By the way, does anyone know of a VNC-like solution that can use MPEG compression?

Also, VNC could be better if it could increase the quality of parts of the screen once they stop updating. E.g. in TigerVNC setting a low bitrate doesn't improve the quality of text once the text stops changing.

For open-source solution for quickly remoting into an existing display, I use freerdp-shadow-cli which is way more stable than x11vnc and uses the RDP protocol instead.

It works well, though, and I'm not really interested in hearing that my own experience with it working well is a lie or some trick. Wayland gives up some things, and pretending that those things have no value isn't going to convince those of us who know they do.

Also, those of us who use non-mainstream window managers (such as Window Maker) are not interested in hearing that we should switch to some UI which doesn't support our workflow just because it's more fashionable these days.

There's a debate to be had here, and it needs to be had on the basis of facts, not lies.

The facts stated are simply that today it is more efficient to encode video for remote graphical sessions because the X11 applications already changed a long long time ago to adapt to the modern world of GPUs and accelerated compositing. BW, latency, efficiency, everything became better because a super computer with thousands of cores can do that and lighten the load on the CPUs.

It doesn't say it doesn't work... It doesn't prevent you neither from running X11 or even booting up a PDP-11 if this is your favorite workflow!

A much more reasonable claim would be that the network transparency afforded by the X protocol adds significant complexity which is no longer utilized by the majority of mainstream apps today. As such there's a reasonable case for dropping all that complexity from the core system and leaving it to peripheral libraries to handle on a case by case basis for the apps that want to make use of it.

And the idea of lossy compression while using an image editing program being a desirable thing (as suggested elsewhere in this comment chain) is laughable. It's already bad enough reading text that's gone through lossy compression. I would never want compression artifacts while manipulating an image.

My impression of Wayland so far is that I like the technicals but absolutely detest the people I encounter pushing it as a solution (it's quite similar to Rust in that regard I suppose). They would probably meet less resistance if they took more care not to misrepresent the overall state of things. I'll leave the link to KDE Wayland "showstoppers" for reference. Certainly that list is far shorter today than it used to be and many (not all) of the items are now solely on KDE's end. Nonetheless, fanboys have been claiming that Wayland is "production ready" the entire time. https://community.kde.org/Plasma/Wayland_Showstoppers

I'll switch to Wayland once it "just works" out of the box in terms of app integration on stable distributions including things like screen capture, fractional scaling factors, color management, all the stuff that works on X.

I have also not heard of any one who loudly proclaims xorg is much beter and should instead be maintained to step up to actually do that.

The people who actually develop x or wayland are a tiny number of people. The people expressing opinions on the internet on tech is 1000x larger. The implications that the proponents are correct in their analysis because they develop it is fatally flawed if for no other reason than the subject is obviously not solely the tiny number of actual devs. Furthermore the arguments even of devs needs to stand on their own feet.

Look at the prior comments where someone complains that random crashes result in the entire session going down.

Who cares what anyone says about the theoretical design decisions regarding manifestly unsuitable tools.

I mean, I think it would be cool if my PC never crashed. Isn't it easy and fun to say things like that?

While the reality is, that toolkits (and applications) used to use those APIs and were revamped to use the DRI APIs and general bitmap based windowing. The old APIs don't support double buffering, access to GPUs with modern APIs (both opengl[indirect sucks] and Vulkan). They don't provide modern font rendering, or any kind of graphical effect (distortions) that UI people might want to play with.

They would be significantly worse for anything displaying animations and one of the most common client libs (libx11) is serial and thus horribly latency sensitive.

The advantage of VNC isn't lossy compression. Which isn't forced by it either. But it handles networking better with bitmaps. And has improvements like acting as a screen/tmux style connectable session for graphical applications. Both VNC/RDB can also support showing the server's desktop if it has one, not just running other applications than currently open elsewhere.

The only advantage of old style X11 was that it's ubiquitous. But since it hasn't been used in ages since it doesn't work well with modern computers/UI frameworks that advantage is gone. And there's 0 reason to try and reimplement that in a new windowing protocol, when there's objectively better choices out there already. Local optimized windowing is a different beast than network capable.

Compare to a protocol like RDP which is extremely optimized for efficient and secure network operation, but is also way more complicated as a result, and it would be foolish to use it on a local display server.

Your own experiences with it aren't a lie, but they're probably based around ignoring the last 20-30 years of advancements, and ignoring many actual statements from the X11 developers saying that it's bad for remoting.

>Wayland gives up some things

Well in the case of X11 fowarding, no it doesn't. That still works.

>Also, those of us who use non-mainstream window managers (such as Window Maker) are not interested in hearing that we should switch to some UI which doesn't support our workflow just because it's more fashionable these days.

By insisting on using these obscure, non-mainstream and under-maintained environments you are setting yourself up for an extraordinary amount of pain for very little benefit. The more time you spend avoiding the issue the harder it gets to figure out how to adapt your workflow to something else. I'm sure you understand that more deeply than anyone else here. So why keep up with the charade? It is not doing you any favors. At some point we have to let bad habits die.

It turns out that CRD is well known for breaking other seemingly random things, such as accessing your printer:

https://askubuntu.com/questions/1196248/automount-when-click...

try this: https://xpra.org/

You want xpra.

It did. It was awesome to be able to run one of the expensive academic apps from any X terminal on campus. Network security was largely non-existent then, and you could run X apps not just across campus but across the Internet. I remember a really early web page that had a text field (for your host name) and a button that would start a particular app on their side and would display on your local X server. It wasn't very fast.

Anyway, all that died as Athena and Motif began to look dated as newer applications in the mid-90s started using more and more bitmaps.

However, there were many who genuinely believed that networks would get arbitrarily faster and compute would not. Of course, the opposite happened, but in that alternative universe X’s design would have made sense.

This simply isn't true. Some operations require roundtrips, drag and drop comes to mind, but very simple things absolutely don't. Events come one way, draw commands go the other.

Essentially xlib is latency limited because its a synchronous protocol. Xcb can help if you redesign your applications for it, but we are talking about old applications (motif...)

Moreover, notice the example they gave there is atom interning, which is a roundtrip on the wire (though you can batch them even in xlib...), and they say "most real applications will see less benefit than this" since that's the worst case - most applications do atom work at startup, not in the main use cycle, which is famously both async and buffered (it used to be a FAQ on xlib tutorials reminding people to run the event loop, and error handling is complicated a bit by it).

https://web.archive.org/web/20160305000336/http://www.thefre...

I remember higher, but it's been over 20 years now (we got broadband pretty early here), so who knows.

Thin client for home use seems like a winning proposition. Rather than giving the kids a Raspberry Pi 400 or garage-sale P4 when they want their own computer, you could hook up another X terminal to a large shared Ryzen box. The hardware gets more efficiently used, files can easily be shared and centrally backed up, and nobody ends up being the guy with the cast-off or otherwise inferior PC.

Inferring from the quotation, I take it you mean application server-side (instead of display server-side)? Just confirming.

The "server" in X11 is the display that's sitting in front of you, not the application running on a remote workstation.

Er, IRIX was pushing 12 bits and alpha channel around over X on twisted pairs c.a. 1993.

So does X.

> and (lossy) compression.

This is legitimate though, the X protocol has no support for any kind of bitmap compression and it can sometimes be pretty painful. Though internets getting faster and faster too so it isn't necessarily a big deal especially since it does have bitmap caching and some display-side rendering capabilities, but it sure would be nice if you could send other formats on the wire.

You could either use WinApps or create your own script and add it to a desktop entry. Users can then open RDP Gimp like any other application without even noticing.

I think who should be client and who should be server is entirely context/application specific.

Sometimes I want to be able to connect to a server from any random client and continue the session.

But that's never where I want the split to be when working across the network.

Remote storage? Sure, sign me up. (The POSIX APIs are horribly unsuitable for network filesystems, but I'm speaking about the concept more than the current implementations.)

Remote heavy computations, like AI workloads and compilation? Definitely.

Remote GUI code? No ugh. Compare the experience of VS Code Remote vs just running VS Code remotely with ssh X11 forwarding, using a high latency connection.

You are fighting the speed of light. It won't go well.

You could also use something like Zerotier-one to recover from network being shortly disrupted. This service connects your machines into a virtual network with static IPs, so the IP addresses through which your machines talk will stay the same and TCP connections will recover and ssh will keep working if a device briefly goes offline.

I don't think you're giving the Dota client enough credit there. Game clients don't wait for network to pretend to respond to user input, because it absolutely is noticeable at 100ms latency. Instead, they predict as much as they can client side and display it as fast as possible. For this reason, the client is not at all thin. It knows how to run the whole program by itself. Not so with remote X11. With remote X programs, the client doesn't know what happens on click for anything, so the user really does get hit with a 100ms delay for every interaction with the program.

Although if I connect to something that's 20ms away (within the same country), the experience is really good.

Dota is fine because it has network prediction and a finite and well defined set of inputs.

And that's also ignoring video compression artefacts which are that you introduce if you send a modern GFX pipeline across the network. Computers screens can no longer be described with just filled rectangles and text.

That is how we have been giving development machines since 2011, Windows workstations on whatever cloud vendor the project is taking place.

The best is always going to be to use a local copy of the logic and data needed most frequently/immediately. E.g. in the VS Code example, they keep the buffer you're editing locally, the logic for cursor movements, the errors you're flipping through, and maybe even some precached autocompletion/highlight stuff. You don't have to wait for a round trip to see your keystrokes show up. That's the advantage of splitting the system in the right place.

NoMachine developed a couple of libraries called NX back in the day, which transferred images and image deltas over with high compression. We used this instead via in the same project (with X2Go), and I reimplemented the same stack to my university where 20 something users connected remotely to a single "terminal" server to do remote research, and it worked like a charm.

While I like Remote X, it's still very inefficient even today. So, unless it's made extremely efficient over normal internet, over residential connections, it won't be missed.

Moreover, the rarity of projects using Remote X, or abstracting it with libraries like NoMachine kinda validates the idea is the feature is considered a novelty and not used much.

While I like the feature, I have feeling that it won't be missed or sought after much.

On the other hand what killed X is its code state, rather than the complex architecture. It's haphazard development over the years which made the code unmaintainable.

Addendum: Remote X made sense back in the day. Carrying minimal data, mostly terminal windows between terminals and central mainframe/time sharing system, over relatively short distances. I guess it's never designed and considered for long distances like today's internet, hence it's left to the wayside.

People on both sides sound somewhat fanatic, and I've never understood that. I just want to use what serves me best with the fewest interruptions.

I ran wayland for 3 years in various forms, and could not reconcile the bumps and stumbles in the process. Maybe next year I'll give it a shot again. There has to be something that it's doing for everyone for me to be hearing this much about it still.

My previous attempts to make it work have ruined the standard configuration so I'll probably need to do some serious purging/reinstalling to get it to work, but for new installs I'm sure remoting into GNOME must be a LOT easier.

> more comfortable to use than X forwarding. A PITA to set up though.

X port forwarding is painless, not sure what aspect you're referring to?

It’s not used or won’t be missed _by you_. It’s extensively used today by science and HPC facilities and clusters, where it’s at best complementary to things like NX (with the problems of basically having a second desktop instead of integrating into the existing system), but often the only option for remote GUI to heavier duty systems available, not to mention the remote OpenGL capabilities which although out-of-date and clunky, allows more efficient local rendering than just streaming bitmap deltas.

Instead, researchers either post process their data in the user interface and download it to visualize, or get the raw results and post process and visualize in their systems.

Once in a blue moon, a user generates some output window which requires very few interactions to look at their preliminary data, that's all.

The last time I needed and X11 remote session in a cluster, it involved Matlab and some kind of toolkit.

The performance of using a GUI remotely is nothing compared to just copying a terminal figure through an SSH tunnel and viewing the figure locally. I’d say that the low performance of remote X11 was the biggest factor in this shift.

100M became the norm in the mid 90s, 1G in the mid 00s, but there was no 10G norm in 2010s or 100G norm in 2020s, we're still at almost the same spot of the curve 20 years later. Save for some tragicomic attempts at 2.5G etc end user networks.

Part of the reason of course is wireless, apps adapted to flakiness and bandwidth unpredictably alternating between slow and very slow, and also last mile consumer uplinks adapted to this.

These slowdown is offset by improvements in video and audio codecs, transparent compression and better static compression formats.

So, having 100mbps WAN connection at home is arguably provides more utility than having 100mbps 5 years ago.

Unless you do professional photo/video work, a 10G connection at home makes no sense. A good 802.11AC network plus some gigabit nodes is more than enough for a nice smooth experience at home, for most people.

P.S.: As a sysadmin, I know delights of having a lightning fast network at any place you live/work, but no, I'd rather spend time with my family rather than maintaining that.

And yes, our apps adapted to working with less bandwidth. We don't know what kind of apps and computing we would have in the alternative universe where the norm would have been 10G connections 10 years ago.

For example lots of P2P stuff has been badly hampered by performance problems resulting in the centralization of the net in hands of big players.

There are lots of hard problems resulting from bad connectivity that result in big $$ tech funneling traditional net uses onto their services, by investing engineering efforts (and complexity) into heroic engineering feats to work around the bad connectivity. The complexity means high barrier to entry to compete with them. Codecs yes but also clever distributed caching, cloud storage, UIs that predict what the user does next, video calls have to go through corporate encoding/multiplexing proxies instead of p2p, file sharing has to be of the hard "sync most likely needed needed files" variety with proprietary server side smarts, instead of just "mount remote share", etc.

Would have been very late 90s I think.

I remember it was even faster than the Windows ICA apps at the time which I think were hosted on a NT4 Citrix server.

Curious to know if Citrix even sell the Xwindows version any more.

(Note that tightvncserver seems to silently ignore the -localhost option now, which means it's completely insecure to run on an internet connected machine. Tigervnc still has the option)

Then it can runs rather fast on X over SSH in LAN and somewhat okayish through the internet.

Ten years ago I was using it all the time and it was very fast over the internet and perhaps even through Tor. I do not know how they could mess it up so badly

Even X2go provides an experience that's strictly worse than using windows via rdp.

It just seems completely pointless to even bother with something x11's network transparency if you're designing an x11 replacement nowadays.

It would be much better to focus on a new vnc replacement for Linux that can use low latency video codecs when needed for games, etc.

Nothing could be further from the truth. If you use Xrender properly you can make very sophisticated drawing operations that are extremely efficient over the wire and that are GPU accelerated even when the process does not run on the local machine.

It is Gtk and Qt that for wahtever reason decided to ditch their Xrender backends.

> multiple round-trips

This is also a problem introduced by badly designed tool-kits like Gtk and Qt. It is trivial to design tool-kits in X11 that require no round-trips.

> It just seems completely pointless to even bother with something x11's network transparency

This is mostly true because desktop software on Linux is mostly written by highly incompetent developers that produced abominations like Gtk3+.

It was often slower and more likely to run in to driver issues than just doing software rendering and sending pixmaps. They're now moving to GL and Vulkan because they can be faster and while they have the same risk of driver issues at least that's the same stack used for video games and CAD and such so more people care about it working well.

Any data on this? I can remember that your typical Cairo backend ran much faster on a PC from 2004 than todays GNOME/Gtk runs on current machines. If performance is your only argument you clearly lose with the modern GNOME/KDE + wayland stack. The only way you could make GLAMOR accelerated Xrender faster is by putting the spline tesselation step into a shader. (This was not possible when Xrender was introduced but can be done today without breaking any APIs)

The protocol was very poorly designed everything needed essentially several trips back and forth between the client and server. That applies also if you're using Athena or motif widgets, it just becomes much worse with QT or gtk because they also transmit bitmaps, because otherwise they can't guarantee the look.

So it's latency not bandwidth which kills the performance. If you need 3 or 4 roundtrips just moving a window around, that's fine on your home network where you have a ping of 10ms, over the Internet with 100ms latency 3 roundtrips become 300ms so just a cursor move becomes painful.

I agree there are problems with various stacks and widgets, but it isn't going to change anytime soon. At the end of the day, it requires someone who can create something from scratch, and those people are few and far between due to the amount of vision and work required. Especially if it's a non-paying task.

It is also not trivial to reduce the amount of roundtrips in an X11 program. If the program uses Xlib then it probably needs to have significant portions of it rewritten to use xcb, which is a lot more complicated than it seems because Xlib handles a lot of caching and logic that xcb simply does not. In some situations X11 roundtrips are simply unavoidable. Complaining about GTK or Qt will not change this. Even if it were possible to fix those, there are less and less contributors to those projects who are willing to spend time to maintain X11 support.

I doubt it will ever be fixed, because it offers no benefits when the application itself uses actual hardware rendering with GL or Vulkan. XCB can't speed that up at all.

The vast, vast, vast majority of the apps i use daily don't do any GPU rendering, just plain classic widget-based productivity apps

It sounds like the vast majority of apps you use are very old. Even plain productivity apps benefit from GPU rendering. If they don't it's because those apps are far behind, compare to things like Electron apps where everything has been GPU accelerated for quite some time because of Skia.

Also apps that do gpu rendering make my laptop really heat up and loose battery quickly compared to when it's not in use - I don't use a compositor partly for this (+ the occasional frame lag)

And that sounds like something is seriously wrong with your machine or your drivers. GPU rendering has massively improved performance and battery life on every machine I've ever tried. And especially on embedded devices with a low power mobile GPU, see for example here: https://social.librem.one/@dos/104984930233748319

Compositing should do so as well by avoiding unnecessary redraws. That sequencer would probably benefit greatly on a Raspberry by using GPU rendering, the screenshot even shows it rendering video and shaders...

I use a tiling WM so I doubt it would help much. If anything, if I run a whole system profile with perf, rendering does not even show up when compared to just running a git status here.

> That sequencer would probably benefit greatly on a Raspberry by using GPU rendering, the screenshot even shows it rendering video and shaders...

Sure, the video & shader parts use GPU of course. But for the main GUI, it can be rendered with OpenGL or with Qt's software renderer ; from my tests (and lord knows I've spent entire weeks profiling and doing everything I could to improve rendering performance) the OpenGL backend for the main GUI only becomes more worth it when using a 4k resolution - and GL is absolutely full of bugs on e.g. windows ; yes there are still people with GMA500 GPUs. Qt's software renderer has no issue rendering at a 1080 screen size on a Pi 3.

It was really nice and convenient at the time but it is going the way of the dodo the same way cars with manual gearbox are because almost nobody cares and there are other ways to connect remotely.

this kind of statement astounds me. The internet is essentially based on network transparency, it's the gold standard for local area networking too. If it hadn't been invented yet and somebody just proposed a viable scheme to create network transparency, your eyes should light up with the possibilities... imagine a Beowulf cluster of these.

network transparency is what networks should provide, not for graphics, but across the board. It's the Apples and Microsofts of the world who don't give it to you both because they never understood it, and because it disrupts their walled gardens. You are thinking of a few network features that you want, and instead of conceiving it as properly architected orthogonal software features, you just want special purpose code for your two features (video and video games) in the current context.

The equivalent to X11 forwarding is waypipe[1], which is far superior to X11 forwarding. Rendering happens entirely on the host and clients can therefore use accelerated resources as they wish, and the (accelerated) h264 encoded buffer feeds means much lower network utilization.

1: https://gitlab.freedesktop.org/mstoeckl/waypipe

The higher the window size the higher the requirements for the encoder (though Waypipe does say "This way, Waypipe can send only the regions of the buffer that have changed relative to the remote copy.", or is it talking about the video encoder?), whereas with primitive-based systems the requirements are only correlated to the amount of changes done on the display—while still allowing to use image or video encoder for tasks better suitable for it.

I just fondly remember the times when (possibly two decades ago) I run

  xlockmore -mode ifs 

I understand though that coming up with a great protocol for user-interface primitives would be a research project in its own right, however. Perhaps something based on JavaScript, WASM, or EBPF fragments sent to the client would be a realistic options. Time has certainly gone past the primitives provided by X11.

But I also think that just "forget about it, we'll video stream it" is just giving up on the problem altogether.

You can have your cake and eat it too: You can disable the compression if it's a problem. It's highly configurable if you want to play with it.

The compression means trading a little bit of hardware resources at either end for a better UX (lower latency, higher throughput).

> The higher the window size the higher the requirements for the encoder (though Waypipe does say "This way, Waypipe can send only the regions of the buffer that have changed relative to the remote copy.", or is it talking about the video encoder?).

The core wayland protocol mandates communicating which parts of a "surface" (read: window) has changed when a new buffer is submitted in a "surface commit". Neither a compositor nor waypipe will do anything if nothing has changed.

> I also think that just "forget about it, we'll video stream it" is just giving up on the problem altogether.

Each surface has its own stream, and is updated independently. E.g., a video player on a webpage will generally be a subsurface, a context menu or plugin is a popup surface. They're all processed independently, with each their own damage tracking (and if applicable, video compression). If content is stretched or scaled up, only the original source buffer will be transmitted, allowing the display server to take care of this.

This is not giving up, this is the maximum effort, optimal implementation.

> I just fondly remember the times when (possibly two decades ago) I run ... over a 100Mbit network

For reference, a single 4k 60Hz display takes ~15Gb/s to keep fed with bitmaps. Even a quarter of the screen takes 3.7Gb/s. Not even cinematic refresh rates would be able to fit within a 1Gb/s line.

Well you've of course lost the game at that point if your surface is very tiny, given you have no primitives to express "write text hello at x, y" e.g. for a terminal; without compression the bitmap presentation of a terminal—or a text document—is very large. Scrolling will damage the whole screen.

> Each surface has its own stream, and is updated independently. E.g., a video player on a webpage will generally be a subsurface, a context menu or plugin is a popup surface. They're all processed independently, with each their own damage tracking (and if applicable, video compression). If content is stretched or scaled up, only the original source buffer will be transmitted, allowing the display server to take care of this.

That's pretty nice and better than I assumed! Some hardware has limited number of hardware video encoders, though, for example in NVIDIA 1080GTX it's four for the _complete system_. I think for this reason waypipe reuses the contexts for different surfaces, resulting in lost video quality? Without reuse I expect one to run out of contexts quite fast—and then you spill to CPU.

Video sending can be a nice way to provide remote frames because it naturally batches all drawing operations into one compressed frame and really works if your task is to send 4k 60Hz video. But can it really beat display server -side composition or even things such as text rendering? As a tool in the toolkit it's a very nice thing to have, but it shouldn't be the complete toolkit. For X11 Someone(TM) could implement XPutVideo.

I think the bad performance of many X11 apps is not inherent to the protocol but inherent to the programs written in synchronous style (libX11 included; libxcb fixes this), assuming immediate access to the display server, instead of putting in requests while waiting for the answer for previous ones. Worst offender: Virtualbox. Access to a local surface and sending that surface as a whole can be a good solution to such code. And this kind of code is possibly so common because doing everything asynchronously can be tedious, and even more tedious in some enviroments such as C..

Sure, if an application is just rendering nothing but text through X (and not using e.g. pango rendering to a cairo context), and you do not prefer using the resources on the machine running the application rather than the one displaying it, and you don't care about performance when using the application locally, then X11's might be more efficient. But for a purely text application, SSH puts X11 and Wayland to shame.

Re: encoder limits, Intel Quick Sync (built into Intel CPUs since 2011) documentation suggests the only limitation there with respect to parallel encoding is whether or not you can keep up with frame-rate requirements - an old example being 10 streams at full HD 30fps. I believe waypipe only focuses on video-memory buffers right now for video encoding right now as a simple heuristic, as CPU memory (shm buffers) are only used for "low performance" content on Wayland.

> I think the bad performance of many X11 apps is not inherent to the protocol but inherent to the programs written in synchronous style ... And this kind of code is possibly so common because doing everything asynchronously can be tedious, and even more tedious in some enviroments such as C.

I believe even libxcb has forced synchronous parts, which are annoying Wayland compositor developers a lot as Xwayland-supporting compositors need a bit of X11 WM code.

The Wayland protocol is asynchronous by nature, and the primary client and server library exposes this with no synchronous pretenses in idiomatic C. Every function you call only queues a request that will be sent when your event loop dispatches next time, and when you receive events your event loop will fire callbacks in bulk.

Nothing is synchronous, and updating your window requires no wait. In the simple case, the only message you'll get back at some point is one informing you that the previous buffer can now be reused (buffer release).

I'm double checking it right now using a remove machine a few blocks away from my home. Running `ssh -X remote firefox` lags a lot worse than `waypipe ssh remote firefox`. The latter feels almost native, very responsive.

So no, I don't think we are giving up a lot. X11 was designed to work over network, but it never really did.

Then it can runs rather fast on X over SSH in LAN and somewhat okayish through the internet.

Ten years ago I was using it all the time and it was very fast over the internet and perhaps even through Tor. I do not know how they could mess it up so badly

  ssh -X remote firefox https://www.youtube.com/watch?v=XqZsoesa55w

And I bet part of the problem is due to Youtube (and browser generally) involving some non-trivial drawing technologies, rendering a video is not like showing a GTK interface.

Latency (how long it takes for messages to travel back and forth), which is where X11 over the network has major issue, doesn't matter in the specific case of watching a video.

Essentially, once you press 'play', there's just a torrent of data flowing down from the server to the client with very little need for two-way banter between the machines.

It's not even fair to compare it to waypipe's h264 compressed buffer feeds.

It is a strictly worse solution to remote desktoping than what followed it — we are no longer drawing things with CPU and the things we draw are not 3 rectangles. A bitmap crossing the wire for an icon/image/whatever is insanely inefficient through the X protocol, you want to compress it with a modern compression algorithm for much better outcome.

Have you ever tried this? I've never had X11 network transparency be a good experience.

It would be cool but to be good all apps would have to be designed with it in mind. And they are not.

The software moves on from X11 as a protocol for remote computing.

Even well before Wayland, all the things you'd use X over the network for were moved to web browsers.

I did, nearly 20 years ago. The computers were over 2500 km apart, though it was over a good university to university connection. The Gimp was certainly usable, though I will not go as far as saying it was good since 20 year old memories can be hazy and the standards of the day are different from the standards of today.

I also experimented with X over a 14.4 kbps modem a few years earlier. It was mostly while writing papers (plotting graphs and viewing dvi files, not the actual writing). It was slow, but it got the job done and was better than juggling documents between software on two computers.

The one really nice thing about X was the ability to use individual applications across a network connection, rather than dealing with an entire remote desktop. All of this remote desktop stuff strikes me as being better suited for accessing a remote system, rather than for running remote software.

That sounds like a UX problem that’s quite trivial to fix, not a technical one and absolutely not inherent with Wayland.

Yes, it's laggy, but it's nice to have the option, and it's really nice that it's already integrated with ssh and doesn't need extra setup (past passing `-Y` to ssh). If this was the only thing I'd lose by switching window managers it wouldn't be a dealbreaker.

We could expect everyone to start investing in datacenter GPUs, but architecturally “one GPU per display, plugged directly into the display” always made a lot more sense to me.

Icons, textures, all these things will be passed as bitmaps with X remoting, in a strictly worse way than a modern compression could do.

I, too, am not comfortable with throwing away such a potentially useful feature (though I believe there's a wayland "protocol" or something that allows for network transparency now), but I personally don't have a need for it.

[0] One of our VLSI design labs was a FreeBSD lab, and the machines there had a bunch of proprietary/paid simulation software on them. It was amazing to be able to ssh in from my dorm room, and run those apps "locally", with access to all my files on the network share. A few of my classmates wondered why I never pulled all-nighters in the lab with them... I never needed to! They all ran Windows at home; back then it was pretty difficult (or at least just kinda unknown) to run an X server on Windows.

For a time I had lots of xterms, emacs sessions, etc running across the network. It’s a great feature.

For some applications it is radically faster than other options.

With X, I can just go ahead and fire up the GUI, and it will appear. Maybe a bit laggy, but as long as its only one application, it's usually good enough to complete the task I need to complete.

With remote work and thin pipes, it's laggier, but "xpra" also allows per-application X forwarding, and removes a lot of the lag.

Of course I could set up full VNC and set up a whole desktop environment on the cluster head node, and remote into it, and maybe in the glorious Wayland future, I will have to do that.

Sometimes when I talk about this, someone in the comments says that Wayland is working on some kind of per-application forwardability -- that would be nice if it's true.

I get that my use-case is niche, and so I don't expect it to be a high priority for the devs, but it's one of those things that, once in a while, is a critical link in my administrative workflow, and I'm not looking forward to the eventual kludging of workarounds.

Edited to add: I have now seen the comment below about "waypipe", this sounds very promising!

How practical is that? I have horrible upload speed at home which ruins all these "just remote into your home machine" workflows for anything more than a terminal.

Somebody should go and provide equally seamless "Wayland forwarding". That might end up looking more like VNC under the hood, but there's nothing inherently wrong with that.

Is it seamless enough for what you had in mind?

TigerVNC (and some others) will do e.g. "-via foo@bar :1" which GP might not know, but is rather convenient.

Xpra is still a better replacement for -X when launching a single application though.