Wayland and Weston 1.2.0 released
| From: | Kristian Høgsberg <hoegsberg-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org> | |
| To: | wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW-AT-public.gmane.org | |
| Subject: | Wayland and Weston 1.2.0 released | |
| Date: | Sat, 13 Jul 2013 02:13:11 -0400 | |
| Message-ID: | <20130713061311.GC26113@tokamak.home> | |
| Archive‑link: | Article |
Hi all, We have a 1.2.0 release of Wayland and Weston: 14e2b4d80b01c5763cc10264e75f71f045f34594 wayland-1.2.0.tar.xz 6ef06ad06d0c32bff6bbd471a50a17bd7f92e0bc wayland 1.2.0 tag 23201d31e71768e5ec3de0d10fa6de988dd273c8 weston-1.2.0.tar.xz a684b5a3d59d5ff42c30e03fe75a857073fb3fd2 weston 1.2.0 tag with tarballs available from http://wayland.freedesktop.org/releases.html as usual. Between the release candidate (1.1.91) and 1.2.0, we (mostly Brian Lovin) managed to drum up a few bugs which we (mostly Rob Bradford) promptly fixed. We have a lot of changes since the last major release (1.1.0) three months ago. The notable features this time are: - Stable wayland-server API. When 1.0 was release we didn't proise a stable API for libwayland-server.so. This means that with every major Wayland release, compositor might break. When it was just weston, it wasn't a big deal, but as more external wayland compositors appear, we have to stop breaking this. Much of the input logic was split in an awkward way and has bee moved to weston. The remaining structs (mostly just wl_resource) have been made opaque. Finally, versioning didn't work correctly with the old API, so we had to replace a few functions. Much of this work was done by Jason Ekstrand. - Color management: Richard Hughes worked on color mangement for Wayland and implemented two schemes in Weston: a simple cms plugin that reads a profile from weston.ini and a more advanced plugin that integrates with colord. Here's a screenshot of how that in turn integrates with the GNOME control center: https://plus.google.com/107928060492923463788/posts/X62Vd... - The Wayland Input Method Framework from Jan Arne Petersen is feature complete, but we're keeping it in weston for now. We need a little more real world exposure and feedback before we promote this to official Wayland API. We have a sample on-screen keyboard in weston, and Maalit has also been ported to the framework. - Subsurface protocol from Pekka Paalanen. This extension lets us build up application windows from multiple Wayland surface, potentially combining surfaces with different color spaces or buffer types. - Output scaling (HiDPI) from Alex Larsson. Alex describes the feature best in this blog entry: http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-... It's worth noting that this is not an arbitrary scaling mechanism, it is for scaling an entire output by an integer factor. - Rasperry Pi backend and renderer from Collabora. There was a lot of coverage on this one: Pekkas post is the most technical, Daniels gives a good overview and then there's the Collaboras case stuy and a linux.com article among others. http://ppaalanen.blogspot.com/2013/05/weston-on-raspberry... http://fooishbar.org/tell-me-about/wayland-on-raspberry-pi/ http://www.collabora.com/services/case-studies/raspberrypi http://www.linux.com/news/embedded-mobile/mobile-linux/72... - Improved thread safety and relaxed thread-model assumptions in libwayland-client. One of the restrictions in the client side library was that we assume that the toolkit or application will provide a "main thread" which is responsible for reading events and distributing them to event queues for the other threads. We also assume that there will always only be one such thread. It turs out that this breaks in many cases, in particular, it clashes with the threading model of EGL. The client side event processing has been reworked to not make those assumptions. - Multi seat support from Rob Bradford. We can now configure how input devices gets assigned to wl_seats by setting udev properties on the devices. This lets us setup multiple seats in weston, similar to multi-pointer X, where each seat gets its own pointer and keyboard focus. Additionally, a pointer can be confined to a given output. - New example client that illustrates the "application compositor" idea. Some clients need to share buffers - a popular example is process separation in web browsers. One client wants to render to a surface, the other client wants to use the result as a texture. In wayland, this is achieved by having one client act as a compositor to the other, and nested is a minimal example of how this is done. - Make libxkbcommon support optional from Matt Roper. Some use cases don't need a full PC keyboard, for example a car dashboard or a set-top box panel has buttons but not a keyboard in the traditional sense. In these cases, we only need keycodes, and libxkbcommon is just dead weight. There's a lot of minor features and improved functionality as well and we have a lot of bugs fixes in this cycle too. Just from commit messages, I count at least 66793, 66798, 66802, 66795, 63360, 57637, 63796, 65913, 63510, 65726, 65933, 65986, 66173, 66198, 66531, 66530, 66529, 65961, 66167, 62910, 61675, 59983, 64873, 63360, 64506, 64874, 64689, 64691, 63812, 64183, and 64537 from bugs.freedesktop.org. Many more bugs have been fixed that never made it into bugzilla in the first place. Thanks to everybody who contributed: Alexander Larsson, Alex Wu, Ander Conselvan de Oliveira, Armin K, Chris Michael, Daiki Ueno, Daniel Stone, David Richards, Dima Ryazanov, Eduardo Lima (Etrunko), Emilio Pozuelo Monfort, Giulio Camuffo, Hardening, Jan Arne Petersen, Jason Ekstrand, Kristian H�gsberg, Krzesimir Nowak, Louis-Francis Ratt�-Boulianne, Mariusz Ceier, Matt Roper, MoD, Mun Gwan-gyeong, Nathan Reboud, Neil Roberts, Ossama Othman, Pekka Paalanen, Peng Wu, Peter Hutterer, Peter Maatman, Quentin Glidic, Richard Hughes, Rob Bradford, Samuel Iglesias Gonsalvez, Sinclair Yeh, Tiago Vignatti, U. Artie Eoff, Yanko Kaneti Kristian _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Posted Jul 16, 2013 0:06 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (3 responses)
Posted Jul 16, 2013 13:43 UTC (Tue)
by gerdesj (subscriber, #5446)
[Link] (2 responses)
Now all you need is a front end
Posted Jul 17, 2013 13:11 UTC (Wed)
by VITTUIX-MAN (guest, #82895)
[Link] (1 responses)
1) is it rootless
If not, can they be included with mean provided by RDP?
Posted Jul 17, 2013 16:57 UTC (Wed)
by Jonno (subscriber, #49613)
[Link]
I don't know about the current Weston server implementation, but the RDP protocol supports both, as does the reference server implementation (Remote Desktop Services; formerly known as Windows Terminal Server).
Posted Jul 17, 2013 19:38 UTC (Wed)
by rahvin (guest, #16953)
[Link]
Posted Jul 19, 2013 0:57 UTC (Fri)
by fedtroll (guest, #91489)
[Link] (1 responses)
Just 3 simple questions for your project:
1. Are you associated with the failed Gnome project or its developers?
Be on subject with your answers, or you will be censored by the Lwn.net editor.
Posted Jul 19, 2013 7:43 UTC (Fri)
by zenaan (guest, #3778)
[Link]
> 1. Are you associated with the failed Gnome project or its developers?
> 2. Are you associtaed with the freakish Ubuntu/Unity/Mir project?
> 3. Are you computer scientists or clueless idiots writing code?
Well, good luck then.
PS - don't worry about censorship for this one. I'll just let 'em slide for a week, hey? Don't tell anyone ...
Wayland and Weston 1.2.0 released
Wayland and Weston 1.2.0 released
Wayland and Weston 1.2.0 released
2) does it support persistent sessions?
Wayland and Weston 1.2.0 released
>1) is it rootless
>2) does it support persistent sessions?
>If not, can they be included with mean provided by RDP?
Wayland and Weston 1.2.0 released
- Improved thread safety and relaxed thread-model assumptions in
libwayland-client. One of the restrictions in the client side
library was that we assume that the toolkit or application will
provide a "main thread" which is responsible for reading events and
distributing them to event queues for the other threads. We also
assume that there will always only be one such thread. It turs out
that this breaks in many cases, in particular, it clashes with the
threading model of EGL. The client side event processing has been
reworked to not make those assumptions.
Maybe it's just me but it's nice to see them post in the release notes that they made a terrible assumption and have now changed course after realizing they made terrible assumptions. I think putting things like this in the release notes is important because it provides better publicity for something that may prevent someone else from making the same mistake.
Wayland and Weston 1.2.0 released
2. Are you associtaed with the freakish Ubuntu/Unity/Mir project?
3. Are you computer scientists or clueless idiots writing code?
Wayland and Weston 1.2.0 released
Absolutely. This really is just the GNOME project (you really need to work on your capitalizations by the way) core-core, but it was politically incorrect to call it GNOME. And Miguel didn't want Metacity's reputation to be tarnished, and Linus was disturbed at just calling it
/lib/systemd/gnome*.so
So Wayland it is :/
Looks like capitalizations are not your only challenge. It's associATed.
Actually we're not associATed with UbNiMir, but they're associated with us - they basically write the code for us. It's called OUTsourcing, you might have heard of that?
And BTW, it could be seen as inflammatory to call us freakish ... not sure on your intent here...
Definitely not computer scientists. We wouldn't have had to outsource the development otherwise. I really thought you would have picked up on that. There are public mailing lists y'know - they're available on this thing called the InterNET; you might have heard of it? Wikipedia has an article on i... oh...
