Talk about timing, I took my first plunge into writing code for X just a week or so ago and this was some really good reading. If someone is interested in digging into a non-toy, C codebase I can highly recommended dwm [1,2]. Yes, it is a very opinionated WM, but the code is clean, brief, and hackable – even for someone like me that has not hacked C for anything serious for over a decade – for something that can be used as a daily driver. It only took me about an hour or two to develop two patches that changed the layout to my liking. Plus, I have found the people in #suckless over at the OFTC IRC network to be very kind and helpful.
Keep in mind that DWM explicitly does not obey the ICCCM [0] (because they don't like it), meaning that large groups of applications might function erratically on it. This is not an idle concern -- I've had several bugs reported to me in some applications I've written were because the user wasn't running an ICCCM-compliant WM.
Do you have a link to a bug report? I tried digging around a bit as I got curious how bugs like these would manifest, but could not find anything good to link. What I am aware of is that Java application can break without workarounds (saw it in the documentation somewhere) and that Steam needs an explicit workaround [1].
All java applications refuse to render without said workaround, because AWT expects the WM to reparent its windows. This is IMO a bug in the JRE, because there is no requirement for the WM to reparent.
I use steam on dwm without the steam patch, haven't noticed an issue so far.
Which is highly ironic as the probably only WM written in Java (Project Looking Glass) is not reparenting.
IIRC the issue with AWT and non-reparenting WMs is mostly limited to popup (ie. override-redirect) windows that are positioned in relation to some kind of owner window (which means menus, tooltip popups...). AWT simply expectes that parent window of its window to be the frame window of reparenting WM and calulates the position in respect to that, if there isn't the frame window the position of the popup inside root window will be calculated as if the root window was the frame, which can result in anything from the position being slightly wrong (eg. shifted down by the height of awesome's "menu" bar) to the window being completely off-screen.
I used to write an X11 window managers as a kick-the-tires exercise when learning a new language. The most fun one was Common Lisp with CLX. You could stay in the WM and code it live. When something went wrong you could continue after making fixes. It’s what lead me to Common Lisp being my favorite language going on decades now.
It's quite ardous and unfun, but the wlroots project does most of the heavy lifting. For beginners it's probably useful to create a toy WM using wlroots[0] and dig deeper from there[1].
sway and wlroots have some of the worst error handling I've ever seen in C code. The number of null pointer bugs and assertion bugs is just mind-boggling. I don't really understand how hard it is to just gracefully handle errors. Literally no one would prefer to crash their entire desktop environment rather than have it silently skip over errors and output them to a log.
I recently used i3 again because my office computer has an NVIDIA GPU and sway doesn't support NVIDIA (yes I'm aware of the new GBM API, it's not ready yet and I don't care anymore anyway). It made me realize how much more gracefully i3 handles a lot of things, and also a few things it really doesn't (but that's more the fault of X11, not i3).
It's disappointing that the defacto library for Wayland is wlroots given those bugs.
I don't know where you heard that, but wlroots is not the defacto standard, there are several other libraries. Off the top of my head, there is libweston, mutter, mir, qtwayland, smithay, and probably some others aimed at embedded that I can't remember...
Not sure why this is downvoted. wlroots wants to be a de-facto standard, and the devs have put in a lot of effort to document how to use it. But it's far from a true de facto standard, since most wayland window managers use their own library.
The last time I used wlroots, via sway, I encountered a bug where I experienced 'multicolored snow' when watching a video in firefox. I wanted to record a video of it to report a bug, but of course that wasn't possible because screen sharing / recording still isn't well supported. Back to gnome I went, and I still don't think wayland is ready for primetime on smaller window managers
Most of the concepts here are the same for wayland. The only difference is, Wayland handles compositing, whereas in x11 compositing is a pluggable component.
A Wayland compositor is responsible for quite a bit more than an X11 window manager. Compositing, as you mentioned, but also display modesetting, input handling, clipboard management, and so on. Although, of course, one can use a library like wlroots or libweston to handle most of that stuff if you just want to focus on the desktop experience.
Last time I checked it was work in progress and I'm not sure how complete it is at this moment, but it includes understandable explanations of the low-level algorithms and acceleration structures involved.
Edit: this shows how X works from the lazout and graphical side. One interesting thing that is not covered by this is the somewhat peculiar wire format of X11 connection (it was obviously designed by someone with LISP background).
This is a great article and I remember reading it numerous times while I was implementing my own window manager.
For someone interested in working on a really fun and rewarding hobby project a WM is a great one to look into since there are so many resources starting from really small implementations:
Gradually as you get more familiar with the ecosystem a few questions will come up:
Should I use X11 or XCB? - I personally used XCB and didn't find it too difficult to interface with, and there are a large number of implementations which use it (2bwm, bspwm, ratpoison, etc) so you shouldn't have an issue with learning more about it. But the documentation is pretty limited. If you are just wanting to write a toy WM than X11 is perfectly fine.
X or Wayland? - If you're wanting to write your first WM as a hobby project than I would recommend X over wayland just due to the much larger amount of reference material and documentation. You will have a much easier time getting your feet wet. Ignore the comments about X dying as it doesn't really matter for a hobby project, since the whole point is to have fun.
Feel free to check out my window manager which is an example of what just reading this blog post and getting inspired can result in: https://github.com/cfrank/natwm
I didn't see a bright future for X (and still don't ;) ), so I switched to NeWS, and began writing pie menus and window managers in PostScript.
NeWS (which was James Gosling's creation before Java and after Emacs) was architecturally similar to what is now called AJAX, except that NeWS coherently:
- used PostScript code instead of JavaScript for programming.
- used PostScript graphics instead of DHTML and CSS for rendering.
- used PostScript data instead of XML and JSON for data representation.
Pie Menus and Tab Windows for NeWS in object oriented PostScript:
At Sun, we even used the above code to write an X11 ICCCM "Open Window Manager" in PostScript for X11/NeWS, which wrapped your X11 windows in NeWS tabbed frames with pie menus, implemented in PostScript, the same as all your NeWS windows used, all running in the same address space, and easily centrally customizable and extensible.
>At Sun we experimented with implementing an X11 window manager in NeWS. We didn't have transparency at the time (1992), but we did support shaped windows!
>The NeWS window manager supported cool stuff (for both X11 and NeWS windows!) like rooms, virtual scrolling desktops, tabbed windows, pie menus, was easily extensible and deeply customisable in PostScript, and ran locally in the window server so it could respond instantly to input events, lock the input queue and provide feedback and manipulate windows immediately without causing any context switches or dealing with asynchronous locking, unlocking and event handling. You'd never lose a keystroke or click when switching between applications, for example.
>And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm".
>Don> If you don't want to dump NeWS, then why have you been caused us so much trouble?
>Steve> I could ask you the same question, "If you want NeWS to be a commercial success, why has NeWSTech been so subborn in the sense of resisting trying to fit into the X environment."
>Don> That's not the same question. We want NeWS to be a commercial success, but "commercial success" is not a standard defined by the X Consortium. I think OWM can do a beautiful job of fitting the X environment into NeWS. If you find that concept terrifying, then you know how we feel about the inverse, knowing that we will have to give up many goals we designed for and successfully achieved, in order to accomodate a half assed "fallback" solution to satisfy some of our customers who want to run our competitors' software (because we aren't allowed to make our software good enough for them to want to run).
>We have had a great deal of trouble trying to fit into the X environment. It has taken a huge amount of PostScript code to deal with many X interoperability issues ranging from undocumented selection protocols that XView and OLIT can't even agree on, to input focus grabbing kludges to work around OLWM's incorrect focus tracking behavior, to the fullscreen.ps hack to keep X from grabbing the pointer when NeWS is tracking it. Then there are problems we could do nothing about, like the system locking up when OLWM grabs the server (grabbing the pointer after grabbing the server, and not checking the return value). Many of these problems should have been addressed by fixing X programs or the server, but they were not, instead we had to code around them in PostScript when we could.
NeWS had its own problems, of course, but its biggest problems weren't technical, but political, and it wasn't free despite all the hard effort, spilled blood, and broken promises. But the consequences of that experience did help to make Java free, eventually. (But then Oracle later ruined worse than Sun ever could have.)
>James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS: [...]
>"We'll get it out, even if I have to spill some real blood on the floor." -James Gosling, on freeing NeWS, March 6, 1990
>[...] It has been very clear for a long time that DEC explicitly targeted
NeWS as something to be trashed. That was probably the major reason
for giving NeWS such a ridiculously low profile. There were folks at
sun who didn't want to give DEC a bigger target. The folks running the
show now have more guts.
>I have been hoping for Sun to make Open Windows free since it was
called SunDew, and during that time, I've made it perform many
indescribable acts (both on and off stage), worked with quite a few
companies trying to make it a succeess, and drained much much more of
my energy than I ever knew I had to give into that incredible piece of
software.
>I have been following the messages on the network in the aftermath of
the OWPS "free for $1000" disaster... The big problem was not the
$1000. It was the word "free".
nitpick but X11 is the protocol XCB speaks. You're probably speaking of Xlib which is a bit of a higher level library over the top of it (but... not really that much higher, for a great many tasks there's no real difference).
>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
Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend):
"[Footnote: We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such as database service or computational service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the application is running,” and when you see “Server” think “the local machine that displays output and accepts user input.”]"
Still having problems with the difference between a client and a server, eh?
P.s. I'm starting to view this article the same way Tesla did the Top Gear review episode: it was cute the first time, but...
I don't get what you point is. What problem or confusion do you think I have with the difference between the terms "client" and "server", and are you blaming me that a remote X-Windows client is called a "client" and a remote web server is called a "server"? Or is it my fault that web "servers" and web browser "clients" are called the other way around than X-Windows "clients" and X-Windows "servers"? Or are you just offended that I pointed out that fact?
The fact that the web finally ended up the way it did, with a so-called "AJAXian" architecture using JavaScript in the web browser (and often the web server too) (not to mention the PostScript Stencil/Paint imaging model in canvas), instead of a fixed protocol like X-Windows (stuck with its terrible obsolete imaging model), certainly proves my point that NeWS's architecture of sending code instead of a fixed protocol like X-Windows is by far the superior, more efficient, future-proof, open-ended architecture.
The term "AJAX" was coined in 1999, but NeWS (aka SunDew) was doing it in 1985, 14 years before the term "AJAX" was coined in 1999. And X-Windows still isn't doing it, 37 years after James Gosling originally proposed that architecture in his paper describing SunDew.
>NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
>used PostScript code instead of JavaScript for programming.
>used PostScript graphics instead of DHTML and CSS for rendering.
>used PostScript data instead of XML and JSON for data representation.
I worked on the display driver for the NeWS version of Gosling/UniPress Emacs, and also on the NeWS display driver for Gnu Emacs, and thanks to NeWS's ability to download code that implements application specific protocols, both versions of Emacs ran quite smoothly, efficiently, and responsively over slow dial-up modems, ISDN, and the slow internet connections of the late 80's - early 90's.
Here's an email I sent to James Gosling in 1988 describing how the Emacs display driver I implemented for UniPress Emacs 2.20 works, by providing smooth live text selection feedback without requiring client/server round trips every time the mouse moves, as well as interactive pie menus and tabbed windows, all implemented in PostScript in the NeWS server:
>Hi! I'm working on Emacs this summer at Unipress. It now supports
menus, and text selection, with rubber banding in the server. It
works, and is much fun to use, but I have a few questions about
getting it RIGHT!
>When you initiate a selection by clicking with the mouse, emacs
replies with an array of the line widths in the current window, and
the row of the window's top line. Some code I stole from nterm rubber
bands an outline around the text as you drag around the window. I
modified it to show that a line's trailing newlines was selected by
drawing the right edge with an arc or a slant.
>[...] Other stuff we're working on include a menu compiler, which compiles
nested menus described as linked info nodes into PostScript code and
MLisp key bindings. (Menu keys are assigned keystroke sequences, with
keytop names that identify them, which are bound to MLisp functions.
Menu keys can invoke submenus or do anything else you want, too.) So
you can make menus without touching PS or MLisp! The menus all run in
the server, so you can type into the emacs underneath while you're in
the middle of completing a menu selection. I changed getmenuaction to
execute executable keywords, to support indirect submenu references,
and magic functions that decide the submenu or menu action.
>[...] I made a class of window that has thin borders, and a little handle
sticking out the top right with its FrameLabel -- you can have a bunch
of them overlapping, and their names all stick out to the right, where
you can click on them to bring them to the top or get a frame menu.
They work really well with multiple emacs frames!
>Thanks for all the neat toys!
Here's a screen snapshot of that code running, from the wikipedia page about tabbed windows:
Also, in case you weren't aware, a single X-Windows "client" can have simultaneous connections to multiple X-Windows "servers", in the same way that a single web "server" can have simultaneous connections to multiple web "browsers".
A good example is SimCity (aka multi player SimCityNet and open source Micropolis), which is a commercial product that I developed for NeWS in PostScript, for X-Windows in TCL/TK (later releasing a single player version as Micropolis for the OLPC), and a multi player open source version for web servers in Python (whose distributed client/server "AJAXian" architecture was most similar to the original NeWS version, no matter how you label the client and server).
The TCL/Tk/X11 version of multi player "SimCityNet" supported simultaneous connections to several players on different (or the same) X-Windows servers at once, so they could play together in the same city.
Product Announcement: Multi Player SimCity for X11 is now available from DUX Software! (1993):
Multi Player SimCityNet for X11 on Linux. Demo of the latest optimized Linux version of Multi Player SimCity for X11. Ported to Unix, optimized for Linux and demonstrated by Don Hopkins:
Micropolis Online (multi player SimCity running on a web server in Python) web demo. A demo of the open source Micropolis Online game (based on the original SimCity Classic source code from Maxis), running on a web server, written in C++ and Python, and displaying in a web browser, written in OpenLaszlo and JavaScript, running in the Flash player. Developed by Don Hopkins.
Unfortunately the support for multi-player applications in X-Windows toolkits like TCL/Tk was buggy and incomplete, so I had to fix it for SimCityNet, and the support for security and authentication in X-Windows is STILL abysmally terrible, so I had to drop the multi player feature from the OLPC version of Micropolis, because I wouldn't want to require children to type "xhost +" or enter hexadecimal magic cookies and ip addresses to play a game.
But it was much safer and easier to implement a secure multi player game in Python on a web server over https to multiple simultaneous web browsers.
Here's the Python source code of the web server, which uses the C++ reimplementation of SimCity called MicropolisCore via SWIG wrappers:
And to demonstrate what I mean by downloading procedural code implementing custom compression protocols between client and server instead of using a fixed protocol, and communicating using efficient application specific protocols instead of rigid fixed protocols like X-Windows, here is a concrete example you can see for yourself.
This is the server side of the tile compression protocol: GetTileData returns a buffer of compressed tile differences (of only the tiles the user can currently see) to send to the browser, which is further optimized to support SimCity's notion of "animated tiles", so it doesn't even have to send deltas for tiles that are automatically animate in the client, or outside of the user's scrolling view:
The resulting distributed real time animated user interface is quite snappy and responsive over the network (especially the pie menu, which track input, interact, and display feedback locally, and only send messages to the server upon completion), as you can see in the demo video above.
Are you following along so far? This "AJAXian" architecture is precisely what James Gosling was writing about 36 years ago in 1985, when he described the client interaction of "SunDew", which was later renamed "NeWS":
>Client interaction with the window system can be broken down into three layers: messages that get passed between the window system and the client, the programs that are contained in the messages, and a procedural interface to program construction. This is one of the key unique points about this window system: clients send programs to the window system whose elaboration causes graphic operations to appear. The client program does not send graphic operations directly. There is, of course, a procedural interface to program construction that blurs the distinction.
>This approach allows the client to redefine the protocol to compress messages passed to the window system. For example, if the client wishes to draw a grid it can download a procedure which iteratively draws the lines, generating their coordinates as a function of the loop index. This is a substantial compression over transmitting a large set of lines, even if the grid is drawn only once. There are other performance advantages: message-passing interactions are relatively slow and downloading a procedure that will respond locally eliminates this overhead. For example, if a client program needs rubber band lines, then rather than have the window system send a message to it each time the mouse moves, it can download a procedure that will track the mouse locally.
>There are a number of features of PostScript that make it attractive. It is very simple, and it is complete. Its simplicity makes it fast to translate and interpret - this can almost be done as quickly as packets can be disassembled in a more traditional IPC environment. Adobe did a very good job of designing a set of primitives and data structures that fit together well. Its chief drawback is that it can be hard for people to understand; the postfix notation is well-suited to consumption and generation by programs, but humans find it obscure.
>It is important to think about the client programmer's model of what the window system does. We expect there to be two levels of model. The first completely hides the existence of PostScript with a veneer of procedure calls that construct and transmit fragments of PostScript programs. The second exposes PostScript. Beyond a certain level of functionality, learning PostScript is inevitable: it can be pushed off by making the veneer more comprehensive, but this just makes the eventual leap harder.
Wow. You're more verbose than I am. I'm impressed.
<Puts on network-protocol-guy hat>
A "server" is a program (loosely speaking) that provides a service. Typically, it is more long-lived than a client, starting before the client, awaiting requests from one or more clients, and continuing after a client goes away. A canonical server is an old-style print server: it's a program that is started on the machine attached to a printer, it awaits requests from clients (those requests including that PostScript that describes what the printed page is supposed to look like), and it multiplexes access to the printer.
A "client" is a program (again, loosely speaking) that requests services from a server. It is typically shorter-lived and performs the active steps of making requests to a server.
You will note that there is nothing about "local" or "remote" machines in these definitions. There is also nothing about the number of servers a client can request services from, nor even whether a server can itself be a client of another server. (But do not ever use CORBA or any other RPC mechanism for that kind of thing. It is not worth the pain. In fact, just skip RPC stuff. Bleah.)
Now, the X server is a server; it starts up, takes over the display and input devices and waits for clients to connect. X clients connect to the server to make requests, either to display some pretty colors or whatever or to request notification of events, as the server is multiplexing input devices to multiple clients. Simple?
I've never had any reason to use Wayland or desire to learn much about it, so I can't tell you anything technical or from first hand experience.
But I think we have X-Windows to thank for the fact that most Unix programmers use Macs now.
And it's way too late for Wayland to change that fact. Especially with the release of the M1 Max. That ship has sailed.
It didn't matter how much better NeWS was than X-Windows -- it still lost despite all its merits.
And I don't see Wayland as being any more better than X-Windows, than NeWS was better, decades ago.
So simply "being better than X" is not sufficient to displace it, and Wayland isn't even that much better than X, and is even worse in some ways.
The fact that it didn't occur to the Wayland designers to make it extensible with an embedded scripting language like PostScript in NeWS or Lisp in Emacs or Python in Blender or Lua in Redis or JavaScript in web browsers means that it was obsolete from the start, and its designers should have considered the design and architecture of NeWS and Emacs and Blender and Redis and web browsers before designing Yet-Another-X-Windows-Clone. It's not like those ideas were secret, or patented, or hard to find, or wrong.
The world moved up the stack a layer to the web browser, and that's where all the excitement's happening these days, not in the window system layer.
Why have X-Windows or Wayland at all, when you could just run the web browser itself directly on the hardware, as efficiently and flexibly as possible, and implement all your user interface, window management and desktop stuff with modern open standard JavaScript / WebAssembly / JSON / XML / HTML / SVG / CSS / Canvas / WebGL / WebGPU / HTTPS / WebRTC?
I've written about this numerous times before, but I'll transclude and reorganize some of it with checked and updated archive urls to save you the pointing and clicking:
>colanderman>And this is my primary issue with Wayland. I cannot fathom why anyone would think it's a sound design decision to bundle a hardware-independent component (the window manager) with a hardware-dependent component (the compositor). This hearkens back to the days of DOS video games – what fun it was to implement support for everyone's sound card! Instead now we'll get to support KMS, Quartz, whatever-the-heck BSD uses, etc.
>Just put a JavaScript (or whatever) interpreter in the window server, and program the window manager locally in that. Then you aren't fucked by synchronization issues. James Gosling did something like that with PostScript many years ago, an alternative to X11, which was then merged with X11, and it was called NeWS (and later X11/NeWS or OpenWindows):
>I've written several window managers / user interface toolkits / tabbed window frames / menu system in PostScript for NeWS. We even wrote an X11 window manager in PostScript, complete with rooms, scrolling virtual desktop, tabbed windows, pie menus, and seamless integration of X11 and NeWS windows.
>Having the window manager running as an outboard process, communicating via an asynchronous protocol, is a terrible idea, but is baked into X11 at a very low level -- with the ICCCM thrown in as a kludgy afterthought. The X11 protocol has hacks and band-aids like "mouse button grabs" and "server grabs" to mitigate the problems, but they cause a lot of other problems, complexity and inefficiencies on their own.
>That's exactly the point of using HyperLook as a window manager, which we were discussing at Sun in 1991 before they canceled NeWS.
>HyperLook, which was inspired by HyperCard, but written in PostScript for the NeWS window system, let you build specialized task-oriented user interface by assembling and customizing and scripting together components and applets into their own "stacks".
>HyperLook (which ran on NeWS, and was like a networked version of Hypercard based on PostScript) was kind of like looking outwards through windows, in the way Rob Pike described the Blit (although it was architecturally quite different).
>I think his point was that window frames should be like dynamically typed polymorphic collections possibly containing multiple differently typed components that can change over time (like JavaScript arrays), not statically typed single-element containers that are permanently bound to the same component type which can't ever change (like C variables).
>With X11, the client comes first, and the window manager simply slaps a generic window frame around it, subject to some pre-defined client-specified customizations like ICCCM properties to control the window dressing, but not much more, and not under the control of the user.
>With HyperLook, the "stack/background/card" or window frame came first, and you (the user at runtime, not just the developer at design time) could compose any other components and applications together in your own stacks, by copying and pasting them out of other stacks or warehouses of pre-configured components.
>For example, I implemented SimCity for HyperLook as a client that ran in a separate process than the window server, and sent messages over the local network and drew into shared memory bitmaps. SimCity had its own custom frames ("screw-up windows") that looked more "mayoral" than normal windows.
>There were multiple map and editor views that you could copy and paste into other stacks while they were running, or you could copy widgets like buttons or drawing editors into the SimCity stack while it was running. So you could copy and paste the "RCI" gauge into your graphics editor window to keep an eye on it while you worked, or paste a clock into your SimCity window to see when it was time to stop playing and get some sleep. And you could even hit the "props" key on the clock to bring up a PostScript graphics editor that let you totally customize how it looked!
>It had "warehouse" stacks containing collections of pre-configured component prototypes (including widgets, applets, and window management controls like close buttons, resize corners, navigation buttons, clocks, graphics editors, etc) that you could copy and paste into your own stacks, and which would automatically be listed in the "New Object" menu you get in edit mode, to create them in place without opening up the warehouse:
>Normal X11 window managers put the cart before the donkey. The window frames are generic, stupid and unscriptable, and can't even be customized by the user, or saved and restored later. The client comes first, with just one client per generic frame. You can't move or copy a widget or panel from one frame to another, to use them together in the same window. That's terribly limited and primitive.
>We implemented a more-or-less traditional (but better than normal) ICCCM X11 window manager in PostScript for X11/NeWS, which had tabbed windows, pie menus, rooms, scrolling virtual desktop, etc, uniformly for all NeWS apps and X11 clients. But the next step (not NeXT Step) was to use HyperLook to break out of the limited one-client-per-frame paradigm.
>(It's interesting to note that David Rosenthal, the author of the ICCCM specification, was also one of the architects of NeWS, along with James Gosling.)
>Our plan was to use HyperLook to implement a totally different kind of integrated scriptable X11 (and NeWS) window manager, so you could compose multiple X11 clients into the same frame along with HyperLook widgets and scripts. You could integrate multiple X11 clients and NeWS components into fully customizable seamless task oriented user interfaces, instead of switching between windows and copying and pasting between a bunch of separate monolithic clients that don't know about each other. But unfortunately Sun canceled NeWS before we could do that.
>Here's some more stuff I've written about that stuff, and how window managers should be implemented today in JavaScript:
>That's how I implemented tabbed windows in 1988 for the NeWS window system and UniPress Emacs (aka Gosling Emacs aka Evil Software Hoarder Emacs), which supported multiple windows on NeWS and X11 long before Gnu Emacs did.
That seemed to me like the most obvious way to do it at the time, since tabs along the top of bottom edges were extremely wasteful of screen space. (That was on a big hires Sun workstation screen, not a tiny little lores Mac display, so you could open a lot more windows, especially with Emacs.)
>It makes them more like a vertical linear menu of opened windows, so you can real all their titles, fit many of them on the screen at once, and you instantly access any one and can pop up pie menus on the tabs to perform window management commands even if the windows themselves are not visible.
>But now that there's another Web Browser layer slapped on top of X-Windows (and the terms "client" and "server" switched places), you're stuck with two competing mutually incompatible window managers nested inside of each other, one for the outside frames around apps, and one for the inside tabs around web pages, that don't cooperate with each other, and operate uncannily differently.
>So none of your desktop apps benefit from any of the features of the web browser (unless they include their own web browser like Electron).
>And you can't write lightweight apps in a couple pages of script like "Big Brother Eyes" that run in the shared window server, without requiring their own separate external app with a huge runtime like Electron.
>Nor can you easily integrate desktop applications and widgets and web pages together with scripts, the way HyperCard, OpenDoc, CyberDog and HyperLook enabled.
>>Now Firefox and Chrome still need decent built-in universally supported and user customizable pie menus, but unfortunately the popup window extension API is inadequate to support them, because there's no way to make them pop up centered on the cursor, or control the popup window shape and transparency. Unfortunately they were only thinking of drop-down linear menus when they designed the API. (Stop thinking inside that damn rectangular box, people!)
>>But I remain hopeful that somebody will eventually rediscover pie menus in combination with tabbed window for the web browser, and implement them properly (not constrained to pop up inside the browser window and be clipped by the window frame, and not just one gimmicky hard coded menu that user's can't change and developers can't use in their own applications). But the poorly designed browser extension APIs still have a hell of a lot of catching up to do with what it was trivial to do in NeWS for all windows 30 years ago.
>And this is why a modern window manager should be written in JavaScript, leverage HTML, Canvas and WebGL, and support Accessibility APIs, as well as screen scraping, pattern recognition, screen casting, virtual desktops, overlays, drawing and image composition, input event synthesis, journaling, macros, runtime user customization and scripting, programming by demonstration, tabbed windows, pie menus, etc:
>[...] About 5 years ago I opened this issue, describing an experiment I did making the web browser in a topmost window with a transparent background to implement user interface overlays scripted in HTML.
>WebView window for HTML user interfaces like pie menus to Slate. #322:
>Slate used a hidden WebView for its scripting engine. So I made it un-hidden and float on top of all the other windows, and was easily able to use it to draw any kind of user interface stuff on top of all the other Mac windows. And I could track the position of windows and draw a little clickable tab next to or on top of the window title bar, that you could click on to pop up a pie menu.
>It actually worked! But I didn't take it much further, because I never got any feedback on the issue I opened, so gave up on using Slate itself, and never got around to starting my own JavaScript window manager myself (like you did!). I opened my issue in June 2013, but the last commit was Feb 2013, so development must have stopped by then.
>[...] Think of it like augmented reality for virtualizing desktop user interfaces and web pages.
>[...] So I adapted the "uwm" window manager to support pie menus, so you could define your own pie menus and linear menus in your .uwmrc file. Because a window manager could really benefit from pie menus: lots of the commands are spatially oriented and can be arranged in appropriate mnemonic directions, and they have a fixed set of common window management commands that can be thoughtfully arranged into a set of efficient pie menus, as well as a menu definition language to enable users to create custom menus for running apps, connecting with remote hosts, etc.
>[...] I had been using Mitch Bradley's "Forthmacs", which was a very nice Forth system for the 68k. (It eventually evolved into the Sun 4 Forth boot ROMS, OpenFirmware, and the OLPC boot ROMs). It was capable of dynamically linking in C code (well not dll's or shared libraries, but it would actually call the linker to relocate the code to the appropriate place in Forth's address space, read in the relocated code, and write Forth wrappers, so you could call C code from Forth, pass parameters, etc -- SunOS 4.2 didn't have relocatable shared libraries or light weight threads back then, so Forth had to do a lot of the heavy lifting to plug in C code. But Forth was a really great way to integrate a library into an interactive extension language, call it from the Forth command line, build on top of C code in Forth, call back and forth between C and Forth, play around with it from the Forth command line, etc).
>Inspired by HyperCard, we (old Sun NeWS hands) also pleaded until we were blue in the face to make HyperLook (a NeWS/PostScript/network based reinterpretation of HyperCard) the window manager / editable scriptable desktop environment!
>“I thought NeWS was ‘the right way to go’ (except it missed the live system underneath). It was also very early in commercial personal computing to be able to do a UI using Postscript, so it was impressive that the implementation worked at all.” -Alan Kay
>What’s the Big Deal About HyperCard?
>"I thought HyperCard was quite brilliant in the end-user problems it solved. (It would have been wonderfully better with a deep dynamic language underneath, but I think part of the success of the design is that they didn’t have all the degrees of freedom to worry about, and were just able to concentrate on their end-user’s direct needs."
>"HyperCard is an especially good example of a system that was “finished and smoothed and documented” beautifully. It deserved to be successful. And Apple blew it by not making the design framework the basis of a web browser (as old Parc hands advised in the early 90s …)" -Alan Kay
>HyperLook was so far ahead of its time in 1989, that there still isn't anything quite like it for modern technology. Since we developed HyperLook and SimCity at the same time, that forced us to eat our own dog food, and ensure that HyperLook supported everything you needed to develop real world applications. (Not to imply that SimCity is a real world! ;)
>This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames.
>Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition.
>Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager!
>>You can't do opengl efficiently over the network. At least xorg can't. Most applications uses opengl these days.
>Sure you can, it's just called WebGL! ;)
>They just added another layer, flipped the words "server" and "client" around, and added more hardware.
>Now you run the web browser client on top of the local window system server, through shared memory, without using the network. And both the browser and GPU are locally programmable!
>And then the local web browser client accesses remote web servers over the network, instead of ever using X11's networking ability.
>One way of looking at it in the X11 sense is that a remote app running in the web server acts as a client of the local window server's display and GPU hardware, by downloading JavaScript code to run in the web browser (acting as a programmable middleman near the display), and also shader code to run in the window server's GPU.
>Trying to pigeonhole practices like distributed network and GPU programming into simplistic dichotomies like "client/server," or partition user interface programming into holy trinities like "model/view/controller," just oversimplifies reality and unnecessarily limits designs.
>Imglorp> Hi Don! Tabs aside, NeWS got so many things right, and not just at the UI but the underlying idea of code instead of bitmaps. I wonder if we were going to start afresh with Wayland/X11 now, bare hardware, what place do you think the NeWS lessons would have? Would a modern NeWS be on top of PS or is there something better now?
>Hi Imglorp!
>Simply use a standard JavaScript / WebAssembly / WebGL / Canvas / HTML based web browser as the window system itself! And use WebSocket/SocketIO/RTP/HTTP instead of the X-Windows or VNC protocols.
>Microsoft kinda-sorta did a half-assed inside-out version of that with Active Desktop, but Internet Explorer wasn't powerful or stable enough to do it right, and it didn't eliminate and replace the whole Win32 / MFC layer, which misses the main point.
>There was recently this discussion about a browser based Mac window manager project (now offline), and there have been others like it (Slate), but the ideal goal is to completely eliminate the underlying window system and just use pure open web technologies directly on the metal:
>Show HN: Autumn – A macOS window manager for (Type|Java)Script hackers (sephware.com):
>I was also quite inspired by Slate. Unfortunately there hasn't been any activity with it for about 5 years or so. It's great you're picking up the mantel and running with it, because the essential idea is great!
>It would also be great to flesh out the accessibility and speech recognition APIs, and make it possible to write all kinds of intelligent application automation and integration scripts, bots, with nice HTML user interfaces in JavaScript. Take a look at what Dragon Naturally Speaking has done with Python:
>I would like to discuss how we could integrate Prefab with a Javascriptable, extensible API like aQuery, so you could write "selectors" that used prefab's pattern recognition techniques, bind those to JavaScript event handlers, and write high level widgets on top of that in JavaScript, and implement the graphical overlays and gui enhancements in HTML/Canvas/etc like I've done with Slate and the WebView overlay.
>Video: Prefab: What if We Could Modify Any Interface? Target aware pointing techniques, bubble cursor, sticky icons, adding advanced behaviors to existing interfaces, independent of the tools used to implement those interfaces, platform agnostic enhancements, same Prefab code works on Windows and Mac, and across remote desktops, widget state awareness, widget transition tracking, side views, parameter preview spectrums for multi-parameter space exploration, prefab implements parameter spectrum preview interfaces for both unmodified Gimp and Photoshop:
>PDF: A General-Purpose Target-Aware Pointing Enhancement Using Pixel-Level Analysis of Graphical Interfaces. Morgan Dixon, James Fogarty, and Jacob O. Wobbrock. (2012). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '12. ACM, New York, NY, 3167-3176. 23%.
>Video: Content and Hierarchy in Prefab: What if anybody could modify any interface? Reverse engineering guis from their pixels, addresses hierarchy and content, identifying hierarchical tree structure, recognizing text, stencil based tutorials, adaptive gui visualization, ephemeral adaptation technique for arbitrary desktop interfaces, dynamic interface language translation, UI customization, re-rendering widgets, Skype favorite widgets tab:
>PDF: Content and Hierarchy in Pixel-Based Methods for Reverse-Engineering Interface Structure. Morgan Dixon, Daniel Leventhal, and James Fogarty. (2011). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '11. ACM, New York, NY, 969-978. 26%.
>Video: Sliding Widgets, States, and Styles in Prefab. Adapting desktop interfaces for touch screen use, with sliding widgets, slow fine tuned pointing with magnification, simulating rollover to reveal tooltips:
>PDF: Prefab: Implementing Advanced Behaviors Using Pixel-Based Reverse Engineering of Interface Structure. Morgan Dixon and James Fogarty. (2010). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY, 1525-1534. 22%
>PDF: Prefab: What if Every GUI Were Open-Source? Morgan Dixon and James Fogarty. (2010). Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI '10. ACM, New York, NY, 851-854.
>Today, most interfaces are designed by teams of people who are collocated and highly skilled. Moreover, any changes to an interface are implemented by the original developers and designers who own the source code. In contrast, I envision a future where distributed online communities rapidly construct and improve interfaces. Similar to the Wikipedia editing process, I hope to explore new interface design tools that fully democratize the design of interfaces. Wikipedia provides static content, and so people can collectively author articles using a very basic Wiki editor. However, community-driven interface tools will require a combination of sophisticated programming-by-demonstration techniques, crowdsourcing and social systems, interaction design, software engineering strategies, and interactive machine learning.
Funny, yesterday someone posted an article about an Ada-based X implementation, and I thought “could be fun to write my own X”. I guess I wasn’t the only one!
In general, wayland does not implicitly have a distinction between server and window manager. There is a server and there are clients. The server gets to decide where a particular client's windows are rendered. Wayland itself is just a spec of the protocol that the client and server use to talk to each other - the format of the messages, and a few documents that describe various such messages. What the server does is basically completely arbitrary.
I don't know about GNOME and KDE's wayland servers, but with sway and river and cage the server is a single process that does the job of both server and window manager. It doesn't mean everyone has to write the equivalent of an X server, ie code that interacts with OpenGL and the kernel interfaces, themselves - there is a popular library called wlroots that can be used for that.
I don't think it's impossible that someone wraps wlroots into a standalone "server" binary that then has its own protocol for talking to an arbitrary "window manager" binary at runtime. ie do the equivalent of what wlroots does with function calls and callbacks at compile time but at runtime via IPC. But I don't know anyone who's doing such a thing.
People have already mentioned wlroots as a starting point, but there is a less opinionated and more compatible (NVIDIA-ready) library that I’m really quite fond of called Mir: https://github.com/MirServer/mir
One thing to note, Wayland, unlike X, does not support server side decorations yet, so compositor’s responsibilities are mostly just placing windows.
This article is about writing an X11 window manager, which is a different piece of software. An XWM is an X11 client. Writing an X11 server is a much more involved effort (there's a reason why there's only one widely used implementation, Xorg).
2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver (https://wiki.freebsd.org/Graphics/Wayland), though work has been done getting Wayland compositors and other software to work on FreeBSD. I use X11 on my FreeBSD desktop. I'm unfamiliar with the current status of Wayland on NetBSD and OpenBSD. I expect X11 to live on for quite some time in the BSD world and among more conservative Linux users, similar to the situation regarding systemd in the Linux community, which was adopted by mainstream distributions and users but faced (and still faces) opposition from some users.
I've been using Wayland and Sway with FreeBSD 13 quite successfully. Everything worked quite well, except some indicators in Waybar that were using some Linux specific things to get values for memory usage etc...
WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.
There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.
Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland.
Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work
Some relevant links for those curious about other people hitting into this:
>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
Qt runs on platforms where there is literally only a kernel + the Qt app running, through for instance EGL for rendering. So it has to have its own way.
I don't have a second monitor right now to double check, but I have this in a script for our office monitors to get a different dpi for one display (named eDP-1):
The final "composing" step in Wayland does require Wayland to use a "giant" buffer as well. Also My GPU has 16 GB of GDDR how can any frame buffer be "giant" in that context?
The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.
You really don't want to use Xrandr information to do scaling, it's not accurate. A better way would be to set a property on the window and have the compositor read that, AFAIK this is the solution that the Kwin developers were working on.
What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow.
One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors.
Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...
You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
> The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI.
The word "properly" here is quite subjective, though. I have a similar setup, combining monitors of different pixel sizes.
It works properly with Xorg: When I move a window of size WxH pixels from one monitor to another, it remains a window of WxH pixels. A thin line of one pixel width remains so. A checkerboard pattern that tingles the monitor refresh rate remains so. This sounds like perfectly appropriate behavior, and anything else would be ridiculously inappropriate. I accept that this usage of "appropriateness" is subjective to a subset of people that includes me, but it may not be universal.
Whatever, this is such a thin point for Wayland: hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. But hey! you can combine monitors of different pixel size as if they had the same pixel size! See, the thing transparently re-scales your windows using cheap-ass bilinear interpolation so that they get the exact same size in millimeters! Fancy, isn't it?
> hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before.
Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype.
Which apps don't support Wayland? The only ones on my machine that need XWayland are some video games and FLTK apps like Dillo (I have to test with xwininfo since it's normally impossible for me to notice if a program is using XWayland). All GTK/Qt apps work OOTB on Wayland as a first class citizen, especially since those toolkits nowadays receive more Wayland testing than X11 since barely any current distros still ship X in their default installations.
Which Wayland compositor/version and GUI toolkit/library gave you blurry bilinear filters?
> barely any current distros still ship X in their default installations.
Bold statement. Citation needed? Debian does, and that's hardly a small percentage of market share. I guess if you include Android as a Linux distribution then you might be correct.
Debian 10, Debian 11, OpenSUSE, Fedora, RHEL 8, Ubuntu, and others ship GNOME on Wayland by default right now. It receives better support than the X version.
KDE upstream is also Wayland by default which is reflected in the KDE version of OpenSUSE, the Fedora KDE spin, and Fedora Kinoite.
Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right?
In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes.
I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal.
Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone.
It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)
You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland. (Those apps use something called XWayland, which is blurry if the user has configured a non-standard size for things.) 99.9% of fonts these days, most icons provided by the OS, and most other graphical elements (e.g., rounded corners) are specified as mathematical descriptions of curves that can be rendered at the display's native resolution regardless of what size the user chooses them to be. (I believe the 0.1% of fonts that are not mathematical descriptions of curves are called bitmap fonts.)
Note that I am not talking about multiple displays, but rather a single display, but the user wants things to be bigger than they are by default.
I know this because have used all 3 major operating systems recently (MacOS, Windows 10 and Linux/Gnome) on plain-old 96-DPI monitors such that if there were any interpolation or scaling algorithm I would be able to see the effects.
On a monitor 1680 pixels wide, Gnome gives me a choice of the scaling factors 100%, 125%, 150%, 175% and 200%. On a monitor 1920 pixels wide, Windows 10 gives me a choice of the scaling factors 100%, 125%, 150% and 175%. Some apps are blurry as hell, but on both Windows and Gnome I was able to live my life using only those apps that don't have the blurriness problem, but then I am not forced to use old Windows apps provided or specified by my employer and don't need to share my screen (which I am told does not work yet on a pure-Wayland set-up like mine).
On Windows 10, I used Google Chrome, some apps such as Settings and Timer provided as part of the OS and VS Code. On Linux I used (and continue to use) Google Chrome, modern Gnome apps and Emacs. On Linux, I need to open Chrome with specific flags to get it to be non-blurry while the visual elements are a non-standard size, and I need an Emacs built from a git branch called feature/pgtk. Both apps have some bugs when used in this way, but the bugs are definitely live-with-able, and I expect the bugs to be fixed eventually.
> You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland.
This can be true only if you use a really narrow definition of "apps adapted for Wayland". For example, a viewer of png files may not be possible to adapt to wayland? A png file is just an array of pixels (typically without a meaningful dpi). How are you going to ever display it without interpolating and resampling?
Yeah. I suppose this functionality isn't everyone's cup of tea. The cool thing about Wayland though is somehow it makes the windows still look crisp and good while making them the same size. With the canonical hack to xorg, they always looked blurry and gross. The gnome wiki had this to say on it:
"On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor."
So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.
Then what is your complaint? No one is stopping you from using X for as long as you like. Meanwhile the majority of users that want sane, modern handling of HiDPI can move on.
What complaint? Why do you think I'm complaining? I wanted to know what's so fundamentally wrong with X to warrant a massive developer effort to replace it.
Based on the comments here, I have my answer: Nothing's wrong with X. Also, something lighter weight is desired for embedded platforms.
Some fraction of the population, like you, wants their display system to render in terms of points, not pixels. To me, and many others, this would be hell, but hey, different strokes for different folks -- good software does what the user wants, not the developer's will.
> ...majority of users that want sane...
You troll. :P I think the majority of users want sane display systems that don't resample and change resolutions away from the native resolution of the hardware. To you, the majority of users want fuzzy text and ugly UIs. We're both wrong to assert this as some obvious fact, because neither of us speak for any user but ourselves!
If I have any complaint (which, again, I'm not sure if I do!) it's that I don't appreciate my reliable computing setup breaking just because some young developer decided the programs I use are "too old".
if you buy a high pixel density display (ex a 15 inch laptop with a 4k display) then you need to be able to map 2 real pixels to 1 logical pixel (what apple did with retina displays)
And this works perfectly fine already with X11. You only encounter issues when you add an additional display with different DPI. But dual monitor setups are the exception, and mixed DPI setups are even less common.
Mixed DPI setups are very common. A Retina Mac getting docked to external monitors of different DPI is tremendously common all over the place. Ironically on the Windows side I see tons of non HiDPI laptops that end up docked to higher DPI external monitors, but the other direction isn’t exactly rare either. Even if you don’t use those monitors simultaneously - this is still mixed dpi for all the apps that are currently running.
This does not work smoothly at all in X11. This is a mixed bag with Windows because of reasons that are well documented. The compromise chosen by Apple works reasonably well.
This is not about my personal preferences unlike the GP asserts, it’s based on observing hundreds of deployments in industry and academia - which both Apple and Microsoft are very much aware of - they don’t try to support these features for no reason at all. I personally don’t love the scaling done by Mac OS, and in an ideal world apps would just magically scale geometry and “do the right thing”, but that is a fantasy land and the best FLOSS unix has to offer with X11 does not meet a lot of users needs.
As for nothing wrong with X? Lol this is a display system that still does not have a sane unified way to prevent screen tearing - despite 30 years of shitty attempts.
Basically it is the same for Win 10. It insists on using small fonts on my laptop so i have to scale it. In the golden age you could tell X the size of your screen.
Thank you! No idea why your comment is so low. Most educational one here.
I enjoyed reading that link -- a fact oriented list, directly answering my question, rather than an assumption that I want eye candy or resampled resolutions. Fixing the input subsystem alone feels like a compelling reason to use Wayland. It's also interesting to me that the list doesn't mention DPI, which seems to be of great concern here. :>
Having read that, I'm much less terrified, though it does mean I probably will have to take the time to write a window manager for Wayland. Thanks!
This link shows what is the problem with SW development, not with X . The same thing is done also in QT or GTK. Why a program written for QT4 cannot compile in QT5 ? Why every library release must be incompatible with the predecessor ? I was able to compile and run X10 programs in X11. Why do i need to have on my linux system more than one version of a library ? Will Wayland fix that, because from this article I see that it is more or less in the same mess of incompatible libraries ?
I have been using Linux for over 25 years. I am not going to shed any tears over the loss of X, though I am concerned that some edge cases will be missed in the transition to Wayland or XWayland. The latter is why I am holding off on switching. Let others figure out and fix those edge cases for me.
As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.
Wayland is pushed by people, who do embedded Linux. Think: infotaiment system in your car. All UI is pre-installed and fixed to one (maybe, custom) toolkit, custom "window manager" (and it is not full-featured WM, as X11 ones are, as you can not move and resize windows arbitrarily), one theme, no remote access, very low response time.
It is better than both X11 and plain framebuffer in this role, for sure.
Wayland is pushed by people, who do embedded Linux.
Maybe when Wayland was started. But X.org is now effectively unmaintained and most of the core X.org developers are now working on Wayland. From the release maintainer of X.org:
So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
> So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse
This implies it's a choice made in isolation, rather than with the matrix of WM features and hardware support driving.
People aren't "choosing" Wayland or X in large numbers. They're making decisions like "I'm using distro A which ships Wayland by default" or "I want a tiling WM and have nvidia hardware, so I have to use X".
I've done a spot of embedded linux programming before and it is a royal PITA to do anything but the simplest graphics. I can easily see a role for Wayland for that.
This is a great answer, thanks. Also, the comment about GUI isolation for security makes sense (though I suspect x11docker would solve the security issues as well). Seems like Wayland is on track to be a good solution for a niche use case.
> The biggest reason is security. X offers no GUI isolation.
This is completely false. X offers both nesting for full isolation and a concept of "untrusted" connections for partial isolation. This is the reason why ssh -Y and ssh -X are separate things.
These facilities could use a little love to make them user friendly, etc., but they're there and have been for ages (enabled by default around 2013, present before then).
X also supports advanced mixed DPI, providing all the information to the application to handle it as they see fit.
I'm really disappointed to see this get mentioned in this context, it's not relevant. At least on debian, ssh -Y and ssh -X has done the same thing since like 2013 because ssh -X is broken and causes clients to crash. The "sandboxing" there doesn't really work. And it's a lot more than a little love that they need to get them working, the whole reason Xephyr sandboxing exists is because Xsecurity and XACE are so broken that it's unusable. You can see more about this in another comment here: https://news.ycombinator.com/item?id=29092612
Security would be the worst reason. Zero cases in the wild, and it's not that difficult to add access checks to X - there used to be an X extension to do this.
The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.
Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...
I read the article, I'm still not clear on why it's a problem. I'd have a very big problem if another user, using my machine via x forwarding, could capture my inputs, but that doesn't seem to be the case here? It seems that this is only for applications running on the same display.
So, to be blunt, this 'security feature' breaks a whole hell of a lot of use cases. If wayland wished to go down this route they should have displayed a prompt to the end user 'this application wishes to record the screen, that ok?'. The last time I made this point someone snidely informed me that 'this was not wayland's responsibility'. I'm sorry, if you break my use case you make it your responsibility!
That is exactly what will happen on a Wayland when you use the portal API, it shows a prompt asking for permission to record your screen and then it sends the stream over pipewire.
It is true that it isn't strictly the responsibility of the Wayland protocol, the API functionality is still there just it has moved somewhere else where it's more appropriate.
>Follow along this post and you'll end up with one case in the wild all by yourself on your own machine
I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter.
Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on.
Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.
There are so many holes in linux’s userspace’s “security” that we should start listing the actually protected parts. The only reason there are no linux botnets everywhere is because libre software fundamentally have good intentions.
So the reason for not exploiting X may very well be simply because there is an even easier exploit available..
> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.
This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.
Or just try to go at things with an open-mind and hell, you might learn something?
X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayland.
> a middleman in the communication of applications and the compositor
There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.
The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature.
> you can’t have displays with different DPIs
This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy.
What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals).
Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well.
Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way.
And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.
> start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.
That’s just one part of what a compositor does. I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor — something solved entirely by wayland’s “every frame is perfect”. Even on window managers like sway which has absolutely no animation or eye candy. Android also uses composition even with animations turned off.
I’m not sure we mean the same thing with multiple monitors having different DPI settings. X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other. If both screens have the same DPI, X can also render at eg. at 2x size.
And thank you for trying it out, X is indeed a cool project that spanned 3 decades. But due to the very major improvements in the underlying hardware, its abstraction is simply not up to date.
> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor.
Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a bit of tear. But.. I don't do that. Most of the time if I'm watching a video it's full screen. It looks perfect.
I bet the tearing you've seen using Xorg is attributable to something else. I remember back when video kinda sucked (in anything other than mplayer) but that was years ago. I have a windowed Netflix playing video as I type this and nope, no tearing. shrug I see in the Xorg.0.log that the COMPOSITE extension is loaded, but I'm not running a compositing WM, nor am I running a stand alone compositor.
I think we can put this "Xorg video playback has tearing" myth to bed.
It was certainly true back when suspend and resume didn't always work right, but that was quite some time ago. Having read much about Wayland in the last few hours, I think a more accurate thing to say would be "In Wayland, there is never any tearing. In Xorg, you can have tearing under some conditions" There are some very compelling reasons to be interested in Wayland that don't require exaggerating Xorg's failings. :)
> X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other.
I think we have a different definition of "handle", and I apologize in advance for semantic pedantry. I'm looking at 3 screens right now, one of them is a 14" "4kish" (3200x1800). Xorg "handles" it just fine. As I drag a window to the highest resolution screen (which I have in portrait orientation and use basically only for coding), the content appears exactly as I expect it to. That monitor has a higher DPI, which means the pixels are a different size. It's not a bug... it's expected and desired behavior. Dots Per Inch. It's right in the name! If some software in the display stack was interpolating everything, making my text look fuzzy, now that would be a serious bug to me!
I reallyreally think what you mean to say is "Xorg doesn't support rendering things in terms of physical size regardless of the underlying resolution." That might be true. Pleaseeeee say that instead. :) Personally, I wouldn't use that feature but I can imagine one desiring it.
But... when you say "X can't have displays with different DPIs" ... I mean this with no offense, but... you sound less intelligent than I'm sure you are. Because I can plainly see multiple displays with different DPIs right in front of my face. :) Xorg has been able to "handle" multiple displays since Xinerama, IIRC.
Anyway, I'm encouraged to take Wayland out for a spin for a reasons not mentioned in this comment thread. I like minimalism. :)
The reason you don't see any tearing is probably because video players under X have gotten better about "guessing" when the frame is supposed to be displayed. The knowledge to do that has accumulated over the last 30 years and it's a pile of hacks, and it's still possible for them to tear under various circumstances because X is still fundamentally an unsychronized protocol (unless you use a compositor with frame sync).
Thanks for this! I was thinking similarly, but you phrased it better than I could. My observation was "it used to suck, just like wireless, and suspend/resume, but now it doesn't." which matches perfectly with "software has built up a pile of hacks... aka bug fixes".
BTW, despite any appearances to the contrary, I recognize (and look forward to!) the superiority of an architecture based on fixed rate interrupts rather than a freewheel unsynchronized protocol. I was just afraid, previously, that:
1) All my stuff is gonna break! (Consider I've been using the same setup unchanged since the mid 2000s, and it's got a lot of self written code)
2) I'm gonna be stuck with a system I consider ugly!
3) My stuff breaking will be in exchange for nothing I consider worthwhile in return!
> X is still fundamentally an unsychronized protocol
Again, factually false. X has various synchronization options from the older double buffer protocol to the XSync extension to the GLX/DRI vsync commands.
I've also never seen tearing in X since like 2006.
No, it's not factually false, those fall in the "pile of hacks" I mentioned, and none of them work in all cases, some of them are highly dependent on driver support which is spotty. I can show you various bug reports from the last few years of people still complaining about tearing. This problem is not even remotely close to being solved in X and I don't think it ever will be. Again just look at the bug reports.
Meanwhile, if you plumb atomic page flipping through the whole system and make it mandatory, the chances of having tearing are pretty nonexistent. But you have to drop legacy stuff from X if you want to do that.
I don't understand, a video card cannot "do vsync" like that. If the program sends its contents at the wrong time then the video card can't do anything about that, the correct information is simply not there.
"This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy."
Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...
You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective. To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen.
I will (grudgingly!) concede that perhaps it's not "universally and obviously correct" that things stay the same number of pixels, if you concede that perhaps it's not "universally and obviously correct" for windows to be drawn in terms of points and scaled behind the scenes.
We don't though, I mean if you explicitly change the scaling factor. Of course if you don't change the scaling factor then your scaling would technically be correct.
You're right! I'm sorry! You said "scaled correctly" but I misinterpreted as "appear/behave correctly".
Before this discussion I didn't have the concept of "scaling" my windows.. because that doesn't make sense to me, and it's something I'd never want. So my scaling factor for everything would be 1. Given that, Xorg "scales" perfectly.
> Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...
No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).
Yeah you do if you want to have the same window span across monitors. And if you have non-integer DPI scaling then things will probably always be either blurry or inaccurate, that is unavoidable.
GPUs don’t have a single start, at least it depends on how you define them, but arguibly the first generally available one came in the late 1990s, compared to the various X server implementations that were around before that as well.
About its current role, there is a famous talk by an ex-Xorg developer that explains it well. Very crudely, a wayland compositor relays events to applications, which signals when it’s ready. Xorg on the other hand does these as well, but sits between the compositor and the clients, relaying their messages with some delay (and not having a concept of every frame is perfect)
Xorg doesn’t have support for mixed-DPI monitors, as it renders to all screens simultaneously with a single DPI setting. This is pretty much unfixable, it is so inside the core of the whole thing.
And finally, Xwayland exists and it is backwards compatible to the most part (other than manipulating wayland clients as if they were x ones, but that is also a wanted “functionality”). These are pretty much just nested x servers, so I don’t see how is it false?
X has had its OpenGL extension available since 1992. Your argument is like saying "Windows 1.0 came out before Direct X even existed, so of course you can't play modern games on Windows 10". As new things came out, they added support for it.
Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says "the X server only talks to the compositor" I'm like "lol what compositor".
But even if you have one, it is still wrong. You have to understand that GUI applications are a LOT more than just low-level rendering. So even if you didn't need it for that, there's so much more going on that the server still plays its role in like coordinating copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc.
And it isn't true that everything goes through the middle man. A graphics-heavy X application actually tends to work very similarly to a Wayland application (not coincidentally - as people love to point out, a bunch of the Wayland devs worked on the gpu rendering parts of X before): you get a direct render context, write to a buffer, then inform it to draw it. See more https://keithp.com/blogs/dri3_extension/
Mixed DPI is fully supported by the system, but may be buggy in applications. See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality, or do auto-scaling for easy support bridges. KDE and Qt manage to do it. So much for "unfixable".
"Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says 'the X server only talks to the compositor' I'm like 'lol what compositor'."
Can't you see how this is self-fulfilling though? People don't use X compositors because they suck and cause issues, so then you have people saying they don't use it because it doesn't add value. Well, yeah, compositing in X is bad and really convoluted and causes issues because X is not built for that, that's why they had to make Wayland to fix it.
The first two, yes, the rest of it not so much. The X server is quite bad when it comes to managing hotkeys or notifications or doing any of that stuff not related to window management and input, most of those uses have been replaced with D-Bus.
"A graphics-heavy X application actually tends to work very similarly to a Wayland application"
Yeah, using extensions that were made way after X was designed.
This article goes around every so often and every time it does, I have to point it out: Randr is not enough information to do mixed DPI. There is a reason the suggestions in that article have not been taken seriously. See this MR if you want more info on what actually needs to be done in the server to get this to work: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
It's for Xwayland but similar things need to be done if you want it to work correctly on the Xf86 hw. And also, you would still need a compositor for this.
> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.
Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.
I'm living a pretty good life without systemd, so it's clearly not necessary. I'm sort of willing to acknowledge that it fits some people's needs better than alternatives however.
systemd doesn't have the ability to cancel tasks from the console like other init systems do, for example when my laptop can't get a DHCP response from the network card that's not plugged in, so it's clearly stupid (and so is the init script or whatever it's called that's trying to get an answer from a not plugged in NIC, but that's a separate although related issue).
On other init systems, if you hit ^C it cancels the current task. On the one systemd machine that I used, ^C did nothing while waiting for DHCP, and no gettys had started yet either, so as far as I could tell, there was no way to get the system to respond other than wait for the timeout (minutes) or reboot and maybe reconfigure in single user mode.
> And I am sure, if you really think about it, you know this yourself.
I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.
Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?
I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most common uses (because, honestly, the most common cases are covered by anything), but it also introduced pain points for even non-esoteric cases (I've personally witnessed systemd getting stuck in fascinating nondeterministic ways more than sysv).
That doesn't seem to be what most Linux distributions were thinking around 10 years ago when the upstart/systemd/openrc/etc arguments started happening. The general consensus seemed to be that sysvinit needed to be replaced, or at the very least it needed to have a ton of other scaffolding on top of it in order to make it keep working.
Sysvinit never got stuck in those cases because it never had service dependencies and thus never needed to have a constraint solver for the dependency graph... So could you honestly say that pain point was better?
>Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.
Was bad faith, naive, and frankly... insulting -- so I just chose to ignore it.
My reservations are well grounded, and when ones concerns are echoed by ESR, Linus, and tytso, I don't think they can be dismissed so easily.
Certainly some people wanted features that sysvinit couldn't provide, obviously, because so much effort went into systemd. But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)
I'm still using sysvinit on my main machine, and on all "critical" servers not because I have an advanced use case requiring a specialized init system but because I have a simple use case and a computing philosophy that requires simple init system. I have a strong (I'll admit, borderline fanatic) affinity for the "unix philosophy" of accomplishing things through the composition of simple to understand and debug tools that do one thing, and do it well.
To me, SystemD is about as far as you can get from "do one thing, and do it well" and "simple to understand and debug". It's a monolith (right?) which is why it's not running directly on the hardware. Unfortunately, Debian now builds some packages that I use occasionally with SystemD specified during the configure stage, and I don't want to maintain my own packaging of tools with different compile flags, at least not yet. Presently, I solve this by having a separate VM for "all tasks that need systemd", but I hope to replace that with something lighter weight, perhaps containers instead.
SystemD provides some features I imagine most users want, and that I strongly see the benefit of, but for the vast majority of those features, those reasons I'd want to use systemd, I'd already solved it myself, through the composition of existing and simple tools. A good example is networking. My computer does exactly what I want it to do, every time, in all permutations of wireless, wired ethernet, wireguard, knowing to mount certain NFS shares when I'm at home, randomizing mac address in certain situations, knowing when &c. It's great functionality, and I got there over time by building simple and easy to debug shell scripts, which call out to tools like `ip`, `iw`, `wpa_supplicant` and reading from /sys/class/net.
I also don't use pulseaudio, as audio happens to be one of the subsystems I have strong experience with, and pulse is an unnecessary (and sometimes error prone) layer, considering I get along just fine with ALSA.
The one thing I'm jealous of is faster boot times. But I'll happily boot a few seconds slower in exchange for PID 1 being simple, and my other services being simple and hence easy to debug.
I don't understand why this philosophy discussion seems to get brought up so frequently or why anyone needs to care about philosophy in the context of a computer program. Linux distributions that adopted it are not sitting around pondering the meaning of life or the existential nature of what it means to boot a computer, they were using it to solve a real problem that they had. It was a complex problem, it was not a simple problem that could have been solved with a simple solution. So what you are saying is not really related to the question.
I don't think the opinions of ESR, Linus, and tytso are relevant here either as none of those people work on init systems. If you developed your own solutions with shell scripts, that's great for you, but I hope you can see how that doesn't work at scale in a big distribution. BTW systemd includes a lightweight implementation of containers so I also don't understand what you're talking about when you said you needed to then put it in a VM or container. The exact problem you're having can also be solved... by just using systemd. So it actually seems like you're making things more complex than it needs to be by jumping through hoops to avoid it.
Audio is also my expertise, and using just ALSA is an experience in pain. You need some kind of userspace daemon in order to get a good experience with that.
Booting is simply a complex problem. The complexity simply lives with your shell scripts instead, which is imo a much uglier and less maintainable solution for most use-cases.
Also, does your system do logging before the file systems are mounted?
> But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)
Sure, but systemd has quickly been adopted by the experts, namely the maintainers of every mainstream distribution. The people who maintain all of that infrastructure think it is much better than what we had before. That does say something about its quality.
> It's a monolith (right?)
That‘s a common misconception. You don‘t have to use all of systemd. And I am not talking about all of systemd, just the init system.
That also invalidates your point regarding networking, btw. You could keep using your setup with systemd.
That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.
What "Wayland people"? You probably mean the former Xorg developers who shifted to full time Wayland development long ago. Xorg is on life support, it has been getting bug fixes and nothing else for the past several years.
From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
> Xorg is on life support, it has been getting bug fixes and nothing else for the past several years.
Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering wheel from 2010 with minor problems.
Now imagine wayland, a brand new tesla, it doesn't have brakes or a steering wheel because history has shown that these concepts evolve and if anything it should be a third party provider that creates them. Who cares that it took ten years between the release of the car as ready for use and the first compatible steering wheel implementation? Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction.
> From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs). Of course the people who wrote wayland also wrote X11 so removing themselves from the equation might have been the nicest thing they ever did, given their own opinion of their past work on X11.
>Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction.
a) nvidia's refusal to implement GBM in their driver was their own choice. The abstraction was never removed; GBM is the abstraction over all drivers.
b) nvidia already relented and implemented GBM in their driver.
The latter doesn't necessarily mean nvidia is a good choice of GPU even now, because it requires a proprietary driver, so compositor / Mesa / kernel devs cannot debug the full stack when anything goes wrong. So having your problems ignored is something you'll have to get used to if you choose to use hardware that requires proprietary drivers, regardless of whether you use it with X or wayland.
>As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs).
wlroots exists to solve that problem. Whether an individual compositor decides to use it or not is up to the compositor.
At least in KDE's case, wlroots did not exist at the time they added Wayland support so of course it's understandable that they don't use it. There's a fork of kwin that uses wlroots ( https://gitlab.com/kwinft/kwinft ) but I believe it's just an experimental one-person effort rather than anything that kwin devs are working on as a replacement.
josefx: Since your reply was flagged, I'll reply here.
>Still not going to amputate my leg over a stubbed toe even if RMS considers the toe cancer.
I didn't say you should. I worded what I wrote specifically to indicate that I'm not passing any judgement on whether you made the right choice or the wrong choice.
There are many people who bought nvidia GPUs because they worked fine, and were rightfully worried that they'd stop working fine if their DE of choice decided to switch to wayland or became abandoned. I empathize with their situation completely.
All I'm saying is that you made the choice to buy hardware that requires a proprietary driver, and so you have to live with the consequences of that choice. This is not something unique to this situation involving nvidia GPUs. Only you have the right to decide whether it was a good choice or a bad one.
I really don't see why a bunch of unpaid volunteers should bother to support the only player in town that refuses to play nicely and tries to strong-arm everybody else to use its technically inferior solution.
Here's a nice write-up. I can imagine how nice it is to spend all your waking time trying to improve the Linux graphics stack and then listen to all the bullshit that we see in this discussion.
> I can imagine how nice it is to spend all your waking time trying to improve the Linux graphics stack and then listen to all the bullshit that we see in this discussion.
Is this really surprising? End users want their stuff to keep working with minimal changes. End users don't know and/or don't care that X is hard to maintain. They seen wayland coming, and they're scared that some of their stuff that they currently use will break. How exactly do you expect people to react to:
> Maybe Wayland doesn’t work for your precious use-case. More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago. Regardless, I simply don’t give a shit about you anymore.
Casting multi-use graphical computing aside is unwelcome.
Most of the toxicity centers on HOW that discussion has played out.
To be fair, many users coming up on single user graphical computing have no idea what the problem is, do not have use cases and we all know the rest.
The users who do understand all that are pissed. They are being told none of it really matters or is necessary, and so on...
Of course all that is definitely not appreciated however spiffy watching videos about it all may be.
And, those users totally get the need to see the embedded use case improvements get done, and still are being asked to just forget multi user graphical computing was ever a thing because reasons...
So yeah, here we are.
People will care about Weyland exactly as much as the Weyland team cares about them.
Multi user graphical computing aware users are not cared about at all despite their repeated explanations on how they depend on that capability. Depend, as in, not having it becomes very expensive for them. Expensive enough to wash away all the value they are being told matters more to everyone else.
Non multi user graphical computing aware people basically just want it settled so they can have few overall worries. They feel some care aimed their way.
The embedded people are super happy and are cared about a lot.
All adds up to a very toxic state of affairs.
Factoring it all down:
Did we absolutely have to trade multi user graphical computing away?
Should the answer be no, this whole ugly mess will go away.
Continuing with a yes means a very painful and drawn out mess for years to come.
And it will be that way because there are plenty of people who really do get a lot of value out of multi user graphical computing.
Who knew?
I bet the former X devs did. And they just do not care.
Xorg barely works on nvidia (source: me)
vsync requires a compositor to work, and even picom needs a very specific combination of flags to get vsync to work.
Chromium cannot gpu accelerate video playback.
On rolling release distros, most major kernel updates leave your system broken, because nvidias out-of-tree driver can't build against new kernel versions.
If nvidia stops supporting your old gpu, like they just did with Kepler, you're screwed.
The problem with nvidia on linux isn't wayland, it's nvidia.
I have used strictly Nvidia gpus, on debian Linux, for 20 years, using the binary drivers, and I have none of the issues you describe. It just works, very well, stable and fast. Xorg is an amazing piece of software and combined with openbox it does exactly what I need.
Users don't care about the underlying abstraction. The points raised before at least covered features that users cared about, even if they where presented without context, vsync worked fine on any NVIDIA desktop system I used, especially without compositor.
Xorg works just fine with Debian and Nvidia (source: me). Some longish (5-10) years ago it got so stable that I managed to stop thinking about it, because it Just Works. Even across upgrades. Your problem lies not with Linux, Xorg, or Nvidia.
>If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles — but you’d be able to shift gears with your car stereo. Useful feature, that. - Marus J. Ranum, Digital Equipment Corporation
> Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction
You mean under “they” the linux kernel devs? Because it has absolutely nothing to do with wayland. Nvidia cards’ proprietary drivers work with X because you are using a part-binary blob for X. Also, finally nvidia realized that they should goddamn support linux, so what all these resulted/will result in is better integration for people with nvidia cards.
FYI there are crowdfunding efforts to keep Xorg maintained https://news.ycombinator.com/item?id=29034479 . The recipient is the current X server maintainer so it's likely this is the best way to help keeping Xorg maintained.
It hasn't gone, it has just moved to other places, i.e. the web browser. In my opinion, X is a failed experiment, we know now that there are better ways to do things.
I would be interested to know why you think that, is this website not a multi-user graphical thing running on a computer?
Edit: Also I'm pretty confused as to why anyone refers to X as "multi-user", are you talking about multi-pointer X? That doesn't really have anything to do with X in particular and is also possible in Wayland.
Fonts from one machine
Window management from another
An application running on yet another, with it's program data sourced from yet another machine accessing data on still another machine.
All of which is displayed on another machine also supplying user input.
Or, I could do something crazy like put a window on your display, with appropriate permission of course, and you could interact with it.
A big wall type display could take windows from a number of users.
The promise back then, and something I used a lot, an many still do use today, is being able to run something and display it somewhere else. Say my cellphone is on my desk. I could ask it to do something for me, and the window into that activity appears on the display like any other window does.
Another case might be several users running on one machine each with their own displays and inputs.
Here is a real world case:
High end CAD software, managed data, many users.
With X, one can make a big application server and that is not visible to users at all in terms of the application or data to be manipulated.
Users run the program via X, running X servers on anything they want. PC, Mac, Linux, whatever.
The only way to interact with the managed data is through the application.
One copy of the application, one data repository, many users.
With X doing that kind of thing is easy, and it works whether one user runs the app on their local machine attached to a shared data repository, or many users run on a remote machine perhaps that machine itself also holding the data repository.
All of that is extremely possible with a web app though, and most of it is probably done even easier with a web app. In fact that is the usual way to build a web app, make a server that does the heavy lifting and then make a GUI that runs in the client which can then be accessed by multiple users. You can easily access them from a smartphone too.
The only exception is this:
"Another case might be several users running on one machine each with their own displays and inputs."
This would be multi-seat which doesn't really have anything to do with the display server. It is implemented in udev and logind, which spawns additional X or Wayland servers for each additional "seat".
Is that sarcasm? A key difference I would say is that the web is actually better because you can run javascript or WASM code in the browser, in X that would be the equivalent of the "server"...
While it's supposed to be "maintenance only", it got a very important addition recently (but not a definitive solution by any means) that helps with dreaded multiscreen setups, AsyncFlipSecondaries.
This is exactly why I would rather do. I see absolutely no reason to abandon X and want to learn its internals to be able to maintain it myself. To me X seems a perfect piece of software which just works and does its job flawlessly, while having all the features I ever needed (including remote execution - I used Windows apps running on a remote Linux machine with Wine over SSH over OpenVPN on a local Windows machine and that was very easy).
1. Wayland does support remote execution; see waypipe for an example.
2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).
ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing.
Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's.
You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.
I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.
The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL
X ran just fine on machines with graphics chips with no acceleration at all, just dumb frame buffers.
You're probably right that a modern X server optimised for modern PCs won't run well on those machines, but the point being that this has little to do with X the protocol, and everything to do with the implementation of the X server and to a certain extent with clients being optimised for different performance characteristics.
As for Vulkan, there's no reason you can't use Vulcan with X. It's again an implementation question, not a protocol issue.
Now, the X protocol is awful, to be clear. There are plenty of issues with X that were worth fixing. But the time it has taken to get Wayland to a usable state (many would argue it still isn't - I certainly have no interest in running Wayland other than with XWayland possibly given the current state) suggests that opting to start from scratch instead of upgrading X step by step was a relatively poor choice - the X protocol is easily upgradable.
X ran "fine" on those machines if you were ok with all the problems of 80s-90s era graphics such as flickering, tearing, windows taking noticeable time to be redrawn, stale contents when resizing or when something else moves above them, the occasional "solitaire effect" where the back buffer doesn't get cleared, or any of that other fun stuff from dealing with expose events...
Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.
Avoiding flickering and tearing is something we've known how to do since the early 80's. It's not a protocol issue, but an implementation issue. If you don't double-buffer and and/or sync updates, then sure.
Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help you with that. Blitting the graphics onto the screen was back to being limited by the hardware from MIT-SHM arrived ~'91.
> Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.
Upgrading the core protocol has hardly been tried. What has been done is piling on extensions - ironically exactly the same mess happening with Wayland to try to get back to reasonable parity with X. But even most of those didn't go very far. E.g. none of them tried stripping out more than a tiny subset of legacy stuff.
The very first message an X client sends includes the protocol version. Nothing stops you from starting by bumping the major protocol to 12, removing whatever you like from the protocol if a client connects and asks for 12, and upgrade Xlib to ask for 12 first and try again with 11 if the server barfs. Nothing stops you from making a version of a server that just refuses to let clients asking for 11 to connect, and defer those to requiring a proxy to translate/implement whatever you strip out if you care rather than upgrade the clients.
I understand why people got fed up and did Wayland instead, but that was largely organisational, not technical.
If there had been the will they could have done a dozen iterations of the core X protocol in the time it has taken to get Wayland reasonably usable and removed things piece by piece instead. To take a concrete example, there are about half a dozen ways of rendering text in X. Nothing would have prevented saying that X12.0 has XRender by default so you don't need to query for it, and that no other text-like rendering operation than RenderCompositeGlyphs8/16/32 is supported and just yanking all of the font code out of the server. If anyone cared, taking the old code and implementing a client side library providing the old string drawing functions would keep compatibility easily enough.
Nobody seriously tried doing this, because the politics of it was maintaining full backwards compatibility or building something new.
Wayland was a technical solution to a political problem. Frankly a fork and iterating would have likely gotten buy-in much faster.
Once you are talking about double/triple buffering every client, you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue. Of course Wayland doesn't "solve" it but it does remove the old slow code paths. If you're on an SoC with a GPU then you want to use it as much as you can otherwise you are wasting CPU.
The rest of your comment doesn't really make any sense to me. Somebody could make X12 but I'm sure you understand that doing that would have all the same technical/organization challenges as Wayland. I don't know why you would think making an incompatible fork of the X server and then trying to convince everyone to use it is a simple endeavor, it's not. There is zero will to actually do that, I've heard similar suggestions to make X12 for the last 15-20 years, and nobody has ever cared enough to do it because the only reason anyone ever uses X is for compatibility with old software. Once you take that away, there's nothing left. The closest existing thing to an X12 is, well you guessed it, Wayland.
> Once you are talking about double/triple buffering every client
Nobody is talking about double/triple buffering every client, but the final composited surface.
> you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue
Double-buffering was viable and done on quite a lot of 1980's hardware. The point remains that this is not a protocol issue.
> Somebody could make X12 but I'm sure you understand that doing that would have all the same technical/organization challenges as Wayland. I don't know why you would think making an incompatible fork of the X server and then trying to convince everyone to use it is a simple endeavor, it's not.
I didn't suggest it would have been simple. I suggested it would have been simple than a well over decade long effort to write a new system from scratch.
The point being that the reasons for the existence of Wayland are not technical, but political, due to the lack of willingness in the Xorg core team to break compatibility at the time. And we're still paying the price.
You need to double buffer the clients or you will still get flickering and noticeable redraw. You can see this with older X clients. It actually is a protocol issue because X was explicitly designed to do this.
You are presenting this as if it's some kind of decision between "break compatibility" and "start from scratch" when really those are a lot closer than you think. Realistically, most of the X server is still overdue for a major rewrite/refactor. But I really doubt anyone would ever volunteer to do that work at this point.
No, you don't need to double buffer the clients if the clients are properly designed and flush the request queue cautiously rather than willy-nilly, and the server takes a minimum of care rather than just stupidly processing requests one by one. None of the clients I use give flickering or noticeable redraw.
There may certainly be cases where it'd be harder to avoid, but realistically this hasn't been a problem for most X users for decades. Of course I'm not doubting that it is a problem for some, but it's not for me and haven't been since the 90's.
> ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for
Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio?
> I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.
Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability.
> The difference will widen as Vulkan
I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that
> Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability.
A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more.
I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link.
A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.
> Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link.
i3/dwm (or any X window manager), unlike Sway (or any Wayland compositor) has nothing to do with client window contents rendering. X and Wayland works fundamentally differently in that respect. Under Wayland the compositor and wm is the same. Under X the server and wm are separate programs in separate processes, and the latter is not involved in rendering the client window contents, only the window chrome, if any.
I see. Quite a reasonable, detailed explanation, thank you. I didn't notice any visible difference in perceived performance (just using the PC to write code, browse the web and watch videos) when I switched spectre/meltdown mitigations on/off on my old Core 2 Duo PC though. It just always worked perfectly fast.
Meanwhile, I often don't need any network connection (when coding, watching pre-download videos, or running data/number-crunching or build scripts). Can I expect 90s-like efficiency if I disable all the mitigations and hardening stuff?
There are...a lot of good reasons to keep the mitigations enabled. All nontrivial software has bugs, and hardening measures can keep some of the worst ones in check. Frankly, the Linux desktop needs more of this, not less.
I was referring to the fact that OpenGL is becoming a second class citizen among the silicon giants, with more attention being drawn to Vulcan/Metal/etc. Now that sway supports a Vulcan backend, it won't be left in the dust stuck on OpenGL.
I'm not aware of GNOME or KDE having similar improvements on their X backends or the same happening for X WMs.
X WMs do not have anything to do with rendering. The conflation of the server/compositor with the window management is a Wayland thing, and one of the big regressions in flexibility that current Wayland compositors bring. You may be confusing X WMs with the X server or with the toolkits rendering backends.
What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO.
I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason.
The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.
> If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason.
I see. Curious that I have never noticed anything like this though. I have always been disabling compositors as I realized I don't really care if my panel is transparent. Perhaps the problem just doesn't affect Intel graphics (Raspberry Pi browsing is slow anyway so fast scrolling just doesn't exist there).
UPDATE: I've just realized I've actually seen screen tearing many times - always within specific Windows apps ran with Wine, e.g. Total Commander.
Screen tearing is largely a software issue anyway - the moment you have hardware capable of double buffering there's no excuse for it unless you don't have sufficient memory.
Have you tried playing a video? Or moving a window around fast? Without a compositor there will be tearing on X. With a compositor, X is just a useless middleman.
There's absolutely no reason to write an X server from scratch to add native compositing support.
You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support older clients, and make the main server itself only support the subset of the X protocol modern clients speak.
> You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done.
If so, why are we observing apparent shortage of developers to maintain the actual Xorg? I can't believe there are no people interested in maintaining it in the whole world. I thought it's so complex it just requires much more expertise and dedication than anybody is ready to invest.
Because Xorg is a huge beast with plenty of legacy, and it's also not a very fun project to hack on because it's largely maintenance of stuff people only care about when it breaks.
E.g. support for a bunch of backends of which most are not worth supporting if you want to implement a server from scratch, but which Xorg has been saddled with, as well as support for a bunch of legacy X functionality that nobody would bother implementing if implementing a server from scratch because most clients never use it.
E.g. a major source of complexity is supporting various X visuals that are irrelevant today when you can decide to only support truecolor natively. Another is support for a bunch of drawing primitives that you might as well just ditch all but the very simplest of, and support for legacy clients via a proxy like Xephyr. That said, most of those drawing primitives are also supported by any 2d canvas style library like Cairo or Skia that does client side 2d rendering, so if you want to implement them for an X server, just picking up one of those libraries would be time far better spent than implementing it yourself.
It'd certainly be a lot of work, and a lot more work to write an X server from scratch that is a complete replacement for e.g. Xorg - you'd need to support a number of X protocol extensions, but most clients backends will fall back on core functionality if extensions are not available (you'd definitely want to support some of them, like Xrender and SHM though, or your server would be largely unusable with modern clients).
At the same time, if someone wants to write a new X server, it'd be silly to do the work of writing their own backends when the could just grab wlroots and build an X server on top of that. "Modern X11" can be reduced to a relatively narrow superset of Wayland functionality if you defer most of the weirder legacy functionality that is rarely but very occasionally used to a proxy like XWayland, Xephyr or XPRA (all of which do, that said, rely on Xorg code) and make people use those for clients that need it.
Honestly, I think this is the most likely/viable future for X on Linux. It'd drastically reduce the amount of code to maintain and share that burden with other projects, and would make it far more viable to keep maintaining X support for those of us who wants (part of) it.
I really don't understand this line of thinking or what you are trying to accomplish. If you are dropping things from the X protocol to the point where it's only XInput2.2, SHM and DRI3, and then farming the rest out to Xephyr, then it's no longer X anymore. That is pretty much entirely what Wayland already is. So you might as well just build it as a Wayland server and call it a day.
I'm not doing this, it's a thought experiment. I'm happy to stay with X for a long time if necessary.
But what you list is not enough, though. There are enough extra bits that goes well beyond what Wayland provides today, like ability to write a standalone wm without having to build a whole compositor, for example, that you'd end up with something quite substantially unlike Wayland if you went down that route and looked at which pieces of X11+extensions people are actually using. It'd be far less than full on legacy X11, but far more than just Wayland.
It doesn't matter if it's not X. Nobody but extreme purists would care if it's not exactly X. What will matter is if you lose capabilities.
E.g currently my preferred wm (bspwm) doesn't have a Wayland alternative, so a Wayland compositor isn't a viable option for me without changing my workflow. Sway might be nice, but it's different and I have no compelling reason to put in the effort to make a switch until running Xorg starts becoming problematic. One day, maybe I'll feel compelled to switch but it won't be soon.
Even so, Xorg will hang around for decades in the form of XWayland because of old X apps people still use (e.g. none of the terminals I have installed on my system except for gnome-terminal supports Wayland).
I still see no purpose to do that, with a lot of hacking it would be also possible to make XWayland work with window managers. But that also would be pretty pointless to do because those other parts of the X protocol are also bad and need to be replaced, you might as well just rewrite the window manager.
If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on. So in however many years it takes before getting Xorg running starts taking more effort than switching. I'm not expecting that to happen anytime soon.
> It doesn't really work fine though, there are numerous really old bugs that never got fixed. Here's a sample:
It works fine for me. I gave my reason for why I won't consider switching to some Wayland compositor. None of the bugs you list affect me, so your suggestion I look at a Wayland compositor which would require me to spend time changing my entire config only to be left running XWayland anyway because the terminals I use are X11 based.
It would be a massive waste of my time for no benefit whatsoever.
And this is why X will stay around for a long time: There are lots of us with dependencies like this and no reasons to change things until things starts breaking.
> I don't understand, you were just talking about spending significantly more time rewriting the X server...
Read again. I have not once suggested I'm planning on rewriting an X server. I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X.
I guess you can consider yourself lucky that you're not affected by those bugs? Things are ostensibly already broken and have been for quite some time, some of those bugs are over 15 years old. If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you. And if that's not what you meant then the other stuff is still there if you change your mind and decide to switch.
"I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X."
I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement. Because that is what we are looking at here. Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
There are always bugs in complex software, so sure. I can also consider myself lucky that I'm not forced into using a Wayland compositor as it'd force me to change my workflows in all kinds of ways.
> If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you
I'm not expecting anything other than to keep using the software which works for me. I'm not the one arguing for people to change setups that works for us. Use what works for you. If that's Wayland that's your choice. For me it's not - it involves putting effort into something that doesn't give me amy benefits. Nobody is arguing for you to do anything or not anything.
> I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement.
No, I wouldn't like to revise that statement, because none of the bugs are relevant for an updated protocol unless you choose to keep the things that are broken, since the "worst case" is to throw away and start over the same way Wayland did.
> Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
And it's obvious that the number of if x12 then dostuff would have been far smaller and/or amortized over longer time because you'd only need them in cases where you actually introduced a breaking change that couldn't be fixed by using functionality that would keep working the same on both.
Most modern X11 apps already don't use most of the functionality of X that is worth deprecating, and for many of those who do the solution would be to change to a request that'd be worth keeping, not to add an if x12. E.g. as I mentioned there are a number of different ways of rendering text with X. The most popular terminals are split roughly in two broad groups: Those who use the old server side rendering, and those who use XRender (a couple of outliers use OpenGL). Most of the ones I've looked at use Xlib etc. directly rather than toolkits, though some of the font stuff in Xlib is wrapping the server side functionality in ways that could be retargeted to use Freetype.
If you remove the former, then ~half of the terminals would need to get updated to use the latter method or forced to use a proxy (ditching most of them isn't really an option - many of the most feature-complete ones use X directly, and all of the ones I have looked at have users who swear by them and will keep using them until there is a feature complete replacement; many of them are decades old and their users still don't agree there's one worth switching to) or client-side reimplementation of the font rendering. But assuming you were to retain the XRender glyph rendering you wouldn't need to special case for this hypothetical x12, just upgrade apps to use XRender, and you could yank out all the font support in the server. Moving to Wayland on the other hand requires all of them to change
To date most of the terminals I've looked at haven't been updated with Wayland support, and many probably never will, making XWayland and so most of Xorg still hang around as long as they have users and someone cares. Given how long many of them have survived, I'm guessing you'll have to wait for their user bases to literally die out.
The X12 approach would have allowed starting to actually deploy the improvements stepwise more than a decade ago. Or more. E.g. the XFIXES extension happened in 2003 and was the first real attempt at some somewhat potentially breaking changes hidden behind an extension flag rather than a version change (and didn't allow the server to actually ditch the old code). Nothing other than politics stopped a more drastic approach.
This notion that there were technical barriers stopping an iteration of X is pure fiction.
Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here:
>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:
I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :)
> WHAT IS YOUR ROOT?
A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though.
The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.
So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.
There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.
In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.
EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.
The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib.
I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp.
Few people still write applications directly to XLib, but many do write applications directly to toolkits and libraries that DO depend on XLib.
So we're all stuck with XLib from now until eternity. If you replace it, you lose the entire ecosystem of client side extension libraries, so you have to reimplement them all from scratch.
At the time, that was a no-go if you wanted to use Adobe's proprietary Display PostScript extension, which was quite popular and included with most commercial X11 servers of the era. Even if most important X extensions are open source, how about about them NVIDIA drivers?
Display PostScript is simply an old example from 1992 of what I mean, that I wanted to use from Common Lisp via CLX, but couldn't. But it shows how this problem has been around for a long time, and is never going away. The only viable solution was to dump CLX and call XLib and the Display PostScript extension libraries directly from Lisp through a wrapper layer.
But now the problem with clients and toolkits depending on X11 extensions is much more entrenched, not just limited to high-end exotic graphics-rich apps that want to use Display PostScript to draw a nice pie chart.
That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries -- just to measure the display, shape windows, listen for input, memory map pixmaps, and composite the first pixel on the screen -- because they've long since abandoned X11's horrible old built-in pixel-based rendering API, broken font model, leaky input system, etc, and switched to using full stacks of X11 extensions (via their XLib based libraries) instead.
> That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries
Then Wayland will be more a nightmare still, since they moved everything but core rendering into extensions and say "just use wlroots" to deal with it.
Absolutely agree that a general purpose replacement for Xlib would be a massive pain, but providing sufficient support for the core protocol to let you add whichever request types you need is quite simple (and I lifted that from a decade old starting point and made it work).
And for my use I only need to support about a dozen requests types, and no third party libs, so it's not that bad. My starting point only linked with Xlib anyway, nothing else, and I verified which requests Xlib actually sent via xtruss before I started.
But of course, that's because I only want to actually use it for something very simple. If I wanted to do something more complex I'd wrap a higher level library instead.
You think this is bad? Just look at a native Wayland "Hello World" client [1]. This doesn't even print hello world. You have to do the text rendering yourself. And you need at least 500 more lines to implement the equivalent to a simple XGetImage() call.
Your toolkit should abstract all that away. We have these wonderful things called dynamic libraries, that X was designed for a world without because they didn't exist under Unix yet.
If toolkits can "abstract that away" they can do the same on X11 and there is even less reason for Wayland to exist. There is no reason for you to even care about X11/Wayland if you only work with toolkits. So stop participating in a discussion that doesn't concern you.
"they can do the same on X11 and there is even less reason for Wayland to exist."
Well actually it's the reverse: the more abstractions were put into toolkits, the more it became obvious that there was little reason to use everything in X11.
Waypipe ships client-rendered images across the network; datacenters would fall back to software rendering because there’s no way to take advantage of a user’s desktop GPU. I think the industry will continue moving to Javascript or Wasm apps as the most widely portable and accelerated remote display system we have.
Also, in X terminology, the server owns/controls the display, the client is the app that wants to draw a window on the server’s display. The classic architecture would be client telling server what to draw, but these days what really happens is that clients draw locally into a buffer and then tell X server to draw the contents of the buffer.
That’s been tried, but most toolkits stopped doing that because it was unreliable, slow, and the number of primitives offered by X wasn’t sufficient for any modern GUI.
It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.
I was under the impression Wayland on FreeBSD required a lot of patching on their end, but this has been merged upstream? If so that's pretty good news.
Also good news re colour management. The last I heard about this was Drew DeVault (and I'm paraphrasing) calling it "precious horseshit".
Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years.
On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not familiar.
Wayland has already taken off; once we get XFCE to switch we should be able to move on.
This is not an organic transition. Major organizations seems to "push" it but there is not much "pull". Compare this to the "transition" from CVS/SVN to git. There was no need to even advertise git. People saw it and wanted it.
The X11 ecosystem is more than just GNOME, KDE and i3 and porting XFCE will not be enough to "move on" (For me it is the small things like Xdotool, Xsel, Xcalib, etc. that are holding me back). Maybe X11 needs to be replaced but Wayland is not the answer. It's just not good enough and because of fundamental flaws of its philosophical concepts it will never be.
Xdotool and xsel have had Wayland equivalents for years: see ydotool/wtype and wl-clipboard.
The reason why major orgs have had to push for Wayland is the same as the reasons they had to push for HTTPS and TLSv1.2, unique passwords, keeping software up to date, etc: using outdated and insecure software with significant attack surface has real costs even if it's convenient.
All "equivalents" you mention have less functionality than their originals and some only work on specific compositors like wlroots/sway. Like all things Wayland it's a mess with zero benefits for the user.
HTTPS vs HTTP is a false equivalent. HTTP works just fine like before. X11 can be made fully secure (e.g. QubesOS does it) but nobody uses it because there is really no need on a FOSS system where 100% of clients you run are trusted.
Qubes devs are in my experience the most vocal X detractors. They had to work around X's inherent lack of isolation by using a Xen mechanism. The equivalent would be putting a wooden chest in a safe to show that wooden chests are secure on their own.
HTTP also doesn't work as well as it did before: Chromium and Firefox have begun rolling out an HTTPS-Only mode that warns when visiting HTTP pages. The landscape has also gotten more hostile: many telecoms have been caught modifying unencrypted traffic. Vodafone was also caught HTTP CSP headers for ad injection.
Firefox devs have expressed interest in removing HTTP-specific logic from FF in the distant future too, with the HTTPS-only mode being the first step. All current browsers have also disabled obsolete TLS/SSL versions, which broke several sites during the initial rollout.
There is no such thing as a trusted client; plenty of FOSS has exploitable vulnerabilities. Rather than "trusted and untrusted" software, the cybersecurity crowd has shifted to thinking in terms of "untrusted and untrusted+malicious".
There's also a reason why software audits typically have their moment of truth during binary analysis, whether or not source code is available: source code is only part of the puzzle. Runtime behavior is influenced by the toolchain behavior, host OS behavior, shared libs, and a ton of other variables that are collectively harder to audit than a black box binary. FOSS' reasons for existing should be primarily related to freedom rather than security. I don't copyleft my work because it improves security, but because it protects users from further infringements upon their freedoms.
I'd suggest chatting up a security researcher or reading some material on modern approaches to exploit mitigations (source availability is not a replacement for exploit mitigation); I could give you some starting points when I wake up if you're interested.
When your solution to "make something secure" is to isolate instances of it in airtight sandboxes, IT IS NOT SECURE.
Theoretically Xorg can be made fully secure: just isolate clients so they can only receive events and bitmap information from windows created on the same client connection. It would be relatively straightforward, if quite involved, to implement.
But nobody wants to implement it because everyone qualified to do so has jumped ship to Wayland. The X architecture is so fatally flawed that the most straightforward way to fix it is to start from scratch, and that's what Wayland is.
X is like global warming: one hundred percent of the people who are in the least wise knowledgeable agree that it is a problem. Unlike global warming, however, that problem has a fix: Wayland.
So just... shut up with the irrelevant bullshit and use Wayland, like all the Linux graphics maintainers and distro maintainers want you to do and have been telling you to do for years now... or find your shit unsupported.
>So just... shut up with the irrelevant bullshit and use Wayland
There are still, to this day, tons of features which end consumers rely on that are still unsupported out of the box with wayland. If you're writing a replacement for x, it had damned well better have feature parity with x. Saying 'shut up and switch' is not an argument for switching.
Also, this sort of attitude is precisely why linux never took off on the desktop. Such arrogance.
I don't agree with the GP comment's attitude but if you could mention those features then maybe someone can help you, they probably exist in some form.
Bazaar style development can’t really transition in such a fast way as cathedrals can. While in case of apple, simply declaring that this framework will be the default from the next release on is enough, linux doesn’t work like that. It is a slow transition, but it already has enough momentum behind it.
There are a lot of smaller projects that lack the resources for the Wayland transition.
I'm a happy Mate user and while there is ongoing work to move towards Wayland, it will likely take several years to complete.
So for the time being I keep X11 dear to my heart, and to be honest I'm not sure what I'm missing with Wayland (expert apparently problems with screen sharing applications that have not been updated to Wayland yet …). X11 + Compiz work fine for me.
I think most smaller project will transition automatically once their widget toolkit is ported. For the cases where this does not happens, xwayland is working well enough.
#/media/File:HyperTIESAuthoring.jpg){kind=link}
[1]: https://dwm.suckless.org
[2]: https://git.suckless.org/dwm/files.html