[ANNOUNCE] wayland 1.10.91
junk at humanoriented.com
Wed May 11 19:32:06 UTC 2016
On May 11, 2016, at 2:11 PM, Bryce Harrington <bryce at osg.samsung.com> wrote:
> On Fri, May 06, 2016 at 02:17:23PM +0300, Pekka Paalanen wrote:
>> On Wed, 4 May 2016 11:46:23 -0700
>> Bryce Harrington <bryce at osg.samsung.com> wrote:
>>> On Wed, May 04, 2016 at 12:55:16AM -0700, Bryce Harrington wrote:
>>>> Here's the alpha for the upcoming 1.11 release. I'll summarize the
>>>> major features for this release in the beta announcement, but see below
>>>> for the detailed listing.
>>>> The schedule going forward is:
>>>> √ 1.11-alpha on May 3rd. Major features done by this point.
> It looks like someone (pq?) has marked some patches we decided to leave
> for post-1.11 as deferred in patchwork. I've followed suit and moved
> other patchsets there which are new APIs or that sound like feature
> Following are what remains. Most of these I think should be deferred
> but am not 100% certain, so would appreciate hearing other people's
I have on my list to review #5 below (text input protocol), and I should
have that done today (May 11). Or I can submit patches after it's merged.
> 1. Detect keyboard capabilities, refactor seat capability [Derek]
> - Awaiting review by jadahl
> - Over a year old now, probably needs rebased too...
> 2. xdg_popup behavior of input devices [Carlos]
> - Protocol additions for xdg-shell, needs review by xdg devels
> - Been in the queue a long time, but no reviews to date
> - No idea about disposition for this
> 3. xwayland drag-and-drop window creation [Carlos]
> - Looks ok to be but xwayland isn't my area
> - Been in the queue a long time, but no reviews to date
> - From the commit description sounds WIP-ish and that there was
> planned some followup work, but not sure if that happened?
> 4. Pointer locking (3 patches) [Jonas]
> - Was planned to land this feature for 1.11
> - Reviewers requested changes, but I'm not spotting a v2 for this
> - At a minimum needs updated for trunk, since the protocol files are
> now in wayland-protocols
> - I'll mark it 'Changes Requested' and hope it will return for
> consideration for 1.12.
> 5. V2 for text input protocol [Jan Arne]
> - This is intended for wayland-protocols so not really pertinent to
> the release. But is on v6 and hasn't received further reviews,
> perhaps it's time to land it?
> 6. FreeRDP fixes (6 patches) [David]
> - Build fixes are suitable for landing now, so I consider at least
> the first 3 patches here good candidates for including in 1.11
> - No R-b's other than my own; I'd be more comfortable landing if we
> had another set of R-b's on this.
> 7. compositor-drm clone mode + fixes (8 patches) [Emmanuel]
> - The fixes look straightforward and probably ok to land
> - I haven't reviewed the clone mode feature, but offhand judging by
> the length of the patch it looks like post-1.11 stuff.
> 8. get_subsurface double-buffered protocol [pq]
> - Is getting strong reviews, but also requests for tests &tc.
> - There is debate on its thread as to whether to land vs. leave for
> 9. Don't set_fullscreen on already fullscreen surfaces [Emmanuel]
> - Short fix, might be worth including in 1.11
> - Needs another R-b or two, but may be an easy thing to land
> 10. compositor fixes (2 patches) [pq]
> 11. eventdemo fixes (3 patches) [pq]
> - These sound landable for 1.11 offhand, but I haven't reviewed.
> - Needs R-b's
> 12. ivi_layout_surface API
> - Straightforward patch, looks fine to me
> - Not sure about landing new API during feature freeze though
> - Needs R-b's
>>>> - 1.11-beta around May 17th.
>>>> - 1.11-rc1 around May 24th.
>>>> - 1.11.0 release around May 31st.
>>>> At this time consider Wayland in feature freeze mode. We'll continue to
>>>> land minor enhancements through beta, and focus on bug fixes thereafter.
>>> Do we need to up the version requirements for weston's libwayland client
>>> or server dependency, or the version of wayland-protocol?
>> Hi Bryce,
>> Wayland-protocol deps should all be dealt with as they happen. I
>> believe we have the policy to land changes in wayland-protocols first
>> and have a w-p release, and then land weston patches depending on them,
>> bumping the dependency on configure.ac at the same time. That's what
>> I've been doing anyway.
> Yeah I know that's the policy, but I figure I need to not blindly trust
> that and do a doublecheck.
>> Unfortunately, we cannot do the same with libwayland since it would add
>> considerable delay in landing such weston patches.
>>> In both cases, it looked to me that no, Weston doesn't depend on any of
>>> the recent changes. We currently depend on wayland-protocols 1.2, and
>>> the changes for 1.3 are primarily tablet protocol, support of which
>>> doesn't sound like landable for Weston at this point. Post 1.3 w-p
>>> changes of note are the presentation-time protocol, which I'm not
>>> certain of.
>> None of the presentation-time changes after 1.2 and 1.3 change any
>> semantics, so no bump needed for them.
> Thanks for confirming
>>> Weston currently depends on wayland-server 1.10 and wayland-client
>>> 1.5.91. I could just bump the server version just to be safe, but
>>> offhand I'm not recalling if we did introduce any changes this cycle
>>> that actually requires it? As to the client dependency, I've never been
>>> clear on when that should be bumped, or if what the implications on
>>> clients would be if we did; I'd love some advice/clarification on that
>>> for future reference if nothing else.
>> I looked through libwayland changes post-1.10 release, and the only ABI
>> change is the addition of the proxy wrappers, which is not used in
>> Weston. ABI additions are easy to spot by looking for changes to the
>> headers. It's unlikely to have other kind of changes, except perhaps
>> scanner.c generated code.
> Thanks for confirming that too.
>> To keep things simpler, I would suggest we keep the all of
>> libweston-server, -client, and -cursor dependencies at the same number
>> in Weston. I'm not sure you even can build things from Weston without
>> both -server and -client. If you use both, they surely are the same
> Great, I'll make those changes.
> What I'd like to do is move the version number requirement up to the top
> of the file next to the version number since for releases both are going
> to be changed at the same time.
>> The client dependency may have been forgotten, and the server
>> dependency will hide any issues it might have.
>> Of course, whenever anyone sends a Weston patch that needs something
>> new from libwayland, the commit message should say so. Maybe we could
>> add a XXX comment in configure.ac also, like my weston patches do for
>> wayland-protocols before there is a wayland-protocols release?
> Yes sounds good.
>>> Other than that, I've been assuming that if there are any other
>>> build-dependency changes, they'd have been patched directly. But it
>>> would be great at this point to do fresh builds/installs on whatever
>>> hardware variations are at hand just to doublecheck, and get patches in
>>> for fixes. I'll make a priority to review those.
>>>> Auke Booij (1):
>>>> protocol: add support for cross-interface enum attributes
>>>> Bill Spitzak (1):
>>>> doc: Use enum argument type to make links in protocol documentation
>>>> Bryce Harrington (3):
>>>> configure.ac: bump to version 1.10.90 for open development
>>>> doc: Note strong recommendation to use S-o-b in contributions
>>>> configure.ac: bump to version 1.10.91 for the alpha release
>>>> Derek Foreman (9):
>>>> resource-test: Use wl_seat instead of wl_display for testing
>>>> server: validate resource versions at creation time
>>>> build: Add an --enable-fatal-warnings configure option
>>>> build: build distcheck with --enable-fatal-warnings
>>>> Revert "build: build distcheck with --enable-fatal-warnings"
>>>> Revert "server: validate resource versions at creation time"
>>>> shm: Split pool reference counting into external and internal references
>>>> shm: Defer wl_shm_pool_resize if a pool has external references
>>>> shm: Log a warning if a shm buffer address is requested when it may be invalid
>>>> Emil Velikov (3):
>>>> scanner: move include directives before extern "C" wrapper
>>>> server: move include directives before extern "C" wrapper
>>>> utils: move include directives before extern "C" wrapper
>>>> Eric Engestrom (7):
>>>> protocol: fix spelling mistake
>>>> wayland-client: fix spelling mistake
>>>> client: fix typo
>>>> server: fix typo
>>>> util: fix typo
>>>> doc: fix typos
>>>> tests: fix typo
>>>> Jonas Ådahl (5):
>>>> client: Don't segfault when receiving error on destroyed object
>>>> client: Make proxy_destroy a static function
>>>> client: Introduce proxy wrappers
>>>> tests/queue-test: Add tests for proxy wrappers
>>>> client: Fix wl_display_roundtrip_queue() race condition
>>>> Marek Chalupa (2):
>>>> tests: add test for receiving an error on destroyed object
>>>> connection: remove redundant assignment
>>>> Pekka Paalanen (2):
>>>> build: fix ./configure --disable-dtd-validation
>>>> scanner: avoid executable stack
>>>> Peter Hutterer (2):
>>>> doc: generate doxygen html output from the scanner
>>>> doc: link between client and server doc and to the wayland book
>>>> Sergi Granell (1):
>>>> server: Fix shm_create_pool size fail path fd leak
>>>> Yong Bakos (7):
>>>> doc: Ignore html subdirectory.
>>>> ignore: Add *.dtd.embed
>>>> scanner: Fix spacing of @param
>>>> protocol: Correct grammar and spelling
>>>> doc: Hyphenate compound adjectives window-local, surface-local
>>>> protocol: Hyphenate compound adjective surface-local
>>>> protocol: Add summaries to event parameters
>>>> git tag: 1.10.91
>>>> MD5: 5a34f0b2dde3512bfd0c9b2a2af9034d wayland-1.10.91.tar.xz
>>>> SHA1: 32568737ab49a5ee3bafcd5b7d002094875e0feb wayland-1.10.91.tar.xz
>>>> SHA256: cb40de85488eb138e0f25b86b161c880c8115e07b7a89ec24c8cc99d02b4ca31 wayland-1.10.91.tar.xz
>>>> PGP: http://wayland.freedesktop.org/releases/wayland-1.10.91.tar.xz.sig
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>> -----END PGP SIGNATURE-----
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel