Separating the Wayland compositor and window manager(isaacfreund.com) |
Separating the Wayland compositor and window manager(isaacfreund.com) |
> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.
Although I'm not sure if it was the least resistance per se (as a social phenomenon), but just that it's an easier problem to tackle. Or maybe the authors means the same thing.
(That and the remote access story needs to be fixed. It just works in X11. Last time I tried it with a system that had 90 degree display orientation, my input was 90 degrees off from the real one. Now, this is of course just a bug, but I have a strong feeling that the way architecture Wayland has been built makes these kind of bugs much easier to create than in X11.)
There were probably other ways to fix those issues, but it would still be a fair amount of churn.
X11's extension mechanisms can - and has - been used to enable backwards incompatible protocol changes. E.g. BigRequest changes the length and format of every single protocol request.
Very few client libraries are only capable of speaking "the existing" protocol if you take that to mean the original unextended X11 protocol.
Adding an X11 extension that when enabled cleans up a lot of cruft would not have been a problem.
> where ideally the window manager would make choices about things before the process continues
Nothing stops you from introducing an extension that when enabled requires the client to wait for a new notification type before continuing, or re-defines behaviour. That said, using my own custom window manager, I don't know what you mean here. My WM does decide the initial window placement and size, and it's the clients damn problem if it can't handle a resize before I allow the window to be mapped.
The X protocol is crusty in places, but it is very flexible. People haven't fixed these things because they chose to invent compatibility hindrances that weren't real when their response was to invent an entirely new protocol with no compatibility at all.
On a tangent, also very ironic that X (the successor of Twitter) has the exact same logo as X (the window system). It's like Elon Musk just Googled for the first X logo that came along and appropriated that and nobody seems to notice or care.
When there was the 90deg off bug, was that a bug in the compositor or in wlroots?
Wayland can use RDP and some other remote desktop protocols, but it is not what I want, I want a window, not a desktop. There is Waypipe now, I heard it works fine now, but I am still doing "ssh -X", because it just works.
The problem with Wayland is that it is very much "batteries not included". To all the things that worked well in X11, the response has been "it can be done, our protocol is very flexible, ask the guys writing the compositor", not "that's how is done". The result, Wayland is 18 years old and it is only starting to work well, with some pain points still remaining, and display forwarding is one of them.
It is funny you mention a "reasonable path" by the way, as it is exactly that problem, I don't want a "reasonable path", I want it to work, and after 18 years, I think it is a reasonable expectation. To their credit, it seems we are getting there: waypipe, and now window managers, we may finally have feature parity.
Or maybe it’s desktop environments pulling the ladder up behind them.
Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.
Now it will take another 15 years for people to settle down in a set of common protocols instead of writing their own extension protocols and others 15 years for window managers to mature at the same level of the X11 window managers.
Then, people who think they know better than everyone else will throw Wayland away and start from zero all over again.
As the sibling comment said, with WSL becoming better and better, it's a dangerous game to play.
The "limitations" are political, not technical.
I thought I still did as my travel netbook died, but then I ended up in UEFI mess, regardless of the distro, and decided in the end to give that role to a Samsung tablet with DEX support instead.
If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.
Also, when it was split up what did he call his window manager? Looks like the River repo is just for his display server/compositor
Simple example of how impactful this separation has been for me.
hy3?
https://github.com/outfoxxed/hy3
(I'm an ex i3/now sway user and hy3 is the only way I can bear using hyprland)
Anything else will be taken by derivatives like Android, ChromeOS, or the VMs on top of Windows/macOS.
Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.
> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.
Whatever ideological debates there are underneath the X vs. Wayland divide, ultimately what I care about is things working as well as or better than other mainstream operating systems, and Wayland seems to deliver on that.
Each driver spells the TearFree / vsync option differently in the config. They probably should have just enabled it by default, since there is no downside.
I wonder if there’s space for a project like xlibre (or x.org, if it were revived) to update the x11 protocol to fill whatever gap compositors were meant to fill.
For what it’s worth, I’ve been moving all my machines to lxde.
Apparently, I accidentally switched back to a compositor free desktop without noticing. High framerate, vsync/tear-free and high dpi work fine. So does fractional scaling, but I disable it.
Personally, I’d rather these hypothetical x11 devs focused on reverse engineering hdmi vrr (blocked by lawyers at the moment), and HDR / expanded color spaces.
Any gotchas or regrets?
Haven't used it in many years and now considering going all in on making it (scaffolding of) next DE. So looking at the same move.
note that compiz is also a windowmanager, so already then compositor and window manager were one unit.
However if you really really really wanna side step this you can look at keyd - https://github.com/rvaiya/keyd
A project that has a daemon run in the background as a root service and that can provide an appropriate shim to pass key strokes to anything you want.
And just to be clear the appropriate secure model is to have a program request to register a "global" hot key and then the compositor passes it to the appropriate program once registered. This is already a thing in KDE Plasma 6 and works just fine.
That's kind of a big sticking point. When GNOME, KDE, and eg. Sway all have different screenshot APIs, the (eco)system doesn't work.
In effect the modern desktop is wayland (window communication), pipewire (audio/video), and xdg-desktop-portal (compositor/environment requests) which all kinda have to be worked with for a desktop application.
i'm a little thrown, because the Wayland diagram doesn't feel quite right. the compositor does lie between the kernel and the apps, but IIRC the apps have their own graphics buffers from the kernel that they are drawing into directly. the compositor then composites them together. to me, that feels more like the kernel is at the center of the diagram here: the wayland compositor is between the kernel and the output / input.
i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as wayland compositors needing to do so much, i can't help but chuckle, because it feels like the kernel does >50% of what X used to have to do itself; it's a much simpler world, using the kernel's built-in abstractions, rather than being multiple stacked layers of abstractions (kernels + X's own).
it means that the task of writing the display-server / compositor is much much much simpler. it's still hard! but the kernel is helping so much. there's an assumed base of having working GPU drivers!
author appears to super know their stuff. alas the FOSDEM video they link to is not loading for me. :(
one major question, since this is a protocol, how viable is it to decompose the window management tasks? rather than have a monolithic window manager, does this facilitate multiple different programs working together to run a desktop? not entirely sure the use case, but a more pluggable desktop would be interesting!
https://www.theregister.com/2026/02/11/river_wayland_with_wm...
I've been heard!
I switched to niri a few months ago, and while I like it for the most part, it feels too... busy for my taste. It defaults to a bunch of animations and decorations, all of which I've turned off. I'm happy with my current setup (aside from Wayland quirks[1]), but river's design and simplicity are very appealing. It reminds me of the philosophy of bspwm/sxhkd which I used for years on X11.
I do need scrollable tiling now that I've tried it, and I'm happy that there are a couple of options to choose from with river.
[1]: Seriously, why does copy/pasting sometimes simply not work?? I often have to copy twice for it to succeed. It's not related to Xwayland -> Wayland apps, and viceversa, or with copying from closed windows, etc. I don't use nor want a clipboard "manager". I just want my clipboard to work consistently. I've read many reports of this same bug on different distros and DEs, and nobody has figured it out. It's infuriating that such a basic feature is half-broken in a project that is 17 years old now!
Also, protect screenshot with permissions.
The NeWS book at page 35 has a picture explaining the structure of the CMU Andrew Window System: the window manager on top of the "base window system" (assuming protocol and logic), which sat on the graphic library, and applications connected to it through sockets. A limit was that the window manager was fixed, so you couldn't change its policy/look and feel without having the sources and recompiling it (and here I wish the source code was available).
Wayland it's kinda similar, but most of the graphic layer is moved from the server into each application (where each one use its own). Unless you have a compositor that is designed to be extensible out of the box, a set of widgets will be needed if you don't ship a desktop environment, and each one is a separate system process (for example: toolbar, clipboard manager, status bar, wallpaper). Another limitation is its "static" protocol, in the sense that you cannot extend the compositor at runtime loading extensions (you have the XML which is used to generate the stubs for the implementation in the compositor AFAIK). This can prevent applications that use them to run on compositors that don't implement them.
On the other hand, systems like NeWS, GMW (a window system from Kyoto University, ASTEC and Omron) and the one described by Rob Pike in "A concurrent window system" are interesting for these reasons:
- runtime extension loading code: new functionalities to the server can be added when needed
- code as a protocol: instead of sending "raw data" and requests, equivalent pieces of code are sent, allowing for compression and to offload a portion of the logic to the server (or even have applications that run inside the server). This can also allow to have applications that run on remote machines, which download the code for the interface to the server.
- concurrency: their programming model is structured around "lightweight processes" (or equivalent), which allow to decompose the interaction in independent tasks, which can eventually interact by sending messages/events or sharing resources.
I think it's worth re-investigating this kind of design, considering also the technological advancement (like the evolution of graphic hardware, multicore CPUs, touchscreens, ecc) and challenges (including security). It would be interesting something like NeWS but a bit more abstract and capable of supporting whatever graphic model you wish.
They took a firm principled stance against screenshots to start with, which set them up for the COVID WFH wave. Then we've got this questionable design that seems hard to make accessible since accessibility is a security risk and we're heading right into Agentic AI which will be interesting. I've been avoiding the Wayland ecosystem for as long as I can after the initial burn and it'll be curious to see how well it supports bringing in new AI tooling. Maybe quite well, I gather that Pipewire is taking over the parts of the ecosystem that Wayland left for someone else and maybe the community has grown to the point where it has overcome the poor design of Wayland's security model by routing around it.
My guess is the frustration is coming from a similar perspective because it is a bit scary seeing Wayland getting picked up everywhere as a default and the evidence to date is they don't really consider a user-friendly system as a core design outcome. Realistically Wayland is 2 steps forward even if there is a step back here or there. The OSS world has never been defined by a clean and well designed graphics stack.
As ordinary user, I actually don't care about any of this. However, from another perspective, I think this is a bad thing—open source projects have become product-centered, defaulting to the assumption that users are ignorant fools. This isn't how community projects should behave, but those projects is not that community-driven anyway.
After all, for a long time, so-called security has only been a misused justification—never letting users make mistakes is just a pretty excuse, meant to keep users from being able to easily access something, and eventually from ever accessing it at all.
I'm not a fan of ADA ambulance chasers on principle, but I wouldn't shed a tear see them be able to go after the bigcos that made this mess (e.g. IBM).
Next, it was accessibility APIs and I guess copy paste is still flaky.
Now, it’s window managers.
What’s next, Remote Desktop?
The whole reason given for wayland’s replacement of x11 was that those things are all fundamentally bad ideas.
It’s been 15 years. Linux desktops are more fragmented than ever, and they’re still going forward with mass deletion of legacy x11 applications.
The only benefits to end users are things like HDR, or backporting a compositor feature or two, which X11 could easily be extended to support.
Instead we get two decades of the digital equivalent of book burning for reasons no one understands.
And variable refresh rate, better fractional scaling (and per-monitor scaling), atomic updates, native touch & gestures. And the isolation/sandboxing is important. The problem is Wayland didn't have portals in the beginning (hence the screenshot issue).
Wayland isn't the problem. The pace at which distros (and GNOME, lets be real who is behind the push here) started stripping out X11 was too fast, and too early.
> for reasons no one understands
Reasons are sadly typical for FOSS: from the start the devs were focused on their favorite use cases with no communication with end users to figure out theirs.
That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.
because the devs actually have implemented things that i cared about
The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.
Wayland is 17 years old. At this point, it's almost more frustrating to have one of its bigger architectural problems potentially addressed, precisely because it shows that it was always possible, and the people pushing for its adoption just... didn't bother doing the things that would make it easier to adopt.
wlroots is a library for a complete display server + window manager.
It does not separate the two.
Furthermore, getting stuff like VRR on Wayland working is way easier than X.org. And, Wayland also supports HDR.
Granted, my requirements were simple, a laptop and occasionally one external monitor, though the issues I did run into were related to graphics drivers and NVIDIA shenanigans, but not to X11.
Now that I'm on Wayland, I do feel that visuals are slightly more responsive and crisper, but honestly, it wasn't worth replacing a bunch of my programs, significantly altering my workflow, and dealing with numerous new issues I didn't have to deal with before.
Unfortunately, the momentum is now fully with Wayland, and it's only a matter of time until X11 stops being supported altogether. The XLibre project is a noble idea, but a few contributors can't maintain an entire ecosystem on their own.
The migration was a one way thing. Lots of things are smoother and simpler, and not having to ever again touch Xorg.conf has improved my quality of life.
To this day, I still have different monitors with different scale factors.
I haven't touched xorg.conf in decades. I suppose you might have to do it to configure some unique setup, but for me this hasn't been an issue in a long time.
Now with Wayland, instead of having to touch a single config file, we have to learn how each compositor/WM is configured, and do it there instead. It hardly seems like an improvement in that regard, IMO.
Unfortunately you will never find yourself in a situation to actually use a mixed dpi X11 setup (you lose your homogeneous desktop) and Wayland is better at spoofing it (for whatever reason fractional scaling works better in Wayland).
http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
My favorite quote from that writeup.
"If you think this idea is a bit stupid, shed a tear for the future of the display servers: this same mechanism is essentially how Wayland compositors —Wayland being the purported future replacement for X— cope with mixed-DPI setups."
That’s not a reason to do it of course, for me the driver was support for multiple monitors with different scaling requirements.
There's a type of input called "DeviceEvent" which is a bit lower level than "Window event". It also occurs even if the window isn't "active".
Windows and X11 support this, but Wayland doesn't except for mouse movement. I noticed my program stopped working on Linux after I updated it. Ended up switching to Window Events, but still kind of irritating.
Meanwhile if you have root you're still free to do so directly.
X11 can't do high refresh rates every time that I've tried to do so.
It will take years to reach the feature set of X11. And for what? From my perspective as both a developer and a user, I see no tangible benefits.
On top of that, it breaks software I rely on professionally. Code that worked perfectly fine under X11.
Meanwhile, I can still build and run Windows programs I wrote 30 years ago on Windows 11.
I am not saying all of the design is corporate-controlled. But a ton of propaganda is associated with how wayland was advertised, until some folks had enough with it and decided to stop buying the "xorg is dead" routine these corporations push on:
https://github.com/X11Libre/xserver
It will be interesting to see what will happen though. The GTK devs said they will help kill off xorg with GTK5. KDE also wants to kill xserver. It would be kind of cool if that would not happen - imagine if a non-corporate controlled ecosystem would emerge. Not likely to happen, but it would be a lot of fun. As well as more real competition with wayland. Wayland broke its biggest promise: that it is a viable alternative to the xorg-server. I don't want to lose any feature, so it is a drawback for me.
But already a majority of Linux desktop users have stopped using it. And it will be 90% in the next 2-3 years. GNOME, KDE, Budgie, and COSMIC are effectively Wayland only now and XFCE and Cinnamon will be Wayland native before then.
The GTK5 devs do not have to “kill off” X11. But it is not really worth their time either.
Keep using Xorg, or Xlibre, or Phoenix. It should keep working.
But don’t mind if the rest of us keep building on Wayland.
By the way, I use Niri, a very cool and absolutely non-corporate Wayland compositor. Not sure how that fits into your narrative.
I'm not anti-Wayland and I think X11 has enough issues that it's worth transitioning over to something better but this is a critical weakness in Wayland's design.
https:/github.com/X11Libre/xserver
Or build on River as this article suggests.
I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.
As a concrete example, Emacs' EXWM package works by implementing an X11 client library in Emacs Lisp, then using it to talk to the X server (which is a separate process, so this works fine) and telling it how to position windows.
Whereas on Wayland, this is not possible without re-implementing a standalone compositor process, because otherwise architecturally it doesn't work. Emacs can't both do the drawing and be drawn.
It's not easy and the major compositors (Gnome, KDE) are NOT wlroots based, making this point mostly moot anyway.
This protocol at least has a chance of using a custom WM with an advanced compositor (which wlroots is not).
I'm glad River is trying to create a bigger base here; this is way cool. And it sort of proves the value of Wayland: someone can just go do that. Someone can just make a generic compositor/display-server now, with their own new architecture and plugin system, and it'll just work with existing apps.
We were so locked in to such a narrow limited system, with it's own parallel abstraction layer to what the kernel now offers (that didn't exist when X was created). It's amazing that we have a chance for innovation and improvement now. The kernel as a stable base of the pyramid, wlroots/sway as a next layer up, and now River as a higher layer still for folks to experiment and create with. This could not be going better, and there's so much more freedom and possibility; this is such a great engine for iteration and improvement.
It's also possible to use hardware planes to get the actual graphics device to composite for you directly from its video memory, effectively reducing latency to the lowest possible.
Are you an AI bot? Modern X11 server using DRM are more than 20 years old. You are talking about how X11 servers worked in the 90's
why? because the compositor completely changed the geometry of the desktop. being 3-dimensional. now, today most wayland compositors are 2 dimensional, but they don't have to be. a window manager that works with a 2 dimensional compositor would not work with a 3 dimensional one and vice versa. the window managers listed in the article are only compatible with this particular compositor.
it seems to me that separating window managers from compositors from the start would have created the expectation that all window managers work on all compositors. that is not and will not be the case.
if all compositors start separating out the window manager then the result would be that as a user i now have to choose two components, a compositor and a window manager, and i have to make sure they are compatible.
The X windows paradigm was fine, and still works great with modern hardware.
X11 was resolution-agnostic from the start, but the ‘desktop Linux’ crowd were so focused on imitating Windows that they ignored Unix lessons and made fixed-resolution toolkits like Windows'.
Touch has been working under x11 for 20+ years (even before the iPhone). I have no idea what you are referring to.
Fractional scaling is a bad idea, and much worse than x11’s native DPI support, which works on multiple monitors.
As for multi-monitor, “forbidden secrets of ancient X11 scaling technology revealed” is a good read. (Offline today?)
https://web.archive.org/web/20250625055403/https://flak.tedu...
Not really. I only need to know how to configure the compositor which I use. I don't need to know how to configure all the other compositors, in the same way I didn't know how to configure all the existing Xorg window managers.
Doing some basic mathematics and xrandr command-line wizardry to apply scaling factors to each display, I was able to get Xorg to render to a virtual framebuffer and treat the monitors as appropriately scaled windows onto it, so that dragging applications from one screen to the other didn't result in any noticeable change in size.
Worked pretty well.
I think x11libre specifically is a little suspicious though. There's nothing wrong with the xorg packages I use today that requires a fork.
You can't expect that everyone will ever be happy, it has never been the case and definitely wasn't when x11 was the default choice.
Despite all that, nothing prevents you to stay on X11 so you have absolutely zero reason to complain.
How does this make any difference if they're going to connect to the same IPC that handles input/display?
The display server must absolutely enforce some kind of security boundary between clients. Clients that are running untrusted code (e.g. a web browser) must not be able to hijacked into controlling a potentially privileged client (e.g. a root terminal).
So it is architecturally possible (but infeasible in plain Emacs Lisp).
For river (the thing this article is about) I wrote an Emacs WM, but also opted for a dynamic module for the Wayland protocol parts: https://code.tvl.fyi/tree/tools/emacs-pkgs/reka
This one could technically be written in plain Emacs Lisp, but I'm happy to use something that already has all the XML codegen stuff for Wayland figured out. Dynamic modules work pretty well, fwiw.
What gets me is how old Wayland is. It's now older than Linux itself was when Wayland started. It started in the era of 2.6 kernel series, when most software was still 32-bit, systemd didn't exist, when Motora Razr was more common than iPhones, when native desktop applications were still the norm, Node.js didn't yet exist and Google Chrome was a completely new beta browser. Wayland is now reaching feature parity and some kind of "it works out of the box, usually" state when it's from a completely different era of computing.
The nearest point of comparison is perhaps systemd, another Linux project that is very large in scope, complicated, critical and must interface well with lots of pre-existing software. Four years after Poeterring's "Rethinking PID 1" post that introduced systemd, it was enabled and in use on many distros. The conservative Debian adopted it within five years. Now it's been clearly a major success, but Wayland has been perhaps the slowest serious software product to be in development.
But say a couple years ago, I definitely had screenshot issues. Sometimes it just wouldn't capture a screenshot. Or I could only capture one monitor and not the other. Or I had graphical artifacts while drawing the snipping rectangle. Or the screenshot would be taken fine and fail to copy to the clipboard.
I'm well aware people's experiences are very different based on their setup and the implementations used but for me, last year was the first time I could do some work on Wayland without running into major issues, at least until I got to the part where I'd normally use ssh -X.
It is very convenient sometimes to access your locked session on big desktop from small laptop, do something, and later go to big desktop physically and unlock "local" termianl and continue with all same programs and windows without starting new session. This scenario were not supported by X11 very well, unfortunately.
You can move the title bar around, and depending on the window manager either double clik to drop down again its contents, or by leaving the mouse pointer for a few seconds hover it, it will temporarly reveal its contents.
It doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol.
Separate process means that the window manager can be written in any language (even, e.g.: Python).
https://en.wikipedia.org/wiki/NeWS
Everything old is new again.
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook:
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
Window Management -- Overview: F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985.
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
James Gosling: SunDew - A Distributed and Extensible Window System.
https://www.chilton-computing.org.uk/inf/literature/books/wm...
The X-Windows Disaster: This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski
X Myths
X is a colletion of myths that have become so widespread and so prolific in the computer industry that many of them are now accepted as “fact,” without any thought or reflection.
Myth: X Demonstrates the Power of Client/Server Computing At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.
Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
Honestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?
It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden.
Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support.
This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again.
Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux.
People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.
I'm personally a KDE user, but I'm with the GNOME folks on this one.
I'm not sure what Windows is like these days, but in MacOS they're patently absurd. My corporate Mac laptop has twelve of the fucking things, and I've never actually had genuine need to click on any of them (and 5 of them are from Apple and so of course use 4 different corner radii between them - the 3rd party ones are at least a little more consistent).
But obviously be pragmatic, if it doesn’t work for you because you have a particular requirement, or even if it doesn’t offer any improvement over what you have then don’t use it.
The setting is still there (or was there until really recently).
And waypipe has been solving this need to run a remote app on a wayland remote system. And it performs way better than X forwarding actually. With ssh -X you also need to remember obscure environment variables (looking at you QT) to not have unusable blank windows on some apps.
To the previous a-hole, frak you: not an AI. That's rude as frak. Also, you manage to be incredibly wrong. Even an AI wouldn't overlook such an obvious error; maybe it'd be better to have it replace you. So rude dude! Behave!
It's vastly deeper than what Wayland does.
Couldn't you stop tearing with a couple lines of code? Don't swap out buffers mid-frame, very simple.
The simple solution doesn't make 144+60 look super smooth, but 120+60 should be almost perfect.
(Hint: It’s not possible to solve correctly.)
Works great.
Ya'll are exhausting. Wayland is the one thing where nerds on the internet will not even bother grabbing a livecd of a linux distro just to try it out and then complain about things that have been implemented for years.
Okay so I STILL have to log in locally before I can log in remotely. Also the list of known issues is pretty concerning. This is in not even close to a remote login solution. You are not accomplishing anything by pretending Wayland is anything more than a half-baked toy at present.
This RDP implementation has clipboard sharing and audio integration. It spawns in a user session but it actually locks the real screens and creates a virtual display. You can make as many virtual displays as you want. In theory you can attach to a single window or rectangular area of the screen. Also it works perfectly fine with SDDM Autologin so you can spawn a display on your server and just auto unlock it.
The project is actually awesome. It's a holistic and far superior RDP solution to anything in the Linux space before.
> Using the wl_seat.get_pointer request, clients may obtain a wl_pointer object. The server will send events to it whenever the user moves their pointer, presses mouse buttons, uses the scroll wheel, etc — whenever the pointer is over one of your surfaces. [...] The server sends this event when the pointer moves over one of our surfaces, and specifies both the surface that was "entered", as well as the surface-local coordinates (from the top-left corner) that the pointer is positioned over.
So the program should know the pointer's local coordinates.