GStreamer Conference 2013 – Haggis edition

So we are quickly approaching the time for GStreamer Conference 2013. This year we will be in Edinburgh, Scotland and the conference will be hosted at the Edinburgh International Conference Centre alongside the Embedded Linux Conference Europe and the Automotive Linux Summit.

The GStreamer Conference 2013 Schedule is now live and as you can see there are a lot of great talks this year too, ranging from OpenGL integration, embedded hardware, new codecs and more. As always the GStreamer Conference is the best place to be to discuss the challenges of multimedia.

The conference will be held on the 22nd and 23rd of October so I strongly recommend you get yourself registered. If you want to attend ELCE or the Autotmotive summit make sure to register for those too and extend your stay in Edinburgh to also cover the 24th and 25th of October.

Looking forward to seeing you all there.

And last but not least, a big thank you to this years sponsors of the GStreamer Conference, especially Platinum sponsor Collabora. Also a big thank you to sponsors Fluendo, Google and for the first time this year Cisco.

And as always a big thank you to Ubicast who as always will be recording and publishing the conference for us. Be sure to check out their recordings from earlier years to find out what the GStreamer Conference is about.

More movements around Wayland

Thought I post another update with some more news on what we are doing here at Red Hat in preparation for our continued push forward for Wayland on Fedora. Peter Hutterer posted his first draft of the Wayland protocol extension to handle Wacom tablets, you can find more details in his Google Plus post. This effort is also a good illustration of our approach to the Wayland switchover, it is not just about working on some high level bits to port them over to existing APIS or protocols provided by Kristian Høgsberg and the other core Wayland devs, but actively contributing to the whole stack where needed.

Giovani Campagna continued his great work on porting the needed GNOME stack over, with his patches to Clutter now being available in a release.

Our biggest challenge currently is with XWayland, due to some internal projects that had to get priority we have not had the amount of time we hoped to worked on it yet, but we hope to rally a bit in order to get it to a state in F20 where we can at least have our GDM Wayland session working.

I would also like to point out that I seen some headlines around the web where people are excited about the Wayland work happening in Fedora and around GNOME 3.10. And it is exciting as things are falling into place very fast these days for Wayland, but still I ask people to keep their cool a bit as we are branding it a tech preview in F20 for a reason. So for developers we hope that this tech preview will provide an easy to use harness for running Wayland and testing your applications against Wayland, but in no way is this tech preview going to be something that an end user would even want to run. So when I see Slashdot headlines like “GNOME 3.10 Is Now Properly Supported On Wayland” I get a little worried because to me such a headline implies that things are in a much more mature state than they actually are. Our expectation and hope is to have something that can be considered fully working and ready for end users in the Fedora 21 and GNOME 3.12 timeframe, and that is the releases in which I feel such headlines are likely to be warranted.

So yes, the Wayland stuff we are working is cool and I think we have some killer features planned to be deployed on top of it, but lets do this right and not jump the gun here.

Fedora Wayland update

So our team here at Red Hat have been working intensively with our counterparts at Intel to merge and stabilize the patches to enable Wayland support in GNOME and at the same time looking into what further improvements are needed in the stack. Enabling Wayland support means essentially turning the GNOME Shell into a Wayland compositor as we are not going to be using the sample compositor Weston. Porting to Wayland isn’t just about replacing X calls with Wayland calls, in many cases there is also functionality that was in X that will be done as a separate library for use with Wayland or settings that used to be handled by X that now needs to be stored elsewhere. The development work is starting to come together now and tarballs are being released with initial Wayland support or core modules such as Mutter.

The goal we are still pursuing is to have a tech preview ready for Fedora 20. So what do we mean with a tech preview? Well there will be a quite a few things missing or maybe not working as expected. What we hope to have ready is a system where you can have the option of a Wayland session available in GDM, so that instead of logging into your normal X based session you log into one running Wayland instead. Once in that session you should be able to launch and run some applications, but stability is likely to not be great and we don’t know how well XWayland will work by then, so you will also likely having limited mileage with applications that still rely on X. The goal for the tech preview is not to create something an end user is likely to find very useful, rather it is about lowering the barrier for developers and contributors to get involved and start preparing for the Wayland future.

But we do think that it will at least be in a state where developers can easily start playing with it and where the community can help us find issues and bugs, so that we can reach our goal of having a full featured and stable GNOME running on Wayland ready for Fedora 21.

As a sidenote, our top priority is to make sure that the transition from X to Wayland becomes something an end users doesn’t really need to care about. So the final switch to Wayland over X will only happen once we are as sure as we can be that our users will not be negatively affected by the change. So if we default to Wayland or X for Fedora 21 is still an open question, we hope to default to Wayland of course, but staying with X as the default for one more release is not considered unreasonable if it will help us ensure a smooth transition experience for us users. We have of course also not forgotten that many of our users use the binary graphics drivers so we are working on making sure we have an answer ready for that going forward.

You can find details on the status of the tech preview if you go to this website.