Wayland Preparing For 1.0 Stable Release

[johnc]

The fact that you think this feature is going to disappear honestly baffles me. Where does this mindset come from? Do you think Red Hat is going to start shipping RHEL without the ability to use remote apps like they currently can?

Where does the mindset come from? How about there doesn't seem to be any serious consideration for network transparency at the design phase? It almost seems like that kind of thing just really isn't that important. Yes, there's a lot of hand-waving, "ohhhhh, welll... you can run X on top of Wayland to run remote apps..." Seriously -- why would I want to do that? Ok, eventually X will be phased out... and then something else will have to be implemented. That "something else" really hasn't been designed yet as far as I can see. I'm sure they'll come up with something. Of course RH will have remote app functionality. Microsoft can check that box too. Maybe we'll end up with something like VNC... wouldn't that be awesome? So will the brunt of the work be done on the server or on the client? Wouldn't it be nice to know some of these things as we're coming upon a "stable release"?

I understand that X is a turd and it'd be great if it was replaced with something better. I'm sure Wayland will be better. Maybe in practice the benefits won't be obvious to the end-user. But I just said what I feel -- that that thread didn't inspire any confidence in me that network transparency is even in the top thousand (<-- that's hyperbole btw) areas of concern for Wayland devs. Hopefully I'm wrong. We'll just have to cross our fingers, keep our mouths shut, and place our trust in them.

FUD. This is FUD. Because seriously - no one has the goal of making linux shitty.

Ok... maybe "goal" was the wrong word, but in practice that is often what we get. We can look to our "Experienced GNOME developers" for evidence of that.

[smitty3268]

...

Everything you say just confirms my original feelings about this subject. It seems we've gone full circle. Good night, and hopefully Red Hat doesn't decide to torpedo their entire business just because they felt like it. That'd be unfortunate.

[89c51]

i am quite surprised that they are approaching 1.0 stable so fast.

i was expecting a long(ish) testing period with fully functional desktops -just in case something goes wrong and to fix minnor stuff here and there- and then release 1.0

props to the devs

[elanthis]

Where does the mindset come from? How about there doesn't seem to be any serious consideration for network transparency at the design phase?

Because there doesn't need to be any. You're either missing some bit of information here, have a grotesque misunderstanding of some of the Wayland fundamentals, or are just being obtuse. :/

Let's ignore the network for a moment and just try to understand how Wayland works. That'll make the network bit much easier to understand.

The Wayland protocol lets clients connect to what is essentially just a compositor and input manager. All rendering happens on the client application. The client application posts updated frame buffers to the compositor. Wayland composites all the clients onto the "display." Wayland delivers input signals to the clients. A few other bits are also done, but that's pretty much the gist of it.

The cool bit of Wayland is that the "display" and input event sources do not at all need to actually be a physical display or OS input devices. They can easily be an X11 window. They can be a hidden surface inside a GUI app test harness that sends scripted input to the apps and records and diffs output frames. They can an offscreen buffer used for compositing over X11, which is what KWin is working on doing (so your Wayland native apps run over X11) and what Weston can already do. They can be just about anything you want, because all the protocol does is coordinate framebuffer updates and handle input events and the like. None of these new applications or special configuration require any kind of new protocol changes. The protocol already works for all of these cases, and more.

This is where networking comes in and becomes so easy. There is no need for Wayland support for networking because Wayland already does everything you'd need to support networking. Since the Wayland server/compositor can easily be any random app (which doesn't even need to have a graphical display of any kind) it's _already supported_ to just drop in any possible networked proxy or remote display system you want. Want VNC? Just write a VNC client that's a Wayland server. Want SPICE? SPICE client that's a Wayland server. Want HTML5? HTTP server with streaming WebM and WebSockets that's a Wayland server. Want something specifically optimized for per-window low-latency low-bandwidth WiFi/Internet remoting of desktop applications? Figure out that new protocol, write a client/server for it, and make the client a Wayland server. _None of these_ will require a protocol change or changes to any Wayland-based applications.

No changes to Wayland itself are needed, period. That's why the Wayland folks are saying they'll worry about it later: because they _can_, because the protocol was designed to be separate from the networking half. It does not need -- nor is there any reason to even want -- the networking aspect to be built into the Wayland protocol itself. The network proxy stuff hasn't appeared yet because nobody who actually does anything but whine has bothered to write one. It's not because Wayland needs some future extension or changes that are being ignored.

There is something lost by this approach which X11 offers. That is remote rendering. With X11, remoting is actually very different than what Wayland requires. With Wayland, the networked proxy would only be sending finished frames across the network, while with X11, the drawing commands are sent across the network. The X11 way kinda sorta works better in environments with very low bandwidth and very low latency, but those networks don't really exist in this day and age; just about everything is decently high bandwidth, and the networks that have bandwidth constraints also have latency problems. The other advantage to the X11 model is that thin client setups allow distributing the actual graphics rendering work out to the actual clients while the Wayland model would require the application server to do all rendering (potentially requiring more expensive application servers, albeit allowing even cheaper and "thinner" clients). I have yet to see anybody actually bitch about this, though; instead we just see "I can't SSH into a box and run an app!" which is a very different use case than thin clients, and for which the Wayland approach will work better anyway.

As a final note, a lot of people complain when they hear "VNC-like" by assuming that means remoting an entire desktop rather than individual windows. All VNC-like means is that the network support is effected by frame transmission rather than drawing command transmission. Pretty much everybody agrees that a seamless per-window approach is a better user experience.

... maybe "goal" was the wrong word, but in practice that is often what we get. We can look to our "Experienced GNOME developers" for evidence of that.

What in $DEITY's name makes you think GNOME is in any way, shape, or form following in Windows' footsteps? Half the reason why everyone is bitching about GNOME lately is that they've gone so far off into "WTF, this is nothing like anything else land" that its' barely recognizable as a desktop at all, much less a Windows-like one. One could only _wish_ that GNOME (and the other desktops) tried to look and act more like Win7; then the Linux desktops might not feel quite so unpolished, buggy, and inefficient as it is.

[Qaridarium]

one is for sure I LOVE WAYLAND!!! *Happy*

and its also perfect for mobile devices

i hope andorid switch to wayland to.

[89c51]

one is for sure I LOVE WAYLAND!!! *Happy*

and its also perfect for mobile devices

i hope andorid switch to wayland to.

i am not sure about android but i thiiiiink i saw some chrome OS related stuff round the web

tizen most likely will use it (at least thats what i expect)

[liam]

Because there doesn't need to be any. You're either missing some bit of information here, have a grotesque misunderstanding of some of the Wayland fundamentals, or are just being obtuse. :/

Let's ignore the network for a moment and just try to understand how Wayland works. That'll make the network bit much easier to understand.

The Wayland protocol lets clients connect to what is essentially just a compositor and input manager. All rendering happens on the client application. The client application posts updated frame buffers to the compositor. Wayland composites all the clients onto the "display." Wayland delivers input signals to the clients. A few other bits are also done, but that's pretty much the gist of it.

The cool bit of Wayland is that the "display" and input event sources do not at all need to actually be a physical display or OS input devices. They can easily be an X11 window. They can be a hidden surface inside a GUI app test harness that sends scripted input to the apps and records and diffs output frames. They can an offscreen buffer used for compositing over X11, which is what KWin is working on doing (so your Wayland native apps run over X11) and what Weston can already do. They can be just about anything you want, because all the protocol does is coordinate framebuffer updates and handle input events and the like. None of these new applications or special configuration require any kind of new protocol changes. The protocol already works for all of these cases, and more.

This is where networking comes in and becomes so easy. There is no need for Wayland support for networking because Wayland already does everything you'd need to support networking. Since the Wayland server/compositor can easily be any random app (which doesn't even need to have a graphical display of any kind) it's _already supported_ to just drop in any possible networked proxy or remote display system you want. Want VNC? Just write a VNC client that's a Wayland server. Want SPICE? SPICE client that's a Wayland server. Want HTML5? HTTP server with streaming WebM and WebSockets that's a Wayland server. Want something specifically optimized for per-window low-latency low-bandwidth WiFi/Internet remoting of desktop applications? Figure out that new protocol, write a client/server for it, and make the client a Wayland server. _None of these_ will require a protocol change or changes to any Wayland-based applications.

No changes to Wayland itself are needed, period. That's why the Wayland folks are saying they'll worry about it later: because they _can_, because the protocol was designed to be separate from the networking half. It does not need -- nor is there any reason to even want -- the networking aspect to be built into the Wayland protocol itself. The network proxy stuff hasn't appeared yet because nobody who actually does anything but whine has bothered to write one. It's not because Wayland needs some future extension or changes that are being ignored.

There is something lost by this approach which X11 offers. That is remote rendering. With X11, remoting is actually very different than what Wayland requires. With Wayland, the networked proxy would only be sending finished frames across the network, while with X11, the drawing commands are sent across the network. The X11 way kinda sorta works better in environments with very low bandwidth and very low latency, but those networks don't really exist in this day and age; just about everything is decently high bandwidth, and the networks that have bandwidth constraints also have latency problems. The other advantage to the X11 model is that thin client setups allow distributing the actual graphics rendering work out to the actual clients while the Wayland model would require the application server to do all rendering (potentially requiring more expensive application servers, albeit allowing even cheaper and "thinner" clients). I have yet to see anybody actually bitch about this, though; instead we just see "I can't SSH into a box and run an app!" which is a very different use case than thin clients, and for which the Wayland approach will work better anyway.

As a final note, a lot of people complain when they hear "VNC-like" by assuming that means remoting an entire desktop rather than individual windows. All VNC-like means is that the network support is effected by frame transmission rather than drawing command transmission. Pretty much everybody agrees that a seamless per-window approach is a better user experience.



What in $DEITY's name makes you think GNOME is in any way, shape, or form following in Windows' footsteps? Half the reason why everyone is bitching about GNOME lately is that they've gone so far off into "WTF, this is nothing like anything else land" that its' barely recognizable as a desktop at all, much less a Windows-like one. One could only _wish_ that GNOME (and the other desktops) tried to look and act more like Win7; then the Linux desktops might not feel quite so unpolished, buggy, and inefficient as it is.

...BLAH BLAH BLAH...

X devs are idiots/X FOREVER!!!

Hmm, I'm sure there's a problem hidden in there somewhere

Nicely said, elanthis...well, mostly. I'm not sure I agree with you sentiments towards the end.

[Welsh Dwarf]

The Wayland protocol lets clients connect to what is essentially just a compositor and input manager. All rendering happens on the client application. The client application posts updated frame buffers to the compositor. Wayland composites all the clients onto the "display." Wayland delivers input signals to the clients. A few other bits are also done, but that's pretty much the gist of it.

The cool bit of Wayland is that the "display" and input event sources do not at all need to actually be a physical display or OS input devices. They can easily be an X11 window. They can be a hidden surface inside a GUI app test harness that sends scripted input to the apps and records and diffs output frames. They can an offscreen buffer used for compositing over X11, which is what KWin is working on doing (so your Wayland native apps run over X11) and what Weston can already do. They can be just about anything you want, because all the protocol does is coordinate framebuffer updates and handle input events and the like. None of these new applications or special configuration require any kind of new protocol changes. The protocol already works for all of these cases, and more.

Thank you for explaining this once and for all.

Now I'm even more excited about wayland's possibilities: You could have your app render on the server, push the result through some standard video compression (vorbis, webm, or h264, choose your poison), and stream it to your mobile phone (or browser). On the phone, you intercept pinches and zooms pokes and input and send the input back to the server. Light weight remote apps from anywhere .

Due to the video compression, you'd get relatively low bandwidth usage, and easy decompression and render on the client side.

What in $DEITY's name makes you think GNOME is in any way, shape, or form following in Windows' footsteps? Half the reason why everyone is bitching about GNOME lately is that they've gone so far off into "WTF, this is nothing like anything else land" that its' barely recognizable as a desktop at all, much less a Windows-like one. One could only _wish_ that GNOME (and the other desktops) tried to look and act more like Win7; then the Linux desktops might not feel quite so unpolished, buggy, and inefficient as it is.

Actually, if people weren't moaning about being outworldish, they'd be moaning about free software copying Windows or OSX and never innovating. Haters gotta hate you know.

[China_Guy]

I wan't to see a webbrowser running on wayland. And what about Adobe Flash, will this ever run on wayland? AFAIK it has got some hard dependencies on X. And as much as I hate the thing, I really need the plugin for some websites.

Intel employee already worked port of Chromium to Wayland. look into this Chromium dev thread:http://groups.google.com/a/chromium....8a0493522fb74d

[kraftman]

I also find that the Linux kernel has a lot of cool features that can make applications faster, safer and simpler, and we often don't use those in the name of portability. There is an accept4 syscall that lets you accept a connection on a socket and sets O_CLOEXEC atomically. The epoll mechanism with timerfd and signalfd does most of what many complex userspace event loops do in many thousands of lines of code. We need to embrace all the new features the kernel offers and not insist on some outdated lowest common denominator.

Make the Linux OS, please and don't care about ancient crap that always slowed you down. Linux+wayland+systemd is the future.