Xplain – Explaining X11 for the rest of us (2017)

I implemented fullscreen OpenGL in my 3D engine a few years ago and this was kind of an interesting part. It was one of the hardest to get right, especially if you want to avoid dictating sort of WM your users will have to use (which IMO is one of X11 strengths over pretty much any other desktop GUI).

Some window managers treat any window that covers the entire screen as being fine to bypass composition. Other window managers need hints - which will be ignored by some other window managers. And a few compositors simply seem to ignore any hint or window state, but they will disable composition for fullscreen windows that also bypass window management (which in general is kind of a "nuclear option" for fullscreen modes since it also bypasses other window manager functionality like alt-tab, etc). Also as a cherry on top, i had a window manager which refused to treat the window as a fullscreen window (added borders, etc) unless i set up things in a very specific order (which i found out via trial and error because normally it shouldn't be an issue - and wasn't in every other window manager i tried).

(that last part was kinda interesting because i downloaded every window manager i could find on Debian and after i tested my code and debugged it with everything i could get my hands on, i sent it to a friend of mine to try it out and he immediately told me that in his computer he got borders :-P)

Should be noted that neither SDL1 nor SDL2 (which are pretty much recommended by people who haven't bothered to create their own engines as "obvious" solutions to not have to bother with OS-specific stuff) handled all the above (SDL1 always bypasses the window manager, which in general works but disables alt-tabbing and other WM functionality whereas SDL2 assumes all window managers support the fullscreen hint, which is certainly not the case - especially with more minimalistic window managers - while compositor support is hit and miss).

SDL2 sets this on windows by default, which is likely what's doing it:

https://specifications.freedesktop.org/wm-spec/wm-spec-lates...

Compositing is required for any sort of antialiasing, especially including window borders, so it's difficult to turn off without having a lot of artifacts. And it also solves vsync which a lot of raw X11 applications can't possibly render correctly with.

(Thanks for replying! https://get.webgl.org/webgl2/ is green and shows a spinning cube, but yeah, it's quite old.)

I pick 2017.

I'm not clear on what you're missing. What meme? The protocol is well documented. The basic abstraction is that there is a separation between the 'processing' part of an application and the 'display' part of the application and those two parts communicate using the X11 protocol. That conversation can happen over a local or a remote socket, or shared memory. The practical use cases are that I can have an application running on my local machine, or one on the other side of the world, and the 'display' portion is consistent. Not much different than, say how Citrix uses it's own protocol to draw remote displays.

It allowed a 'mainframe' model where you could have a very fast, expensive application servers that could display to less expensive local resources, and mix the display with local applications. So my heavyweight applications could run on the monster Sun or Cray in the datacenter, but my clock, calc and notepad app ran locally, but all in the same display.

Yes, over the years things like MIT-SHM and NX came along to paper over problematic issues in X11. And yes, there are other, possibly better ways so solve it now. But in the late 80s and through the 90s, it was pretty cool stuff.

> Nobody has ever explained to me what it means, what its goals are, what constraints it has on the system or the protocol.

In today's world, what I think people want to do (and certainly what I want to do) is ssh to a machine, run a graphical program on that machine and see and interact with it in my graphical environment. X11 with ssh tunneling lets me do that. It's not a great experience, for all sorts of reasons, but it's an experience, and people who have been around for a while remember that it used to work better. It's usable enough on many applications to work in a pinch, or for ocassional work (I always run mythtv-setup via remote X, because it's inconvenient otherwise; sometimes I run a graphical browser over remote X to access localnetwork only servers from outside my home, but only if I can't get proxying to work, because browsers on remote X are awful in 2020 in ways they weren't in 2005)

I haven't looked in a while, and maybe waypipe fills this gap now, but I think at least some people are frustrated because Wayland is supposed to replace X11, but it doesn't hit all their use cases, and they may not care that much about the things it does better because they were used to the old ways. (Of course, if those things include hardware support, that will be a forcing function).

I certainly understand your frustration though. You built something new and better, and people won't use it because they're stuck on something that barely works.

Network transparency meant that when I was doing Finite Element Analysis on the beefiest Sun workstation they sold, running a proprietary application, I could log in from home, run the application on the Sun, and see the results of the prior run.

I could edit the model, regenerate the mesh if needed, and kick off another big batch run, and then drop the X11 frontend GUI.

Over dial-up, from a Windows box to a Sun workstation, in the mid 90s. And it was could be secure, tunneled through SSH.

All of that said, "ssh -Y" works pretty well for me. It's pretty usable.

And from a user perspective I personally like the "application connects to render" model much better than VNC or RDP style entire-desktop streaming.

NX partially solves the problem that applications don't use the X primitives anymore and are way to chatty with the X server (which leads to many unnecessary roundtrips which is the real killer for remote X11). Old applications work great even without NX or any hacks.. just anything modern is quite sluggish.

And it's less about the actual protocol, but the desired behavior. I want to launch applications on a remote machine and have the windows appear on my local machine as if I was running them locally. And so far there is nothing except X11 that can really do that..

Back in the 90s, I had a serial cable under the carpet from my computer to my couch. My computer would access the internet over PPP and my laptop would PPP over to my computer. Then I would launch netscape and browse the web from the comfort of my couch.

I have had a couple other use cases over the years like virt-manager at work, and a graphical management tool that I made for my son's minecraft server.

Sure there were other solutions but X11 over the wire worked well.

Not that anyone feels it is important today, but X11 is multi user graphical computing.

A display server can display anything any user connected to it wants to display.

Actual 90's era use cases:

Application server. One copy of 3D CAD, one database, 30 users all running on a beefy machine well up to the task.

Each ran via X talking to the app server. Admin was cake, data big model access was fast, no user could actually touch the data except through use of the program.

User having trouble, push a window onto my display. I fix it, close window.

Display wall, conferencing. Big wall display, multiple users display data on it, one management user handling windows, etc...

Display wall, many small displays, each running via workstation. App sends display data to all of them.

Distributed computing resources:

Once, just for fun, I had an application data shared via a machine running nfs, fonts served by another machine, yet another machine running the application, yet another handling window management, all displayed on yet another machine serving the display and taking input.

(BTW, it was possible to literally kill the window manager and launch a different one and the display would shift a bit and the user continued along still running their app, but now using a different window manager!)

User could click on an icon, all those machines contributed to the app experience. Was hard to tell the difference between that and it running all locally.

Why?

Linux user wanted to run CAD unavailable on Linux, was developer who wanted a Linux box. So I used X to push the whole experience to their machine and distributed it for fun once it was working well just to learn and really push things, frankly.

While running, it was hard to tell the Linux machine was not an expensive commercial Unix machine.

All that was over 10-T and 100-T ethernet BTW.

Well designed X applications, particularly those using the SGI GLX extensions ran very well on local LANs. Poorly designed ones were nowhere near the quality of experience.

That skill was expensive. I think this is a big part of why so many struggled with X. A browser, for example, would not be comparable, pretty terrible.

Displaying web pages sucked, yet modeling a freaking car was amazing!

At the time, the X implementation of multi user graphical computing allowed for these and other combinations of users, machines, displays and applications.

It was well thought out multi user graphical computing!

The users could be local, as in a multi head machine offering two sets of keyboard, mouse, display, or they could arrive over the network.

Same as the Unix it was built on top of.

I think that is what people really are trying to get at when they say "network transparency"

Not all these use, or the set of possible use cases X made possible, make sense today.

But, when it was done?

Nobody knew, so they made a system as capable and that employed the best ideas in multi user computing, so that it was all possible.

That's why people who got to understand and really use X appreciate it as we see them do today.

I'm afraid I'm dreadfully confused by your comment.

"The typical answer I see is "you can send the same bits locally that you do over the wire", but nobody ever explains why that's even desirable for a network protocol."

Yes, you can use a network protocol to chat between local processes as well as between remote processes. Desirable? It's impossible to avoid...

"Transparent, distributed RPC was tried in the 90s and largely judged a failure."

True (ahem[1]), but irrelevant. X isn't a remote procedure call system.

"Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years. Most modern enhancements to X11 have been about taking the X server out of the loop for as much as possible."

This is true; network speed hasn't kept up with graphics power and requirements for the most part, so processing has been pushed to the client. On the other hand, HTTP/HTML/JS/CSS can be seen as a poor-man's reimplementation of X (or more closely, of Plan 9 client-ui/server-processor protocols). And for the 20 years previous, clients were underpowered in comparison with a big honking machine you could log into remotely (or at least a dedicated machine that didn't have to bear the weight of a graphical interface).

"To make X11 usable over the network..."

X11 has been usable over the network since 1987 (and X < 11 before that) (https://en.wikipedia.org/wiki/X_Window_System#Origin_and_ear...).

"...even advocates of the principle usually use something like NX which is a network-designed fork of the protocol..."

I'm not sure what you mean be NX. The...

"NX technology, commonly known as NX, is a proprietary software application for remote access, desktop sharing, virtual desktop on Linux and file transfer between computers. It is developed by the Luxembourg-based company NoMachine which also lends its name to the software." (wikipedia)

which has nothing to do with X other than being descended from one of the low-bandwidth X extensions. (Not the low-bandwith X, and low-bandwith means dial-up. Plain ol' X was pretty chirpy on a SPARCstation with 10MB ethernet.)

"...multiple independent streams so we don't have reach head-of-line blocking with roundtrips..."

Welcome to the wonderful world of TCP.

"...and client-side rendering."

Once upon a time, there was a thing called a Sun Ray (https://en.wikipedia.org/wiki/Sun_Ray), basically a (non-3d) graphics card glued to an ethernet card, that was used as a thin client for a Sun server. I didn't see one until after I'd used an IBM X-terminal (a smallish pizzabox that ran the X server and pointed everything else at a bigger IBM box) for several years and the latter was much better than the former.

[1] Protobuffs, et al., notwithstanding.

> Nobody has ever explained to me what it means, what its goals are, what constraints it has on the system or the protocol

You answer it later on. They want something like NX. We can fill in the details as one pleases.

> We know how to design much more resilient systems than that.

I think you are overstimating the progress of computer/network engineering. Anyway, CORBA's "transparency" might be a thing of the past, but what's the point here? Unless you plan to make a graphics API explicitly asynchronous, what alternatives you have? Sending PostScript over the wire? :/

The users want graphic primitives sent through the wire. There is not much alternative other than CORBA style RPC.

> Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years

That is not true. See how many commercial Qt engagements were stuck with Qt 4 because Qt 5 initially forced to use Qt's local rendering and only pushing the final pixmap to the server. Multi-million CAD machines slowing down to a halt because the clients were suddenly sending megabits through the pipes * . Eventually they had to backpedal and Qt5 now offers coreX/Xrender rendering too. _Most_ toolkits _to this day_ still render with X by default, and people do notice when this changes (see Mate). Sure there are exceptions and likely amongside the most used software (e.g. browsers), but I'd hardly claim "anything but MIT-SHM is all that matters for the past 20 years".

> is a network-designed fork of the protocol,

Yet compatible (to a high degree, at least). Up to the point the "transparency" illusion is maintained.

> Problems like remote desktop and streaming can be solved by other solutions

The biggest problem is that once you drop the codeflow on most opensource programs that renders using X, it's code that's rotten forever, and this entire method of "network transparency" will never be workable again in the free desktop world. Everyone and their mother will draw in a different way.

We'll have to resort to full video streaming or the like that have their own share of disadvatanges. There is absolutely no technical reason behind this, it's just a "code is done by volunteers" problem.

* And please don't say VNC/video here, since this is CAD. It's mostly a several megapixel black bitmap with a couple million white lines rendered on it. Relatively easy for a "drawing primitives over the wire" solution, insane for anything that tries to encode it as realtime video.

Yes...this is one of the key innovations that X had that probably isn't so useful now. Efficient use of memory was critical. In the mid-1990s, low end Sun's could actually ship as a supported config with 24-bit video and as little as 20MB of memory (16M system ram + 4M vsimm) like the the SX/CG14 in the SS20. There were 24-bit cards for earlier, mc68k Suns that could run in even less, but were more for rendering and of questionable utility for interactive use.

Another thing this efficiency allowed was the X Terminal. It was something akin the a serial terminal but running X, modest processor and memory, diskless (some had floppies for file transfer), usually running a couple of built-in local clients (xclock, etc), and costing far less than a full workstation. Most of them I recall being either monochrome or 8-bit color, but around this time I had an NCD X Terminal with 24-bit graphics, a MIPS processor and 16M ram + 8M vram, and network (streaming) audio for about a fraction the cost of an SGI Indy. Nice machine.

Xpra has a way to do this: https://xpra.org/trac/wiki/Clients/HTML5

There's a similar thing for Wayland too: https://github.com/udevbe/greenfield

And GTK has yet another way to do this built-in, that uses its own protocol: https://developer.gnome.org/gtk3/stable/gtk-broadway.html

I guess the first question is how much people spend.

Millennials spend a fair bit it seems.

$112 a month

https://venturebeat.com/2019/06/06/superdata-millennials-spe...

This makes a console between 2 and 4 months of gaming budget.

A network focused console still requires sone hardware or runs on a pc that costs more than most consoles.

The big benefit would appear to be killing the secondary markets for used games dead which is a hard benefit to sell to your users. It also only saves you money up front as they pretty much must charge more than a console over time to cover their own costs.

Then you have the problem of latency which can only be rendered slightly less crappy with substantial hardware at the isp, unpredictable demand hello covid, and annoying Netflix like account sharing.

The real problem is that the more money your target audience has the better off they would be buying a desktop pc. Nothing up front sounds great to someone who can afford to pay 20 a month but then you can't eat. If someone can pay 99 why not buy a Playstation or pc?

I predict it's a bad idea whose time will never come.

For which X is entrely inappropriate and needs a completely different approach.