I use existing tools, so the data going over the socket is the same, but a second socket is used with an RFB-like protocol that syncs up the framebuffers on damage and creation. Later, there will need to be a third socket for Drag and Drop, but I am not that far yet.

I am working on implementing a standalone remote Wayland application that would enable the functionality that the GP mentioned.

Wayland also brings to the table improved performance, and the freedom for each developer to use whatever means they want to generate their own framebuffer to the compositor. This means that Wayland won't need to be updated in 10 years to remove old, useless primatives and add new ones, like many others here are suggesting we do with X now.

There is a nice website with an explanation of the architecture here: http://wayland.freedesktop.org/architecture.html and they have a FAQ as well.

My understanding is that Wayland is just a spec, the compositor and the client are separate programs that just communicate over a socket and a shared buffer. And that if you wanted to make and then use this PDF based renderer, you could then call it from any client, and it would make no difference to the compositor at all. This seems like a better architecture than forcing clients to use whatever inside X, or adding something on to X before they can use it.

I made another post to this effect, but it seems to have gone unnoticed:

I am currently working on implementing a standalone project that enables running Wayland applications remotely for my GSoC project. This functionality is important to many of the devs who work on the linux graphics stacks, and it will be implemented.

Not only do the current OSS drivers have pretty good support for older cards, but they are currently the only option for using ATI and Nvidia cards. The performance might not be as good, but it is getting better, especially on older cards.

I was under the impression that once the closed source drivers implemented KMS and other features, they could be used. I am using Intel's current drivers and they support Wayland well.

Wayland supports being run inside X, as well as running individual apps, and entire desktops running on top of X within Wayland. And not an X emulator; since wayland basically passes framebuffers around, running real X on top of was one of the first things done. Not only will the functionality of being able to run remote X apps be maintained, X support is being maintained in pretty much every way I can think of.

There is a pretty good description here: http://wayland.freedesktop.org/architecture.html

Pretty much all of the modern advances in Linux Graphics have been to push the performance sensitive parts of X to the kernel and the client. In current 3D apps, X does little more than the Wayland compositor does, but adds a cumbersome middle man.

Hi, I am working on making a networking client/server that will enable this remote window functionality in wayland for my Google summer of Code project. Since each Application communicates with the compositor over a socket has it's own framebuffer, doing a RFB like protocol and forwarding this protocol is pretty straightforward, conceptually.

This is my first open source project and I won't have it working by the end of the summer, but I will stick with it until it is done, and I know at least one other professional developer who has his own ideas and will probably run with it should I fail. This is an important feature and it will be implemented.

He needs to make space for his race of hyper-intelligent cyborgs.

I only speak two languages, English and bad English.

Wasn't the 7000 series the last card ATI released the source code for?

I would imagine that it would work very well.

I have a touchscreen HP, and the upgrade to 10.04 completely horked the touchscreen until someone reworks the evtouch driver.

The touchscreen has always been a pain to set up, this is really something that needs working on if they want to go against the ipad.

Blowing into a USB port just isn't the same.

No, actually It is basically a bunch of Pentium 3s with cache coherency removed for a small chunk of on chip RAM, and a message passing interface for inter core communication. It has alot of interesting features, and is more usable than the 80 core chip they came out with a few years ago.