[ANNOUNCE] wayland 1.10.91
Bryce Harrington
bryce at osg.samsung.com
Thu May 12 20:29:30 UTC 2016
On Wed, May 11, 2016 at 05:32:37PM -0500, Yong Bakos wrote:
> On May 11, 2016, at 2:32 PM, Yong Bakos <junk at humanoriented.com> wrote:
> >
> > 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
> >> work.
> >>
> >> Following are what remains. Most of these I think should be deferred
> >> but am not 100% certain, so would appreciate hearing other people's
> >> thoughts:
> >
> > Hi Bryce,
> > 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.
> >
> > yong
>
> Actually, I did review #5 (v2 for text input protocol), but at the time
> I had to manually re-construct the reply as I was receiving mailing list
> digests at the time... so Patchwork didn't associate my response.
>
> https://lists.freedesktop.org/archives/wayland-devel/2016-April/027922.html
>
> The things I pointed out weren't fixed, but they were all writing corrections,
> which I can submit after a merge.
>
> yong
Thanks for reviewing it. The patch is against wayland-protocols, whose
release schedule isn't sync'd with the wayland/weston schedule, so
there's no impact if this patch needs more time.
Bryce
> >> 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
> >> 1.12
> >>
> >> 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
> >>> version.
> >>
> >> 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.
> >>>
> >>> Indeed.
> >>
> >> Bryce
> >>
> >>> Thanks,
> >>> pq
> >>>
> >>>
> >>>>> Changes:
> >>>>> --------
> >>>>>
> >>>>> 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
> >>>>> http://wayland.freedesktop.org/releases/wayland-1.10.91.tar.xz
> >>>>> 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
> >>>
> >>> iQIVAwUBVyx9QyNf5bQRqqqnAQjqyBAAkXl/EZB75UVlnhLI2rnSMRA8ealKifd2
> >>> 25CQ5n2YbvOoVlQd40hKyh5U35wycDikpMcvrPHrflu06HwHUePPRjfHpzC07lXS
> >>> vfm/KiteGGYD2O8NJqe6NAz4vD8nJ3IEDWWDoH36UJJaQi7l1EsPWFnFSSIFKuwH
> >>> otlizHZqfrVulkN095WnS+m0wKfiRy8z5gbroF3KGZNxsbFY2c5RNQQC6j/XqT8i
> >>> MUIaTUU9XP/5GAJBXEd8ta7km0QJCy9fRZh+K6UIz35vI15zxnnJ1vCbM2b+7VTS
> >>> mkJAQThagp+yzzXfIex1seM2Eb8ix/UUkviRAw3ESNrjUcnEKHAu7jMbjFBfE3K8
> >>> 666l1Gu/dwR9yyaqAncSH5mdHijfWnUHFhTWyTjprw6cs8IZoycTOl86ZYtJu/V0
> >>> eGX3OvFXMLGKT9/iypFWa4QKWEcRHVHF0qRfyUaJQLeDjy+ILXdajDF9Jg/ttDZN
> >>> xZYmZ6a73XQXeN+hnCOlajBNOlPlhwBrMK5Ft8Pg9iJbj1pbm6Joi9VXj7GVK1vf
> >>> Dx3QuCPqD21y/JmRbi7bYW41fAv+xGqNyznevVP84u1mSj5fiWDlD53XzhT21k/f
> >>> WUrDIOpKZ8RRf9TpOW4232YEX7NRdeIbCfFkwuoHMjXP8ce7osFOMD7lI/gYjB1D
> >>> faR2a/vuzWs=
> >>> =YYM+
> >>> -----END PGP SIGNATURE-----
> >>
> >> _______________________________________________
> >> wayland-devel mailing list
> >> wayland-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list