Update: Daniel’s blog post here provides some more info, including how to install the technology preview on Raspbian today. And Pekka’s blog post here has some very detailed technical information on the implementation of the Weston backend.

If you’re familiar with the Raspberry Pi desktop experience, you’ll have noticed that windows on the desktop can be a bit slower to move around than you’re used to on your PC or laptop. This is because X, the windowing software (or composition protocol) that we use, is not optimised to use the graphics core of the BCM2835, the chip at the heart of the Raspberry Pi. All the work is done by the ARM processor instead, which slows things down and leaves the graphics core twiddling its thumbs. That graphics core is extremely powerful, so we’re working on putting it to good use to fix the issue.

We’ve made the decision to bypass X completely. Over the past few months we’ve been working with our friends at Collabora to implement the open-source Wayland composition protocol on top of the BCM2835 hardware video scaler (HVS). The HVS is a very powerful piece of hardware, with a scaling throughput of 500 megapixels per second and blending throughput of 1 gigapixel per second. It runs independently of the OpenGL ES hardware, so we can continue to render 3d graphics at the full, very fast rate, even while compositing.

Wayland composited desktop with XWayland and native applications.

In comparison to our current X11 desktop environment, Wayland frees the ARM from the burden of stitching together the top level of the composition hierarchy, and allows us to provide some neat features, including non-rectangular windows, fades for windows which don’t have input focus and an Exposé-like scaled window browser (the sort of thing that Mac users will be familiar with). Legacy X applications can still be supported using XWayland. Check out this video from Collabora to see these features in action, and to compare the current state of affairs with the Wayland future. Those non-rectangular shapes? They’re also windows.

We’re still working to improve performance and memory consumption, and don’t expect to be able to replace X11 as our default desktop environment until later in the year, but we will be including a technology preview in our next Raspbian release. Until then, this post on Collabora’s website gives some more background.

As with PyPy, the Raspberry Pi Foundation has funded this work on Wayland; it’s one of the ways we are trying to give back to the open-source community. Obviously, much of the work on this particular project is Raspberry Pi specific, but there’s a large portion of what’s being done, particularly around XWayland and some of the generic effects in Weston, that can be reused on many other platforms.

We’re looking forward to being able to push out the full release in the next few months. We hope you like the look of it!

Looks good. As long as you can turn off the annoying animations that seem so prevalent nowadays. If I click on something, I want it to just appear. No fading, no sliding, no stretching.
By all means have all that headache inducing nonsense, but let those of us who use computers for work turn it off.
Or even better disable it at compilation time to save some MB.

Not only does everyone like lasgne, but this may have eased the way somewhat to porting Wayland over to other cheap Arm based computers. This gift horse may well feed others, rather than just Raspberry lasagne eaters. Saying that, long live the Raspberry Pi!

Liz, perhaps your isolation in Nippon has prevented you from seeing the preview of the reaction from the Nerdocracy when I clumsily attempted to pass on the good news in my sleep-deprived state around 4 AM local Sunday during the SF Faire weekend. I hope to be able to add at least some small demonstration of the advantages of this technology via my Pi-finity! STEM game system, even if it’s received as yet-another good deed that doesn’t go unpunished (I have no idea whether I got the multiple negatives right and frankly, I don’t give a rat’s posterior, Nerdocracy! :ugeek: ).

Maybe someday it will get through some incredibly thick skulls that the Pi was developed for students and their educators, not people who should be wasting their time elsewhere commenting on their adoration of “reality” TV or whatever it is those people think is actually cool. I’m not holding my breath though, as I don’t look good in blue skin (other than to complement my incredible baby blues, of course :lol:).

It’s a fantastic improvement, but I think the point that was not so well made by the other poster is that the transition effects on the windows appearing and closing in the video are masking the improvement in snappiness.

I’m sure there will be a config option to shut it of if it’s not what a user wants.

Hmm, I guess you took that the wrong way. With computers in general nowadays, manufacturer X tells you “this is the new interface. You will like the new interface. No, you can’t change it. You should change.”
The great thing (for me) about the Raspberry Pi is the user has control. You can do whatever you want with it. If you don’t like something, and there’s a way to change it, then change it, although this is true for Linux in general. Optimisation is a big deal, and even more so on the Pi. Getting it to do exactly what you want does involve making sure it’s not doing anything unnecessary. Which is why Wayland looks very interesting.
So no, not trying to criticise. Just commenting.

Bravo! Funding development like this is such a clever move for the foundation. This goes way beyond what I expected and is really a game changer. Projects like this take the Raspberry Pi to another level altogether. Thanks to all who make things like this happen and we should not take them for granted!

Yeah, Daniel Stone said yesterday the package in the Collabora is slightly out of date. His latest package should include a weston-launch script to work out of the box. Hopefully it should go live soon.

I followed the 3 steps and when I rebooted, I got partly through boot when I got hard I/O errors reading the SD card. So I re imaged the SD card back to the latested rpi wheezy. Using 32GB SD card by Sandisk

I installed the demo and promptly got lots of file system errors on my SD card. Fixed them with fsck on another computer, but the system was unusable after that — no desktop, no internet. Had to re-image the system.

(This isn’t a slam against Weston, which I’m looking forward to trying. Just reporting what happened.)

File system errors on the SD card can be caused by a bad SD card. fsck doesn’t check the storage media itself, only the structure of the file system on top of the storage media.

Running non-destructive badblocks across the card can tell you if all bytes are readable. If you are working with a card you can afford to erase, then badblocks writing patterns on your SD card will detect a garbage card. I had to do that when one of my SD cards was behaving oddly.

Almost forgot the most important improvement to having this acceleration. Pages will almost always be responsive and scroll smoothly, even while pages are loading. This’ll make the browser seem much faster.

My first idea was use Raspberry Pi as computer for quick internet browsing. (It is not useful to wait for booting of PC due to reading of one e-mail.) Unfortunatelly, browsing internet is incredibly slow with my Raspberry Pi model B even if it is connected to 40Mb/s line. Wayland seems to help me to reach my idea :-)

Is Collabora providing a Weston remote client for the Pi that would allow for optimally-fast trans-network sessions of desktop GUI elements? I’m looking forward to trying out some remote display of 3-D objects in Wayland windows on a second Pi (or other remote Wayland-capable platform) where the descriptions of Open GL ES objects within the windows are passed over the network for local GPU rendering rather than simply passing way-too-many window content pixels at an unsatisfactory frame rate. That was always what I had hoped to be able to do in my Pi-finity! STEM game system and Wayland/Weston should make this feasible.

Looks like I’m going to have to buy yet another pi as my current two units run XMBC and a Minecraft server I’m loath to give up.

The idea of getting rid of the loud, old and power hungry old desktop pc running puppy linux under the stairs to make way for a pi is just too tempting though. I can’t wait until you release this fully. It’s amazing that the same chipset from the Roku 2 can be pushed to do so many amazing things from 1080p video to a full fat desktop.

This looks like very good news for improving the performance ‘feel’ of Thin Clients – and they are important in schools – particularly the Linux Terminal Server Project LTSP. However effectively interfacing RPi with LTSP does seem a bit tricky tho’. Or have I got the wrong end of the stick?

You can use networked X clients as-is with XWayland acting as the X server and window manager. I guess it’s not quite the same as a stock LTSP set-up as the window manager is running locally, but you could probably figure out a way to make it work.

Looks really good. Creating smart (and free!) software to get the best use out of inexpensive hardware is a Good Thing – for users, for the environment and for the parts of the world where they can’t afford the expensive options. Well done the Foundation!

Impressive!! I’ve been avoiding X on the Pi because it’s unusable and irritating for a lighweight-lover like me. I’m a commandline junkie, so I could live without a desktop enviroment as it’s not needing for vim, gcc or gdb (and the Pi has the great, accelerated dispmanx backend for graphics without X11, too!), but this wayland stuff shows how hardware and software integration can benefit a device with a smart design as the Raspberry Pi. Just like on the Amiga, desktop stuff was originally handled by the custom chips. Way to go!!!

Midori probably won’t load pages much faster. A little though. Scrolling should be a bit smoother if run as a Wayland application using the GTK3 and webkit2 backends. X11 apps should run through a kind of compatibility layer, right there within Wayland.

Gtk WebKit isn’t fully ported to WebKit so running Midori as a native Wayland app won’t be possible as yet. There are a bunch of pieces to handle: getting GL set up for Accelerated Composition, getting overlays set up for HTML5 video, and for WebKit 2 you need a way to pass graphics between the rendering process and the UI process.

Collabora has been working on Wayland Subsurfaces which are needed for most of those – so one WebKit app window can set up different surfaces for eg the GL accelerated composition, video, etc and Wayland can composite them all. But it needs quite a bit more work in WebKit to make use of it.

At present it’s the very simplistic desktop shell implemented by Weston (the reference implementation of Wayland). GNOME has aggressive plans to port to Wayland by later in the year but to benefit directly from this work they would need a Raspberry Pi renderer/backend in the same way we’ve added one to Weston. However, GNOME3 uses GL composition in the shell so this might be pretty tricky. You could port bits of LXDE or XFCE over to Wayland either on top of or alongside Weston – LWDE / WFCE? :)

Looks fantastic, and great to see that GPU getting something to do (first the camera and now the desktop), all that untapped power. No doubt the guys who worked so it are chuffed, I know it is used in other things but must be annoying otherwise not being used to its full power.

How will this effect using things like X11-forwarding, as I typically use the Raspberry Pi headless. (I am hoping it will still work, if not speed it up).

Something about having a fixed platform allows for the software to catch up and do impressive things with a lot less. Brings to mind Mr Braben & Co. shoehorn of Elite into 80’s hardware.

This won’t affect X11-forwarding at all – if your app is remote, XWayland looks like a normal X server so stuff will works as usual – you will get your remote app scaled/composited/etc on the Pi a little quicker. If your app is on the Pi and you’re displaying it to a remote X server, it will work precisely as it is now, but this work won’t help you at all – it only speeds things up when the Pi is putting stuff on it’s screen.

If it’s a case of running X.org as a Wayland client then it’s probably not worth it for the Pi. The increase in memory from running both would likely outweigh the performance benefits of running Wayland.

The alternative for those that must have x-forwarding is just to stick with X.org. That will mean maintaining the x.org packages in the repositories, but they wouldn’t need to be installed for most users.

For the majority and in particular the target market (ie 8 to 18 year olds learning programming) then there is little benefit in learning X-forwarding, which will become a legacy protocol when the mainstream distros start moving to Wayland and as client applications drop . For those used to using X-forwarding then this is going to need a changing in working, but the performance improvement will hopefully outweigh that.

Not sure about this – even with remote X clients, the benefit of using the GPU for the 2D composition – moving windows around etc – has a massive impact on perceived responsiveness and usability. Its probably worth the RAM – and Weston is pretty small anyway.

Actually a bit easier than this – X11 forwarding works normally with XWayland as it’s just the normal X server rendering to Wayland instead. So remote X11 clients displaying on the Pi will work and get the benefit of this accelerated 2D desktop composition.

The Ubuntu thread is looking at “native” Wayland clients running remotely, as X11 is a pretty lousy network transparency protocol. Wayland can support any other protocol for this though – there’s a prototype RFB-based protocol for Wayland so you can have a remote “native” Wayland app, but it’s not a priority for the developers.

I’m not as enthuastic about Wayland this as some people. An acellerated GUI is great news if you use the Pi with a screen an keyboard but if the idea is for Wayland to replace the X desktop this is going to make it harder to use X windows to access the desktop remotly.

The sooner people realize the Pi is not meant to be a Pixar/Dreamworks/PDI/etc., graphics rendering farm, the happier they will become. There’s a very good reason that the board has both an HDMI and composite output connectors on it – the BCM2835 system-on-a-chip (SoC) was originally developed for the Roku 2 series of Internet media streaming products, so the expected output is HDMI digital video and 5,1 surround sound or composite analog video and sound (the latter via the 3.5 mm audio jack).

That the Foundation volunteer engineers have been able to do so much with so little for so long is testament to how much their work needs to be appreciated, not deprecated. No one seems to complain that they can’t remotely stream 1080p video at full resolution and frame rate beyond a LAN from a netbook that costs 10 times as much as the Pi, much less full-on laptops or desktops that often have the same limitation, often also because of network issues (and assuming non-encrypted content).

Waw, great job guys! Looks really smooth; Its nice that the foundation optimizes instead of bringing “hardware upgrades”. At least now I get the feeling you can pull out everything out of this computer;

I’m not sure but this will propably be very interesting for XMBC’s aswell ? or do they use alternative to X ?

Probably won’t affect XMBC a lot as this is focused more on a typical desktop set-up – they don’t use windows on a desktop as it’s a full-screen app. They might be able to use the same 2D APIs (DispManX) to accelerate certain things – or they might already do so.

DispManX is both the way to get stuff on screen (basically the framebuffer API) as well as the way to access the more exciting composition / blending / scaling / etc features we’re using here. Our first port of Weston to Pi used DispManX to set up the screen but composited using GL – this time we’re doing both the set-up and the composition using DispManX. Just to say that using DispManX doesn’t immediately imply using hardware-accelerated 2D composition like we’re doing here. Not saying they’re not – I have no idea. :)

It doesn’t directly help client-side rendering of window contents. That’s something work such as ARMv6 pixman optimisations has helped with. Work has been and is being done on scratch. Try a `sudo apt-get update && sudo apt-get install scratch` to make sure you’re running the latest version, there’s been great progress.

As teh_orph discovered after a good chunk of a year working on it, X can’t effectively be hardware-accelerated on the Pi due to the X app legacy method of pushing pixels around. There are historical reasons for this going back to the MIT Project Athena work in the early 1980s, when bitmapped graphics were only a layer or two from both the user and the hardware. The world is much different now, with GPUs many times more powerful than the CPUs on many systems, to the point where the CPU on the Pi is little more than a traffic cop between the Ethernet port and USB bus and the GPU (even the Pi GPU boots from the SD card and then starts the CPU). The key is to do what makes the most sense on each of the specialized hardware components, and drawing vectors (including typeface outlines), 2-D areas, and 3-D surfaces at any scale at any moment is what the GPU does for a living. The Pi doesn’t have or need a 3+ GHz CPU and gobs of RAM to be useful as the educational tool it was designed to be. The Nerdocracy keeps projecting what requires that kind of horsepower onto the poor little board that costs a tenth or much less than a state-of-the-art system. Heavy doses of both reality as well as imagination are in order to get the most out of the Pi.

Py-Py, now this and hints of much more to come , the Pi Foundation may be aimed at education, however the benefits you have also brought to the open source world are also fantastic. Big thank you from me for all your hard work.

Thank you to everyone working on this. One of the aspects of the Raspberry Pi project is that there continues to be a strong drive to make the computer system as a whole better: faster, more functional, easier to use. Improvements have been coming fast and furious in the year since I first received my Model B, and I’m very much looking forward to trying out a Wayland-based GUI as well.

A big congratulations to the foundation for working on this. I think this will make the pi a lot more usable and improve general use performance for applications since the CPU will be freed up from doing the lifting in X. I can’t wait to try it out. The Pi has had so much improvement on the software side which shows just how much things can be improved with optimized code when you have limited hardware. Keep up the good work.

How did you get it to run? I installed per Daniel Stone’s blog post and just ignored the request for a key. On trying to run weston, I got the error – environment variable XDG_RUNTIME_DIR is not set. Running weston -h produced a helpful looking list but it’s beyond me at this stage. (my Raspian & firmware is bang up to date). Any suggestions? Thx

This is great news. A few of us have followed the X acceleration thread and wondered if there was a better solution that was reachable. Looking forward to the next Raspbian update! Thanks and best regards, Will

So this little beauty fruit, has two hardware accelerators; a HVSand OpenGL ES hardware.

Can either of these be the target of a compiler for us mere mortals? I’m particularly interested in using haskell with llvm for a project to plot 0.5M floating point complex numbers frame-1, though I don’t need a large frame rate.

I would like to know more about this as well. If I install JOGL successfully, I will have a bunch of java functions that will work on the GPU right? No change to the operating system required, and “streaming” from the raspicam will be obvious?

In addition, I can do parallel math operations if I can map them into a representation of pixels and shader functions?

Hey, this is really great news! I’m using RPI as a digital signage player running a chrome browser. The animations like sliding, fading and others are very slow.
I really hope this impacts this kind of experience and could improve the abilities as a signage player!

I built a handheld unit from a Raspberry Pi, and I use Claws (or subsequently Sylpheed, if you prefer) to check my mail. Standards compliant web browsers will always be bulkier and slower than dedicated e-mail clients.

Typically, I can switch on my computer, have my mail checked (from a decent connection) and switch it back off in less than a minute. Two, tops.

If your e-mail service doesn’t allow this, then I totally understand, but if you have free POP3 and IMAP access, by all means, give it a shot.