Re: [PATCH weston 3/3] compositor: don't map surfaces without a buffer

On Fri, 3 Feb 2017 09:27:18 -0600 Derek Foreman wrote: > On 03/02/17 09:10 AM, Emilio Pozuelo Monfort wrote: > > We were calling weston_surface::committed on surfaces with > > no buffer attached. Stop doing that, since surface::committed > > will map the surfaces and put

[PATCH weston] config-parser: Export weston_config_next_section

This symbol wasn’t exported from the weston binary, most likely due to an oversight in 6e2c12496bbef3cc913cfe9d5f0aeb4d8b23b368, and because internal modules can link against libshared.la directly it hasn’t been found ever since. This commit makes it possible for external modules to iterate over

Re: [PATCH weston] clients/weston-info: print unknown formats better

On Monday, 2017-02-20 15:47:57 +0200, Pekka Paalanen wrote: > From: Pekka Paalanen > > Don't just dump the raw 32-bit values, try to interpret it as a DRM > fourcc too. > > This prints properly the formats YUYV, NV12 and YU12 supported by > Weston. > >

Re: [PATCH weston 2/3] shot: add test for sub-surface with unmapped parent

On Fri, 3 Feb 2017 16:10:38 +0100 Emilio Pozuelo Monfort wrote: > This reproduces https://bugs.freedesktop.org/show_bug.cgi?id=94735. > > The test currently fails, so mark it as expected to fail. > > Signed-off-by: Emilio Pozuelo Monfort

Re: [PATCH weston 3/3] compositor: don't map surfaces without a buffer

On Fri, 3 Feb 2017 16:10:39 +0100 Emilio Pozuelo Monfort wrote: > We were calling weston_surface::committed on surfaces with > no buffer attached. Stop doing that, since surface::committed > will map the surfaces and put them in a visible layer. That may > not be a problem

Re: [PATCH weston] config-parser: Export weston_config_next_section

On Tue, 21 Feb 2017 11:58:20 + Emmanuel Gil Peyrot wrote: > This symbol wasn’t exported from the weston binary, most likely due to > an oversight in 6e2c12496bbef3cc913cfe9d5f0aeb4d8b23b368, and because > internal modules can link against libshared.la directly

Re: [PATCH weston] clients/simple-egl: add -d option

> Subject: [PATCH weston] clients/simple-egl: add -d option s/-d/delay/ in the commit title? On Monday, 2017-02-20 16:13:48 +0200, Pekka Paalanen wrote: > From: Eero Tamminen > > This emulates extra drawing work by usleep(). > > This is an enhancement to reproduce

Re: [PATCH weston 19/68] compositor-drm: Refcount drm_fb

On Fri, 9 Dec 2016 19:57:34 + Daniel Stone wrote: > Sometimes we need to duplicate an existing drm_fb, e.g. when > pageflipping to the same buffer to kickstart the repaint loop. To handle > situations like these, and simplify resource management for dumb and > cursor

Re: [PATCH weston 18/68] compositor-drm: Drop output from release_fb

On Fri, 9 Dec 2016 19:57:33 + Daniel Stone wrote: > We only need it for the GBM surface the FB was originally created > against; a mismatch here is very bad indeed, so no reason to pass it in > explictly every time rather than store it. > > Differential Revision:

Re: [PATCH weston 16/68] compositor-drm: Store format in drm_fb

On Fri, 9 Dec 2016 19:57:31 + Daniel Stone wrote: > This uses the new pixel-format helpers, so we can also replace depth/bpp > with these. > > Signed-off-by: Daniel Stone > > Differential Revision: https://phabricator.freedesktop.org/D1513 >

Re: [PATCH weston 17/68] compositor-drm: Refactor destroy drm_fb function

On Fri, 9 Dec 2016 19:57:32 + Daniel Stone wrote: > From: Tomohito Esaki > > The drm_fb destroy callback to mostly the same thing regardless of > whether the buffer is a dumb buffer or gbm buffer. This patch refactors > the common parts into a new

Re: [PATCH weston 15/68] compositor-drm: Add explicit type member to drm_fb

On Fri, 9 Dec 2016 19:57:30 + Daniel Stone wrote: > Rather than magically trying to infer what the buffer is and what we > should do with it when we go to destroy it, add an explicit type > instead. > > Differential Revision: https://phabricator.freedesktop.org/D1488

Re: [PATCH weston 1/2] screen-share: Avoid NULL dereference

On Thu, Feb 16, 2017 at 07:59:50PM +, Daniel Stone wrote: > Don't try to dereference the seat if it's NULL. > > Signed-off-by: Daniel Stone Yep, obviously correct. Reviewed-by: Bryce Harrington > --- > compositor/screen-share.c | 3 ++- > 1

Re: [PATCH weston 2/2] screen-share: Use wl_list_for_each_safe on destroy

On Thu, Feb 16, 2017 at 07:59:51PM +, Daniel Stone wrote: > Destroying the shared seat removes the link from so->seat_list. > > Signed-off-by: Daniel Stone Acked-by: Bryce Harrington > --- > compositor/screen-share.c | 4 ++-- > 1 file

Re: [PATCH weston] clients: Fix build without Cairo/GLES2

On Mon, Feb 20, 2017 at 03:46:55PM +, Emil Velikov wrote: > On 16 February 2017 at 21:52, Daniel Stone wrote: > > If we're building with EGL support generally, but without Cairo/GLESv2, > > building the clients fail, because window.c defines the EGL native > > types,

[ANNOUNCE] wayland 1.13.0

This is the official release of Wayland 1.13. There have been no changes since beta and RC1. In addition to a range of bug fixes, changes since wayland 1.12 have added some API for controlling the visibility of globals and numerous documentation and other improvements. Our next major release

[ANNOUNCE] weston 1.99.94

This is another release candidate for weston 2.0. A handful of fixes have come in since the first release candidate so we're putting out a second RC just to be safe. This includes a couple fixes to potential crashes in screen-share, decouples building with EGL from also requiring Cairo, and

Re: [PATCH weston] config-parser: Export weston_config_next_section

On Tue, Feb 21, 2017 at 02:35:14PM +0200, Pekka Paalanen wrote: > On Tue, 21 Feb 2017 11:58:20 + > Emmanuel Gil Peyrot wrote: > > > This symbol wasn’t exported from the weston binary, most likely due to > > an oversight in

Re: [PATCH wayland 1/4] wayland-util: do not export the wl_map_* API

Hi Daniel, all, On 21 November 2016 at 17:32, Daniel Stone wrote: > Hi Emil, > > On 30 August 2016 at 18:24, Emil Velikov wrote: >> From: Emil Velikov >> >> Use only internally and explicitly marked as such with commit

[PATCH wayland v2 3/4] wayland-util: build/ship as separate shared library

From: Emil Velikov Currently both of libwayland-{client,server} export the same util (amongst other) symbols. Although not crucial this is something which should be avoided where possible. As such let's move the library to a shared one and introduce a static one for

[PATCH wayland v2 0/4] wayland-util to all

Hi all, As a continuation of an earlier thread: While not crucial, it's recommended that different libraries do not provide the same [conflicting] global symbol(s). As such I've fleshed out libwayland-util.so. It is considered internal one to wayland, since users implicitly use the API (as

[PATCH wayland v2 2/4] wayland-util: split out private functionality to separate file

From: Emil Velikov With next commit we'll make wayland-util a shared library (for reasons mentioned in the commit). As such we need to make sure that the private symbols are somewhere that they can be used internally. Otherwise we'll end up with link errors. v2:

[PATCH wayland v2 1/4] wayland-util: do not export the wl_map_* API

From: Emil Velikov Used only internally and explicitly marked as such with commit cf04b0a18f2 ("Move private definitions and prototypes to new zwayland-private.h") Signed-off-by: Emil Velikov --- src/wayland-util.c | 18

[PATCH wayland v2 4/4] build: remove white space in -uninstalled.pc.in files

From: Emil Velikov v2: Rebase, address wayland-client-uninstalled Signed-off-by: Emil Velikov Reviewed-by: Derek Foreman (v1) --- src/wayland-client-uninstalled.pc.in | 2 +-