I haven't implemented everything, but as long as a client doesn't send any references to objects the compositor doesn't have, it should work fine. I don't know how realistic this is, or how well it can be made to handle custom additions to the protocol. My contributions will be separate from wayland, more like wayland-demos, but it should be usable with other compositors; I don't know how varied the other compositors will be.

Wayland is just the protocol defined in a xml file. There is also a wire format specified in the docs, and there is no framebuffer information in there, that is done through shared memory. I am pretty sure wayland will always need something like RFB to mimic this shared framebuffer, in addition to the wayland socket, and another connection for drag and drop data.

Once you understand the internals of wayland, I don't think it would be a big step to make this remote client, so it is entirely feasible that Qt/Gtk could come up with their own.

Right now, all I know is that the software I am writing knows what the compositor knows, and I just plan on sending the parts of the framebuffer matching the damage requsts. Any plugins for remote framebuffer sharing will have to work alongside the data going over the main wayland connection, so I don't know how that will work.

I've only been working on this since May, and my understanding of the inner working of X is hazy, so I don't know how the finished product will work(right now I am working locally manually starting everything) or how ssh will play into it. But the effect is going to be the same; you will be able to run a client program running on a remote machine, while viewing it in the compositor running on your desktop.

This will not be built into the core of wayland. The instructions passed from client to compositor contain no contents of the frame buffer, since the FB is shared in memory. A separate connection is needed to mimic this shared framebuffer. Wayland offers a big advantage here, the intermediate software (that I am working on) knows when the screen is updated, and where. This means the least possible amount of data is sent.

I'll keep the code modular enough that, if needed, I can switch in another protocol, once I have a working prototype.

Hi, I'm working with the creator of wayland on a google summer of code project to enable remote clients with wayland. This Is fairly conceptually simple, I just forward the information that goes over the main wayland socket, preserving the wire protocol, and on another socket, I use a RFB like protocol to pass on creation and changes to the framebuffer. Later on, I'll need a third socket to pass Drag and Drop data, but that is still a ways off.

If you have any questions come ask in #wayland on freenode. I'll answer what I can, and krh comes by frequently.

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.