On Thu, 15 Feb 2018 15:30:55 +
Emil Velikov wrote:
> On 13 February 2018 at 17:46, Daniel Stone wrote:
> > Hi Emil,
> >
> > On 13 February 2018 at 16:37, Emil Velikov
> > wrote:
> >> The following two questions come to mind:
> >> - app bugs - using threads? ivi-shell-user-interface.c me
On Thu, Nov 30, 2017 at 09:23:38AM +0100, Quentin Glidic wrote:
> From: Quentin Glidic
>
> If libdir is an absolute path (which means it’s outside of prefix) we
> would wrongly add the prefix to it in the install script. Just pass the
> correct libdir from Meson directly thanks to join_paths() ma
On 2018-02-15 12:50 PM, Emil Velikov wrote:
From: Emil Velikov
private is a reserved keyworkd in C++. Thus to make things work, we
should use something else - wl_egl_window::driver_private.
Make sure to do so only for C++ contexts, or otherwise it will break the
API - leading to build failures
On February 15, 2018 6:55:14 PM UTC, Emil Velikov
wrote:
> From: Emil Velikov
>
> Based on a similar patch (in Mesa) by Eric Engestrom.
>
> Cc: Eric Engestrom
Reviewed-by: Eric Engestrom
> Signed-off-by: Emil Velikov
> ---
> egl/wayland-egl-symbols-check | 10 +-
> 1 file chang
From: Emil Velikov
... to get the user_data. Like everywhere else through weston.
Signed-off-by: Emil Velikov
---
Some ancient patch, that I had locally.
It should be fine to land as-is, although it brings an interesting
question - should one keep struct linux_dmabuf_buffer private or not?
-
From: Emil Velikov
Seems like I was overoptimistic with my earlier assumption, namely:
"... 17.3.x should be the last version that ships the library."
Mesa 18.0.0 and its wayland-egl is about to be released any time soon,
so bump the number since it must no be smaller. As soon as we get
a wayla
From: Emil Velikov
Based on a similar patch (in Mesa) by Eric Engestrom.
Cc: Eric Engestrom
Signed-off-by: Emil Velikov
---
egl/wayland-egl-symbols-check | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/egl/wayland-egl-symbols-check b/egl/wayland-egl-symbols-check
From: Emil Velikov
private is a reserved keyworkd in C++. Thus to make things work, we
should use something else - wl_egl_window::driver_private.
Make sure to do so only for C++ contexts, or otherwise it will break the
API - leading to build failures when used alongside existing Mesa.
Cc: Danie
From: Emil Velikov
The current test had a few fall-outs:
- it was checking only for T (.text) symbols
- did not consider symbol removal
Fix that by fetching all the symbols and doing a bidirectional check -
for added and removed symbols. Error out with informative message for
each case.
Signe
This reverts commit 9fa60983b5799be62b9d88a4059f4d0038d7c80d.
The commit preserves the ABI, although breaks the API. This is fine for
most cases - building up-to date components, or shipping binary-only
drivers.
Yet it breaks when using old, released, Mesa alongside new wayland-egl.
A simpler and
This reverts commit 85cb5ed64aa8246f4da93fc5b76dfc34096bf803.
It seems like we've misread the existing code - the DSO name can be
propagated via the build-system. The one available in the script was a
simple fall-back.
Cc: Daniel Stone
---
Makefile.am | 1 -
egl/wayland-egl-sy
On 13 February 2018 at 17:46, Daniel Stone wrote:
> Hi Emil,
>
> On 13 February 2018 at 16:37, Emil Velikov wrote:
>> The following two questions come to mind:
>> - app bugs - using threads? ivi-shell-user-interface.c mentions
>> pthread, but haven't looked closely
>
> Hm, I couldn't find any th
From: Pekka Paalanen
Nothing on the client side uses it since
9fe75537ad207c1496e6d9be41a8f5af4b876506 which was just before the 0.99
release.
Signed-off-by: Pekka Paalanen
---
src/wayland-client.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-cli
On Thu, 15 Feb 2018 13:07:09 +0200
Alexandros Frantzis wrote:
> Ensure the server can safely handle client requests for wl_seat resource
> that have become inert due to weston_seat object release and subsequent
> destruction.
>
> The clean-up involves, among other things, unsetting the destroyed
Ensure the server can safely handle client requests for wl_seat resource
that have become inert due to weston_seat object release and subsequent
destruction.
The clean-up involves, among other things, unsetting the destroyed
weston_seat object from the user data of wl_seat resources, and handling
On 2/14/18 2:05 PM, Alexandros Frantzis wrote:
Ensure the server can safely handle client requests for wl_seat resource
that have become inert due to weston_seat object release and subsequent
destruction.
The clean-up involves, among other things, unsetting the destroyed
weston_seat object from
16 matches
Mail list logo
