Wayland and Weston 1.5.0 is released
hoegsberg at gmail.com
Tue May 20 13:12:55 PDT 2014
I tagged 1.5.0 of Wayland and Weston and uploaded tar balls last
night. Tarballs available from
http://wayland.freedesktop.org/releases.html as usual. Magic SHA1
number for the tags and tar balls:
3ac62cd6b6012f40e37b1bd7fc1e8178585905ca wayland 1.5.0 tag
880193622024d7dc2b36421251d97b08da324570 weston 1.5.0 tag
In retrospect, this release was pretty quiet. We ended up not merging
a whole lot of features, but we did fix a lot of bugs and at one point
the bug count  hit 14, the lowest in a long time. I think that's a
pretty good feautre in itself.
• Use an internal event queue for wl_display events. This allows the
client library to dispatch delete_id and error events immediately,
even if the default queue is not dispatched.
• Wayland now uses non-recursive Makefiles.
• More work on xdg-shell, still not complete. We did add the long
missing minimize feature thought. We expect to finalize the
xdg-shell interface in time for 1.6, which will come out in time
for GNOME Shell 3.14 to use.
• The weston input stack was split out as a new library, libinput.
Weston can be configured to link to libinput for input but defaults
to the built in input code for now. As the libinput API
stabilizes, we'll remove the in-weston input code and make libinput
a hard requirement.
• Weston now uses the new Xwayland server. The Xwayland code was
refactored to be its own X server in the Xorg tree, similar to how
Xwin and Xquartz and Xnest work. A lot of the complexity and hacks
in the old Xorg based Xwayland was about fighting Xorg trying to be
a native display server, discovering input devices and driving the
outputs. The goal was to be able to reuse the 2D acceleration code
from the various Xorg DDX drivers. With glamor becoming a credible
acceleration architecture, we no longer need to jump through those
hoops and the new code base is much simpler and cleaner as a
result. Xwayland is upstream now and will be released with the
1.16 Xorg release.
• Animate window closing. A minor feature, but it validates the
mechanism for keeping surfaces around after the client that created
them goes away.
• Fullscreen shell. The fullscreen shell provides a mechanism for a
single client to provide a fullscreen surface, for kiosk-mode or
appliance type use cases.
• Weston now supports different color dephts on different outputs.
• Weston now uses non-recursive Makefiles.
As I mentioned in the RC2 notes, we have a few things lined up for a
1.5.1 release and we'll try to get that out in a few weeks. As for
1.6, we'll try to do four months from now, so something like this:
• Mid August: alpha release, all big features landed, only minor,
contained features after this.
• Early September: RC1, only bug fixes after this.
• One week later: RC2, only critical fixes.
• Mid September: Release 1.6 should be RC2 ideally.
Going forward, for master, I'd like to change the work flow a bit.
The biggest problem with how we work today is me being a bottleneck at
best or flat out dropping patches. So I'd like to open up commit
access to some of the key contributors. Either people that have their
corner of weston that they maintain (for example Pekka and the
Raspberry Pi backend or Hardening and the RDP backend) or contributors
who have been part of the project for a while and understands the code
base well - or both.
Being able to review *and* commit a patch will hopefully increase the
incentive to review and I won't need to be around all the time for
things to move forwards. I think everybody has enough common sense to
decide when something is a quick fix that can be committed right away
and when something needs wider discussion and concensus. For anything
that touches core weston and in particular, anything that adds
protocol, we still want to see patches, reviews and discussion the
list before committing.
Thanks to everybody who contributed to 1.5, let's start talking about
what we want to do for 1.6.
More information about the wayland-devel