Hi.
I was just wondering if the Wayland protocol can be sent over a
network running on a remote machine, connected to a remote Wayland
server, without recompiling/rewriting the apps.
There are many people that see this ssh -x feature as usable. And this
ability in X11 is used in many different forms, such as NoMachine's
NX.
Please don't say it has to be a VNC type of deal, where the whole
desktop is just boxed in, or a Citrix type of deal, where remote apps
where an afterthought, and resulted in a flaky implantation.
I just think that network functionality is too big of a functionality
to lose.
<bluescreen_aven...@verizon.net> wrote: > Hi. > I was just wondering if the Wayland protocol can be sent over a > network running on a remote machine, connected to a remote Wayland > server, without recompiling/rewriting the apps.
> There are many people that see this ssh -x feature as usable. And this > ability in X11 is used in many different forms, such as NoMachine's > NX.
> Please don't say it has to be a VNC type of deal, where the whole > desktop is just boxed in, or a Citrix type of deal, where remote apps > where an afterthought, and resulted in a flaky implantation.
No, Wayland is a _display_ server not a user interface server. It operates at a lower level than X11. As such, it is not meant to work across a network, similar to how Windows Terminal Services desktops do not use Aero.
> <bluescreen_aven...@verizon.net> wrote:
> > Hi.
> > I was just wondering if the Wayland protocol can be sent over a
> > network running on a remote machine, connected to a remote Wayland
> > server, without recompiling/rewriting the apps.
> > There are many people that see this ssh -x feature as usable. And this
> > ability in X11 is used in many different forms, such as NoMachine's
> > NX.
> > Please don't say it has to be a VNC type of deal, where the whole
> > desktop is just boxed in, or a Citrix type of deal, where remote apps
> > where an afterthought, and resulted in a flaky implantation.
> No, Wayland is a _display_ server not a user interface server. It
> operates at a lower level than X11. As such, it is not meant to work
> across a network, similar to how Windows Terminal Services desktops do
> not use Aero.
Does someone know how SteveJobs managed to video-project ipod nano (5G) screen in the last demo he made ? Is it fake or it is possible to capture a screen of that device and project it with no visible performance lag ? Just asking to know if a similar thing can be made with Wayland.
(Asking, even if it seems fake to me, or maybe they just captured only some input)
Well, considering Apple makes the nano and all other ipods, they most likely can enable a debug mode on it that would output the complete contents of the screen through the dock connector. However, its not that its without lag, its just not much lag since the new nano has such a small screen.
On Sep 18, 2010, at 10:32 AM, Mohamed Ikbel Boulabiar <boulab...@gmail.com> wrote:
> Does someone know how SteveJobs managed to video-project ipod nano > (5G) screen in the last demo he made ? > Is it fake or it is possible to capture a screen of that device and > project it with no visible performance lag ? > Just asking to know if a similar thing can be made with Wayland.
> (Asking, even if it seems fake to me, or maybe they just captured only > some input)
> i
> -- > You received this message because you are subscribed to the Google Groups "Wayland" group. > To post to this group, send email to wayland-display-server@googlegroups.com. > To unsubscribe from this group, send email to wayland-display-server+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/wayland-display-server?hl=en.
<bluescreen_aven...@verizon.net> wrote: > Then what is this "Wayland 'Protocol'" I keep reading about?
There are wayland clients (eg. the X server could be one) and a wayland server (the compositor). However, the protocol is not network-friendly (it uses Unix sockets only) because the commands refers to data in the GPU memory.
This seems to be a common complaint about Wayland. Here is the short
answer: remote desktop with just Wayland is impossible because it
communicates with local DRM buffers. It could be extended to allow
clients over a network to send image data, however that would be kind
of like VNC. Wayland will definitely not take drawing commands like X,
because it is supposed to be rendering API neutral.
The long answer: Remote desktop is really something that belongs in
the toolkits (Gtk+, Qt), not the display server. This would be
preferable both to the X11 method, and to the VNC method. A remote
application would use the toolkit just like normal, and the toolkit
would issue commands to a daemon running on the local computer, which
would draw the windows and send them to Wayland in DRM buffers. This
is better than both X and VNC because it has the potential to save a
lot of bandwidth. As much as X/NX is better than VNC, this would be
even better, because the toolkit wouldn't have to send every little
drawing detail, since the local daemon would know those details. This
would allow Wayland to remain rendering API neutral, and use even less
bandwidth than X for remote desktop.
On Sep 17, 9:41 pm, Nerdopolis <bluescreen_aven...@verizon.net> wrote:
> Hi.
> I was just wondering if the Wayland protocol can be sent over a
> network running on a remote machine, connected to a remote Wayland
> server, without recompiling/rewriting the apps.
> There are many people that see this ssh -x feature as usable. And this
> ability in X11 is used in many different forms, such as NoMachine's
> NX.
> Please don't say it has to be a VNC type of deal, where the whole
> desktop is just boxed in, or a Citrix type of deal, where remote apps
> where an afterthought, and resulted in a flaky implantation.
> I just think that network functionality is too big of a functionality
> to lose.
> This seems to be a common complaint about Wayland. Here is the short > answer: remote desktop with just Wayland is impossible because it > communicates with local DRM buffers. It could be extended to allow > clients over a network to send image data, however that would be kind > of like VNC. Wayland will definitely not take drawing commands like X, > because it is supposed to be rendering API neutral.
> The long answer: Remote desktop is really something that belongs in > the toolkits (Gtk+, Qt), not the display server. This would be > preferable both to the X11 method, and to the VNC method. A remote > application would use the toolkit just like normal, and the toolkit > would issue commands to a daemon running on the local computer, which > would draw the windows and send them to Wayland in DRM buffers. This > is better than both X and VNC because it has the potential to save a > lot of bandwidth. As much as X/NX is better than VNC, this would be > even better, because the toolkit wouldn't have to send every little > drawing detail, since the local daemon would know those details. This > would allow Wayland to remain rendering API neutral, and use even less > bandwidth than X for remote desktop.
> On Sep 17, 9:41 pm, Nerdopolis <bluescreen_aven...@verizon.net> wrote: >> Hi. >> I was just wondering if the Wayland protocol can be sent over a >> network running on a remote machine, connected to a remote Wayland >> server, without recompiling/rewriting the apps.
>> There are many people that see this ssh -x feature as usable. And this >> ability in X11 is used in many different forms, such as NoMachine's >> NX.
>> Please don't say it has to be a VNC type of deal, where the whole >> desktop is just boxed in, or a Citrix type of deal, where remote apps >> where an afterthought, and resulted in a flaky implantation.
>> I just think that network functionality is too big of a functionality >> to lose.
> -- > You received this message because you are subscribed to the Google Groups "Wayland" group. > To post to this group, send email to
Then I'd hope a more network friendly protocol would be added on top
of the Wayland protocol, before they are ported to the native
protocol, but it already seems toolkits are being ported to the native
protocol as far as I can tell...
I hope we don't have to rely on all toolkits to implant their own
network protocol. Worrying about security/performance/other issues on
3 new protocols (GTK's protocol,QT's protocol,XT's protocol) instead
of focusing on one will be more work for the community.
IMHO network transparency is too huge of a feature to lose. I don't
want to see any hacks like Citrix needed for Linux.
P.S: I know X11 apps could be run in Wayland, but if apps start being
ported to Wayland, then those apps won't be able to be run over the
network. Which I guess would be fine for apps for mobile devices like
MeeGo, but not really for the Desktop.
On Sep 18, 10:37 am, Paolo Bonzini <bonz...@gnu.org> wrote:
> <bluescreen_aven...@verizon.net> wrote:
> > Then what is this "Wayland 'Protocol'" I keep reading about?
> There are wayland clients (eg. the X server could be one) and a
> wayland server (the compositor). However, the protocol is not
> network-friendly (it uses Unix sockets only) because the commands
> refers to data in the GPU memory.
Zifre: you posted when I was typing up my reply... ...Anyway, if the
networking interface is in each toolkit, then that means the toolkits
will have to be installed on the remote machine as well
Maybe if they're not going to do a network friendly [i]protocol[/i],
they can do a low level [i]toolkit[/i], that the toolkits use, that
way there is only one.
On Sep 18, 6:15 pm, Zifre <kmick...@gmail.com> wrote:
> This seems to be a common complaint about Wayland. Here is the short
> answer: remote desktop with just Wayland is impossible because it
> communicates with local DRM buffers. It could be extended to allow
> clients over a network to send image data, however that would be kind
> of like VNC. Wayland will definitely not take drawing commands like X,
> because it is supposed to be rendering API neutral.
> The long answer: Remote desktop is really something that belongs in
> the toolkits (Gtk+, Qt), not the display server. This would be
> preferable both to the X11 method, and to the VNC method. A remote
> application would use the toolkit just like normal, and the toolkit
> would issue commands to a daemon running on the local computer, which
> would draw the windows and send them to Wayland in DRM buffers. This
> is better than both X and VNC because it has the potential to save a
> lot of bandwidth. As much as X/NX is better than VNC, this would be
> even better, because the toolkit wouldn't have to send every little
> drawing detail, since the local daemon would know those details. This
> would allow Wayland to remain rendering API neutral, and use even less
> bandwidth than X for remote desktop.
> On Sep 17, 9:41 pm, Nerdopolis <bluescreen_aven...@verizon.net> wrote:
> > Hi.
> > I was just wondering if the Wayland protocol can be sent over a
> > network running on a remote machine, connected to a remote Wayland
> > server, without recompiling/rewriting the apps.
> > There are many people that see this ssh -x feature as usable. And this
> > ability in X11 is used in many different forms, such as NoMachine's
> > NX.
> > Please don't say it has to be a VNC type of deal, where the whole
> > desktop is just boxed in, or a Citrix type of deal, where remote apps
> > where an afterthought, and resulted in a flaky implantation.
> > I just think that network functionality is too big of a functionality
> > to lose.
At risk of stating the obvious, why not target toolkits, and let the toolkit decide whether Wayland or X11 is the correct backend to use? Wayland can host X, and X isn't ever going away, so this is not unacceptable.
Sending from a mobile, pardon the brevity. ~ C.
On Sep 18, 2010 4:31 PM, "Nerdopolis" <bluescreen_aven...@verizon.net> wrote:
> Zifre: you posted when I was typing up my reply... ...Anyway, if the > networking interface is in each toolkit, then that means the toolkits > will have to be installed on the remote machine as well
> Maybe if they're not going to do a network friendly [i]protocol[/i], > they can do a low level [i]toolkit[/i], that the toolkits use, that > way there is only one.
> On Sep 18, 6:15 pm, Zifre <kmick...@gmail.com> wrote: >> This seems to be a common complaint about Wayland. Here is the short >> answer: remote desktop with just Wayland is impossible because it >> communicates with local DRM buffers. It could be extended to allow >> clients over a network to send image data, however that would be kind >> of like VNC. Wayland will definitely not take drawing commands like X, >> because it is supposed to be rendering API neutral.
>> The long answer: Remote desktop is really something that belongs in >> the toolkits (Gtk+, Qt), not the display server. This would be >> preferable both to the X11 method, and to the VNC method. A remote >> application would use the toolkit just like normal, and the toolkit >> would issue commands to a daemon running on the local computer, which >> would draw the windows and send them to Wayland in DRM buffers. This >> is better than both X and VNC because it has the potential to save a >> lot of bandwidth. As much as X/NX is better than VNC, this would be >> even better, because the toolkit wouldn't have to send every little >> drawing detail, since the local daemon would know those details. This >> would allow Wayland to remain rendering API neutral, and use even less >> bandwidth than X for remote desktop.
>> On Sep 17, 9:41 pm, Nerdopolis <bluescreen_aven...@verizon.net> wrote:
>> > Hi. >> > I was just wondering if the Wayland protocol can be sent over a >> > network running on a remote machine, connected to a remote Wayland >> > server, without recompiling/rewriting the apps.
>> > There are many people that see this ssh -x feature as usable. And this >> > ability in X11 is used in many different forms, such as NoMachine's >> > NX.
>> > Please don't say it has to be a VNC type of deal, where the whole >> > desktop is just boxed in, or a Citrix type of deal, where remote apps >> > where an afterthought, and resulted in a flaky implantation.
>> > I just think that network functionality is too big of a functionality >> > to lose.
> -- > You received this message because you are subscribed to the Google Groups "Wayland" group. > To post to this group, send email to
Windowing systems use a server/client model to share the display and input (server) between multiple applications (clients). To communicate, the clients and the display server need to use the same protocol. The "Wayland Protocol" is a protocol in the sense it is "a formal description of digital message formats and the rules for exchanging those messages".
This protocol is described in XML files which are used to generate bindings for different languages (a la XCB). For example, the reference wayland implementation has a tool which generates C bindings. These bindings are then compiled in easy to use libraries for clients and server.
This system makes Wayland an open architecture which allows to easily write clients in any language or even replace the reference compositor with one more suited for specific requirements.
The core Wayland protocol only define the minimal semantic necessary for applications to cooperate with the compositor (cf spec/main.tex). This includes window management (e.g surface requests, geometry setup, update notifications) and input management (e.g input redirection, focus, cursor). Additionally, Wayland also define protocol for functionality like Drag and Drop (which rely on the compositor to send events to the correct target) and the shared object cache (which can reuse the buffer sharing mechanisms).
What makes Wayland much simpler is that it does support any rendering commands in the protocol. Instead it provides applications with a handle to a graphic buffer (this is why it can only be used between applications on the same system). Applications can render directly to this buffer using the CPU or the GPU without the server having to support the redirection of graphic commands. Actually there would be no reason to support rendering in the display server since using the GPU doesn't affect the display. You might wonder why X support this redirection which amount to virtualizing the GPU for the clients.
X was designed for thin clients at a time where the primary purpose of video cards was to render graphic primitives on a display, thus it was natural to send graphic commands to be executed on the display server. Nowadays, X is more commonly used in desktop configurations where the server is executing on the same system as its clients. That's why modern X implementations developed optimizations like local sockets, shared memory and direct rendering. However, with the GPU now becoming a general purpose data processor, It makes more sense to consider it as a local resource which can be used by the client (like the CPU) instead of transferring all instructions and data to a display server.
While remote GPU rendering is no longer supported with wayland, It doesn't mean the end of rootless network transparency. Since implementing a wayland server is much simpler than implementing an X server, you can implement a compositor which transfer window contents via an existing protocol (e.g. RDP). A similar solution exists for X applications using an X server (Xvfb) and a special compositing manager (Xpra). These solutions have the advantages of pixel-based protocols: - persistent remote applications - migrating applications between displays - variable compression - independent of rendering complexity
Supporting only the common case (local display) will also make it possible to create a tearing-free desktop compositing chain without sacrificing latency or performance.
In the current X graphic stack, the compositing manager is a client like any other. As any client, it is affected by the accumulated latency between the time it receive damage notifications and the time its rendering commands are processed. Since running a remote compositing manager would be useless and unusable, the only advantage with having the manager as a client is the ability to replace it with another implementation (to have different effects).
Wayland design integrates the display server and compositing window manager. This integration avoid redundant implementations and inconsistencies like having a representation of the window stack in both the server and the compositor. Since the compositor has complete control over the screen, it can synchronize its updates with vertical blanking to avoid flicker and tearing. Modularity is not lost since custom effects can be implemented as plugins to the display server (similarly to Compiz plugins).
Coincidentally two other desktop system also merged these components in their graphic stack (see Quartz Compositor and Desktop Window Manager).
In conclusion: Wayland is not a reimplementation of X doomed to be bloated when feature complete. Wayland is not yet another abstraction in the graphic stack (except when providing legacy X compatibility). Wayland will simplify the graphic stack and finally provide a tearing-free linux desktop.
On 9/18/10, Nerdopolis <bluescreen_aven...@verizon.net> wrote:
> Then what is this "Wayland 'Protocol'" I keep reading about?
I hope you and other users now better understand what wayland really is. I tried to provide a rationale for why it is needed though I became recently interested in the graphic stack and I'm not a wayland developer, so don't take this as ground truth.
> At risk of stating the obvious, why not target toolkits, and let the toolkit > decide whether Wayland or X11 is the correct backend to use? Wayland can > host X, and X isn't ever going away, so this is not unacceptable.
> Sending from a mobile, pardon the brevity. ~ C.
> On Sep 18, 2010 4:31 PM, "Nerdopolis" <bluescreen_aven...@verizon.net> > wrote: >> Zifre: you posted when I was typing up my reply... ...Anyway, if the >> networking interface is in each toolkit, then that means the toolkits >> will have to be installed on the remote machine as well
>> Maybe if they're not going to do a network friendly [i]protocol[/i], >> they can do a low level [i]toolkit[/i], that the toolkits use, that >> way there is only one.
>> On Sep 18, 6:15 pm, Zifre <kmick...@gmail.com> wrote: >>> This seems to be a common complaint about Wayland. Here is the short >>> answer: remote desktop with just Wayland is impossible because it >>> communicates with local DRM buffers. It could be extended to allow >>> clients over a network to send image data, however that would be kind >>> of like VNC. Wayland will definitely not take drawing commands like X, >>> because it is supposed to be rendering API neutral.
>>> The long answer: Remote desktop is really something that belongs in >>> the toolkits (Gtk+, Qt), not the display server. This would be >>> preferable both to the X11 method, and to the VNC method. A remote >>> application would use the toolkit just like normal, and the toolkit >>> would issue commands to a daemon running on the local computer, which >>> would draw the windows and send them to Wayland in DRM buffers. This >>> is better than both X and VNC because it has the potential to save a >>> lot of bandwidth. As much as X/NX is better than VNC, this would be >>> even better, because the toolkit wouldn't have to send every little >>> drawing detail, since the local daemon would know those details. This >>> would allow Wayland to remain rendering API neutral, and use even less >>> bandwidth than X for remote desktop.
>>> On Sep 17, 9:41 pm, Nerdopolis <bluescreen_aven...@verizon.net> wrote:
>>> > Hi. >>> > I was just wondering if the Wayland protocol can be sent over a >>> > network running on a remote machine, connected to a remote Wayland >>> > server, without recompiling/rewriting the apps.
>>> > There are many people that see this ssh -x feature as usable. And this >>> > ability in X11 is used in many different forms, such as NoMachine's >>> > NX.
>>> > Please don't say it has to be a VNC type of deal, where the whole >>> > desktop is just boxed in, or a Citrix type of deal, where remote apps >>> > where an afterthought, and resulted in a flaky implantation.
>>> > I just think that network functionality is too big of a functionality >>> > to lose.
>> -- >> You received this message because you are subscribed to the Google Groups > "Wayland" group. >> To post to this group, send email to > wayland-display-server@googlegroups.com. >> To unsubscribe from this group, send email to > wayland-display-server+unsubscribe@googlegroups.com<wayland-display-server% 2Bunsubscribe@googlegroups.com>
This is one of the reasons I am so excited about wayland. I used to use OSX, until I came to love the freedom of the gnu/linux desktop. One thing that has always bothered me however, is the "ugliness" of graphics rendering. any movement or animation causes horrible tearing, and flickering is a common problem also. It is something that many other mac owners cannot get over when working with the GNU/Linux desktop, and that's a shame.
> Windowing systems use a server/client model to share the display and > input (server) between multiple applications (clients). > To communicate, the clients and the display server need to use the > same protocol. > The "Wayland Protocol" is a protocol in the sense it is "a formal > description of digital message formats and the rules for exchanging > those messages".
> This protocol is described in XML files which are used to generate > bindings for different languages (a la XCB). > For example, the reference wayland implementation has a tool which > generates C bindings. > These bindings are then compiled in easy to use libraries for clients > and server.
> This system makes Wayland an open architecture which allows to easily > write clients in any language or even replace the reference compositor > with one more suited for specific requirements.
> The core Wayland protocol only define the minimal semantic necessary > for applications to cooperate with the compositor (cf spec/main.tex). > This includes window management (e.g surface requests, geometry setup, > update notifications) and input management (e.g input redirection, > focus, cursor). > Additionally, Wayland also define protocol for functionality like Drag > and Drop (which rely on the compositor to send events to the correct > target) and the shared object cache (which can reuse the buffer > sharing mechanisms).
> What makes Wayland much simpler is that it does support any rendering > commands in the protocol. > Instead it provides applications with a handle to a graphic buffer > (this is why it can only be used between applications on the same > system). > Applications can render directly to this buffer using the CPU or the > GPU without the server having to support the redirection of graphic > commands. > Actually there would be no reason to support rendering in the display > server since using the GPU doesn't affect the display. > You might wonder why X support this redirection which amount to > virtualizing the GPU > for the clients.
> X was designed for thin clients at a time where the primary purpose of > video cards was to render graphic primitives on a display, thus it was > natural to send graphic commands to be executed on the display server. > Nowadays, X is more commonly used in desktop configurations where the > server is executing on the same system as its clients. > That's why modern X implementations developed optimizations like local > sockets, shared memory and direct rendering. > However, with the GPU now becoming a general purpose data processor, > It makes more sense to consider it as a local resource which can be > used by the client (like the CPU) instead of transferring all > instructions and data to a display server.
> While remote GPU rendering is no longer supported with wayland, It > doesn't mean the end of rootless network transparency. > Since implementing a wayland server is much simpler than implementing > an X server, > you can implement a compositor which transfer window contents via an > existing protocol (e.g. RDP). A similar solution exists for X > applications using an X server (Xvfb) and a special compositing > manager (Xpra). > These solutions have the advantages of pixel-based protocols: > - persistent remote applications > - migrating applications between displays > - variable compression > - independent of rendering complexity
> Supporting only the common case (local display) will also make it > possible to create a tearing-free desktop compositing chain without > sacrificing latency or performance.
> In the current X graphic stack, the compositing manager is a client > like any other. > As any client, it is affected by the accumulated latency between the > time it receive damage notifications and the time its rendering > commands are processed. > Since running a remote compositing manager would be useless and > unusable, the only advantage with having the manager as a client is > the ability to replace it with another implementation (to have > different effects).
> Wayland design integrates the display server and compositing window manager. > This integration avoid redundant implementations and inconsistencies > like having a representation of the window stack in both the server > and the compositor. > Since the compositor has complete control over the screen, it can > synchronize its updates with vertical blanking to avoid flicker and > tearing. > Modularity is not lost since custom effects can be implemented as > plugins to the display server (similarly to Compiz plugins).
> Coincidentally two other desktop system also merged these components > in their graphic stack (see Quartz Compositor and Desktop Window > Manager).
> In conclusion: > Wayland is not a reimplementation of X doomed to be bloated when > feature complete. > Wayland is not yet another abstraction in the graphic stack (except > when providing legacy X compatibility). > Wayland will simplify the graphic stack and finally provide a > tearing-free linux desktop.
> On 9/18/10, Nerdopolis <bluescreen_aven...@verizon.net> wrote: >> Then what is this "Wayland 'Protocol'" I keep reading about?
> I hope you and other users now better understand what wayland really is. > I tried to provide a rationale for why it is needed though I became > recently interested in the graphic stack and I'm not a wayland > developer, so don't take this as ground truth.
> -- > You received this message because you are subscribed to the Google Groups "Wayland" group. > To post to this group, send email to
I don't know if its possible to do something similar as XPRA in
Wayland. AFAIK there is a potential for client side window management
(which I hope is not chosen) to be used in Wayland...
I guess this is another argument against client side decorations...
How would it know how to do rootless windowing (so they could be
exported over the network) if the windows are being managed by the
apps?
<matthias.fauconn...@gmail.com> wrote:
> Windowing systems use a server/client model to share the display and
> input (server) between multiple applications (clients).
> To communicate, the clients and the display server need to use the
> same protocol.
> The "Wayland Protocol" is a protocol in the sense it is "a formal
> description of digital message formats and the rules for exchanging
> those messages".
> This protocol is described in XML files which are used to generate
> bindings for different languages (a la XCB).
> For example, the reference wayland implementation has a tool which
> generates C bindings.
> These bindings are then compiled in easy to use libraries for clients
> and server.
> This system makes Wayland an open architecture which allows to easily
> write clients in any language or even replace the reference compositor
> with one more suited for specific requirements.
> The core Wayland protocol only define the minimal semantic necessary
> for applications to cooperate with the compositor (cf spec/main.tex).
> This includes window management (e.g surface requests, geometry setup,
> update notifications) and input management (e.g input redirection,
> focus, cursor).
> Additionally, Wayland also define protocol for functionality like Drag
> and Drop (which rely on the compositor to send events to the correct
> target) and the shared object cache (which can reuse the buffer
> sharing mechanisms).
> What makes Wayland much simpler is that it does support any rendering
> commands in the protocol.
> Instead it provides applications with a handle to a graphic buffer
> (this is why it can only be used between applications on the same
> system).
> Applications can render directly to this buffer using the CPU or the
> GPU without the server having to support the redirection of graphic
> commands.
> Actually there would be no reason to support rendering in the display
> server since using the GPU doesn't affect the display.
> You might wonder why X support this redirection which amount to
> virtualizing the GPU
> for the clients.
> X was designed for thin clients at a time where the primary purpose of
> video cards was to render graphic primitives on a display, thus it was
> natural to send graphic commands to be executed on the display server.
> Nowadays, X is more commonly used in desktop configurations where the
> server is executing on the same system as its clients.
> That's why modern X implementations developed optimizations like local
> sockets, shared memory and direct rendering.
> However, with the GPU now becoming a general purpose data processor,
> It makes more sense to consider it as a local resource which can be
> used by the client (like the CPU) instead of transferring all
> instructions and data to a display server.
> While remote GPU rendering is no longer supported with wayland, It
> doesn't mean the end of rootless network transparency.
> Since implementing a wayland server is much simpler than implementing
> an X server,
> you can implement a compositor which transfer window contents via an
> existing protocol (e.g. RDP). A similar solution exists for X
> applications using an X server (Xvfb) and a special compositing
> manager (Xpra).
> These solutions have the advantages of pixel-based protocols:
> - persistent remote applications
> - migrating applications between displays
> - variable compression
> - independent of rendering complexity
> Supporting only the common case (local display) will also make it
> possible to create a tearing-free desktop compositing chain without
> sacrificing latency or performance.
> In the current X graphic stack, the compositing manager is a client
> like any other.
> As any client, it is affected by the accumulated latency between the
> time it receive damage notifications and the time its rendering
> commands are processed.
> Since running a remote compositing manager would be useless and
> unusable, the only advantage with having the manager as a client is
> the ability to replace it with another implementation (to have
> different effects).
> Wayland design integrates the display server and compositing window manager.
> This integration avoid redundant implementations and inconsistencies
> like having a representation of the window stack in both the server
> and the compositor.
> Since the compositor has complete control over the screen, it can
> synchronize its updates with vertical blanking to avoid flicker and
> tearing.
> Modularity is not lost since custom effects can be implemented as
> plugins to the display server (similarly to Compiz plugins).
> Coincidentally two other desktop system also merged these components
> in their graphic stack (see Quartz Compositor and Desktop Window
> Manager).
> In conclusion:
> Wayland is not a reimplementation of X doomed to be bloated when
> feature complete.
> Wayland is not yet another abstraction in the graphic stack (except
> when providing legacy X compatibility).
> Wayland will simplify the graphic stack and finally provide a
> tearing-free linux desktop.
> On 9/18/10, Nerdopolis <bluescreen_aven...@verizon.net> wrote:
> > Then what is this "Wayland 'Protocol'" I keep reading about?
> I hope you and other users now better understand what wayland really is.
> I tried to provide a rationale for why it is needed though I became
> recently interested in the graphic stack and I'm not a wayland
> developer, so don't take this as ground truth.
