From: Emil Velikov
The later can give false positives.
Signed-off-by: Emil Velikov
---
shared/platform.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/shared/platform.h b/shared/platform.h
index 98849f0..b8be6bf 100644
--- a/shared/platform.h
+++ b/shared
On 4 July 2016 at 15:32, Quentin Glidic wrote:
> On 04/07/2016 16:23, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> When managing headers there's normally two ways to handle them
>> - with or without the subfolder.
>>
>> Opting for the latte
On 4 July 2016 at 15:55, Pekka Paalanen wrote:
> On Mon, 4 Jul 2016 15:23:48 +0100
> Emil Velikov wrote:
>
>> Hi all,
>>
>> Here is a respin of the earlier series which changes how libweston is
>> named, and thus shipped. I believe all the logic/reasoning is
On 4 July 2016 at 15:35, Quentin Glidic wrote:
> On 04/07/2016 16:23, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> Signed-off-by: Emil Velikov
>> ---
>> configure.ac | 1 +
>> libweston/libweston.pc.in | 2 +-
>> 2 files
On 4 July 2016 at 15:45, Quentin Glidic wrote:
> On 04/07/2016 16:23, Emil Velikov wrote:
>>
>> Use the documented libweston-$major.so.0.$minor.$patch scheme.
>>
>> An (almost) identical one is used by GLIB, GTK{2,3}, QT5, json-glib and
>> others.
>>
On 4 July 2016 at 15:34, Emil Velikov wrote:
> diff --git a/shared/config-parser.c b/shared/config-parser.c
> index 2256469..d316958 100644
> --- a/shared/config-parser.c
> +++ b/shared/config-parser.c
> @@ -39,6 +39,7 @@
>
> #include
> #include "config-parser.
On 5 July 2016 at 13:18, Quentin Glidic wrote:
> On 04/07/2016 15:57, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> compositor/main.c depends on the header, while the dependency isn't
>> specified. Thus depending on the order of how things are
On 5 July 2016 at 15:46, Pekka Paalanen wrote:
> On Mon, 4 Jul 2016 15:23:51 +0100
> Emil Velikov wrote:
>
>> From: Emil Velikov
>>
>> Signed-off-by: Emil Velikov
>> ---
>> Pekka,
>>
>> There's a couple of things to 'break&#
On 7 July 2016 at 10:05, Pekka Paalanen wrote:
> On Wed, 6 Jul 2016 13:57:48 +0100
> Emil Velikov wrote:
>
>> On 5 July 2016 at 15:46, Pekka Paalanen wrote:
>> > On Mon, 4 Jul 2016 15:23:51 +0100
>> > Emil Velikov wrote:
>> >
>> >> From:
On 7 July 2016 at 10:20, Pekka Paalanen wrote:
> On Mon, 4 Jul 2016 16:02:23 +0100
> Emil Velikov wrote:
>
>> On 4 July 2016 at 15:32, Quentin Glidic
>> wrote:
>> > On 04/07/2016 16:23, Emil Velikov wrote:
>> >>
>> >> From: Emil Velikov
On 7 July 2016 at 10:46, Pekka Paalanen wrote:
> On Mon, 4 Jul 2016 16:25:54 +0100
> Emil Velikov wrote:
>
>> On 4 July 2016 at 15:35, Quentin Glidic
>> wrote:
>> > On 04/07/2016 16:23, Emil Velikov wrote:
>> >>
>> >> From:
Hi all,
Jumping the gun a bit, hope you'll forgive me :-)
On 8 July 2016 at 09:17, Quentin Glidic wrote:
> On 18/05/2016 14:55, Andrew Kosteltsev wrote:
>> Then the user can make use this cross-wayland-scanner in his SDK, for
>> example, like follow:
>>
>> $ ../MesaLib-10.3.4/configure
>> WAILA
On 7 July 2016 at 19:18, Quentin Glidic wrote:
> On 07/07/2016 18:28, Emil Velikov wrote:
>>
>> On 7 July 2016 at 10:20, Pekka Paalanen wrote:
>>>
>>> [snip]
>>> Therefore a NAK from me too.
>>>
>> As you guys wish. In that case can we
On 7 July 2016 at 19:08, Quentin Glidic wrote:
> On 07/07/2016 18:11, Emil Velikov wrote:
>>
>> On 7 July 2016 at 10:05, Pekka Paalanen wrote:
>>>
>>>
>>> [snip]
>
>>>
>>> Now that you mentioned the semantics could be of upper or low
On 8 July 2016 at 12:00, Quentin Glidic wrote:
> On 08/07/2016 12:52, Emil Velikov wrote:
>>
>> On 7 July 2016 at 19:08, Quentin Glidic
>> wrote:
>>>
>>> On 07/07/2016 18:11, Emil Velikov wrote:
>>>>
>>>>
>>>> On
On 10 July 2016 at 11:11, Jan Engelhardt wrote:
>
> On Saturday 2016-07-09 18:24, Pekka Paalanen wrote:
>>>
>>> First, what kind of parallel installability is sought?
>>>
>>> * just runtime
>>> * parallel development environment (like what e.g. libabw,
>>> librevenge.. do)
>>
>>everything that i
On 10 July 2016 at 13:23, Jan Engelhardt wrote:
>
> On Sunday 2016-07-10 12:46, Emil Velikov wrote:
>>> PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
>>> ...repeat the fun...
>>> ])]
>>>
>>Yes, it's one line of fun f
On 9 July 2016 at 16:32, Pekka Paalanen wrote:
> On Thu, 7 Jul 2016 20:08:40 +0200
> Quentin Glidic wrote:
>
>> On 07/07/2016 18:11, Emil Velikov wrote:
>> > On 7 July 2016 at 10:05, Pekka Paalanen wrote:
>> >>
>> >> [snip]
>> >>
>
On 9 July 2016 at 17:26, Pekka Paalanen wrote:
> On Thu, 7 Jul 2016 17:45:24 +0100
> Emil Velikov wrote:
>
>> On 7 July 2016 at 10:46, Pekka Paalanen wrote:
>> > On Mon, 4 Jul 2016 16:25:54 +0100
>> > Emil Velikov wrote:
>> >
>> >>
On 11 July 2016 at 17:58, Jan Engelhardt wrote:
>
> On Monday 2016-07-11 16:44, Emil Velikov wrote:
>>>>http://ometer.com/parallel.html. I would strongly recommend giving it
>>>>a look.
>>>
>>> I read it now, and I do not buy it - at least not for 2
On 4 July 2016 at 15:00, Quentin Glidic wrote:
> From: Quentin Glidic
>
> Signed-off-by: Quentin Glidic
> ---
> libweston/gl-renderer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
> index 28c0b50..73b6ccc 100644
> --
never be read (get_unicode) when it's invalid, since
::state will equal to utf8state_reject (as set in utf8_next_char).
Seems like the compiler/optimiser cannot see that far, thus throws a
warning message.
With anything vaguely like the above in the commit message, the patch is
Reviewed-by: E
On 13 July 2016 at 15:53, Jan Engelhardt wrote:
>
> On Wednesday 2016-07-13 13:54, Pekka Paalanen wrote:
>>
>>I think Quentin raised a good point, though. In source-based
>>distros, well, in Gentoo at least which I use almost exclusively,
>>there are no separate -devel packages.
>
> A package is,
On 4 July 2016 at 15:27, Emil Velikov wrote:
> It seems that a handful of extensions were missing fallback definitions
> and/or were handled sub optimally.
>
> So this series folds most (the
> remainder coming in another series) of the typedef/defines in
> weston-egl-ext.h an
On 4 July 2016 at 15:34, Emil Velikov wrote:
> Hi all,
>
> This series depends on "EGL/GL definitions cleanup" and does a couple of
> things:
> - makes sure that we consistently use check_extension over strstr for
> extension checking, as the latter might trigg
On 5 July 2016 at 13:16, Quentin Glidic wrote:
> On 04/07/2016 15:57, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> Otherwise we'll pick up the stale (in-tree) generated source(s) over the
>> fresh (out-of-tree) ones.
>>
>> Signed-off-by
On 6 July 2016 at 12:52, Emil Velikov wrote:
> On 5 July 2016 at 13:18, Quentin Glidic
> wrote:
>> On 04/07/2016 15:57, Emil Velikov wrote:
>>>
>>> From: Emil Velikov
>>>
>>> compositor/main.c depends on the header, while the dependency isn
Hi all,
Here is hopefully the final take on the series of the topic in question.
The changes:
- Reworked the README, elaborating on why and how to use
REQUIRE_LIBWESTON_API_VERSION (what to write in your configure), how to
avoid forward compat and misc working improvements.
- There is a com
From: Emil Velikov
Signed-off-by: Emil Velikov
---
Pekka, considering the noticable rework I've dropped your r-b.
v2:
- s/QT/Qt/;s/GTK/GDK/
- s/LIBWESTON_API_VERSION/REQUIRE_LIBWESTON_API_VERSION/
- Provide configure.ac example and mention how to override the fwd
compat checking.
-
From: Emil Velikov
Use the documented libweston-$major.so.0.$minor.$patch scheme.
An (almost) identical one is used by GLIB, GDK{2,3}, QT5, json-glib and
others.
Signed-off-by: Emil Velikov
---
I kind of agree with Quentin that the revision log isn't too helpful
in the commit message in
From: Emil Velikov
Common practise it to provide the includes directly into Cflags, hence
the variable is not needed and we can remove it.
Signed-off-by: Emil Velikov
---
Replaces the "libweston: do not add libweston-$version to the Cflags"
patch.
---
libweston/libweston.pc.in | 3 +
From: Emil Velikov
The linker processes those in the order that they are given. Thus
as-it we can get unresolved symbols.
Signed-off-by: Emil Velikov
---
Some places in weston already follow this approach, and although I've
not had a problem it'll be nice to fix things.
Noticed whi
On 2 August 2016 at 12:03, Pekka Paalanen wrote:
> On Fri, 22 Jul 2016 14:52:42 +0100
> Emil Velikov wrote:
>
>> From: Emil Velikov
>>
>> The linker processes those in the order that they are given. Thus
>> as-it we can get unresolved symbols.
>>
>>
s fine with me, so the series is
Reviewed-by: Emil Velikov
Thanks
Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On 12 August 2016 at 08:47, Pekka Paalanen wrote:
> On Mon, 4 Jul 2016 15:27:14 +0100
> Emil Velikov wrote:
>
>> From: Emil Velikov
>>
>> Those the function declarations alongside the EGL_EGLEXT_PROTOTYPES
>> guards. Although those are copy/paste sections fro
From: Emil Velikov
Since one is (about to be) using libweston, they should check for it as
opposed to libwayland.
Silly copy/paste mistake that would have caused a lot of confusion.
Signed-off-by: Emil Velikov
---
Seems like we all missed that one, oops :-\
---
README | 2 +-
1 file changed
From: Emil Velikov
Provides some ease wrt constructing the required version.
Cc: Quentin Glidic
Suggested-by: Quentin Glidic
Signed-off-by: Emil Velikov
---
I've swapped ENCODE with API since it makes comparisons a lot better and
it implies a full version including PATCH/MICRO. Yes, GT
IES install-moduleLTLIBRARIES:
> install-libLTLIBRARIES
> +
Or we can convince people into using slibtool - it doesn't relink ;-)
Written in C, a bit faster although it's missing --uninstall atm (iirc).
On the patch in question - checked with the Makefile.in and things look great.
Re
On 16 August 2016 at 09:49, Quentin Glidic
wrote:
> On 16/08/2016 10:26, Pekka Paalanen wrote:
>>
>> On Mon, 15 Aug 2016 16:51:32 +0100
>> Emil Velikov wrote:
>>
>>> On 15 August 2016 at 16:29, Quentin Glidic
>>> wrote:
>>>>
>>&
On 15 August 2016 at 17:16, Quentin Glidic
wrote:
> On 15/08/2016 17:31, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> Provides some ease wrt constructing the required version.
>>
>> Cc: Quentin Glidic
>> Suggested-by: Quentin Glidic
>
Hi all,
On 29 August 2016 at 20:23, Derek Foreman wrote:
> Hi Bryce,
>
> On 26/08/16 08:11 PM, Bryce Harrington wrote:
>> On Fri, Aug 26, 2016 at 06:06:43PM -0700, Bryce Harrington wrote:
>>> It is confusing terminology to call this 'uninstalled'; sounds like this
>>> might remove something from
On 30 August 2016 at 15:27, Derek Foreman wrote:
> On 30/08/16 06:09 AM, Emil Velikov wrote:
>> Hi all,
>>
>> On 29 August 2016 at 20:23, Derek Foreman wrote:
>>> Hi Bryce,
>>>
>>> On 26/08/16 08:11 PM, Bryce Harrington wrote:
>>>> On F
From: Emil Velikov
Use 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
---
I could not find any users of the API and I doubt there was ever one. If
people feel ner
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.
Signed-off-by: Em
Hi all,
For a while I've noticed that on mesa side we have few providers of the
wl_drm_interface symbol and literally all our 'wayland binaries' are
linked against both the client and server wayland libs.
After having a look, it seems that:
- the server exposes the interface symbols for 'inher
From: Emil Velikov
Signed-off-by: Emil Velikov
---
Afaict the gratuitous space isn't a requirement, then again I've just
read up on -uninstalled .pc files.
---
src/wayland-scanner-uninstalled.pc.in | 2 +-
src/wayland-server-uninstalled.pc.in | 2 +-
2 files changed, 2 insert
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 the purposes of wa
On 30 August 2016 at 19:56, Derek Foreman wrote:
> From: "Reynaldo H. Verdejo Pinochet"
>
> The wl_uninstalled script provides a shell environment to
> build and use an uninstalled Wayland/Weston setup.
>
> For example, this script and a fresh checkout of Wayland,
> libinput, wayland-protocols an
On 31 August 2016 at 19:10, Derek Foreman wrote:
> Thanks for taking a look!
>
> On 31/08/16 04:22 AM, Emil Velikov wrote:
>> On 30 August 2016 at 19:56, Derek Foreman wrote:
>>> From: "Reynaldo H. Verdejo Pinochet"
>>>
>>> The wl_uninstalled
On 1 September 2016 at 10:13, Pekka Paalanen wrote:
> On Wed, 31 Aug 2016 23:17:09 +0100
> Emil Velikov wrote:
>
>> On 31 August 2016 at 19:10, Derek Foreman wrote:
>> > Thanks for taking a look!
>> >
>> > On 31/08/16 04:22 AM, Emil Velikov wrote:
>&
On 1 September 2016 at 15:12, Emmanuel Gil Peyrot
wrote:
> This prevents a segfault when running on Mesa master, due to the GLES2
> symbols not being declared with the correct prototype (or at all).
>
> Signed-off-by: Emmanuel Gil Peyrot
> ---
> libweston/gl-renderer.c | 1 +
> 1 file changed, 1
On 1 September 2016 at 17:49, Derek Foreman wrote:
> On 01/09/16 04:13 AM, Pekka Paalanen wrote:
>> On Wed, 31 Aug 2016 23:17:09 +0100
>> Emil Velikov wrote:
>>
>>> On 31 August 2016 at 19:10, Derek Foreman wrote:
>>>> Thanks for taking a look!
>>
On 12 September 2016 at 12:11, Daniel Stone wrote:
> Hi Armin,
>
> On 10 September 2016 at 21:23, Armin Krezović
> wrote:
>> It appears that in current Mesa git master, GLESv2 function
>> prototypes are hidden.
>>
>> Per Emil's suggestion on [1], use eglGetProcAdddress to get
>> the functions an
On 12 September 2016 at 13:04, Emil Velikov wrote:
> On 12 September 2016 at 12:11, Daniel Stone wrote:
>> Hi Armin,
>>
>> On 10 September 2016 at 21:23, Armin Krezović
>> wrote:
>>> It appears that in current Mesa git master, GLESv2 function
>>&
On 12 September 2016 at 13:15, Pekka Paalanen wrote:
> On Mon, 12 Sep 2016 13:56:30 +0200
> Armin Krezović wrote:
>
>> Khronos has decided to hide the GLESv2 function prototypes
>> in GLESv2 headers and the code has landed in latest mesa git.
>>
>> Without this change, weston is unusable when bui
Hi all,
On 30 August 2016 at 18:24, Emil Velikov wrote:
> Hi all,
>
> For a while I've noticed that on mesa side we have few providers of the
> wl_drm_interface symbol and literally all our 'wayland binaries' are
> linked against both the client and server wayland
Hi Pekka,
Huge thanks for the input.
On 14 September 2016 at 14:35, Pekka Paalanen wrote:
> On Tue, 30 Aug 2016 18:24:18 +0100
> Emil Velikov wrote:
>
>> Hi all,
>>
>> For a while I've noticed that on mesa side we have few providers of the
>> wl_drm_
On 15 September 2016 at 11:47, Pekka Paalanen wrote:
> On Wed, 14 Sep 2016 16:57:17 +0100
> Emil Velikov wrote:
>
>> Hi Pekka,
>>
>> Huge thanks for the input.
>>
>> On 14 September 2016 at 14:35, Pekka Paalanen wrote:
>> > On Tue, 30
Hi Pekka,
Thanks again for keeping up.
On 16 September 2016 at 10:46, Pekka Paalanen wrote:
> Hi,
>
> there seems to be two different issues discussed here.
>
You cought me, yes there are.
> 1) libwayland-client and libwayland-server export the same interface
> symbols each, and cannot stop exp
On 15 September 2016 at 23:22, Joe Konno wrote:
> From: Joe Konno
>
> In a cross-compilation environment with packages depending on
> wayland-scanner, ensure the path to wayland-scanner is correct. Without
> this patch, the path will _not_ point to the target environment but to
> the host's, pote
On 19 September 2016 at 07:08, Daniel Stone wrote:
> Hi,
> I do think this is best discussed in-person later in the week, but one
> quick note ...
>
> On 16 September 2016 at 14:47, Emil Velikov wrote:
>> On 16 September 2016 at 10:46, Pekka Paalanen wrote:
>>>
On 28 September 2016 at 20:54, Armin Krezović wrote:
> On 27.09.2016 15:18, Emmanuel Gil Peyrot wrote:
>> On Tue, Sep 27, 2016 at 12:29:51PM +0200, Armin Krezović wrote:
>>> This patch makes use of recently implemented
>>> EGL_KHR_no_config_context extension in Mesa,
>>> which superseeds EGL_MESA_
Hi Bryce,
On 12 October 2016 at 00:33, Bryce Harrington wrote:
> Except for weston-info, client source files are not prefixed "weston-".
>
> Signed-off-by: Bryce Harrington
> ---
> Makefile.am| 2 +-
> clients/simple-im.c| 524
> +++
Functionally identical to the EXT version of the extension.
Signed-off-by: Emil Velikov
---
clients/simple-egl.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 9d401f9..8c923f8 100644
--- a
Hi all,
Khronos has promoted the EXT extension to KHR one and I was wondering if
weston won't be interested in handling systems that support the latter
and yet lack the former.
Admittedly I've not seen (or looked for) any such beasts thus the RFC
(also the oddly named foo - suggestions welcome
Extension is identical to the EXT one, yet we need to check for the KHR
abbreviated extension name + entry-point.
Signed-off-by: Emil Velikov
---
libweston/gl-renderer.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libweston/gl-renderer.c b
Hi Pekka,
It's great to see some tests for the scanner. There's a few thoughts I
may have mentioned before - please don't read too much into them.
On 10 November 2016 at 09:57, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Add tests that ensure that wayland-scanner output for a given input d
On 14 November 2016 at 09:28, Pekka Paalanen wrote:
> On Fri, 11 Nov 2016 20:31:54 +
> Emil Velikov wrote:
>
>> Hi Pekka,
>>
>> It's great to see some tests for the scanner. There's a few thoughts I
>> may have mentioned before - please don'
On 4 November 2016 at 11:32, Eric Engestrom wrote:
> On Thursday, 2016-11-03 22:38:19 +0000, Emil Velikov wrote:
>> Extension is identical to the EXT one, yet we need to check for the KHR
>> abbreviated extension name + entry-point.
>>
>> Signed-off-by: Emil Velik
From: Emil Velikov
Extension is identical to the EXT one, yet we need to check for the KHR
abbreviated extension name + entry-point.
v2: s/foo/swap_damage_ext_to_entrypoint/ (Eric, Daniel)
Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom (v1)
---
libweston/gl-renderer.c | 32
From: Emil Velikov
Functionally identical to the EXT version of the extension.
v2: s/foo/swap_damage_ext_to_entrypoint/ (Eric, Daniel)
Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom (v1)
---
clients/simple-egl.c | 33 +++--
1 file changed, 27 insertions
Hi all,
Here is a bunch of trivial fixes which add the odd eglDestroySurface,
eglTerminate, $other call.
None of them are particularly exciting, just something I came across
while fixing/testing some mesa bugs a few months ago.
I'd imagine that I've missed the odd piece, but they seem like a g
From: Emil Velikov
Introduce the weston_platform_destroy_egl_surface() wrapper to
complement the weston_platform_create_egl_surface() one.
We'll use the former with the next patches trhoughout weston to
consistently destroy the surface as needed.
Signed-off-by: Emil Velikov
---
s
From: Emil Velikov
... over a direct eglDestroySurface call. Provides symmetry in the
create/destroy paths.
Signed-off-by: Emil Velikov
---
clients/subsurfaces.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/clients/subsurfaces.c b/clients/subsurfaces.c
index 45801a8
From: Emil Velikov
Signed-off-by: Emil Velikov
---
clients/window.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clients/window.c b/clients/window.c
index 84d585e..dabd0b0 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -645,7 +645,7 @@ egl_window_surface_destroy
From: Emil Velikov
... over a direct eglDestroySurface call. Provides symmetry in the
create/destroy paths.
Signed-off-by: Emil Velikov
---
clients/simple-egl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 9d401f9
From: Emil Velikov
Might be a bit of an overkill, but still. One should cleanup after
themselves.
Signed-off-by: Emil Velikov
---
tests/buffer-count-test.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/tests/buffer-count-test.c b/tests/buffer-count
From: Emil Velikov
Signed-off-by: Emil Velikov
---
clients/nested-client.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/clients/nested-client.c b/clients/nested-client.c
index 9918da1..0ac6d8f 100644
--- a/clients/nested-client.c
+++ b/clients/nested-client.c
@@ -333,6 +333,8
From: Emil Velikov
Do a minimalistic teardown at program exist.
Signed-off-by: Emil Velikov
---
clients/nested-client.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/clients/nested-client.c b/clients/nested-client.c
index 0ac6d8f..5027075 100644
--- a/clients/nested-client.c
+++ b
From: Emil Velikov
Signed-off-by: Emil Velikov
---
libweston/gl-renderer.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 09256b4..099d099 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
From: Emil Velikov
Functionally identical to the EXT version of the extension.
v2: s/foo/swap_damage_ext_to_entrypoint/ (Eric, Daniel)
v3: do the above sed for real (Frank)
Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom (v1)
---
Thanks Frank !
---
clients/simple-egl.c | 33
On 15 November 2016 at 05:11, Peter Hutterer wrote:
> The latter is for commandline overrides.
>
> Signed-off-by: Peter Hutterer
Reviewed-by: Emil Velikov
> ---
> Ooops, didn't notice until Semaphore CI failed (it uses the environment
> itself)
>
We have another CI
From: Emil Velikov
v2: Use correct (destroy) API (Dan)
Signed-off-by: Emil Velikov
---
clients/window.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clients/window.c b/clients/window.c
index 84d585e..9c2fc68 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -645,7
Hi Dan,
My voice doesn't carry much weight on wayland-devel still I think it
will bring some nice food for thought.
As you know better than me the actual speed increase isn't in using
Meson, it's due to ninja.
If one is to use (write?) make backend for Meson the results wouldn't
be that differen
On 29 November 2016 at 20:50, Daniel Stone wrote:
> Hey Emil,
>
> On 29 November 2016 at 20:41, Emil Velikov wrote:
>> My voice doesn't carry much weight on wayland-devel still I think it
>> will bring some nice food for thought.
>>
>> As you know better t
On 1 December 2016 at 11:46, Daniel Stone wrote:
> Hi,
>
> On 30 November 2016 at 10:00, Daniel Stone wrote:
>> On 30 November 2016 at 01:02, Emil Velikov wrote:
>>> NB: Everything but the Install test, varies ±0.2s across 3 consecutive
>>> runs, thus it'
On 2 December 2016 at 14:55, Pekka Paalanen wrote:
> On Fri, 8 Jul 2016 11:29:16 +0100
> Emil Velikov wrote:
>
>> Hi all,
>>
>> Jumping the gun a bit, hope you'll forgive me :-)
>>
>> On 8 July 2016 at 09:17, Quentin Glidic
>> wrote:
On 1 December 2016 at 15:24, Daniel Stone wrote:
> Hey Emil,
>
> On 1 December 2016 at 14:11, Emil Velikov wrote:
>> On 1 December 2016 at 11:46, Daniel Stone wrote:
>>> On Intel, the configure stage (autogen / meson -Dfoo) is 14-15x
>>> faster. A complete b
On 2 December 2016 at 18:28, Daniel Stone wrote:
> Hey,
>
> On 2 December 2016 at 18:25, Emil Velikov wrote:
>> On 1 December 2016 at 15:24, Daniel Stone wrote:
>>> On 1 December 2016 at 14:11, Emil Velikov wrote:
>>>> This does not mitigate the fact th
Yes I fully agree that things are not perfect atm, and we want to work
towards improving things.
I'll see to "polishing" the scanner as early as possible.
Thanks
Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freede
Hi Dima,
Your patch reminded me a few trivial fixes/cleanups.
In case you/others feel like sorting out some low hanging fruit ;-)
- wayland: bring WESTON_SEARCH_LIBS check for dlopen (libdl) and
clock_gettime (librt).
- weston: replace WESTON_SEARCH_LIBS([JPEG] ...) with
PKG_CHECK_MODULES(JPEG,
fall back to checking via AC_PATH_PROG.
XXX: Should we just drop the AC_PATH_PROG check altogether ?
Signed-off-by: Emil Velikov
---
configure.ac | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1db9f79..ee08cfc 100644
--- a
On 13 February 2015 at 15:24, Daniel Stone wrote:
> Hi,
>
> On 10 February 2015 at 14:42, Emil Velikov wrote:
>> -AC_PATH_PROG([wayland_scanner], [wayland-scanner])
>> +PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner],
>> + wayland-scanner=`$PKG_CONFIG
On 13 February 2015 at 18:58, Bill Spitzak wrote:
>
>
> On 02/10/2015 06:42 AM, Emil Velikov wrote:
>>
>> Currently we use the wayland-scanner executable as found with
>> AC_PATH_PROG, and after that check the presence of wayland-scanner.pc
>>
>> Even if th
On 16 February 2015 at 13:04, Andrew Oakley wrote:
> On 10/02/15 14:42, Emil Velikov wrote:
>> Currently we use the wayland-scanner executable as found with
>> AC_PATH_PROG, and after that check the presence of wayland-scanner.pc
>>
>> Even if the latter is pointing to
Spitzak
Cc: Daniel Stone
Signed-off-by: Emil Velikov
---
configure.ac | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1db9f79..b44675f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -503,11 +503,10 @@ AM_CONDITIONAL(HAVE_LCMS, [test &q
Hi Bryce
On 20 February 2015 at 23:26, Bryce Harrington wrote:
> On Tue, Feb 17, 2015 at 03:13:32PM +0000, Emil Velikov wrote:
>> Currently we use the wayland-scanner executable as found with
>> AC_PATH_PROG, and then check the presence of wayland-scanner.pc
>>
>> Cur
On 23 February 2015 at 14:10, wrote:
> On 2015-02-17 16:13, Emil Velikov wrote:
>>
>> Currently we use the wayland-scanner executable as found with
>> AC_PATH_PROG, and then check the presence of wayland-scanner.pc
>>
>> Currently the latter is unused even
On 23 February 2015 at 15:31, Emil Velikov wrote:
> On 23 February 2015 at 14:10, wrote:
>> On 2015-02-17 16:13, Emil Velikov wrote:
>>>
>>> Currently we use the wayland-scanner executable as found with
>>> AC_PATH_PROG, and then check the presence of wayl
On 23 February 2015 at 19:20, Bill Spitzak wrote:
> On 02/22/2015 11:52 PM, Pekka Paalanen wrote:
>
>>> I'll give Bill and Daniels a chance to comment, but meanwhile:
>>>
>>> Reviewed-by: Bryce Harrington
>
>
> My only concern is that trying to build Wayland from scratch on a machine
> that does
301 - 400 of 400 matches
Mail list logo
