Danjou: Thoughts and rambling on the X protocol [LWN.net]

Julien Danjou shares some thoughts about X, XCB and X11. "Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades." (Thanks to Paul Wise)

to post comments

Ranting on the X protocol

Posted Jun 1, 2010 20:35 UTC (Tue) by clugstj (subscriber, #4020) [Link] (73 responses)

23 years is an eternity in the Software realm. Anything that has existed that long MUST have done a lot of things right.

Kids these days... ;^)

Ranting on the X protocol

Posted Jun 1, 2010 23:22 UTC (Tue) by jg (guest, #17537) [Link] (72 responses)

What we did right was (some) thought about designing for extension, and the separation of most UI from the base window system (e.g. X Window managers). This allowed for a decent evolutionary path.

At this point, however, one of X's biggest features is moribund: network transparency is a really good thing, and has been lost. And X11 was at best designed for campus scale transparency; we did not do a good job avoiding round trips that causes major performance problems when on WAN's.

However, if I had a chance to do another distributed UI system, it would look <b>radically</b> different than X (though able to run X on top in the style of rootless applications, as has been done on both Mac and Windows).

I've been stewing hard about what this might look like, between work we did at CRL prior to its destruction, and sparked much more intently recently by exposure to the ideas in CCNx (see www.ccnx.org), which has to be the most interesting networking technology I've seen in 20 years.

Maybe this summer I'll have a few minutes to blog about the ideas; the last 18 months has been more than chaotic to me.

Ranting on the X protocol

Posted Jun 1, 2010 23:41 UTC (Tue) by rriggs (guest, #11598) [Link] (46 responses)

I have a number of X11 IDEs that I try to publish for users to run and evaluate on their own desktops. Most of them work fine locally, mostly work when run on another remote Gnome or KDE desktop, and dump core when run remotely on a generic X server (e.g. Hummingbird Exceed).

It's really a sad state of affairs at the moment.

Ranting on the X protocol

Posted Jun 2, 2010 0:26 UTC (Wed) by nix (subscriber, #2304) [Link] (45 responses)

And everything now depends on D-Bus, which *intentionally* avoided any attempt at network-transparency. So if you want to run things on another host, and they use D-Bus... you pretty much can't.

Nice halfassed job, guys. :(

Ranting on the X protocol

Posted Jun 2, 2010 6:18 UTC (Wed) by paulj (subscriber, #341) [Link] (44 responses)

I think you mean "hasn't been implemented". Neither buses nor objects on it are named by host, so there's no great API reason why you couldn't implement a proxy, methinks. Just a matter of hacking :).

Ranting on the X protocol

Posted Jun 2, 2010 11:33 UTC (Wed) by nix (subscriber, #2304) [Link] (43 responses)

Last time I asked about this I was told that for security reasons cross-host buses would *never* be implemented, and any patches to add it would be rejected out of hand. Maybe this policy has changed...

Ranting on the X protocol

Posted Jun 2, 2010 13:42 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Would that apply even to patches to port DBus over an existing secure link?

Ranting on the X protocol

Posted Jun 2, 2010 14:12 UTC (Wed) by mjthayer (guest, #39183) [Link]

> Would that apply even to patches to port DBus over an existing secure link?

If ssh were adapted to forward DBus too, would DBus even need to be patched?

Ranting on the X protocol

Posted Jun 2, 2010 15:12 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (37 responses)

We did network transparent DBUS few years ago. Simply by using network-transparent UNIX socket layer.

Nothing in DBUS' design precludes the possibility of network transparency. It's just that people are disenchanted about it after CORBA, NFS and X11 fiascoes.

Really, you either should design protocols for WAN in the first place or don't even try to be 'network transparent'.

Ranting on the X protocol

Posted Jun 2, 2010 16:42 UTC (Wed) by nix (subscriber, #2304) [Link] (36 responses)

What's a 'fiasco' about X11? It works perfectly well.

I'd agree that the right way to do this would probably be to teach SSH to proxy the thing: is there an environment variable like DISPLAY that D-Bus clients can use to find their server, though?

Ranting on the X protocol

Posted Jun 2, 2010 16:48 UTC (Wed) by paulj (subscriber, #341) [Link]

DBUS_SESSION_BUS_ADDRESS seems to be one.

Ranting on the X protocol

Posted Jun 2, 2010 17:04 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Unfortunately, X11 is not really good. It can't pass through firewalls and even a small latency kills it. If your network address changes (reconnection after network failure on 3G), it hangs.

Fixing these problems is not trivial.

So VNC over the network is way better. Nowdays, I prefer to just start vnc4server on the target host and use vncviewer to connect. It works everywhere, goes through firewalls easily, and has good enough latency.

Ranting on the X protocol

Posted Jun 3, 2010 13:58 UTC (Thu) by rriggs (guest, #11598) [Link] (3 responses)

VNC cannot export a single application. It exports an entire desktop. Which means that every user has to have a full desktop environment running just to run one application. This doesn't work at all in a server environment where you have many people trying to run an X application on their desktop from the same host.

Ranting on the X protocol

Posted Jun 3, 2010 14:56 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

"VNC cannot export a single application"

It can. VirtualBox uses this functionality.

Ranting on the X protocol

Posted Jun 3, 2010 19:55 UTC (Thu) by wahern (subscriber, #37304) [Link]

http://www.tightvnc.com/Xvnc.1.php

Ranting on the X protocol

Posted Jun 10, 2010 5:08 UTC (Thu) by mfedyk (guest, #55303) [Link]

Virtualbox uses RDP, which can export one application.

Can you give an example of using VNC to forward one application without the surrounding desktop (ie, rootless)?

Ranting on the X protocol

Posted Jun 2, 2010 23:25 UTC (Wed) by roc (subscriber, #30627) [Link] (29 responses)

X11 does not work well. It is a fiasco.

X penalizes the performance of local applications by forcing you to communicate with the X server over a socket where other window systems can do the work with a user-space library, kernel module or customized fast IPC. X effectively is penalizing local applications in order to support network transparency.

But then X bungles network display by being horrendously bandwidth-inefficient and intolerant of latency, especially over WANs. That's why VNC and rdesktop are much more pleasant to use than remote X.

X11: The Worst Of Both Worlds.

Ranting on the X protocol

Posted Jun 3, 2010 1:00 UTC (Thu) by jonabbey (guest, #2736) [Link]

Local socket communications are *extremely* fast, though, and X has had support for shared memory image transfer between the client and the server on the local desktop for a very long time.

The problem isn't the network transparency.

Ranting on the X protocol

Posted Jun 3, 2010 9:25 UTC (Thu) by modernjazz (guest, #4185) [Link] (27 responses)

> X penalizes the performance of local applications by forcing you to communicate with the X server over a socket

This myth has been debunked many times---profiling shows that socket communication accounts for an absolutely negligible fraction of the problem. For local applications, the real issues tend to be inadequacies in the way video hardware is used, which is why this area has received so much attention (but still isn't complete) over the last few years.

I agree with the latency problems over WAN, though. For anything beyond LAN I use NX, which I like much better than VNC. Back when I had a 54k modem, NX was still somewhat usable, whereas nothing else was. NX proves the (perhaps unsurprising) fact that there is some value in a protocol that doesn't just rasterize everything.

Ranting on the X protocol

Posted Jun 3, 2010 12:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (26 responses)

"This myth has been debunked many times---profiling shows that socket communication accounts for an absolutely negligible fraction of the problem."

No. Socket communication is fairly slow. X becomes fast if shared memory is used to transfer images - i.e. if you forget about network transparency.

And if you really want to do it, then moving graphics to the kernel (like Windows did) can make your system even faster. I quite distinctly remember that X was unbearably slow compared to Windows in 90-s. Today overhead is pretty small, but it's still there.

Anyway, way forward seems to be client-side direct drawing using OpenGL. In this way X effectively only manages window frames and input events.

Ranting on the X protocol

Posted Jun 4, 2010 4:15 UTC (Fri) by rqosa (subscriber, #24136) [Link] (19 responses)

> Socket communication is fairly slow.

Compared to what? Unix domain sockets should have about the same performance as any other type of local IPC, except for shared memory.

> X becomes fast if shared memory is used to transfer images - i.e. if you forget about network transparency.

But that's beside the point the two posters above were trying to make, which is this: contrary to what "roc" said, X's capability for network transparency does not "[penalize] the performance of local applications".

> moving graphics to the kernel (like Windows did)

Didn't it move back to userspace in Vista?

> can make your system even faster

It might reduce the amount of context-switches slightly, but it's bad for system stability and security.

> Anyway, way forward seems to be client-side direct drawing using OpenGL.

What's wrong with the AIGLX way?

Ranting on the X protocol

Posted Jun 4, 2010 5:30 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (18 responses)

"Compared to what? Unix domain sockets should have about the same performance as any other type of local IPC, except for shared memory."

Windows-style message passing, for example.

"But that's beside the point the two posters above were trying to make, which is this: contrary to what "roc" said, X's capability for network transparency does not "[penalize] the performance of local applications"

But it does. X penalizes local application, it's just that the workaround for this is so ancient that it is though of as normal.

"Didn't it move back to userspace in Vista?"

Partially. They now moved some parts to userspace to reduce number of context switches. Vista still has user32 subsystem in the kernel.

"It might reduce the amount of context-switches slightly, but it's bad for system stability and security."

Ha. X used to be the most insecure part of the OS - several megabytes of code running with root privileges and poking hardware directly.

KMS has finally fixed this by moving some functionality to the kernel, where it belongs.

And AIGLX is a temporary hack, good DRI2 implementation is better.

Ranting on the X protocol

Posted Jun 4, 2010 7:19 UTC (Fri) by rqosa (subscriber, #24136) [Link] (17 responses)

> Windows-style message passing, for example.

Do you have numbers from a benchmark to support that statement? And is there any property of the API that makes it inherently faster than the send(2)/recv(2) API? (When using Unix domain sockets, all that send(2)/recv(2) does is to copy bytes from one process to another. How can you make it any faster, except for using shared memory to eliminate the copy-operation?)

> X penalizes local application, it's just that the workaround for this is so ancient that it is though of as normal.

You're contradicting yourself. If the "workaround" exists, then the "penalty" doesn't exist.

> Ha. X used to be the most insecure part of the OS - several megabytes of code running with root privileges and poking hardware directly.

> KMS has finally fixed this by moving some functionality to the kernel, where it belongs.

One of the major benefits of KMS is that it can get rid of that need for the X server to run as root and access the hardware directly. Moving the windowing system into the kernel, like you're suggesting, would throw away that benefit.

> And AIGLX is a temporary hack, good DRI2 implementation is better.

How is it "better"?

Ranting on the X protocol

Posted Jun 4, 2010 8:14 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (16 responses)

>Do you have numbers from a benchmark to support that statement? And is there any property of the API that makes it inherently faster than the send(2)/recv(2) API? (When using Unix domain sockets, all that send(2)/recv(2) does is to copy bytes from one process to another. How can you make it any faster, except for using shared memory to eliminate the copy-operation?)

Quick-LPC in Windows NT ( http://windows-internal.net/Wiley-Undocumented.Windows.NT... ). It was waaaay better than anything at the time. It's phased out now, because overhead of real LPC is not that big for modern CPUs.

>> X penalizes local application, it's just that the workaround for this is so ancient that it is though of as normal.
>You're contradicting yourself. If the "workaround" exists, then the "penalty" doesn't exist.

No, penalty is right there - in the architecture. It just can be worked around.

>>One of the major benefits of KMS is that it can get rid of that need for the X server to run as root and access the hardware directly. Moving the windowing system into the kernel, like you're suggesting, would throw away that benefit.

I'm not suggesting moving the whole windowing system, it makes no sense _now_.

Vista is 100% correct in its approach (IMO). Each application there, in essence, gets a virtualized graphics card so it can draw everything directly on its surfaces. And OS only manages compositing and IO.

So we get the best of both worlds - applications talk directly to hardware (it might even be possible to make a userland command submission using memory protection on recent GPUs!) and windowing system manages windows.

>> And AIGLX is a temporary hack, good DRI2 implementation is better.
>How is it "better"?

Faster, less context switches, etc. And if you try to accelerate AIGLX - you'll get something isomorphic to DRI2.

Ranting on the X protocol

Posted Jun 4, 2010 9:58 UTC (Fri) by rqosa (subscriber, #24136) [Link] (15 responses)

> Quick-LPC in Windows NT ( http://windows-internal.net/Wiley-Undocumented.Windows.NT... ). It was waaaay better than anything at the time. It's phased out now, because overhead of real LPC is not that big for modern CPUs.

The first reason why it says that Quick LPC is faster than regular LPC, "there is a single server thread waiting on the port object and servicing the requests", does not exist for Unix domain sockets. For a SOCK_STREAM socket, you can have a main thread which does accept(2) and then hands each new connection off to a worker thread/process, or you can have multiple threads/processes doing accept(2) (or select(2) or epoll_pwait(2) or similar) simultaneously on the same listening socket (by "preforking"). For a SOCK_DGRAM socket, (unless I'm mistaken) you can have multiple threads/processes doing recvfrom(2) simultaneously on the same socket (again, preforking).

As for the second reason, "the context switching between the client thread and the server thread happens in an "uncontrolled" manner", that is also the way it is for Unix domain sockets, but is that really a problem? If "the thread waiting on the signaled event is the next thread to be scheduled", then what would prevent a pair of malicious threads from hogging the CPU by constantly sending messages back and forth?

> No, penalty is right there - in the architecture. It just can be worked around.

If it's possible for local clients to be fast, then there's no "penalty". ("Penalty" would mean that the capability for clients to be non-local prevents local clients from being fast. But it doesn't, because local clients can use things that remote processes can't, like shared memory, etc.)

> Each application there, in essence, gets a virtualized graphics card so it can draw everything directly on its surfaces. And OS only manages compositing and IO.

X can work essentially that way too, except that compositing is done by another user-space process (a "compositing window manager"). Each application using OpenGL generates a command stream which is sent to the driver and rendered off-screen, and then the compositing window manager composites the off-screen surfaces together. Alternately, 2D apps can use OpenVG instead of OpenGL (at least, they should be able to fairly soon; is OpenVG supported in current Xorg and current intel/ati/nouveau/nvidia/fglrx drivers?)

Ranting on the X protocol

Posted Jun 4, 2010 10:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

"As for the second reason, "the context switching between the client thread and the server thread happens in an "uncontrolled" manner", that is also the way it is for Unix domain sockets, but is that really a problem? If "the thread waiting on the signaled event is the next thread to be scheduled", then what would prevent a pair of malicious threads from hogging the CPU by constantly sending messages back and forth?"

Quick-LPC had special hooks in scheduler. You could hog CPU, of course, but that was not a big deal at that time. It's so no big deal that you still can do this in Windows and up until several years ago in Linux: http://www.cs.huji.ac.il/~dants/papers/Cheat07Security.pdf :)

Also, Quick-LPC had some special hooks that allowed NT to do faster context switches. I remember investigating it for my own purposes - it was wickedly fast, but quite specialized.

"X can work essentially that way too, except that compositing is done by another user-space process (a "compositing window manager")"

And by that time only a hollow shell of X remains. About the same size as Wayland. So it makes sense to ditch X completely and use it only for compatibility with old clients. Like Apple did in Mac OS X.

"Each application using OpenGL generates a command stream which is sent to the driver and rendered off-screen, and then the compositing window manager composites the off-screen surfaces together."

And where's the place for network transparency? Remote GLX _sucks_ big time. It sucks so hopelessly that people want to use server-side rendering instead of trying to optimize it: http://www.virtualgl.org/About/Background

"Alternately, 2D apps can use OpenVG instead of OpenGL (at least, they should be able to fairly soon; is OpenVG supported in current Xorg and current intel/ati/nouveau/nvidia/fglrx drivers?)"

OpenVG is partially supported by Gallium3D.

Ranting on the X protocol

Posted Jun 4, 2010 11:19 UTC (Fri) by rqosa (subscriber, #24136) [Link] (11 responses)

> And by that time only a hollow shell of X remains.

If you put it that way, then it's pretty much already the case that "only a hollow shell of X remains"; XRender has replaced the core drawing protocol, and compositing window managers using OpenGL and AIGLX are already in widespread use. So the next step is probably to replace XRender with OpenVG for 2D applications, to offload more of the work onto the GPU. (An OpenVG backend for Cairo has been around for some time already.) And maybe another next step is to have GPU memory protection replace AIGLX, like you suggested, in the case of local clients.

> So it makes sense to ditch X completely and use it only for compatibility with old clients. Like Apple did in Mac OS X.

An X server that supports OpenGL/OpenVG + off-screen rendering + compositing should be able to perform as well as anything else (when using clients that do drawing with OpenGL or OpenVG), while at the same time retaining backwards compatibility with old clients that use XRender and with even older clients that use the core protocol. So there's no good reason to drop the X protocol.

> And where's the place for network transparency? Remote GLX _sucks_ big time. It sucks so hopelessly that people want to use server-side rendering instead of trying to optimize it: http://www.virtualgl.org/About/Background

What about 2D apps using OpenVG? If desktop apps that don't require very high graphics performance (for example Konsole, OpenOffice, Okular, etc.) migrate from XRender to OpenVG, then it seems like it would be useful to make the OpenVG command stream network-transparent, because performance should be adequate to run these clients over a LAN.

As for remote-side rendering for remote GLX clients: what GLX clients would anyone actually want to run remotely? It seems like most apps that need fast 3D graphics would be run locally.

Ranting on the X protocol

Posted Jun 4, 2010 12:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

""If you put it that way, then it's pretty much already the case that "only a hollow shell of X remains"; XRender has replaced the core drawing protocol, and compositing window managers using OpenGL and AIGLX are already in widespread use. So the next step is probably to replace XRender with OpenVG for 2D applications, to offload more of the work onto the GPU. (An OpenVG backend for Cairo has been around for some time already.) "

Applications skip directly to OpenGL. QT right now even almost works, try running QT applications with "-graphicssystem opengl" switch. GTK has something similar.

"And maybe another next step is to have GPU memory protection replace AIGLX, like you suggested, in the case of local clients."

AIGLX is not necessary already with the open stack drivers which use DRI2. The main reason for AIGLX was impossibility of compositing of DRI1-applications - they pass commands directly to hardware. DRI2 fixed this by allowing proper offscreen rendering and synchronization.

"What about 2D apps using OpenVG? If desktop apps that don't require very high graphics performance (for example Konsole, OpenOffice, Okular, etc.) migrate from XRender to OpenVG, then it seems like it would be useful to make the OpenVG command stream network-transparent, because performance should be adequate to run these clients over a LAN."

Makes no sense, OpenVG is stillborn. It's already obsoleted by GL4 - you can get good antialiased rendering using shaders with double-precision arithmetic.

"As for remote-side rendering for remote GLX clients: what GLX clients would anyone actually want to run remotely? It seems like most apps that need fast 3D graphics would be run locally."

A nice text editor with 3D effects? :)

The problem with X is that it's crufty. It's single-threaded and legacy code has a non-negligible architectural impact (do you know that X.org has an x86 emulator to interpret BIOS code for VESA modesetting? I'm kidding you not: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/... ). So IMO it makes a sense to design "X12" protocol to break away from legacy and just run rootless X.org for compatibility.

Ranting on the X protocol

Posted Jun 4, 2010 12:58 UTC (Fri) by rqosa (subscriber, #24136) [Link] (7 responses)

> OpenVG is stillborn.

Says who?

> It's already obsoleted by GL4

And will ARM-based cell phones and netbooks be able to run OpenGL 4 with good performance?

> The problem with X is that it's crufty. It's single-threaded

Is there anything inherent in the X protocol that requires an X server to be single-threaded? I doubt it.

Also, if the X server no longer does the rendering (replaced by GPU offscreen rendering), then does it really matter if the X server is single-threaded?

> and legacy code has a non-negligible architectural impact (do you know that X.org has an x86 emulator to interpret BIOS code for VESA modesetting? I'm kidding you not: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/... ).

That's probably not used much any more (not used at all with KMS). And if you're already not using it, why should you even care whether it exists?

Ranting on the X protocol

Posted Jun 4, 2010 13:59 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

>> OpenVG is stillborn.
>Says who?

Me, obviously.

http://www.google.com/search?q=OpenVG
About 45,600 results (0.32 seconds)

Oh, and Google too.

>> It's already obsoleted by GL4
>And will ARM-based cell phones and netbooks be able to run OpenGL 4 with good performance?

In a few years - yep. There's nothing in GL4 which makes it intrinsically slow.

>Is there anything inherent in the X protocol that requires an X server to be single-threaded? I doubt it.

And who's going to rewrite X.org? And it matters if server is single-threaded (because of input latency, for example).

And old legacy code in X.org does have its effect. For example, it's not possible to have tiled frontbuffer - because all of the code in X.org has to be rewritten. And X.org is LARGE.

Ranting on the X protocol

Posted Jun 4, 2010 20:12 UTC (Fri) by rqosa (subscriber, #24136) [Link]

> About 45,600 results (0.32 seconds)

How do those numbers prove anything? (Incidentally, a search for "Gallium3D" gives only "About 26,300 results".)

Also, if OpenVG is useless, then why are Qt and Cairo both implementing it?

> And who's going to rewrite X.org?

It's being rewritten all the time. Just look at how much has changed since X11R6.7.0.

> And it matters if server is single-threaded (because of input latency, for example).

I don't remember ever seeing users complaining about the input latency of the current Xorg.

Ranting on the X protocol

Posted Jun 5, 2010 18:13 UTC (Sat) by drago01 (subscriber, #50715) [Link]

http://lists.x.org/archives/xorg-devel/2010-June/009571.html

Ranting on the X protocol

Posted Jun 5, 2010 18:25 UTC (Sat) by daniels (subscriber, #16193) [Link]

For example, it's not possible to have tiled frontbuffer - because all of the code in X.org has to be rewritten. And X.org is LARGE.

This will probably come as a huge surprise to the >95% of desktop X users (all Intel, most AMD, all NVIDIA beyond G80) who have a tiled frontbuffer.

Ranting on the X protocol

Posted Jun 8, 2010 17:09 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

There is nothing intrinsic in the X protocol that requires the server to be single-threaded. In fact, the X Consortium spent a lot of effort in the 1990s making a multithreaded X server.

It was abandoned, because the locking overhead made it *slower* than a singlethreaded server.

Perhaps it is worth splitting the input thread out from a SIGIO handler into a separate thread (last I checked the work in that direction was ongoing). But more than that seems a dead loss, which is unsurprising given the sheer volume of shared state in the X server, all of which must be lock-protected and a lot of which changes very frequently.

Ranting on the X protocol

Posted Jun 10, 2010 12:37 UTC (Thu) by renox (guest, #23785) [Link] (1 responses)

>> Perhaps it is worth splitting the input thread out from a SIGIO handler into a separate thread <<

Could you explain?
The input thread needs to read the display state to pass the events to the correct applications, so there's also a kind of locking which must be done here: wouldn't this create the same issue as before?

Ranting on the X protocol

Posted Jun 14, 2010 20:12 UTC (Mon) by nix (subscriber, #2304) [Link]

Yes, some locking is still necessary, but perhaps not so much that the whole thing would be a dead loss (as happens if e.g. you try to handle each X client with a separate thread in the X server).

Ranting on the X protocol

Posted Jun 8, 2010 17:07 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Hang on. You're (IMHO correctly) promoting KMS/DRI2 over AIGLX/DRI1 because DRI1 passed commands directly to hardware, which is bad... but you're proposing direct hardware access as a way to fix the (unproven) 'slowness' of X?

I am confused. You seem to be contradicting yourself without need for any help from the rest of us.

Ranting on the X protocol

Posted Jun 9, 2010 11:07 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

No.

DRI1 passes commands directly to the card, but it can't be composited (no Compiz for you with DRI1).

AIGLX (which is used _without_ DRI1) passes commands through the X-server, but can be composited.

DRI2 passes commands directly to the card and can be composited.

Ranting on the X protocol

Posted Jun 8, 2010 17:05 UTC (Tue) by nix (subscriber, #2304) [Link]

Yeah, remote GLX sucks. So hopelessly that I just ran World of Goo remotely (which 2D app uses OpenGL to do its rendering) over a 1Gb LAN, without noticing until I quit that it was remote.

That's hopeless, that is.

Ranting on the X protocol

Posted Jun 5, 2010 20:09 UTC (Sat) by renox (guest, #23785) [Link]

>>As for the second reason, "the context switching between the client thread and the server thread happens in an "uncontrolled" manner", that is also the way it is for Unix domain sockets, but is that really a problem? <<

I would argue that for latency purpose the lack of cooperation between the scheduler and current IPCs can really be a problem.

>>then what would prevent a pair of malicious threads from hogging the CPU by constantly sending messages back and forth?<<
IMHO, there should be an IPC provided by the OS which would allow a process to say: deliver this message to this other process and run it as a part of my 'runtime quota'.
This wouldn't allow CPU hogging, and would provide lower latency, but note that for this to truly work, you still need that a shared server works on the message provided by the client who give the 'scheduling time' and not on something else..

Ranting on the X protocol

Posted Jun 4, 2010 16:54 UTC (Fri) by jd (guest, #26381) [Link] (5 responses)

Moving graphics to the kernel, eh? So we can assume you've tried the X11 drivers for kernel framebuffers and/or for KGI?

It's easy to say it would be faster, but context switches are expensive and therefore you need to make sure that you place the division between kernel and userspace application at the point where there would be fewest such switches. I've not seen any analysis of the code of this kind, so I'm not inclined to believe anyone actually knows where a split should be incorporated.

Personally, I remember X being considerably faster than Windows in the 1990s. I was using a Viglen 386SX-16 with maths co-processor, and X ran just fine. Windows was a bugbear. I was even able to relay X over the public Internet half-way across Britain and have no problems.

Ranting on the X protocol

Posted Jun 4, 2010 17:43 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

"Moving graphics to the kernel, eh? So we can assume you've tried the X11 drivers for kernel framebuffers and/or for KGI?

Read about KMS and DRI2, please.

"Personally, I remember X being considerably faster than Windows in the 1990s. I was using a Viglen 386SX-16 with maths co-processor, and X ran just fine. Windows was a bugbear. I was even able to relay X over the public Internet half-way across Britain and have no problems."

On a fast machine - sure. However, Windows 95 could be started on a computer with 3Mb of RAM (official minimal requirement was 4Mb) and ran just fine on 8Mb. Linux with X struggled to start xterm on that configuration.

Ranting on the X protocol

Posted Jun 4, 2010 19:01 UTC (Fri) by jonabbey (guest, #2736) [Link]

On the other hand, I remember using dedicated X Terminals against remote systems (VMS, early 90's Unix) that didn't even have graphics hardware.

Horses for courses.

Ranting on the X protocol

Posted Jun 4, 2010 19:12 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

On a fast machine - sure.

Hm. IIRC, in the 1990s, the previous poster's 386SX-16 wasn't a »fast machine« by any stretch of the imagination. It probably would have struggled with Windows 95, considering that Windows 95, according to Microsoft, required at least a 386DX processor (i.e., one with a 32-bit external bus).

Windows 95 could be started on a computer with 3Mb of RAM (official minimal requirement was 4Mb) and ran just fine on 8Mb. Linux with X struggled to start xterm on that configuration.

No. In 1994 my computer was a 33 MHz 486DX notebook with 8 megabytes of RAM – not a blazingly fast machine even by the standards of the time but what I could afford. I used that machine to write, among other things, a TeX DVI previewer program (like xdvi but better in some respects, worse in others) based on Tcl/Tk, with the interesting parts written in C of course, but even so. There was no problem running that program in parallel with TeX and Emacs, and in spite of funneling all the user interaction through Tcl it felt just as quick as xdvi, even with things like the xdvi-like magnifier window.

Five years before that, a SPARCstation 1 was considered a nice machine to have, and that ran X just fine, thank you very much. I doubt that the machine I was hacking on at the time had anywhere near 8 megs of RAM.

Ranting on the X protocol

Posted Jun 5, 2010 0:27 UTC (Sat) by jd (guest, #26381) [Link]

You're absolutely right, the 386SX-16 (a 16MHz 386 processor with a 387 co-processor) was not a "fast machine". It was also limited in memory - for some reason, the maximum was 5 megs of RAM.

Yet I was using X11R4, with OpenLook (BrokenLook?). I could open up to 20 EMACS sessions simultaneously before experiencing noticeable degradation in performance. When gaming, I'd have a Netrek server, Netrek client and 19 Netrek AIs running in parallel on the same machine.

Compiling was no big. GateD would sometimes cause OOM to kick in and kill processes, but I don't recall any huge difficulty. It was the machine I wrote my undergraduate degree project on (fractal image compression software).

Mind you, I paid huge attention to setup. The X11 config file was hand-crafted. Everything was hand-compiled - kernel on upwards - to squeeze the best performance out of it. Swap space was 2.5x RAM.

Ranting on the X protocol

Posted Jun 7, 2010 15:13 UTC (Mon) by nye (guest, #51576) [Link]

>Windows 95 could be started on a computer with 3Mb of RAM (official minimal requirement was 4Mb) and ran just fine on 8Mb

No.

Everyone not working for Microsoft stated a minimum of 16MB to run Windows 95. I actually tried running it on a computer with 8MB of RAM - as long as you had no applications running you might just about be able to use explorer to browse the filesystem, very slowly, but trying to launch an application would cause a 5 minute swap storm.

Ranting on the X protocol

Posted Jun 16, 2010 20:27 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

OK, that's mystifying. Cross-host buses will never be implemented, only, uh, they are. And they're even documented in the manpage! :) (grep for 'tcp' in dbus-daemon(1).)

I guess they found a secure way to do it, or decided the tradeoffs were worthwhile. Yay, cross-system KDE4 IPC calls, here we come!

Ranting on the X protocol

Posted Nov 5, 2010 20:51 UTC (Fri) by mgedmin (guest, #34497) [Link] (1 responses)

Can I please have ssh -X forward my DBUS session too?

Ranting on the X protocol

Posted Nov 5, 2010 21:11 UTC (Fri) by foom (subscriber, #14868) [Link]

Yeah, It'd sure be nice if DBus Just Worked with a remote display. It's is a pretty significant step backwards in terms of being able to run apps on remote machines...it worked fine for KDE's DCOP for years before...

Ranting on the X protocol

Posted Jun 2, 2010 14:17 UTC (Wed) by bronson (subscriber, #4806) [Link] (23 responses)

Hi Jim. Agreed, X11 has allowed an incredible amount of change. That's a definitely success.

But I disagree with you in one place: nobody cares anymore about X's network transparency! Even today setting up xauth is so unreliable and enough of a hassle that everybody I know just fires up VNC instead. Can't wait for spice.

With X, if there's a network blip, your apps all hang. With VNC, you can leave the office now and access your apps from the coffee shop 6 hours later. No forethought needed.

VNC feels MUCH faster, especially over today's 1Mbit 3G links. Remote X has weird terminology (which is the client and which is the server), and a weird auth setup that nobody wants to understand anymore.

Sample size of one, don't shoot the messenger. All I'm saying is this: as long as VNC and Spice are easier to use, feel faster, and are more reliable out of the box, very few end users are going to give a hoot about X's network transparency. I think the KDE and Gnome guys can be forgiven for chucking a poorly-implemented, seldom-used feature out the window.

Ranting on the X protocol

Posted Jun 2, 2010 15:25 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (5 responses)

"Remote X has weird terminology"

It's not "weird terminology". The program which starts first, ends last, and provides access to system resources (display, keyboard, mouse) is the server. The shorter-lived applications which connect to the server to make use of these shared resources are the clients. This is perfectly consistent with every other client/server arrangement out there.

What throws people is that we're used to thinking of servers as a particular type of *hardware*, steadily ticking away the CPU-hours in some climate-controlled back room, out of sight, whereas "clients" are the visible workstation PCs at everyone's desk. However, the X client/server terminology is perfectly reasonable from a *software* point-of-view, and X is software, not hardware.

Anyway, so long as X uses Unix-domain network sockets for IPC--a reasonable choice, even for purely local apps--it gets network transparency practically for free. I'd probably drop support for xauth and remote display managers in favor of SSH forwarding and Avahi service discovery, though, and extend SSH to forward D-Bus and PulseAudio by default along with X.

Ranting on the X protocol

Posted Jun 2, 2010 15:54 UTC (Wed) by mgedmin (guest, #34497) [Link] (2 responses)

PulseAudio is already transparently forwarded over ssh X11 forwarding, which I accidentally discovered when I ran mplayer over an ssh'ed connection and heard the music over my local speakers. I'm not sure how that works (a property on the X root window telling Pulse clients where to find the right Pulse server?), especially since it doesn't work for me any more when I try it _now_.

Ranting on the X protocol

Posted Jun 2, 2010 18:33 UTC (Wed) by njs (subscriber, #40338) [Link]

IIRC, there's a property on the X root window giving the *absolute network address* of the Pulse server. ssh isn't forwarding Pulse; it's just that if you're ssh'ing within a local, unfirewalled, network, then apps whose X stuff is forwarded through ssh will be able to make an additional direct connection to the pulseaudio server.

Ranting on the X protocol

Posted Jun 2, 2010 18:36 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

PulseAudio uses an X11 property to tell clients where the PA server is, so clients will automatically connect (directly, not via SSH) to the PA server started under the same X11 session. However, the PA server isn't necessarily persistent across the entire session, or started automatically on login, so what happens if the remote client starts PulseAudio on its own? (That may be your problem--the first time you already had PA running locally, and later it was started on the remote system by the client app.)

I think it would be better to forward the PA connections via SSH, as with X11 tunneling, so that no one can eavesdrop and there are no PA-specific issues with firewalls, etc. There is a PULSE_SERVER environment variable one can set to override the X11 property.

Ranting on the X protocol

Posted Jun 2, 2010 20:16 UTC (Wed) by RCL (guest, #63264) [Link] (1 responses)

It's weird design choice, in the first place. One that makes it hard to have persistent sessions or allow the same application to be broadcasted to multiple erm... "servers".

Ranting on the X protocol

Posted Jun 3, 2010 10:44 UTC (Thu) by nix (subscriber, #2304) [Link]

The fact that servers hold data on behalf of clients, and that clients often do not bother holding a copy of this themselves or responding to a disconnection by reconnecting and restoring the server state, makes it essentially impossible to implement persistent sessions in any case. (You can do it by interposing a persistent proxying X server that does not die, but that's not solving the problem, just pushing it onto another thing that must be persistent.)

I'm not sure how you could fix this without dropping *all* server-side state, which would be a performance catastrophe.

Ranting on the X protocol

Posted Jun 2, 2010 16:12 UTC (Wed) by martinfick (subscriber, #4455) [Link] (6 responses)

"nobody cares anymore about X's network transparency!"

Perhaps you don't, but I do (and I suspect that many others still do too), so please don't speak for others. Yes, many people have cell phones, but you might be shocked to find out that land lines are still very common also. :)

Yes, it is a pain to re-enable kdm to allow remote logins anytime I upgrade it, (for some reason, the old settings are never enough), but that is hardly X's fault, and surely it doesn't make me want to throw out the baby...

As for VNC, it never seems to work as well for me, last time I tried it, youtube videos were all blue... If it works for you, I am happy and I wouldn't want (or advocate) to take it away from you, I hope you could see it in you to return that sentiment.

Ranting on the X protocol

Posted Jun 2, 2010 16:21 UTC (Wed) by rsidd (guest, #2582) [Link] (5 responses)

As for VNC, it never seems to work as well for me, last time I tried it, youtube videos were all blue...

And youtube video works over X11 forwarding? How about the audio, over either X11 or VNC?

VNC works well for the cases it's meant for, and on slow links it's much faster than X11 forwarding.

Ranting on the X protocol

Posted Jun 2, 2010 16:37 UTC (Wed) by martinfick (subscriber, #4455) [Link]

I am not sure if your questions were aimed at me? What do you mean by X11 forwarding? (via ssh?) Via normal X11 (non ssh) the videos are just fine (not blue). I don't work remotely over slow links, I use X on my home LAN only. As for sound, I don't use any X11 or VNC features for it, I just use PA and multicast so I can hear what I want anywhere on my LAN, works fine. Again, I am not criticizing VNC, I think it is great too, but it is different than X and not a good substitute in all use cases. And, as with most software, it helps to have multiple solutions available since sometimes they don't all work perfectly.

Ranting on the X protocol

Posted Jun 2, 2010 21:36 UTC (Wed) by daglwn (guest, #65432) [Link] (2 responses)

VNC works well for the cases it's meant for, and on slow links it's much faster than X11 forwarding.

That's not been my experience at all. VNC has always been slower than just running windowed emacs over the X protocol, for example.

Ranting on the X protocol

Posted Jun 8, 2010 20:23 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Yes, with things that don't use Render much, or which render mostly monocoloured backgrounds (like most text editors), VNC's simpleminded 'just transmit giant bitmaps' scheme is intolerably inefficient and laggy. It's laggy even over a gigabit network... tightvnc makes it a bit better, but not much.

Apps that render backgrounds which consist of repeating elements can use Render to transmit those elements only once.

With things that have heavily coloured/textured backgrounds which are different at every point, maybe, just maybe both would be equally efficient... although surely you'd send that to the X server as a pixmap.

Can anyone think of *any* application (other than e.g. talking to Windows systems on the far side, or handling disconnected operation, neither of which X was designed for) for which VNC is preferable to X? I can't think of any.

Ranting on the X protocol

Posted Jun 8, 2010 22:15 UTC (Tue) by rsidd (guest, #2582) [Link]

Here's one: a slow network connection with latency (eg, connecting to office from my home). VNC is usable, X11 forwarding is not. I am willing to believe that X11 beats VNC on gigabit networks. And, of course, if the connection goes down you lose nothing (except time). You seem to be saying X was designed for LANs (where disconnected operation is relatively uncommon) and not wider networks. If so, that's another argument for VNC.

Ranting on the X protocol

Posted Jun 3, 2010 0:12 UTC (Thu) by agriffis (guest, #10251) [Link]

Regarding youtube, it works fine over X11 on a gigabit LAN. But a better example is mplayer which runs 720p video dandily using Xvideo over the network, and audio syncs well using pulseaudio. I haven't tried VNC and don't know how it would do for that, but I run thin clients upstairs to a server in the basement and the system works great, with one notable exception: mythtv-frontend. Unfortunately the only way to make this work on the thin client is to run it locally, but the thin client doesn't have the horsepower to do so.

Ranting on the X protocol

Posted Jun 2, 2010 16:51 UTC (Wed) by jg (guest, #17537) [Link] (6 responses)

Exactly my point: there are better, more robust ways to do network transparency than with the X protocol.

However, it is also the case that toolkits/applications should be involved in a deep way. If I want to run an app on a phone display, it should in fact be a different UI than when I'm on the HD screen across the room.

Our current architecture is broken, in ways that are not recoverable. This is why I said I'd do it in a radically different way, if I got the chance to do it again.

Every other system out there is similarly (or worse) broken, btw, there is nothing about this rant that is X specific.
- Jim

Ranting on the X protocol

Posted Jun 2, 2010 23:47 UTC (Wed) by obi (guest, #5784) [Link] (5 responses)

If you want a different UI depending on the hardware it's displayed on (phone vs HD screen) you'd need the toolkit's involvement. Or do you mean a Fresco-style toolkit-on-the-server-side? Now you got me curious.

Ranting on the X protocol

Posted Jun 3, 2010 0:18 UTC (Thu) by jg (guest, #17537) [Link] (4 responses)

Heh. At the moment, the UI is pretty tied up in the application's toolkit (for most applications).

NeWS attempted the opposite: load the UI into the display server, and send messages. In some ways, they were right; except the language chosen was horrid (postscript), and interesting extensions almost always still would have required modifications to that engine.

I think we (both NeWS and X) were wrong and the rendering for a UI should be in an entirely separate (set of) address spaces; in fact, I think for most applications, that they are currently written at too low level a level of abstraction.

The extra address space transitions this would imply is just not important any more, and would enable lots of interesting scalability and other enhancements.

So, think of a system in which identity is a first class citizen along with security (as occurs in CCNx, out of the box), based around the idea of the fundamental operation just being compositing of pixels, and multiple engines that might generate these pixels (which might even be VM's, running on the same iron, but with possibly very different graphics models).

And it would be pull, rather than push, and time based. Everything would be named (potentially globally).

A fundamentally different sort of architecture.

As I said, I've been stewing about this for much of the last 10 years, and it is seeing CCNx that has caused the fog to (partially) clear. I'm trying to clarify these ideas for a workshop later this summer; until then, this is as far as I will go.
- Jim

Ranting on the X protocol

Posted Jun 3, 2010 14:41 UTC (Thu) by obi (guest, #5784) [Link] (2 responses)

Thanks for the reference to CCNx - I can't believe I missed that. I've been messing about and doing some experiments based on the exact same premises, and coming to the exact same conclusions - trust/identity with immutable data, pervasive caching/dissemination, etc. I think the zeitgeist is clearly moving in that direction, as projects like Freenet, Git, Bittorrent, Allmydata etc all demonstrate. In the end I'd like to see us get to nearly stateless computing, where the data is everywhere (preferably local), and your hardware is just a window on it.

I think I can guess some aspects of the graphics architecture you have in mind, based on what you imply. I'd be very interested to hear more about it though - guess I'll have to wait until summer.

CCNx is important work...

Posted Jun 3, 2010 20:57 UTC (Thu) by jg (guest, #17537) [Link]

CCNx has not seen much notice; it is a still reasonably early research with much to work out yet.

Conceptually, however, it and some similar projects elsewhere I believe will change how we think about communications as much as TCP/IP (and packet networking in general) changed the view from the world of telephony.

It's view (which I still am working to get my head around), is a very different view of the world; there is some other work that has also affected my world view deeply (in particular the T-Time view found in Croquet derived from Dave Reed's thesis of so many years ago).

It is time for something *really* new....
- Jim

Ranting on the X protocol

Posted Jun 3, 2010 21:35 UTC (Thu) by dmk (guest, #50141) [Link]

"In the end I'd like to see us get to nearly stateless computing, where the data is everywhere (preferably local), and your hardware is just a window on it."

I like that. Kinda like the Matrix. :)

Ranting on the X protocol

Posted Jun 6, 2010 16:02 UTC (Sun) by ortalo (guest, #4654) [Link]

Really sounds mind-raising. Hope to hear again from you on this topic in a not-too-distant future.

Ranting on the X protocol

Posted Jun 3, 2010 14:30 UTC (Thu) by mebourne (guest, #50785) [Link]

"nobody cares anymore about X's network transparency!" - I care deeply, I use it extensively to earn a living.

"Even today setting up xauth is so unreliable and enough of a hassle that everybody I know just fires up VNC instead" - ssh solved the xauth problem back in the nineties, you don't even have to know it's there.

"VNC feels MUCH faster, especially over today's 1Mbit 3G links" - native X11 is unusable on high latency links but then VNC sucks on high latency links too. VNC also gives an unpleasant user experience and forces you to remote a whole desktop preventing any useful integration with your local system. X11 makes remote programs behave like local ones and lets you use them with all the same convenience.

As to solving the latency issue just use XPRA (http://en.wikipedia.org/wiki/Xpra). This removes round-trips in the X11 protocol and makes very high latency links usable - more useable than any other technology I've seen. It has the added bonus of surviving disconnections, allowing you to connect from somewhere else, all the same stuff you get from VNC. It's like having "screen" for X. It's as easy to use as VNC but all the advantages of normal remote X.

I use XPRA over a 270ms round-trip link for all my work apps all day every day and it's the only useable solution.

Ranting on the X protocol

Posted Jun 6, 2010 19:58 UTC (Sun) by Wol (subscriber, #4433) [Link]

As someone who knows nothing whatsoever about VNC (other than it's similar to X), but who currently uses one PC as an X-term into another all the time, you have one user here to whom X's network transparency is rather important ...

Cheers,
Wol

Ranting on the X protocol

Posted Jun 8, 2010 9:02 UTC (Tue) by jschrod (subscriber, #1646) [Link]

VNC a replacement for remote X? You're joking, right?

Maybe for people who just want to do a short action on a remote desktop, and don't care for consistent keyboard handling or working X selections. But for people like me who have X applications open from 5-10 remote systems all the time, network transparency on the application level (and not on the desktop level!) is one of THE reasons to use X.

Ranting on the X protocol

Posted Jun 11, 2010 11:02 UTC (Fri) by renox (guest, #23785) [Link]

I didn't know what CCNx is, so I've investigated, interesting, but I'm quite surprised by a reference to CCNx in a discussion about X's network transparency as CCNx seems to solve a very different problem: duplicating existing 'fixed' data..

Can you elaborate?

Android

Posted Jun 1, 2010 21:22 UTC (Tue) by bboissin (subscriber, #29506) [Link] (22 responses)

So I'm wondering, android doesn't seem to use xorg but they still use a bunch of graphical apps (including webkit). What are they using instead? Could the major toolkits (qt/gtk) be ported to this framework?

Android

Posted Jun 1, 2010 23:03 UTC (Tue) by drag (guest, #31333) [Link] (19 responses)

For more traditional Linux environments Redhat has developed Wayland as a alternative to using a X Windows-based environment.

It depends heavily on the modern graphics infrastructure being built up (Gallium3d, Kernel-mode setting, etc etc) for it's acceleration. Unlike Xorg it's designed from the ground up to not touch hardware directly; which should make things easier.

GTK has been ported to it. I think QT has also.

Theoretically it can happily support running X11-based applications through composition. The idea being that you have a X Server that draws entirely to a off-screen buffer and then you bring the application windows via desktop composition. Similar thing should be possible for Android's stuff..

That way you could still maintain backwards compatibility with maximizing the benefits of a modern display design.

--------------------

I would not mind seeing a effort to modernize X by creating a X12 protocol.

I've read that the vast majority of X and X extensions is no longer used by most modern applications. So I figure you could massively simplify things and get X12 with only relatively minor changes needed for existing applications.

Then maybe they could add support for streaming video to remote systems using WebM, similar to how Redhat SPICE uses MJPEG to stream desktops from virtualized Windows environment.

Android

Posted Jun 2, 2010 0:38 UTC (Wed) by quartz (guest, #37351) [Link] (15 responses)

Unless something changed, I think Redhat is not actually developing Wayland. Methinks it is done in KR's spare time.

Not to mention there is very little activity on it. Mind you, I'd love to have a simpler stack, but Wayland is pretty far away and slow to get there...

Android

Posted Jun 2, 2010 6:21 UTC (Wed) by drag (guest, #31333) [Link] (14 responses)

Your probably right about the Redhat thing. Seeing how it's hosted on Google code and all that.

As far as Wayland goes... there is really not much point to putting a huge amount of effort into something like that until the Linux graphics stack matures quite a bit.

We need to eliminate all direct access from the X server to your hardware so that the X Server is nothing more then the software redirects Linux graphics APIs and input to the applications. Maybe when we get to that point Wayland may not be needed, but it would be nice to get rid of the legacy crud that is hanging around "Linux on the desktop"'s neck.

Android

Posted Jun 2, 2010 11:34 UTC (Wed) by nix (subscriber, #2304) [Link] (13 responses)

We need to eliminate all direct access from the X server to your hardware

Isn't KMS very nearly there already? The only thing it needs root for now is to ensure that nobody else is snooping on your input devices.

Android

Posted Jun 2, 2010 15:22 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

That's what Wayland is, basically. It's a simple layer between hardware and client software.

It uses KMS and command submission infrastructure so it doesn't need to run as root and touch hardware directly.

If/when KMS+Gallium3D layer matures enough, it should be fairly simple to move QT/GTK directly to this layer (they are less and less dependent on exotic X features, anyway) and run rootless X for compatibility with the old clients. Like Apple did in 2000-s.

Android

Posted Jun 2, 2010 17:04 UTC (Wed) by nix (subscriber, #2304) [Link] (9 responses)

I meant that *X with KMS* is very nearly at the 'not running as root or touching hardware directly' stage. This is quite different from some direct-on-the-hardware layer: we still have X protocol support, network transparency and the whole shebang.

To be honest I can't see any advantage whatsoever in having a direct-on-the-hardware Gtk/Qt port: you lose network transparency, which is useful, and gain a tiny bit of performance which is probably entirely imperceptible locally in any case.

Android

Posted Jun 2, 2010 17:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Network transparency will be soon broken in KDE, so it's not a great loss.

And there are better ways to create networked GUI applications now - VNC and SPICE. One can even use streaming video with SPICE, something which is impossible in pure networked X.

And X with KMS already can work as a simple user, without root access. It might happen in Ubuntu this year: https://blueprints.edge.launchpad.net/ubuntu/+spec/deskto... (Fedora might have it already, no idea)

X network transparency

Posted Jun 2, 2010 19:02 UTC (Wed) by martinfick (subscriber, #4455) [Link] (7 responses)

"Network transparency will be soon broken in KDE, so it's not a great loss."

Wow, where is the logic in this statement? If KDE breaks it, it will be a great loss (more for KDE than for X). If another large project breaks some other standard, NFS, HTTP, TCP, would you simply conclude that it must therefore be "not a great loss"?

Everyone claiming that network transparency of X can currently be done in better ways is obviously NOT thinking about all the use cases that X supports.

If you are a single user with simple use cases, i.e. I want to see my home desktop from my laptop while at work, yes VNC is good. But if you have ever worked in a collaborative environment across many unixy machines, X is undeniably way more powerful than VNC.

If I simply want to log into a test machine and run one GUI app (perhaps a browser), remotely, without having an entire desktop setup, I can do that easily with X. I can have ten different apps on my desktop running across ten different remote hosts transparently. The fact that these apps might not eventually integrate perfectly with KDE or GNOME in the future is not going to kill X (and they certainly would integrate even less well with VNC). It will be a shame, but the desktops are not the end all be all. X will survive just fine without their full support and will continue to be used in creative powerful ways, even if some people can't envision the use cases that other's have been (and will still be) using for decades.

X network transparency

Posted Jun 2, 2010 19:56 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

"Wow, where is the logic in this statement? If KDE breaks it, it will be a great loss (more for KDE than for X). If another large project breaks some other standard, NFS, HTTP, TCP, would you simply conclude that it must therefore be "not a great loss"?"

Is HTTP used by less than 1% of KDE users?

Also, what do you think about removal of Gopher support from FireFox?

"If you are a single user with simple use cases, i.e. I want to see my home desktop from my laptop while at work, yes VNC is good. But if you have ever worked in a collaborative environment across many unixy machines, X is undeniably way more powerful than VNC."

Yawn. I worked in a collaborative environment. X is still not superior to VNC.

Yawn. So most of people won't care about it. Apple's GUI is not network transparent, but I don't see people crying rivers about it. That's what is going to happen.

Also, you can certainly have only your application windows without complete desktop environment with VNC. VirtualBox does this, for example.

X network transparency

Posted Jun 2, 2010 20:27 UTC (Wed) by sfeam (subscriber, #2841) [Link] (3 responses)

"If I simply want to log into a test machine and run one GUI app (perhaps a browser), remotely, without having an entire desktop setup, I can do that easily with X. I can have ten different apps on my desktop running across ten different remote hosts transparently."
Yawn. So most of people won't care about it. Apple's GUI is not network transparent, but I don't see people crying rivers about it. That's what is going to happen.

Maybe all that yawning indicates you are too tired to think about how and why people still use this? I agree strongly with martinfick. It is very nice to be able to ssh in to another machine, often a server not running a desktop at all, and fire up one X-based utility. Ditto for ssh access to an older or minimally configured machine that doesn't have enough memory to run vncserver.

And yes, it is a problem that Apple's GUI does not support this. It means, for example, that even though FileMaker running on an Apple server provides a nice http interface for user access, I still have to walk over to another lab in order to perform administrative tasks on it. I don't cry a river, but I'd switch to an X11+linux equivalent for FileMaker if I knew of one.

X network transparency

Posted Jun 2, 2010 21:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

"Maybe all that yawning indicates you are too tired to think about how and why people still use this? I agree strongly with martinfick. It is very nice to be able to ssh in to another machine, often a server not running a desktop at all, and fire up one X-based utility. "

And there are people who still use Gopher. Should we base all our browsers around Gopher layer? Maybe, you know, by using big ASCII ART pictures transformed 'on-the-fly' to 24-bit color images.

Cause that's about the same way current X works.

"Ditto for ssh access to an older or minimally configured machine that doesn't have enough memory to run vncserver."

This excuse is quite thin. Vnc4server with minimal DE takes about 4Mb of RAM.

"And yes, it is a problem that Apple's GUI does not support this. It means, for example, that even though FileMaker running on an Apple server provides a nice http interface for user access, I still have to walk over to another lab in order to perform administrative tasks on it. I don't cry a river, but I'd switch to an X11+linux equivalent for FileMaker if I knew of one."

And I just use VNC for Apple. You know the one that Apple bundles with each copy of Mac OS X (http://www.wikihow.com/Setup-VNC-on-Mac-OS-X).

So maybe you should stop assuming that networked X is the only way to do networked graphics?

X network transparency

Posted Jun 8, 2010 14:38 UTC (Tue) by jschrod (subscriber, #1646) [Link]

Did it ever occur to you that a remote desktop is something different than a remote application and that for many people it is not a good enough substitution? Use cases that cannot be replicated have already been cited. (In particular: many remote applications that integrate with one's WM, and not many remote desktops that need a full desktop setup at the remote system.)

But you think that all the world has to have the same needs as you, don't you?

X network transparency

Posted Jun 3, 2010 8:42 UTC (Thu) by Janne (guest, #40891) [Link]

Well, you could just use VNC, which works just fine on Macs. Apple even has a polished implementation of it available:

http://www.apple.com/remotedesktop/

But of course, standard free VNC would work as well, it just might not have all the bells and whistles of the Apple Remote Desktop.

And if you are running X11-aware UNIX-apps, then you could use X11 for MacOS, which is shipped with every copy of OS X....

X network transparency

Posted Jun 2, 2010 20:39 UTC (Wed) by sbishop (guest, #33061) [Link] (1 responses)

Yawn. So most of people won't care about it. Apple's GUI is not network transparent, but I don't see people crying rivers about it. That's what is going to happen.

And if that's what you're looking for--a Unix GUI which isn't network transparent--then a solution, as you have already pointed out, is already available.

I know from experience that X network transparency for a single app is extremely useful in a lab environment, where the rest of Linux is also useful.

Inflexible operating systems which only cater to the average user are easy to find. I don't see any reason to throw out the very things which make Linux flexible and unique.

By the way, does anyone know how it is that KDE is supposed to be breaking this valuable feature of X exactly? I don't follow KDE.

X network transparency

Posted Jun 2, 2010 21:17 UTC (Wed) by drag (guest, #31333) [Link]

I like X network transparency a lot and use it all the time.

Moving to OS X is not a good one because I really dislike Apple's corporate policies and I dislike how the Unix side of things and the Aqua side of things are two entirely different worlds. With Gnome on Linux I have full system integration from top to bottom.

But if I was to loose out with X network transparency in exchange for a more efficient system, less memory usage, and better designed drivers (and the other benefits that that gives) then it would be a happy trade off.

There are a massive number of different ways to do remote GUI systems nowadays.

X is pretty good, but nobody ever fixed it's deficiencies. Instead we have a shitload of hacks and work arounds on the toolkit level to make it usable.

Android

Posted Jun 2, 2010 18:44 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

> Isn't KMS very nearly there already? The only thing it needs root for now is to ensure that nobody else is snooping on your input devices.

We are getting closer and closer, certainly.

What we will eventually need is a generic DDX that only targets "Linux" rather then individual video devices.

Graphics drivers are maturing: Open Source ATI and Nvidia drivers are doing a good job progressing and are in the progress of providing mature Gallium drivers.

Open Source Intel driver developers do not seem to have received the 'Gallium religion' yet.. they seem happy with their own UXA stuff happening in the X Server; but I think they will get the religion rapidly once they realize that writing a new driver from the hardware-on-up for each API they want to support is a shitty idea.

--------------------------

For remote desktop/network transparency I envision something like SPICE were you are able to stream video using modern compression techniques to client systems.

Maybe using WebM. Have the rendering happen on the remote machine, the buffers for the applications get rendered to Vp8. PulseAudio + Gstreamer outputs the audio to Vorbis.

These get combined to a WebM stream that get sent to the 'client' (your local machine).

Then all that is needed is a protocol for input control were pointer, keyboard, copy/paste buffer, input gets feed back to the remote machine in order to interact with the programs.

The client program to display the remote desktop then needs to not be anything more complicated then a web browser. Browser would render the WebM video and then Javascript to capture the input from the user and send it back to the remote system.

With modern computer architectures with built-in video acceleration both the clients and the servers will be able to do the compression/decompression no-sweat.

Android

Posted Jun 3, 2010 16:24 UTC (Thu) by Spudd86 (guest, #51683) [Link]

VP8 is not a low delay codec, it would not be suited to this usecase (Dirac however does have a low delay mode, but it's not implemented in a way that enables low delay operation in the open source encoders and decoders, however there is hardware that does it, but it's REALLY high end stuff like $10k price tag type things)

X11 extensions are not dead

Posted Jun 2, 2010 0:44 UTC (Wed) by jreiser (subscriber, #11027) [Link] (2 responses)

I've read that the vast majority of X and X extensions is no longer used by most modern applications.

On my machine xdpyinfo shows 27 extensions [list follows] and over 20 of them are used intensively. Extensions: BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-DRI XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo

X11 extensions are not dead

Posted Jun 2, 2010 2:42 UTC (Wed) by jg (guest, #17537) [Link]

There are a number of major turkey (gobble, gobble) extensions that have been consigned to the dustbin of history: e.g. PEX, XIE, LBX, and are thankfully no more.

X11 extensions are not dead

Posted Jun 3, 2010 16:26 UTC (Thu) by Spudd86 (guest, #51683) [Link]

Well some of those extensions have wound up replacing large portions of the core protocol (for example XRender pretty much replaces all the stuff related to drawing since nobody wants to do the kind of drawing the core protocol supports anymore)

Android

Posted Jun 2, 2010 3:11 UTC (Wed) by eklitzke (subscriber, #36426) [Link] (1 responses)

It seems like a lot of the problems in X11 have to do with how devices are handled (i.e. multiple keyboards, mice, monitors, etc.) and configured. These things are presumably baked into the android display code, which presumably doesn't offer a lot of flexibility with these things (since users aren't expected to be hotplugging input devices, or managing multiple displays). I know that things like screen resizing (when you change the orientation of the device) need to be handled manually by the application via a callback, compared to X11 in which applications aren't expected to know or care about display changes.

Based on this, my assumption is that the android display code probably isn't a viable replacement for the kind of things that xorg does, even if it is more efficient in some areas.

(disclaimer: I'm not an X11 or android hacker, so these are just my guesses)

Android

Posted Jun 2, 2010 9:03 UTC (Wed) by juanjux (guest, #11652) [Link]

"I know that things like screen resizing (when you change the orientation of the device) need to be handled manually by the application via a callback"

Not really; you receive a callback when the screen changues orientation, but you can explicitly ignore it and Android will resize your app just fine (if you dont have hard coded sizes, of course.) You can also provide alternative layouts in case you prefer to alter the disposition of widgets with different orientations like hidding or showing some buttons instead of resizing the same set, but it's not required.

Danjou: Thoughts and rambling on the X protocol

Posted Jun 2, 2010 18:21 UTC (Wed) by did447 (guest, #49454) [Link] (6 responses)

X is like CVS, a lot of good ideas but barely good enough. The faster it go away the better.

Danjou: Thoughts and rambling on the X protocol

Posted Jun 2, 2010 21:47 UTC (Wed) by daglwn (guest, #65432) [Link] (5 responses)

The analogy is not correct. CVS had many deficiencies which could not be easily fixed. X has deficiencies but provides an extension mechanism to fill them.

The primary reasoning behind most "dump X" comments I read ends up being "it's ugly." While that may be true and it may be worthwhile to clean up, it's not a reason to completely dump a system that's served us very well for over two decades. Old is not bad. Old is good, stable and useful. Most of the "dump X" people unfortunately don't seem to care that some of us actually use things like X's network transparency, for good reasons.

Danjou: Thoughts and rambling on the X protocol

Posted Jun 3, 2010 6:02 UTC (Thu) by jmorris42 (guest, #2203) [Link] (4 responses)

> Most of the "dump X" people unfortunately don't seem to care..

And seem to have a lot of overlap with the set of Linux people who care not for UNIX and are hellbent on dumping everything that makes *NIX worth having.

1. The Network is the Computer. The Computer is the Network. SUN may be defunct but that idea is more than just a marketing slogan.... for some of us.

2. Everything is a file. Things like PulseAudio and the eternally changing *bus/*kit stuff tend to violate this one. Hint: if the primary interface is a library instead of a device you are probably doing it wrong. Lets not bring over bad habits from Windows.

3. Small is beautiful. Lots of small programs are better than one big one.

4. X provides mechanism, not policy.

But worse still, the old UNIX books are all but useless on a 'modern' linux and there are no replacements available, i.e. it is all scrounge around on obscure wikis and blogs for docs that are either out of date or describe an even newer version than your distro shipped.

Danjou: Thoughts and rambling on the X protocol

Posted Jun 3, 2010 6:40 UTC (Thu) by intgr (subscriber, #39733) [Link] (1 responses)

I'm not sure where you are going with this rant.

> Hint: if the primary interface is a library instead of a device you are
> probably doing it wrong.

That also includes X11.

> 3. Small is beautiful. Lots of small programs are better than one big one.

Again, you are proving the point. X11 is a bloated mess with lots of redundant functionality that nobody uses or needs anymore.

Danjou: Thoughts and rambling on the X protocol

Posted Jun 6, 2010 20:45 UTC (Sun) by Wol (subscriber, #4433) [Link]

>> 3. Small is beautiful. Lots of small programs are better than one big one.

>Again, you are proving the point. X11 is a bloated mess with lots of redundant functionality that nobody uses or needs anymore.

That WAS true of XFree, which was project-managed by a bunch of Windows fans. It's not true of Xorg except insofar of the legacy code they haven't yet managed to rewrite out of the system.

It's a sad fact that X stagnated for years, precisely because the people in charge thought MS-Windows was a better solution. Fortunately the project threw the main developer out, because he didn't agree with them, so now we have the Xorg fork and X is motoring along nicely again.

Cheers,
Wol

Danjou: Thoughts and rambling on the X protocol

Posted Jun 3, 2010 16:46 UTC (Thu) by Spudd86 (guest, #51683) [Link]

In the case of properly handling audio it makes sense to have a library to do it, we have one for alsa, and analogously we have Xlib for X, and even for framebuffer stuff not many people deal with fbdev directly (or at all see DirectFB) once your problem reaches a certain level of complexity it no longer makes any sense to NOT have a library, it reduces duplicated effort and bugs, simplifies development of programs that use the facility and generally is all around a good idea, there is a reason we have them.

dbus is an IPC mechanism, that's all.

most of the *kit stuff is a small daemon doing one thing (replacing hal the huge daemon that did everything) it uses dbus because it's a good IPC mechanism that avoids re-implementing a bunch of stuff for each new thing and brings some nice features (like automatic activation, think inetd for IPC)

and if you're not interested int running a desktop environment than all you need to look at is udev and a little bit of dbus (And you can leave dbus out if you really want to).

The other things are for desktop environments where small programs that do one thing are not always the best for a good UI design, you have to put the splits in a different place (for one thing pipes are no longer really an option for connecting your apps together, again dbus comes in here)

dbus is basically a small daemon that does one thing well, and a small library for talking to it. It is an enabler for writing MORE small daemons that do one thing well, while at the same time avoiding the massive bloat of hundreds of small daemons by providing on demand starting of them.

The modern Linux desktop is moving towards a GUI version of the UNIX philosophy of small programs doing one job well as much as it possibly can, which is exactly where things like pulseaudio and *kit come in.

(pulse is bigish because it's solving a big problem, consolekit, polkit, udisks, etc are all replacing some big monolithic things with lots smaller programs so what are you complaining about?)

Danjou: Thoughts and rambling on the X protocol

Posted Jun 6, 2010 15:58 UTC (Sun) by ortalo (guest, #4654) [Link]

"But worse still, the old UNIX books are all but useless on a 'modern' linux and there are no replacements available, i.e. it is all scrounge around on obscure wikis and blogs for docs that are either out of date or describe an even newer version than your distro shipped."
You are probably true, but maybe there is hope not so far... I really enjoyed spending the last decade reading something like LWN.net - I do not lack so much of the old Unix books that were deprecating at an incredibly fast pace (and were so expensive btw).

Danjou: Thoughts and rambling on the X protocol

Posted Jun 2, 2010 23:09 UTC (Wed) by jonabbey (guest, #2736) [Link] (1 responses)

I remember porting X11R4 (client libraries and apps, anyway) to an Alliant mini-supercomputer back in the very early 1990's.

X has come a very, very long way since then, both in the server space (thanks to XFree86 for carrying the torch and driving improvements during the 90's) and in toolkits, but it could certainly use a clean up and slim down of the protocol, with greater emphasis on asynchrony and maybe even some local server-side GUI event processing support, imho.

Of course, all of the projects that were structured in that way (NeWS, Fresco) seem to have fallen away, and everyone's efforts seem to be focused on optimizing the local desktop/phonetop experience, and using HTTP for everything network oriented.

Which I think is a shame. I'm one of those users who regularly uses the network portability of X for individual apps with great enthusiasm.

There's a great whole lot of development under the bridge now, though, and it doesn't seem likely that there will ever be an X12.

Danjou: Thoughts and rambling on the X protocol

Posted Jun 2, 2010 23:19 UTC (Wed) by jonabbey (guest, #2736) [Link]

Though XCB is a great effort!

Threads on X11 being useless

Posted Jun 3, 2010 19:57 UTC (Thu) by cdmiller (guest, #2813) [Link] (1 responses)

There are lot of comments and threads here about X11, network transparency, etc. being useless or no longer needed from folks who appear to have little experience using those features. Thin clients, "weird kiosks", and remote application access via X11 are used extensively in academic, scientific, and government environments. Many of those deployments throw away the copycat wanna be Microsoft bloat built into Gnome and KDE, and some even use such "useless" features as the X Font server. Perhaps the proponents of "modern" desktop environments can concentrate on fixing them rather than ranting about a perceived need to break the functionality X11 provides. In turn, the X11 devs can keep working on making X better at what it already does.

Threads on X11 being useless

Posted Jun 8, 2010 17:52 UTC (Tue) by nix (subscriber, #2304) [Link]

Agreed. I'd pay attention when jg says it's not the right way to do things, though: he's been hacking X for longer than almost anyone else, and possibly longer than *anyone* else continuously (the only other contender would I think be Keith Packard).