I recently tried switching to Linux with a few different distro's (Ubuntu, Elementary OS, etc.) and use Wayland.
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.
Wayland is not GNOME, what you describe is not Wayland problem, but GNOME problem.
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.
With X11, I can change scroll speed using the `imwheel` tool.
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.
> Wayland is not GNOME, what you describe is not Wayland problem, but GNOME problem.
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.
No it's not possible in a newer LTS (> 20.04, don't have laptop on hand) Ubuntu KDE. There's no scroll speed configuration, as sibling comments discuss. Switching driver to libinput or whatever made it configurable, but other bugs popped up, and suddenly every accidental palm touch sent my cursor clicking somewhere.
There may be GNOME specific issues as well but I also noticed the other week FF scrolling being bonkers in sway (just a light swipe can "smooth scroll" across several screenfulls way too fast and long, with several seconds of slow trailing scrolling) but not under i3 (IIRC it might even have been fine in sway when running under XWayland). I don't recall the details but got back to somewhat sane behavior with some non-obvious about:config changes.
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
>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.
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.
Gnome on Ubuntu 20.04 does have thumbnails in file picker. I checked that right now before clicking Reply: Slack, upload from your computer, click on PNG, the thumbnail appears to the right of the file list.
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)
I would think that's a toolkit (GTK, Qt, etc.) issue, not a window manager (well, in Wayland parlance, compositor) issue. The apps just get the scroll events from libinput, and it's up to them to decide how much/how fast to scroll based on what it sees.
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.
> because it doesn't know anything about windows or focus
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.
And yet, in every other OS, scroll speed is a global setting, potentially with per-app overrides. No user in their right mind will configure a different scrolling speed in each and every app they use - they will have a preferred scrolling speed, and at most a handful of apps where they want custom behavior (e.g. scrolling in a game will probably require completely different precision than day-to-day, or perhaps a CAD tool).
I'm able to set the trackpad speed in both GNOME and KDE on Wayland with libinput. In GNOME, it is under Settings > Mouse & Touchpad > Touchpad Speed. In KDE, it is under Settings > Input Devices > Touchpad > Pointer speed. Do these settings not show up for you?
They're talking about scroll speed, not cursor speed. When using those high precision touchpads where you can scroll pixel by pixel (so not line by line scroll wheel emulation), it's impossible to configure the speed of that scrolling in GNOME, and on a whole lot of systems, it's insanely sensitive.
- "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."
The scroll behavior is highly configurable on Firefox' side: check out some of these about:config flags (if this is still of interest),
The same driver is used for wayland but I don't know how you configure it there, it will no doubt be possible to do something similar with a single text file config.
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.
I’m puzzled by your comment because I observe precisely the opposite: in Sway (Wayland) I have `input * scroll_factor 0.35`, but in i3 (X) I can’t reduce the scroll speed.
I noticed the same thing and it was hard to believe that such a basic thing is actually unsupported in 2022. It's really just not supported by Gnome or KDE when using Wayland.
I just don't bother with all of that, since it has been years without any improvement and with confusion of alternatives of alternative system components that are not working together and decide to fight against the OS as you have already explained this inconsistency.
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.
From https://wiki.ubuntu.com/Wayland
"The X11 protocol was designed around running graphical apps across the network. While some people use this feature, it's far from common. Wayland drops this requirement as a way to greatly simplify its architecture."
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...
You can also use Gimp via a RDP or VNC session, which will give much better performance on low-bandwidth connections, since those protocols do damage detection, only sending updates of what's changed, and (lossy) compression.
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.
Very much this. Running the X11 protocol over the network is usually not a good idea anymore.
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.
> my understanding is that the whole X11 is network transparent thing worked great when apps used the X11 drawing primitives.
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.
I was around back in the days that X-servers were still very much a thing, and even then many thought they were an expensive and inefficient way of doing things.
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.
> These days a significant number of X11 apps just render _everything_ "server-side" as bitmaps and then send them over the wire to the client to composite them.
Inferring from the quotation, I take it you mean application server-side (instead of display server-side)? Just confirming.
> since those protocols do damage detection, only sending updates of what's changed
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.
Editing my photos over a layer of video compression artifacts doesn't sound fun. Web apps are a more reasonable replacement for X11, with browser client much more capable to do low latency local processing. The only problem is lack of easy support for local apps and LAN-distributed apps. Probably still easier to add than to support low input latency eventually consistant Canvas over X11 or VNC.
> 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.
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.
I never had to do it myself, but I have a feeling it will work better with Wayland. The delay of 50-80ms introduced by the network is not terribly much (everything under 110ms is fine for playing Dota), so if your software doesn't lag itself, like X11 did, maybe it will work.
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 know whether you used Remote X, but I used it in a project, and it's extremely inefficient, esp. in thin client applications, and if you try to carry anything like a video, a 100mbps connection could easily be saturated by one pair of X server and client. In other words, it doesn't work in any way unless you have a gigabit LAN.
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.
Remote X has been a godsend for me. I'm not always able to lug around a worthy machine, so being able to use lesser hardware as a 'thinclient' to my wireguard'd assets is very handy. Obviously I'm not going to expect high definition video or realtime gaming, but that's not what it's billed as either, so within the scope of what it's for I'm wholly satisfied.
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.
> 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.
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.
Also, I suspect that the bandwidth used by a typical X app was far lower back when it was invented. I remember seeing some greyscale X terminals, and probably not many levels of grey either.
It's interesting how our networks have gotten relatively much slower. When X11 was designed and for a long time afterwards, networks were fast enough. But now end user networking performance has plateaued much earlier and faster than computing power and app bandwidth requirements.
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.
On the other hand, this works increasingly poorly as most desktop environments and software assumes there is no network involved (for example, last time I tried running Firefox over a forwarded X session I got a bunch of errors about a broken GL context). And you can do the same thing, with usually better results, by using VNC instead (and there are indeed VNC servers for Wayland, for example wayvnc).
Just had to use Firefox remotely (to use WeTransfer to ship a giant file, they dropped support for their cli, grr), and had exactly this issue - it works incredibly slowly over X over SSH. In the end had to use vnc over SSH.
(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)
I'm not sure what experience you're describing, for me the real crime trying to run a remote Firefox over a forwarded X session is that it figures out you're doing that and instead decides to run another window of your local Firefox instance. It's been like that a few years now. I can't imagine what they're doing under the hood, haven't looked into it, but it sure is irritating.
Without x2go most apps aren't usable over the internet now because x11 was designed around assumptions that are no longer correct and you end up with multiple round-trips during rendering.
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.
> x11 was designed around assumptions that are no longer correct
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 just seems completely pointless to even bother with something x11's network transparency
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.
This is a big misunderstanding. Network handling is stripped from the core design, but is very much available on all compositors.
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.
Low network utilization yes and perhaps superior to X11 core protocol, but it doesn't come for free, for example in terms of latency. And what if said app was actually a video player in it own self? Then you get to decode the video on server and re-encode it again for transport, whereas a primitive-centric protocol could allow decoding the original video directly on the client.
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
at work accidentally from my home computer and it was running fine over the 100Mbit network, so I didn't realize my mistake until coming back from lunch. Basically just a bunch of pixels running around smoothly, but I think it would be quite a quality test for a video encoder..
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.
Each time I tried running Firefox over ssh with X11 it either lagged or crashed. With Wayland's Waypipe it works flawlessly, I could even watch a Youtube video through it.
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.
The issue is the new webrenderer or how it is called. There are options in about:config to disable it and force the old webrenderer.
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
And any program not made with goddamn XMotif will be slow as fuck on anything non-ethernet.
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.
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.
I've used it in the past month to impromptu demonstrate something that I had set up on a GUI app at home (with a lot of dependencies) from my laptop.
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.
This is what I keep coming back to. A backend that targets Javascript can take advantage of the desktop/laptop GPU. A backend that targets Wayland has to render everything locally in software (no GPU), and nobody I’ve ever worked for wants to build a system that runs this way.
Xaw and Motif worked okay, and it’s getting hard to imagine a heavy user who has access to only one computer, yet newer GUI toolkits have lost interest in X11 as a platform for remote rendering.
I actually still use this feature a lot. I run some linux software on a server and can see the window on my main desktop without any need for rdp, vnc or similar. It’s really great!
I used to use X11's network transparency features a lot in college[0], but it's been a good 20 years and I haven't used it since -- even once.
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.
I use it quite often. And I am dreading the day the office switches to wayland. I like having terminals open to several machines on the premises and being able to fire up individual applications from each. I don't really like having a workspace devoted to a vnc for each machine. It doesn't work as well. It makes me use the mouse more. I don't want windows into those machines. I want a gui on my machine hooked to the heavy lifting on another. I'm sure I'll adapt. But sonfar, its a productivity killer.
It's in the "critical path" for certain niche applications. I do HPC operations, and every now and then, I run across some (usually commercial) scientific software application whose installer and/or configuration manager is a GUI. I am not sitting in front of the cluster head-node, I am ssh'd in to it.
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!
I used that feature very rarely but the times I did it was insanely useful. Mostly running some debug software so debugging session could run locally but I could control it remotely, without installing whole graphical environment and somehow setting up vnc session just to run single app
> While on the road, you can use your notebook to open a Gimp session on your home machine and edit an image stored there.
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.
Not at all practical. Remote X11 isn’t really practical on a LAN, much less over a slower internet link. It’s cool in theory but not especially useful.
Realistically speaking, what matters is that openssh comes with X11 forwarding built-in.
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.
It's a lot more than just cool compositing effects. If you are just trying to get some work done reliably with a dynamic multimonitor setup, Wayland is vastly superior.
I use remote display of apps daily as part or work. I've a Linux VM, and all compute or memory intensive programs run on LSF with x11 forwarding or via direct login. Sure desktop users don't need the remote part, but enterprise / high end compute definitely does
I use X11 remotely daily (and did so for 25 years). It comes for free with a simple ssh login and doesn't require setting up any server on the remote machine. It just works (even if slowly at times). It beats setting up x2go/VNC/etc hands down.
I'd be a big fan if that worked, but I haven't found an open remote desktop solution on Linux that works out of the box and acceptably fast¹, to the point that I have to use proprietary software to perform remote desktop sessions - there is a huge gap between the open solutions and the proprietary ones².
¹=they're all either incredibly slow, or clunky to configure/use. interestingly, X2Go, which I think was working out of the box, but was too slow, is based on an old version of the Nomachine (NX) protocol.
waypipe[1] is the wayland equivalent people are looking for. It gives you the UX and ease of use of X11 forwarding, but with the performance and efficiency of things like RDP (which is gross, but can run quite well on Windows Server if you throw enough money at Microsoft).
Wayland applications will render entirely on the host using host resources and acceleration as needed, buffer content gets transmitted using (hardware accelerated) h264 encoding, while messages in general get passed as-is to give a fully local experience.
This. It takes hundreds of megabits per second to work smoothly.
If you're doing this while on the move, your mobile data is going to be gone in a literal matter of seconds, if the network were fast enough to support it, which it isn't so in reality you're going to be frustrated and wondering why you didn't use a different protocol. From VM to host or on gigabit LAN it works okay, which is where I've used it before.
I used X forwarding a lot until last year, so I can find various arguments for it, but "while on the move" makes absolutely no sense.
What percent of Linux users do you think would ever use software this way? What percent of all "desktop" OS users would ever use software this way? It seems like an extremely niche and rare use case and probably not the right thing to target for the main desktop environment.
I've been using Linux as my main OS for ~12 years now. I have personally never wanted to do anything like that. For remote software, I would prefer a web UI or a VNC/remote-desktop tool.
X-forwarding (over ssh, or directly like this person is doing) is extremely useful and powerful. I use it this way, and I know plenty of people that do too. On top of that, wayland doesn't solve any problems that I have, so there's your data point.
Using a wayland desktop, remote login into a Linux server, start a graphical text editor like gvim, it fails. This is a very common way to dev on Linux, I too have been doing this daily, and with ssh+X11 it works out of the box. I wonder what is the best way to do this with Wayland. Should I ask an admin to reconfigure the remote server to run a VNC or RDP server, and then use a specific tool to connect? I wonder if VNC/RDP can integrate apps as windows instead of all-in-one window.
>> X client and server are usually the same machine, but they don't have to be.
When I was in college there were rooms full of X-terminals which would be used to remote into various bigger workstations. You could also sit locally at one of those machines, but plenty could be done over the network and by more people on lower cost hardware.
Nobody is arguing it's not a great and powerful feature, nor that it's not "a lot to give up". The only argument posited is that not a lot of people will actually have to make that sacrifice (as not many actually use that feature). Is that not true?
X11 is way too slow to run something like gimp remotely, unless perhaps you are sitting near the other machine connected via gigabit ethernet. Giving that up is an easy win for better everything else.
> This is a lot to give up for cool compositing effects...
I've used networked X windows and it's always felt like a kludgy, crash-prone hack. The better solution is to render the entire desktop remotely and stream it over wholesale, such as with VNC and other protocols.
If companies like YC's Mighty have their way, the future will be thin-client based. And it won't be built on X Windows, because that's the wrong layer of abstraction.
The thing I dislike about Wayland is: Sometimes the server will crash. Video drivers or something. Hasn't happened much with 22.04, but used to happen more frequently before. Both with Intel and AMD.
When this happens in X11, the server restarts, I see the screen go black for an instant, that's it.
When this happens in Wayland, all my open programs are killed. No save prompts or anything, just insta-killed. This makes Wayland unusable unless they can guarantee no crashes, ever.
Same here. Only, Wayland just hangs the entire screen, no recovery possible. I could reproduce this across distros and hardware (Intel, AMD and Nvidia). This was using stock Fedora 34, and I haven't tried since, because those hangs would occur within minutes of boot and I the closest I could come was "must be a driver bug". Exactly the same bug for all three GPU makers...
Unfortunately, nobody seems interested in such user reports or quality control (apparently, turns out there are many like us who're getting "upgrade your hardware", "works for me", "user error", etc. I retreated to Debian stable, which is indeed very stable.
A display server crash is fatal under X. A window manager crash is not. A window manager is not particularly affected by GPU drivers.
What you see might be a GPU hang or reset that recovered.
Some Wayland compositors have a window manager model by using an external process for window positioning logic (e.g. river). This is mostly just for convenience of development though, making it easy to experiment with layout engines.
> A window manager is not particularly affected by GPU drivers.
Since the window manager is also the compositor in many X setups (e.g. GNOME and KDE), the WM is very much affected by GPU drivers. It doesn't have to be the GPU drivers though, plenty of complexity in the WM/compositor itself.
The core complaint is absolutely valid - the protocol and libraries should have been designed so that applications can recover from a server crash/restart, even if the legacy X server does not provide that guarantee.
To be nitpicky, if the X server crashes, you're just as hosed with X as with Wayland.
The difference is that X survives a window manager crash, whereas Wayland typically does not, because on Wayland it's usually the same process as the server.
i really want to support Wayland. X has done us well, but it's about time a protocol based around more modern situations supplants it.
Wayland has a myriad of these sharp-edge cases which i also find each time i try it out. what worries me a little is that some of them are clearly design decisions with no simple remidiation, your crashing example (which i have also witnessed first hand) is one of them.
Though I'm not sure what's the current status of that is or how actively it's progressing. Hopefully it will turn into something usable, it's important.
I takkede to an X11 dev once about this. I remember him saying that X supports recovering already. The issues was that most compositors and applications did not.
I think currently we have compositors that are monolithic and due "it all". Sounds like we'd need a separate process to maintain window state, that the compositor interfaces with. is this recreating some of the problems of X11?
Perhaps a better approach would be to make sure that clients can wait for the server to restart and reconnect. Then you don't need any crash-proof server part.
As a fellow X11 apologist, this was pretty cool to read. It's nice to see that things are shaping up, even if there are still quite a few rough edges.
Having said that, I'm still a die-hard Xfce user, and until someone makes an xfwm4-like Wayland compositor, and ports (at least) xfce4-panel and xfdesktop to Wayland, I'm not gonna switch.
Every 2 years I take Xfce (Xubuntu, Mint Xfce) for a test drive. It seems light and fast, I want to like it. Then every 2 years, I rediscover that the resize border on each window is 1px wide, which is completely unusable. When I google for a solution, the answer seems to be use Alt-Left-Mouse. I don't understand how that is a solution. I don't want to use 2 hands to resize a window.
Used Xfce for a decade. I have never had trouble using the mouse to resize windows. I use 1080p screen, maybe you use a higher resolution and 1px is too small on that.
If you right click the title bar of any window, to open a menu, from which you can select resize.
Even though it has been 7 years since the initial report and the issue is still very much active, the assigned dev says it's a low priority to him. If you know how some FOSS project still work, there's very little hope for a change anytime soon.
Wat. I'm writing this from under Xfce. Just targeted my mouse pointer at a window border, moved it around. No, the resize-sensitive width is deifinitely wider than 1 px.
Have you tried changing the window title / border theme in Settings / Window Manager? There are a few themes with resize corners only provided on top and bottom, and with left/right borders 1px thick; you might have switched to that and had the frustration. But there are definitely a number of themes with comfortably thick border. (My preferred one is Smoothwall.)
> When I google for a solution, the answer seems to be use Alt-Left-Mouse. I don't understand how that is a solution. I don't want to use 2 hands to resize a window.
For what it's worth, it works very well one-handed on laptops, this is how I've used it for years and I greatly prefer it. The click target, that is the area you have to aim for with the mouse cursor, is much bigger than even the most absurdly thick window borders, so I find it much easier to use.
Yeah, that's frustrating sometimes, and I don't even have a super hi-res screen.
But I just live with it. Honestly I don't resize windows that often. I either use the window's natural size, or maximize. In the 18 years I've used Xfce it hasn't been a big issue for me.
I'll be holding out for that too, Xfce has been my DE since the day that Gnome 2 was forcibly retired. A simple, configurable, responsive, unopinionated, low fuss DE is essential.
There are lots of stubs of news out there on the web that xfce development may head in that direction, potentially moving from xfwm4 to mutter, so fingers crossed.
(I am definitely an xorg apologist but ... that's because it does what I need, painlessly. As/when wayland can, I'm good to move, especially if the majority of development is taking place there. We just never quite seem to reach that point.)
I've tried to use Sway a number of times, and the biggest reason I keep bouncing off it is environment variables.
There's a bunch of environment variables I want set for every process in my desktop session, from basic things like $EDITOR and $LD_LIBRARY_PATH to more complex things like $MOZ_USE_XINPUT2 or $SSH_AUTH_SOCK. When I use i3 under X11, gdm runs my ~/.profile script so I get all my standard login environment variables, then it runs ~/.xsession so I get all my GUI-specific settings. There's also some integration with systemd so that the SSH agent can set $SSH_AUTH_SOCK and have it show up in my terminals.
With Wayland/Sway, none of this works. gdm does not execute ~/.profile, and there's no equivalent to ~/.xsession. Something starts a user-level systemd instance, but its environment variables aren't synced to the compositor, and the compositor doesn't use it to start apps, so $SSH_AUTH_SOCK isn't available in anything I care about.
Having an SSH agent seems like such a basic feature, but it doesn't work for me and I can't even imagine where I'd begin to look for the problem, or for documentation to learn more about it.
This is not really a wayland or sway problem, but really a systemd problem. It's really annoying because the documentation around this is very scattered and contradictory.
The advice used to be that you should use pam user environment (~/.environment and you need to edit pam configuration on some distributions to allow user environments). However, IIRC there are some possible security implications around this so this has been deprecated. I think you are now supposed to use systemd user variables (or so). I'm not on my computer right now so can't look it up, but hopefully that gives you enough Google keywords to set things up.
It seems like the main developers behind systemd and several of the other fundamental layers of the system stack only use gnome/KDE and assume everyone else is. So some things become quite frustrating to set up for regular users.
Yeah, I can create files in ~/.config/environment.d/ to set some environment variables. My problems are that (a) that syntax only allows very simple variable assignments, not complex things like "run ssh-agent and add the environment variables it prints to stdout" and (b) those environment variables aren't available to the Wayland compositor or applications it launches.
Definitely agree. It took several days to figure out the exact environment variables needed to get basic applications working and scaling properly. For example, if you want “click link and open it in default browser” to work in, say, Slack, you need environment variables to get it working.
And since (like you say) basic profiles are not executed on startup, it’s very difficult to fix anything.
I completely disagree with the Sway author’s approach to go batteries excluded for the project. It means that next to nothing works out of the box, and that you either have to put in hours of work to fix undocumented things, or rely on a distro to package everything exactly right. And there really aren’t any distros packaging Sway right now.
Sway would benefit from integrating more of these things out of the box and it should rely much less on end-user configuration and other software to accomplish basic desktop behavior.
One excellent example is that you need a separate Lock Screen app like swaylock to lock your computer. And since you’re in charge of configuring all its settings, it’s difficult to know if you’ve done something insecure.
It seems to me that sway is intended for power users, people who know exactly what is going on with their linux from boot to window manager, and thus have no difficulty configuring whatever they desire.
If sway adopts opinionated defaults it will mess with people who don't care for those defaults. Perhaps there is a way to do it such that opinionated defaults immediately turn off in the presence of configuration but as far as I can see there is no interest in this.
Under GDM you can use systemd environment.d(5)[1] to configure those variables. I have some examples in my dotfiles[2]. Your Sway configuration also has to inject it's own environment variables to systemd session like is documented here[3]. Arch Linux does that in `/etc/sway/config.d/50-systemd-user.conf`[4]
If you really want to run some shell scripts before sway then you have to create a new desktop file under `/usr/share/wayland-sessions/` that calls your script that setups environment and does `exec sway`[5]
When you 'exec sway' it inherits the tty env vars... So just stuff your vars into whatever .profile the tty loads when you login after boot. This has never been a problem I spent any amount of time on.
If you are doing something magical like auto starting sway or something, then you need to make sure that a .profile is loaded by whatever is starting sway if it doesn't inherit a .profile.
In addition to the reply, he mentions gdm so he likely doesn't login from the console. This is a bit extreme but one day they might (for security reasons) remove that too.
> With Wayland/Sway, none of this works. gdm does not execute ~/.profile, and there's no equivalent to ~/.xsession. Something starts a user-level systemd instance, but its environment variables aren't synced to the compositor, and the compositor doesn't use it to start apps, so $SSH_AUTH_SOCK isn't available in anything I care about.
This probably won't help you, since you say the compositor isn't using the user-level systemd instance to start apps, but in case it helps someone else: I recently faced a similar problem at work (I needed to set the DOCKER environment variable so that unit tests running directly from the IDE could find the podman socket from the user-level podman.socket systemd unit), and solved it by creating a file under ~/.config/environment.d (https://www.freedesktop.org/software/systemd/man/environment...).
Same here. I also use i3 in a non-standard way: in KDE but with i3 instead of Kwin, and it has been the dream setup for me navigation wise. I wished I could somehow do the same with Sway under Wayland, But that doesn't seem to be supported.
Yeah, I've got a lovely GNOME+i3 setup that I really like. There doesn't seem to be an equivalent for Sway, but the GNOME services get more memory-hungry over time so I'm always looking to see about Sway becoming more usable.
I settled on pam_env and ~/.pam_environment for handling these. Required a small change to pam config to load it by default, but it felt like a sane solution at the time.
Over the last decade and a half I've written dozens of small tools, applets, etc to hone my desktop environment I use. Half of those have required patching, some don't work at all (like a nifty oneliner I used to kill of hung ssh connections by targeting the ssh process name, that no longer includes the ip or domain).
I will use X11 until I can't - simply because I do not want to rewrite my tooling.
Agreed. I use xdotool heavily, ssh -YC quite a lot. underpowered devices...
I'm going to stay on X11 as long as there are options. Thankfully, there are still plenty of options, FOSS seems good at that long tail. Just like MATE still offers me a nice simple desktop that doesn't even force compositing for the particularly wimpy laptop.
This is a good article, one of the best in this vein that I've seen. The author clearly had some features that he really needs from X and has been tracking their progress under Wayland. If you find yourself in a similar circumstance, I think it's a good read.
My own experience was different. I came back to Linux as a daily driver after years away. I bought a machine expressly to be a good Linux workstation and set it up from scratch. So for me the new stuff (Wayland (via Sway), Pipewire, etc..) has simply been excellent. I just didn't have the legacy issues to deal with that other people have.
The pet peeve of mine is lack of subpixel rendering: if you move from X to Wayland, it's hard to get used to fuzzy fonts.
Then again, recent MacOS versions have also dropped it, and I couldn't stand fuzzy fonts either (and so much for their screens being "retina" screens).
In order to do subpixel font rendering correctly, the application needs to know about the subpixel arrangement of the display hardware. So it falls under the same category as things like color management, which Wayland also doesn't support; they just didn't standardize an API to provide that information.
Thanks: I haven't dove deep enough to know exactly where the issue was, but booting into Gnome wayland session on Ubuntu 22.04 resulted in blurry fonts on my external 32" 4k screen, whereas just switching the session to Gnome on X worked fine.
My search at the time (a few months ago) suggested that subpixel rendering didn't work (changing settings from gnome-tweaks didn't do anything either).
Readit News
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.
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.
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.
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
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.
[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)
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.
The scroll behavior is highly configurable on Firefox' side: check out some of these about:config flags (if this is still of interest),
Deleted Comment
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
ScrollAnywhere. It's much better UX than even the best scroll wheels.
Deleted Comment
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.
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.
Inferring from the quotation, I take it you mean application server-side (instead of display server-side)? Just confirming.
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.
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.
That is how we have been giving development machines since 2011, Windows workstations on whatever cloud vendor the project is taking place.
Deleted Comment
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.
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.
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.
(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)
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+.
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
at work accidentally from my home computer and it was running fine over the 100Mbit network, so I didn't realize my mistake until coming back from lunch. Basically just a bunch of pixels running around smoothly, but I think it would be quite a quality test for a video encoder..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.
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
Watching a Youtube video on remote X is rarely a problem, there's no latency involved.
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.
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.
Xaw and Motif worked okay, and it’s getting hard to imagine a heavy user who has access to only one computer, yet newer GUI toolkits have lost interest in X11 as a platform for remote rendering.
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?
Wait, you think this is what this is all about?
How about the cool security effects...?!
Lack of tearing without vsync… effects?
Edit: replaced 10Gbit with 1Gbit. And also I love using this feature even with all its slowness
It also lists FreeRDP and wayvnc.
¹=they're all either incredibly slow, or clunky to configure/use. interestingly, X2Go, which I think was working out of the box, but was too slow, is based on an old version of the Nomachine (NX) protocol.
²=the recent RustDesk tries to fill that gap.
Wayland applications will render entirely on the host using host resources and acceleration as needed, buffer content gets transmitted using (hardware accelerated) h264 encoding, while messages in general get passed as-is to give a fully local experience.
And it of course works over SSH.
1: https://gitlab.freedesktop.org/mstoeckl/waypipe
Have you actually tried that in recent years? In my experience not much actually works this way anymore, the performance is just terrible.
If you're doing this while on the move, your mobile data is going to be gone in a literal matter of seconds, if the network were fast enough to support it, which it isn't so in reality you're going to be frustrated and wondering why you didn't use a different protocol. From VM to host or on gigabit LAN it works okay, which is where I've used it before.
I used X forwarding a lot until last year, so I can find various arguments for it, but "while on the move" makes absolutely no sense.
When was the last time you used this feature ?
X11 is a protocol designed for machines which didn't have the power to draw a GUI locally. That time has long passed.
Open up gimp remotely on the road, try it. It isn't usable ny any stretch of imagination.
That is why we need hacks such as x2go to make it usable.
Even the worst RDP solution is orders of magnitude better in performance than X11.
I've been using Linux as my main OS for ~12 years now. I have personally never wanted to do anything like that. For remote software, I would prefer a web UI or a VNC/remote-desktop tool.
When I was in college there were rooms full of X-terminals which would be used to remote into various bigger workstations. You could also sit locally at one of those machines, but plenty could be done over the network and by more people on lower cost hardware.
For whom?
Nobody is arguing it's not a great and powerful feature, nor that it's not "a lot to give up". The only argument posited is that not a lot of people will actually have to make that sacrifice (as not many actually use that feature). Is that not true?
It never actually worked "on the road".
VNC and windows remote desktop was always better.
X11 remoting took me to a new level in college, when I needed to use Solaris workstations to complete assignments.
I've used networked X windows and it's always felt like a kludgy, crash-prone hack. The better solution is to render the entire desktop remotely and stream it over wholesale, such as with VNC and other protocols.
If companies like YC's Mighty have their way, the future will be thin-client based. And it won't be built on X Windows, because that's the wrong layer of abstraction.
When this happens in X11, the server restarts, I see the screen go black for an instant, that's it.
When this happens in Wayland, all my open programs are killed. No save prompts or anything, just insta-killed. This makes Wayland unusable unless they can guarantee no crashes, ever.
Unfortunately, nobody seems interested in such user reports or quality control (apparently, turns out there are many like us who're getting "upgrade your hardware", "works for me", "user error", etc. I retreated to Debian stable, which is indeed very stable.
What you see might be a GPU hang or reset that recovered.
Some Wayland compositors have a window manager model by using an external process for window positioning logic (e.g. river). This is mostly just for convenience of development though, making it easy to experiment with layout engines.
Since the window manager is also the compositor in many X setups (e.g. GNOME and KDE), the WM is very much affected by GPU drivers. It doesn't have to be the GPU drivers though, plenty of complexity in the WM/compositor itself.
The core complaint is absolutely valid - the protocol and libraries should have been designed so that applications can recover from a server crash/restart, even if the legacy X server does not provide that guarantee.
The difference is that X survives a window manager crash, whereas Wayland typically does not, because on Wayland it's usually the same process as the server.
Wayland has a myriad of these sharp-edge cases which i also find each time i try it out. what worries me a little is that some of them are clearly design decisions with no simple remidiation, your crashing example (which i have also witnessed first hand) is one of them.
* https://www.youtube.com/watch?v=fRdnRwPBFBk
* https://invent.kde.org/plasma/kwin/-/wikis/Restarting
Though I'm not sure what's the current status of that is or how actively it's progressing. Hopefully it will turn into something usable, it's important.
Your windows manager crashed. If xorg had crashed you'd have lost your data.
Having said that, I'm still a die-hard Xfce user, and until someone makes an xfwm4-like Wayland compositor, and ports (at least) xfce4-panel and xfdesktop to Wayland, I'm not gonna switch.
Edit: ok, looks like there's Hopalong (https://github.com/iridescent-desktop/hopalong), so we're part of the way there, even if it's pretty new.
If you right click the title bar of any window, to open a menu, from which you can select resize.
Even though it has been 7 years since the initial report and the issue is still very much active, the assigned dev says it's a low priority to him. If you know how some FOSS project still work, there's very little hope for a change anytime soon.
Have you tried changing the window title / border theme in Settings / Window Manager? There are a few themes with resize corners only provided on top and bottom, and with left/right borders 1px thick; you might have switched to that and had the frustration. But there are definitely a number of themes with comfortably thick border. (My preferred one is Smoothwall.)
For what it's worth, it works very well one-handed on laptops, this is how I've used it for years and I greatly prefer it. The click target, that is the area you have to aim for with the mouse cursor, is much bigger than even the most absurdly thick window borders, so I find it much easier to use.
But I just live with it. Honestly I don't resize windows that often. I either use the window's natural size, or maximize. In the 18 years I've used Xfce it hasn't been a big issue for me.
Deleted Comment
There are lots of stubs of news out there on the web that xfce development may head in that direction, potentially moving from xfwm4 to mutter, so fingers crossed.
(I am definitely an xorg apologist but ... that's because it does what I need, painlessly. As/when wayland can, I'm good to move, especially if the majority of development is taking place there. We just never quite seem to reach that point.)
There's a bunch of environment variables I want set for every process in my desktop session, from basic things like $EDITOR and $LD_LIBRARY_PATH to more complex things like $MOZ_USE_XINPUT2 or $SSH_AUTH_SOCK. When I use i3 under X11, gdm runs my ~/.profile script so I get all my standard login environment variables, then it runs ~/.xsession so I get all my GUI-specific settings. There's also some integration with systemd so that the SSH agent can set $SSH_AUTH_SOCK and have it show up in my terminals.
With Wayland/Sway, none of this works. gdm does not execute ~/.profile, and there's no equivalent to ~/.xsession. Something starts a user-level systemd instance, but its environment variables aren't synced to the compositor, and the compositor doesn't use it to start apps, so $SSH_AUTH_SOCK isn't available in anything I care about.
Having an SSH agent seems like such a basic feature, but it doesn't work for me and I can't even imagine where I'd begin to look for the problem, or for documentation to learn more about it.
The advice used to be that you should use pam user environment (~/.environment and you need to edit pam configuration on some distributions to allow user environments). However, IIRC there are some possible security implications around this so this has been deprecated. I think you are now supposed to use systemd user variables (or so). I'm not on my computer right now so can't look it up, but hopefully that gives you enough Google keywords to set things up.
It seems like the main developers behind systemd and several of the other fundamental layers of the system stack only use gnome/KDE and assume everyone else is. So some things become quite frustrating to set up for regular users.
And since (like you say) basic profiles are not executed on startup, it’s very difficult to fix anything.
I completely disagree with the Sway author’s approach to go batteries excluded for the project. It means that next to nothing works out of the box, and that you either have to put in hours of work to fix undocumented things, or rely on a distro to package everything exactly right. And there really aren’t any distros packaging Sway right now.
Sway would benefit from integrating more of these things out of the box and it should rely much less on end-user configuration and other software to accomplish basic desktop behavior.
One excellent example is that you need a separate Lock Screen app like swaylock to lock your computer. And since you’re in charge of configuring all its settings, it’s difficult to know if you’ve done something insecure.
Otherwise, I really enjoyed using it.
If sway adopts opinionated defaults it will mess with people who don't care for those defaults. Perhaps there is a way to do it such that opinionated defaults immediately turn off in the presence of configuration but as far as I can see there is no interest in this.
If you really want to run some shell scripts before sway then you have to create a new desktop file under `/usr/share/wayland-sessions/` that calls your script that setups environment and does `exec sway`[5]
[1]: https://man.archlinux.org/man/environment.d.5
[2]: https://github.com/artizirk/dotfiles/tree/master/.config/env...
[3]: https://wiki.gnome.org/Initiatives/Wayland/SessionStart
[4]: https://github.com/archlinux/svntogit-community/blob/package...
[5]: https://github.com/swaywm/sway/issues/100
If you are doing something magical like auto starting sway or something, then you need to make sure that a .profile is loaded by whatever is starting sway if it doesn't inherit a .profile.
This probably won't help you, since you say the compositor isn't using the user-level systemd instance to start apps, but in case it helps someone else: I recently faced a similar problem at work (I needed to set the DOCKER environment variable so that unit tests running directly from the IDE could find the podman socket from the user-level podman.socket systemd unit), and solved it by creating a file under ~/.config/environment.d (https://www.freedesktop.org/software/systemd/man/environment...).
See also: https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasm...
Over the last decade and a half I've written dozens of small tools, applets, etc to hone my desktop environment I use. Half of those have required patching, some don't work at all (like a nifty oneliner I used to kill of hung ssh connections by targeting the ssh process name, that no longer includes the ip or domain).
I will use X11 until I can't - simply because I do not want to rewrite my tooling.
I'm going to stay on X11 as long as there are options. Thankfully, there are still plenty of options, FOSS seems good at that long tail. Just like MATE still offers me a nice simple desktop that doesn't even force compositing for the particularly wimpy laptop.
My own experience was different. I came back to Linux as a daily driver after years away. I bought a machine expressly to be a good Linux workstation and set it up from scratch. So for me the new stuff (Wayland (via Sway), Pipewire, etc..) has simply been excellent. I just didn't have the legacy issues to deal with that other people have.
Then again, recent MacOS versions have also dropped it, and I couldn't stand fuzzy fonts either (and so much for their screens being "retina" screens).
At least this is coming to Wayland :)
My search at the time (a few months ago) suggested that subpixel rendering didn't work (changing settings from gnome-tweaks didn't do anything either).