[PATCH wayland] scanner: Fix broken private-code generation

Missing a closing bracket. Signed-off-by: Derek Foreman --- src/scanner.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/scanner.c b/src/scanner.c index c93070c..1737911 100644 --- a/src/scanner.c +++ b/src/scanner.c @@ -1748,7 +1748,7 @@

Re: [PATCH wayland] scanner: Fix broken private-code generation

Pushed with Daniel's RB. Thanks, Derek On 2018-02-23 04:39 PM, Daniel Stone wrote: Rb me (sorry for mangled phone client formatting ...) On Fri, 23 Feb 2018, 10:25 pm Derek Foreman, > wrote: Missing a closing bracket.

Re: [PATCH wayland] scanner: Fix broken private-code generation

On 23 February 2018 at 22:24, Derek Foreman wrote: > Missing a closing bracket. > Eek, that's a embarasing. Reviewed-by: Emil Velikov We might want to tweak the existing infra to check that, bonus points if we also check the headers actually

Re: [PATCH v14 19/41] compositor-drm: Extract buffer->plane co-ord translation

Hi Pekka, On 23 January 2018 at 14:20, Pekka Paalanen wrote: > On Wed, 20 Dec 2017 12:26:36 + Daniel Stone wrote: >> + if (sx1 < 0) >> + sx1 = 0; >> + if (sy1 < 0) >> + sy1 = 0; >> + if (sx2 >

[PATCH wayland] wayland-egl: use correct `nm` path when cross-compiling

From: Emil Velikov Inspired by Heiko Becker and Eric's work in libdrm and Mesa respectively. Cc: Eric Engestrom Signed-off-by: Emil Velikov --- configure.ac | 1 +

Re: [PATCH wayland] wayland-egl: use correct `nm` path when cross-compiling

On Friday, 2018-02-23 17:31:53 +, Emil Velikov wrote: > From: Emil Velikov > > Inspired by Heiko Becker and Eric's work in libdrm and Mesa > respectively. > > Cc: Eric Engestrom > Signed-off-by: Emil Velikov

Re: [PATCH wayland] wayland-egl: use correct `nm` path when cross-compiling

Hi, On 23 February 2018 at 17:31, Emil Velikov wrote: > Inspired by Heiko Becker and Eric's work in libdrm and Mesa > respectively. Seems trivially correct and also worked here - pushed, thanks! Cheers, Daniel ___

Re: [RFC wayland] server: Add special case destroy signal emitter

On Thu, 22 Feb 2018 16:02:49 -0600 Derek Foreman wrote: > In the past much code (weston, efl/enlightenment, mutter) has > freed structures containing wl_listeners from destroy handlers > without first removing the listener from the signal. As the > destroy notifier only

Re: [PATCH wayland v2 4/4] tests: add code, public-code and private-code tests

On Thu, 22 Feb 2018 13:03:49 -0600 Derek Foreman wrote: > On 2018-02-22 05:55 AM, Pekka Paalanen wrote: > > On Thu, 22 Feb 2018 11:23:39 + > > Emil Velikov wrote: > > > >> From: Emil Velikov > >> > >> First

[PATCH 0/1] Add remove-without-free test

From: Markus Ongyerth In [1] it was pointed out, that the proposed patch breaks code, that does not remove their listener from a wl_signal list, but just free()s them. From libwayland's perspective, this has never been different. People just got lucky. wl_priv_signal_emit will

Re: [PATCH 3/3] rdp-backend.so: OpenGL hardware acceleration

Hi, Two patches that improve performance in my case. First, supporting ARGB gbm-format for the output allows a much better performance of the intelReadPixels function of the i965 driver of Mesa, which is my case: diff -rup a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c ---

Re: [PATCH 1/1] tests: Add free-without-remove test

On 2018/2月/23 08:53, Derek Foreman wrote: > On 2018-02-23 07:44 AM, Markus Ongyerth wrote: > > On 2018/2月/23 07:31, Derek Foreman wrote: > > > On 2018-02-23 03:52 AM, w...@ongy.net wrote: > > > > From: Markus Ongyerth > > > > > > > > This is related to the discussion earlier on

[PATCH 1/1] tests: Add free-without-remove test

From: Markus Ongyerth This is related to the discussion earlier on the mailing list and demonstrates a problem with current wl_priv_signal_emit and wl_listener that free themselves, but do not remove from the list. The testcase itself passes. And I'm not sure if that can be

Re: [RFC wayland] server: Add special case destroy signal emitter

Hi, I have a v2 RFC _emit_final based on your idea. It passes `make check` of libwayland and weston. It also passes the remove-without-free test I sent in another mail. --- (This patch isn't quite intended to be merged, but to get feedback on the approach) This adds a wl_priv_signal_emit_final

[PATCH 0/1] free-without-remove v2

From: Markus Ongyerth This is a v2 for the free-without-remove test, that actually fails the test and does not require the use of valgrind to make observe the problem. This is intended to fail at the moment, as the primary purpose is to show a problem with current days

[PATCH 1/1] tests: Add free-without-remove test

From: Markus Ongyerth This is related to the discussion earlier on the mailing list and demonstrates a problem with current wl_priv_signal_emit and wl_listener that free themselves, but do not remove from the list. This testcase asserts that the wl_list inside wl_listener is not

Re: [PATCH 1/1] tests: Add free-without-remove test

On 2018/2月/23 07:31, Derek Foreman wrote: > On 2018-02-23 03:52 AM, w...@ongy.net wrote: > > From: Markus Ongyerth > > > > This is related to the discussion earlier on the mailing list and > > demonstrates a problem with current wl_priv_signal_emit and wl_listener > > that free

Re: [RFC wayland] server: Add special case destroy signal emitter

On 2018-02-23 02:15 AM, Pekka Paalanen wrote: On Thu, 22 Feb 2018 16:02:49 -0600 Derek Foreman wrote: In the past much code (weston, efl/enlightenment, mutter) has freed structures containing wl_listeners from destroy handlers without first removing the listener from

Re: [PATCH 1/1] tests: Add free-without-remove test

On 2018-02-23 03:52 AM, w...@ongy.net wrote: From: Markus Ongyerth This is related to the discussion earlier on the mailing list and demonstrates a problem with current wl_priv_signal_emit and wl_listener that free themselves, but do not remove from the list. This testcase

Re: [PATCH 1/1] tests: Add free-without-remove test

On 2018-02-23 07:44 AM, Markus Ongyerth wrote: On 2018/2月/23 07:31, Derek Foreman wrote: On 2018-02-23 03:52 AM, w...@ongy.net wrote: From: Markus Ongyerth This is related to the discussion earlier on the mailing list and demonstrates a problem with current wl_priv_signal_emit