Forgot your password?
typodupeerror

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

by jmknsd (#37085798) Attached to: Firefox 6 Ships Next Week, 8 Blocks Sneaky Add-Ons

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

by jmknsd (#37083262) Attached to: Firefox 6 Ships Next Week, 8 Blocks Sneaky Add-Ons

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

by jmknsd (#37083252) Attached to: Firefox 6 Ships Next Week, 8 Blocks Sneaky Add-Ons

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

by jmknsd (#37082794) Attached to: Firefox 6 Ships Next Week, 8 Blocks Sneaky Add-Ons

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:Stupid (Score 1) 413

by jmknsd (#37015588) Attached to: KDE Plans To Support Wayland In 2012

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.

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

by jmknsd (#37015522) Attached to: KDE Plans To Support Wayland In 2012

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

by jmknsd (#37015450) Attached to: KDE Plans To Support Wayland In 2012

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:X allows us to use legacy programs (Score 1) 413

by jmknsd (#37014156) Attached to: KDE Plans To Support Wayland In 2012

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

by jmknsd (#37013980) Attached to: KDE Plans To Support Wayland In 2012

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.

Comment: Re:Stupid (Score 1) 413

by jmknsd (#37013950) Attached to: KDE Plans To Support Wayland In 2012

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.

How many NASA managers does it take to screw in a lightbulb? "That's a known problem... don't worry about it."

Working...