Wayland preview

Yes, I saw that too.  One thing I like about RasPi is that it currently draws my X Windows graphics properly, as opposed to my Ubuntu 11.10 machine which sometimes has delayed rendering problems with diagonal lines and arcs.  They sometimes don't show up until I click the window's title bar, and I have no idea where in the Emperor's Old Clothes the problem might be.

So when I read that an adaptation layer (XWayland) will be provided, I have misgivings.  When I read that Wayland flings images around instead of graphical objects, my misgivings intensify.  At this point, I'm wondering if the gift horse is really a white elephant?

[Edit: changed "Emperor's New Clothes" to "Emperor's Old Clothes".  Sorry about that, C.A.R.]

Yes, it sounds like existing X applications will need to use an adaptation layer,

which will make them slower than they already are, but applications that use

GTK or Qt instead of X can run without an adaptation layer, with the potential

of a speedup.

coder27 wrote:

 

Yes, it sounds like existing X applications will need to use an adaptation layer,

which will make them slower than they already are, but applications that use

GTK or Qt instead of X can run without an adaptation layer, with the potential

of a speedup.

OK, so what do they use for drawing graphics and text and clipboard, so I can bypass them as well?  I have my own adaptation layer, so it's easy for me to switch from Xlib and Xft calls to something else.  I've just haven't come across something that's given me a good enough reason to switch.  I've found Xlib and Xft on every GNU/Linux system I've ported to.

from the faq:

What is the drawing API?

"Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is done, it informs the Wayland server of the new contents. The current test clients use either cairo software rendering, cairo on OpenGL or hardware accelerated OpenGL directly. As long as you have a userspace driver library that will let you render into a sharable buffer, you're good to go.

http://wayland.freedesktop.org/faq.html#heading_toc_j_3

"Will this be backwards-compatible with the 256MB Raspberry Pi Model B?"  -- Corbin Davenport

"Yes. All the work’s being done by the GPU."  -- Liz

"We’re still working to improve performance and memory consumption"  -- Eben

gpu_mem=128

    How much memory to reserve for the VideoCore, i.e. framebuffers, GL textures,

http://wayland.freedesktop.org/raspberrypi.html

Funnily enough, if Pi becomes an early adopter of Wayland, it'll be a feather in its cap, because X11 has needed a major kick in the pants and some fundamental design changes for well over a decade now.  Some would say two.

The many Wayland articles list a whole slew of reasons why X11 isn't adequate, but I've always considered a different one to be most important.  Single Points of Failure are bad engineering, period.  The fact that all the X11 applications connected to a given X11 server will die when the server drops is simply ridiculous.  It's not a primary goal of Wayland to remove SPoFs, but the project offers an excellent opportunity for it.

Of course, with change comes pain.  You need Xlib and Xft on every system to ensure your app can be ported, and yes, that is an important issue.  On the positive side though, the Wayland people seem to be considering backwards compatibility with traditional X11 quite seriously.

I like change (it's part of progress), and I think that this one is for the better.  Network transparency will come from a different angle, a remoting protocol, which I think is the right place for it.

Morgaine.

Funnily enough, if Pi becomes an early adopter of Wayland, it'll be a feather in its cap, because X11 has needed a major kick in the pants and some fundamental design changes for well over a decade now.  Some would say two.

The many Wayland articles list a whole slew of reasons why X11 isn't adequate, but I've always considered a different one to be most important.  Single Points of Failure are bad engineering, period.  The fact that all the X11 applications connected to a given X11 server will die when the server drops is simply ridiculous.  It's not a primary goal of Wayland to remove SPoFs, but the project offers an excellent opportunity for it.

Of course, with change comes pain.  You need Xlib and Xft on every system to ensure your app can be ported, and yes, that is an important issue.  On the positive side though, the Wayland people seem to be considering backwards compatibility with traditional X11 quite seriously.

I like change (it's part of progress), and I think that this one is for the better.  Network transparency will come from a different angle, a remoting protocol, which I think is the right place for it.

Morgaine.

Wayland is stuck with a nasty chicken vs egg problem. As it's such a different beast it effectively breaks all the existing X11 apps, no users means no focus on developing it further etc.

So they either spend lots of effort developing an X11 translation layer, or spend the effort on both QT & gtk+2 toolkits, and if either of those translations turns out to be under performant they could end up in trouble quickly.

I can't see it solving your SPOF problem either.  It's, rightly IMHO, targetting the now usual scenario where the single user is tightly coupled to the single screen on his device. Far less of a client / server setup than X11 has. So when my device dies will I be particularly bothered that the app is still running ?  Doubtful, and recent generations have been well trained that a reboot cures everything, good or bad engineering has little to do with it.

The bits I've read suggests they're going to use a version of the windows rdp protocol for their idea of network transparency. That's got upsides and downsides. It could mean that microsofts client will be able to connect to it and give lots of people a 'free' and well understood client experience. OTOH, I find the windows rdp stuff not so great, better than vnc certainly but still has it's issues - not that X11 doesn't as well.

If you've ever used the NoMachine nxclient stuff you probably already know that it does a mighty fine job of overcoming X11's deficiencies, but it also has an interesting additional mode where you connect remotely to your NX server and it then uses rdp to connect to a windows machine. Oddly, this conversion of rdp to compressed X11 usually results in a better user experience over any type of slow-ish or high latency network than raw rdp.

So change can be good, but needs doing right. Lots of change with either no visible user benefit, or worse with a performance hit from a translation layer, is unlikely to be seen as 'progress' by those pesky users who have a habit of voting with their feet

Still too early to tell for Wayland, but I think it's brave going for a very minimal desktop environment as currently implemented.

selsinork wrote:

 

Wayland is stuck with a nasty chicken vs egg problem. As it's such a different beast it effectively breaks all the existing X11 apps

Is this true though?  My understanding (which is entirely derivative and may easily have been swayed by overly optimistic Wayland articles) is that X11 compatibility is provided not just grudgingly but as a primary goal.  Indeed, anything less would be stupid, since practically 100% of Unix graphics applications would be abandoned --- not a recipe for success.

As I read it, all the old stuff will still work, some of it a bit slower because of translation overheads, some of it faster because the translation overheads may be less than the new gains.  The only thing that will disappear for a while (until remoting protocols take over) and is an accepted regression is network transparency.  That will definitely impact some people, but it's in the single digit percentages of X11 users or less.

Morgaine Dinova wrote:

 

Is this true though?  My understanding (which is entirely derivative and may easily have been swayed by overly optimistic Wayland articles) is that X11 compatibility is provided not just grudgingly but as a primary goal.  Indeed, anything less would be stupid, since practically 100% of Unix graphics applications would be abandoned --- not a recipe for success.

and therein lies the problem, if you make it a goal to provide X11 compatibility where's the incentive to move away from X11 ?  With no incentive to move and possibily less performance due to the compatibility layer will wayland ever gain the developer acceptance needed for success ?

and IMHO it also needs wide OS, proprietary GPU vendor, toolkit (Qt & GTK) and desktop environment support.  If it ends up being Linux/Weston only it's going nowhere fast.

> if you make it a goal to provide X11 compatibility where's the incentive to move away from X11 ?

They do apparently intend to provide an X11 compatibililty layer.  But how much time and space overhead

that will involve, remains to be seen, as does whether it will "just work".  With the X11 compatibility layer,

you will apparently be able to slide windows smoothly on your display.  I think Simon's GPU driver for X11 also

saw benefit from using the GPU for such large operations.  How much better Wayland is than what can be done

using Simon's approach is unknown. 

The Wayland folks talk about GTK and Qt applications bypassing X11 and going "direct" or "native".

Since Wayland doesn't have a native rendering API, I'm not sure exactly what that means or how much

benefit it provides in rendering speed.  Presumably it involves using the GPU for rendering somehow,

such as perhaps by using the OpenGL ES interface.   So it isn't clear if the X11 compatibility layer is

intended to be temporary until "direct" or "native" solutions are implemented, or whether it is intended

to be a permanent solution.

coder27 wrote:

 

So it isn't clear if the X11 compatibility layer is

intended to be temporary until "direct" or "native" solutions are implemented, or whether it is intended

to be a permanent solution.

I suspect it's going to be permanent.  A little further digging reveals that supposedly QT5 already has wayland support and GTK will get it later this year. Existing QT and GTK appear to have some support, but it read as if you need to do something to enable it and then run every app with a certain command line switch to change the backend.

Qt may be able to do it's own rendering - it already runs on various embedded things that don't use X11, but the choices appear to be either simple framebuffer (i.e software rendering) or OpenGL.

It's also worth keeping at least one eye half open on Sailfish, a mobile device O/S seeking to compete in Android's space by being more open, more plain Linux, compatible with Android apps yet totally different in UI concept, and faster through using Wayland.

That's a tall order, but ambitious ideas got us to the moon in 1969.  The early prototypes look interesting.