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.
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.
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.
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.
You also need to consider the other part of a physical manifestation of these theoretical engineering procedures, everyone would be able to tell that the rich were keeping such things for themselves. They might be smarter and capable of living longer, but I don't see them being bulletproof.
The masses would fight for something like this, and it won't be like in the middle ages(At least in the States) where the wealthy were capable of easily quelling an uprising; it would be a bloody mess.
I can see it drastically changing things, but eventually it would come down in price. There might be an elite class that is one step ahead of everyone else, but it would even itself out.
It is my understanding that China recruits people who prove themselves technically by attacking foreigners or helping their government.
The large number of people who are attacking the rest of the world aren't a part of the Chinese government, the government just looks the other way and pulls out the best to work for them.
So it was probably just some guy or group of guys doing what they thought the government would reward them for.
Slashdot Mirror
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.
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.
If like is anything like supertroopers, they have been pistol whipped thoroughly.
Well, there is always the option of knocking all of the pieces off the board and throwing a tantrum.
You also need to consider the other part of a physical manifestation of these theoretical engineering procedures, everyone would be able to tell that the rich were keeping such things for themselves. They might be smarter and capable of living longer, but I don't see them being bulletproof.
The masses would fight for something like this, and it won't be like in the middle ages(At least in the States) where the wealthy were capable of easily quelling an uprising; it would be a bloody mess.
I can see it drastically changing things, but eventually it would come down in price. There might be an elite class that is one step ahead of everyone else, but it would even itself out.
I have a degree in Math and CS. The math degree doesn't seem to be helping me get accepted to grad school, or getting a job.
Any idea what fields/companies would have a strong demand for a CS/Math person?
Wow I wasn't expecting to get to the classic retort to libertarians until a bit further down.
Also, you left out roads, we hate roads too.
It is my understanding that China recruits people who prove themselves technically by attacking foreigners or helping their government.
The large number of people who are attacking the rest of the world aren't a part of the Chinese government, the government just looks the other way and pulls out the best to work for them.
So it was probably just some guy or group of guys doing what they thought the government would reward them for.
If Intel wants to beat ARM they would have to take a page from the microsoft playbook and release their low end processors for (near)free.