Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Bugs, memory leaks, and poor performance. (Score 1) 247

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.

Comment Re:Bugs, memory leaks, and poor performance. (Score 1) 247

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.

Comment Re:Bugs, memory leaks, and poor performance. (Score 1) 247

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.

Comment Re:Bugs, memory leaks, and poor performance. (Score 1) 247

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.

Comment Re:Not so stupid. (Score 1) 413

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.

Comment Re:Stupid (Score 1) 413

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: and they have a FAQ as well.

Comment Re:Not so stupid. (Score 1) 413

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.

Comment Re:Not so stupid. (Score 1) 413

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.

Comment Re:Stupid (Score 2) 413

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.

Comment Re:X allows us to use legacy programs (Score 1) 413

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.

Comment Re:What's wrong with X11? (Score 2) 413

There is a pretty good description here:

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.

Comment Re:Stupid (Score 1) 413

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.

Slashdot Top Deals

"Probably the best operating system in the world is the [operating system] made for the PDP-11 by Bell Laboratories." - Ted Nelson, October 1977