XPlain – Explaining X11 for the rest of us | Hacker News Reader

XPlain – Explaining X11 for the rest of us

magcius.github.io

329 pointsemillon65 comments

Actually embedding an X server in the article is one of the coolest things I've seen in a while.

That's a seriously awesome piece of work. I'm sure it could be used for more things than demos.

X11's client-server model is seriously underappreciated, and the continuing efforts to make X behave exactly like Microsoft Windows frequently forget about network transparency.

Conversely, trying to make X behave like Microsoft Remote Desktop is often unreasonably painful. I've not yet seen a nice solution for detaching and reattaching X applications like screen(1)

I wrote the server from scratch JavaScript, and I can't verify its accuracy towards real server behavior:

https://github.com/magcius/xplain/blob/gh-pages/src/server/s...

It's fake in a lot of ways, especially in its input model. It's well-commented and designed as a codebase to learn from, not as a real implementation of an X server that's reusable.

Very cool.

Unfortunately, while it appears to run just fine under Safari, the window inspector is broken. It's not vertically splitting the area and putting the attributes on the right; it's horizontally splitting and putting the attributes below the window list, except there's no room to see any of the attributes like that.

It seems a real shame for the layout of the window inspector to be the only compatibility issue with Safari. Any chance you can get that fixed?

I don't know why, considering that it works fine under Firefox and Chrome. I don't have a Mac to test on here. Pull requests are welcome.

Actually, it turns out it's not even working right under Chrome either. The inspector isn't tall enough to show Properties, and it's not scrollable, so all I see is the "Properties" header with nothing under it. Here's what I'm seeing:

https://files.app.net/299dvuDv6.png

Is this supposed to scroll, or what?

Edit:

The issue with Safari is purely that the flexbox model requires the -webkit prefix, so it needs `display: -webkit-flex` and `-webkit-flex: 1`.

Edit 2:

I'll submit a pull request for the Safari issues shortly, I'm trying to see if I can figure out what's wrong with scrolling first.

Edit 3:

PR submitted. This fixes both Safari compatibility and scrolling for Chrome/Safari.

It looks like it is supposed to scroll -- but it doesn't in Firefox 26 or Firefox 30.

I don't think X11's network transparency is useful at all nowadays. RDP and VNC give much better results.

Wayland's model is much more likely to end up with useful network support.

Modern graphics simply does not scale across networks naively.

I don't think X11's network transparency is useful at all nowadays. RDP and VNC give much better results.

And yet every single time someone brings this up, plenty of people chime it that it is useful, because they're using it. Unless RDP and VNC have fixed their performance problems and don't break UI flow by putting the whole remote desktop in a separate window (instead of making windows for remote apps seamless), then many would contend that RDP and VNC don't give better results.

And yet Wayland keeps steamrolling over these objections. Oh well, at least they finally admitted that network support isn't just some useless toy that can be added on later, "if anybody even uses it".

> Unless RDP and VNC have fixed their performance problems

They are both much, much faster than X11. X11 has higher latency and uses significantly more bandwidth.

> by putting the whole remote desktop in a separate window (instead of making windows for remote apps seamless)

Many of the things that make modern desktops nice (like client-side decorations) make it hard to merge remote and local windows. It's not impossible (witness VirtualBox's attempt), but there are peculiar corner cases if you want to make it generic across platforms.

If you want a modern desktop that's fast on modern hardware (arguably its primary purpose), remote desktop will have to work RDP/VNC style.

I do 99% of my development in the office in an eclipse instance running on a remote server connected via LAN. It's completely seamless, you would have absolutely no way of knowing that it's not running locally. Having never use RDP, I can't rule out it's as good; I don't see how it could be better. VNC is laughably bad in comparison.

For working from home, we've got NX. Again, it mostly just works; I can't really tell that it's a non-local window. Again, I can't rule out though cannot imagine RDP does it better; some amount of latency is unavoidable via WAN; VNC would be excruciating.

This setup has been working fine for about 6 years now, btw.

I am also using NX (specifically, Nomachine's NX, an older version before they replaced everything with proprietary crap.) Right now for Linux, I think it is still the best thing going. I use it in full desktop mode, as if it were a VNC or RDP session. Offsite, there's very little latency or artifacting. Onsite, as you say, it's nearly indistinguishable.

They are both much, much faster than X11. X11 has higher latency and uses significantly more bandwidth.

In my experience, this hasn't been the case. Running Emacs via X full screened across two monitors (both at 1920x1080) is much snappier than running VNC from a Windows box, single screened, lower resolution (can't remember exact numbers just now) and lower BPP. Of course, that could just be the typical disparity in IO performance between Windows and Linux.

And while I grant that X sessions can't be detached by default, there are solutions for that (see XPra further up thread). There's also been compression for X quite some time. On top of all of this, you don't even have to be running an actual GUI on the serving end; can the same be said for RDP and VNC? Or Wayland?

> Running Emacs via X

Emacs is a relatively simple application, which behaves very differently than, say, Firefox.

More significant difference is that Firefox doesn't care about remote performance, emacs does.

Modern hardware is measured by the rack in server rooms. Nothing that fits under my desk is really relevant beyond twitch games.

If your concept of "network transparency" is "remote desktop", then you're undoubtedly right. But that's not the only use case for X11 (or even the one it was developed for). Many of us are just fine pushing an individual app back to our display without having to load up VNC.

I don't know why people keep thinking that Wayland won't have remote display support, considering we already wrote the code and demoed it.

http://cgit.freedesktop.org/~krh/weston/log/?h=remote

https://www.youtube.com/watch?v=L8zwnqKysfI#t=4371

Perhaps because for the longest time it was being said it wouldn't be supported; the FAQ still says no network transparency:

http://wayland.freedesktop.org/faq.html

I can understand and emphasize with the feeling that X is way too crufty and needs a re-write; and I know I've done jack-all to contribute (haven't had the time); but I wish that the lessons of history wouldn't be so quickly forgotten and people might ask themselves why X has hung on so long and is so beloved.

I realize that the Wayland developers worked on X, and recognize their expertise and hard work. I have high hopes for Wayland! But I also chose Linux because it doesn't lock me into options (like one window manager), and it's just so gosh darn flexible I can use it for everything from embedded systems to servers, smartphones, clusters, supercomputers and desktops, all being able to export GUI apps in individual windows, without them having to be specially written, even if the sending side doesn't have a graphics card. To lose that would be disappointing to say the least.

I wouldn't use "beloved" to describe X, not when even its developers say "it's time to switch to Wayland".

As for Linux and choice, its desktop market share is barely above statistical noise. Platforms which limit choice, such as Windows and Mac, are much more widely used. This is because, as it turns out, consistency is preferable to choice when developing a platform. It makes it easier to run new desktop apps, it makes software integration easier, and it even makes requisitioning IT or devops personnel easier because their skills more readily translate between jobs and environments.

So the chaos of development in the 90s is settling into a focus on a few well-supported software components. This includes systemd for the startup daemon and Wayland for the display server. Everything else will be in semi-legacy status, and you will see brokenness or limited functionality in other software if you stray from the community-accepted path.

Welcome to life with a mainstream, modern operating system.

"No network transparency" is still true of the Wayland protocol. However, compositors (such as Weston) can forward windows over the network. I think this is where most of the confusion comes from.

There's a very big difference between network transparency and remote display. The FAQ is misleading about this, though. It's long needed an update. Perhaps I'll get to rewriting it one of these days.

The absolute curbstomping of the rest of the Unix workstation market by Mac OS X should put the lie to the notion that network-transparent display is in any wise essential. Beautiful, pixel-perfect, tear-free GUIs are much more important.

And anyway, even if you need remote display, network support isn't necessary in the core protocol. You can get networked display by having a Wayland compositor that runs on the remote end and communicates with a Wayland client on the local end in any number of better-than-X11 protocols: rdp, vnc, frickin' streaming h.264. And remote apps don't even have to know that they're being displayed remotely.

>> ...should put the lie to the notion that network-transparent display is in any wise essential. Beautiful, pixel-perfect, tear-free GUIs are much more important.

OSX comes pre-installed with an X server, which should put the lie to the notion that you can't have both. I don't know my way around this issue at an extremely low level, such as if I'd worked on the guts of an X server; however, I'm perfectly able to believe that video hardware has evolved capabilities that X11 just can't support properly. It also seems somewhat dubious that the subsystem that provides access to the video hardware needs to be coupled to a network protocol. It seems like, in principle, you could layer one atop the other and get the same -- or better -- result. Now, if GUI applications weren't forced to deal with X, then client support for X might start to erode as applications chose to go around it. But, how bad would that be? Is preventing it worth the opportunity cost?

OS X no longer comes preinstalled with an X server. Most Mac users are capable of getting along perfectly fine without it -- even developers. And anyway, X11 apps in Mac OS X are like weeaboos on the streets of Tokyo: no matter how earnestly they try to assimilate, they stand out like sore, awkward thumbs and obviously don't belong there.

If you want to develop beautiful apps on the Mac platform you use Cocoa -- not X. Apple decided against basing its graphics stack on X11 for sound technical reasons.

>> Apple decided against basing its graphics stack on X11 for sound technical reasons.

and even still, X runs on OSX just fine, AFAIK (please correct me if I'm wrong -- anyone). The X server could stand to have been a little more seamlessly-integrated into OSX from a usability standpoint, IME. But from a purely technical perspective it seemed to be fine.

And it'll also run on Wayland, in a similar manner. No loss there.

Wayland knows the framebuffer of every application running in it. There's no reason the compositor can't export windows on a window by window basis.

This is actually how Xpra (mentioned earlier) works. It creates a dummy x server and installs itself as a compositing window manager.

In fact, they have fixed it. Well, RDP has; I don't know what the state of the art is for VNC implementations. Microsoft's "RemoteApp" does exactly what you describe.

> Unless RDP and VNC have fixed their performance problems

Well, they always felt faster to me than X-Windows.

Yes, a lot of people say it's useful

However, I never managed to configure it in a way it's workable and not very slow even in local connections

I am surely missing something, and I find VNC easier to configure (especially if you have to force a low quality for crappy connections)

It is when you have a networked device that speaks X protocol. They were common in the 90's for test equipment and many are still useful today. These sort of legacy devices can't use newer alternatives.

This is an ongoing complaint I have with X: remote desktop on Windows systems is still far superior to Linux systems.

Not if you use X11rdp.

I should really do a Show HN of my X11rdp-o-Matic script, which automatically builds and installs X11rdp/xrdp from the github repo - it's been in existence for 2 years and I update the script(s) with enhancements from time to time.

xrdp and the X11rdp back-end X server is in constant and full development, with an actual Xorg module being worked on as well.

Edit: Indeed, I just submitted a Show HN at https://news.ycombinator.com/item?id=8021592

Have you tried Xpra?

It bills itself as "screen for X"

https://www.xpra.org/

I love xpra and used to use it every day (using a Mac laptop now and haven't figured out how to make xpra not suck on it w.r.t. modifier keys and dock / cmd-tab support).

A big problem with xpra in myind is that the wire protocol doesn't even try to be version independent. If you're using slightly different versions on client and server, it just falls down.

If you're using distro packages this is fine e as long as all clients and servers are similar enough to have overlap in the versions that they package. Otherwise you're building from source on every client and server, on various platforms.

Ah, the magic of X. I've done my first steps into X by programming a graphical FTP client on a SGI Indy 2 under IRIX. It was 1994 and I spent about 3 weeks and I had luck to get the O'Reilly X books [0] ( and other two, can't remember ).

[0] http://shop.oreilly.com/product/9781565920156.do

I hope Wayland innards gets similar efforts to be explained and publicised with this same level of quality as this piece on venerable x11.

I'm trying: http://blog.mecheye.net/2014/06/xdg-shell/

Really, a big part of Wayland is that there isn't much there. It's not a ridiculously complicated system to explain with lots of extensions, you're just having clients pass image files around and get streams of messages for input. The easiest way to get a feel for the system is to use the built-in protocol dumper:

  $ WAYLAND_DEBUG=client weston-terminal

... or so... and that's it, that's the entire system.

If anybody has any more questions on Wayland internals, I'll certainly consider writing a series of articles on it.

Interesting, that's the most positive thing I've heard about Wayland so far (much simpler system).

What else have you heard about Wayland?

Guaranteed perfect frames. Compositor built in. Both awesome.

It's simple and slim, and therefore hopefully more performant.

And then there was some drama about client side windows decorations, that I didn't quite get.

The protocol doesn't specify decorations. It is up to the compositor. The reference one, Weston, was using client side (I think Mutter is doing that too) while Kwin is using server side.

It is a personal choice. And Wayland the windowing system doesn't care what you do - its decoration agnostic.

That's not necessarily true. If your toolkit and compositor don't agree on whether you're using client-side or server-side decorations, then you're going to see either double decorations or no decorations.

Most of the core Wayland team believes that client-side decorations is the technically superior approach for efficiency and accuracy reasons, and we're disappointed KDE is still pushing for server-side decorations.

There is currently no protocol to negotiate between the toolkit and compositor whether to use client-side or server-side decorations. And I can't see one being added in the near future, either.

It's not a ridiculously complicated system to explain

So I don't know much about the wayland architecture outside of the docs and Daniel Stone's linux.conf.au talk on it. It seemed like a clean and smart replacement to what X has become, after using it for a while have you run into any serious limitations or is everything still going along smoothly?

I've poked my head in a few times, but is there anywhere good to keep up on progress other than the mailing lists?

There's no serious limitations that I've ran into. I have a variety of very minor gripes with certain parts of the protocol, and there certainly are parts of it that are a bit underdeveloped, but we're moving forward on a lot of these.

Nice piece. And a quicky, can a compositor be a client of another?

Sure. Weston has a nested backend for this use case, and I'm told that KWin is going to do the same thing, because they don't want to fiddle with DRM/KMS directly.

http://cgit.freedesktop.org/wayland/weston/tree/src/composit...

This article was last updated in May 2014:

https://github.com/magcius/xplain/commits/gh-pages

I have plans and some code for the next article, but I've been busy with actual real work. I promise you'll see it before the end of the year.

Sorry, I should have been more clear. I was pleasantly surprised by how recent the updates are and many commits there were. Keep up the good work!

Beautifully done; the writing style, the server running inside my browser - wow!

I haven't been so excited about a piece of software for ages. Reading this and looking at demos gives me the same feeling of amazement I got reading paper magazines when I was younger. Exploring floppies included with books, hearing the modem connecting for the first time, short pause, stream of characters before the login prompt. Magical.

Thank you Jasper_ for doing this and emillion for the link.

Slightly unrelated, but does all of this recent github hacking for blogs/books/etc remind anyone else of myspace?

I chose GitHub because it's an easy way to publish a static website that I don't have to rsync: contributors can fix a typo and I press a button on the website and things are automatically deployed.

It's a super convenient workflow for me, and there's nothing else like it in my opinion. If there is, please let me know! I hate rsync / scp for deploying static sites, but that's the best thing we have right now.

I'm not saying it's a bad thing. I really just meant it as a comment. Hacking the layout just reminded me of those good old myspace profile days. No I'm not "hating". Everybody does this these days. I just think it's interesting.

The article about the linux graphics stack that he links right at the beginning is also very interesting.

What are some other good resources for learning X? It seems like quite the dark art.

You can look here, they have a tutorial and a web version of the XLib Manual:

http://tronche.com/gui/x

I would recommend against the Tronche site for references. It was automatically converted, but there are sometimes fields missing in places. I've tried emailing him, but the email address is disconnected. You can find reference documentation officially here:

http://www.x.org/releases/current/doc/libX11/libX11/libX11.h... http://www.x.org/releases/current/doc/xorg-docs/icccm/icccm....

I haven't read the tutorial, so maybe that's perfectly OK.

> you might remember that Xorg was forked from XFree86 a decade ago

Today's xkcd is relevant :( ( http://xkcd.com/1393/ )

Ah, by the title I thought it's about crypto currencies and X11 algorithm...

X11 is a protocol, not an algorithm.

Thanks for the correction! And I wondered why I got all those downvotes...

Well, the downvotes might also be from the perceived snark.

Reply on news.ycombinator.com