On Thu, Jan 17, 2019 at 4:26 AM Sharma, Shashank
wrote:
>
> Hello Arnaud
>
> Thanks for your comments, mine inline.
>
> Regards
> Shashank
> On 1/17/2019 6:38 AM, Arnaud Vrac wrote:
> > On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
> > wrote:
> >>
On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
wrote:
>
> Hello All,
>
> This mail is to propose a design for enabling HDR support in Wayland/Weston
> stack, using display engine capabilities, and get more feedback and input
> from community.
> Here are few points (you might already know these
On Fri, Jun 15, 2018 at 10:08 AM Pekka Paalanen wrote:
>
> On Thu, 14 Jun 2018 13:09:24 +0200
> Arnaud Vrac wrote:
>
> > On Wed, Jun 13, 2018 at 12:34 PM, Nautiyal, Ankit K
> > wrote:
> > > Hi All,
> > >
> > > I am working on wayla
On Wed, Jun 13, 2018 at 12:34 PM, Nautiyal, Ankit K
wrote:
> Hi All,
>
> I am working on wayland content-protection protocol extension, to enable
> content-protection (HDCP1.4, HDCP2.2) in wayland.
> DRM layer already has support for HDCP1.4 and patches for HDCP2.2 are in
> review : https://patchw
On Fri, Feb 16, 2018 at 2:53 PM, Emil Velikov wrote:
> On 16 February 2018 at 10:49, Daniel Stone wrote:
>> Hi Emil,
>>
>> On 16 February 2018 at 10:40, Emil Velikov wrote:
>>> On 15 February 2018 at 23:12, Derek Foreman wrote:
Maybe it's just me, but having different names for the same va
On Wed, Jan 17, 2018 at 4:57 PM, Emil Velikov wrote:
> On 16 January 2018 at 22:10, Daniel Stone wrote:
>> Hey Bryce,
>>
>> On 12 January 2018 at 22:51, Derek Foreman wrote:
>>> On 2018-01-12 04:00 AM, Daniel Stone wrote:
I did a clearout of the review queue last month, but that's not yet
>
This will allow to make some assumptions in further patches when GLES3
is available.
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index abf556f0
then adding a check for the GLES version.
Patch 2 hasn't received a Reviewed-by but I hope this can be landed !
Thanks,
Arnaud
Arnaud Vrac (4):
gl-renderer: save OpenGL version in renderer context
gl-renderer: try to create a GLES3 context
gl-renderer: move GL_EXT_texture_rg extension
This is a GL extension and not EGL, so it should be checked after the
EGL context has been created.
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index ff0a2bb9
extensions string, but still support OpenGLES3.
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index c2767cfc..8a9e4c57 100644
--- a/libweston/gl-renderer.c
+++ b
lable.
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index c4b6af18..ff0a2bb9 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -3
orted code.
>
>
> Any formal Acked-by, Reviewed-by or other will be appreciated. Comments
> and suggestions are also welcome.
>
> Thanks
> Emil
>
> [1]
> https://lists.freedesktop.org/archives/wayland-devel/2017-September/035019.html
Besides my concern in patch 1, the wh
Hi Emil,
On Tue, Oct 10, 2017 at 3:43 PM, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently the client-facing libwayland-egl API is defined by a header
> file shipped by Wayland, but the implementation is left to each vendor.
>
> This can cause collisions when multiple implementations are i
lable.
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 38ae7d60..7ec97b95 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -3
extensions string, but still support OpenGLES3.
Signed-off-by: Arnaud Vrac
Reviewed-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 7ec97b95..0dbba53c 100644
--- a
This will allow to make some assumptions in further patches when GLES3
is available.
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index abf556f0
On Mon, Dec 4, 2017 at 5:57 PM, Emil Velikov wrote:
> On 29 November 2017 at 14:25, Arnaud Vrac wrote:
>> From: Arnaud Vrac
>>
>> The GL_EXT_unpack_subimage and GL_EXT_texture_rg are part of the core ES
>> 3.0 specification, so also check the GL driver version in a
On Mon, Dec 4, 2017 at 6:08 PM, Emil Velikov wrote:
> On 29 November 2017 at 14:25, Arnaud Vrac wrote:
>> Signed-off-by: Arnaud Vrac
>
> Please mention how you've spotted and/or verified this.
>
> I'm ~90% this is correct, although I would check with the author.
On Mon, Dec 4, 2017 at 5:31 PM, Emil Velikov wrote:
> Hi Arnaud,
>
> On 29 November 2017 at 14:25, Arnaud Vrac wrote:
>> From: Arnaud Vrac
>>
> Here I'd mention why we care about the version. Esp. since the helper
> itself looks quitie strange.
Hi Emil,
Will
Hi,
this patch is Reviewed-by: Arnaud Vrac
Nicolas made some changes to the waylandsink element in gstreamer [1] to
better support pitfalls of the SHM protocol. With this patch and the one I
posted earlier today, gstreamer git now works perfectly with weston when
using SHM, even when using YUV
From: Arnaud Vrac
In glTexImage2D / glTexSubImage2D calls, the only pixel formats allowed
for the GL_R8 and GL_RG internal formats are respectively GL_RED and
GL_RG [1].
Make sure we match this requirement, as some drivers will fail with the
current code.
[1]
https://www.khronos.org/registry
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 60a7bf06..4fffa78c 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -1596,7 +1596,6
From: Arnaud Vrac
The GL_EXT_unpack_subimage and GL_EXT_texture_rg are part of the core ES
3.0 specification, so also check the GL driver version in addition to
the extension string to determine if those features are supported.
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 10
From: Arnaud Vrac
Some GL drivers do not expose useful extensions like GL_EXT_texture_rg
or GL_EXT_unpack_subimage, while they are actually supported. Since
those extensions are part of the ES 3.0 core spec, we can workaround
this issue by creating an ES3 context. We fallback to ES2 if the
From: Arnaud Vrac
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 94d81ef4..0a7db13f 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
From: Arnaud Vrac
I found a few issues while trying to display videos backed with SHM memory.
Tested with the following commands on multiple GL stacks (mesa swrast, nvidia,
adreno), with GL_EXT_texture_rg enabled and disabled:
gst-launch-1.0 videotestsrc ! 'video/x-raw, format
From: Arnaud Vrac
---
libweston/gl-renderer.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 94d81ef4..0a7db13f 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -199,6 +199,9 @@ struct
From: Arnaud Vrac
I found a few issues while trying to display videos backed with SHM memory.
Tested with the following commands on multiple GL stacks (mesa swrast, nvidia,
adreno), with GL_EXT_texture_rg enabled and disabled:
gst-launch-1.0 videotestsrc ! 'video/x-raw, format
---
libweston/gl-renderer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 60a7bf06..4fffa78c 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -1596,7 +1596,6 @@ gl_renderer_attach_shm(struct weston
From: Arnaud Vrac
The GL_EXT_unpack_subimage and GL_EXT_texture_rg are part of the core ES
3.0 specification, so also check the GL driver version in addition to
the extension string to determine if those features are supported.
---
libweston/gl-renderer.c | 10 ++
1 file changed, 6
From: Arnaud Vrac
In glTexImage2D / glTexSubImage2D calls, the only pixel formats allowed
for the GL_R8 and GL_RG internal formats are respectively GL_RED and
GL_RG [1].
Make sure we match this requirement, as some drivers will fail with the
current code.
[1]
https://www.khronos.org/registry
From: Arnaud Vrac
Some GL drivers do not expose useful extensions like GL_EXT_texture_rg
or GL_EXT_unpack_subimage, while they are actually supported. Since
those extensions are part of the ES 3.0 core spec, we can workaround
this issue by creating an ES3 context. We fallback to ES2 if the
---
libweston/gl-renderer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 60a7bf06..4fffa78c 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -1596,7 +1596,6 @@ gl_renderer_attach_shm(struct weston
From: Arnaud Vrac
In glTexImage2D / glTexSubImage2D calls, the only pixel formats allowed
for the GL_R8 and GL_RG internal formats are respectively GL_RED and
GL_RG [1].
Make sure we match this requirement, as some drivers will fail with the
current code.
[1]
https://www.khronos.org/registry
From: Arnaud Vrac
---
libweston/gl-renderer.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 94d81ef4..0a7db13f 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -199,6 +199,9 @@ struct
From: Arnaud Vrac
Some GL drivers do not expose useful extensions like GL_EXT_texture_rg
or GL_EXT_unpack_subimage, while they are actually supported. Since
those extensions are part of the ES 3.0 core spec, we can workaround
this issue by creating an ES3 context. We fallback to ES2 if the
From: Arnaud Vrac
The GL_EXT_unpack_subimage and GL_EXT_texture_rg are part of the core ES
3.0 specification, so also check the GL driver version in addition to
the extension string to determine if those features are supported.
---
libweston/gl-renderer.c | 10 ++
1 file changed, 6
From: Arnaud Vrac
I found a few issues while trying to display videos backed with SHM memory.
Tested with the following commands on multiple GL stacks (mesa swrast, nvidia,
adreno), with GL_EXT_texture_rg enabled and disabled:
gst-launch-1.0 videotestsrc ! 'video/x-raw, format
ot
> + visible below the fullscreened surface.
>
> allow-null="true"/>
>
> --
> 2.14.2
>
Very nice, thanks. The patch to on libweston-desktop to match this wording
is pretty simple, I'll push it if needed when libweston-desktop supports
the stable xdg-shell protocol.
Reviewed-by: Arnaud Vrac
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi all,
this patch prevents weston from importing dmabuf buffer when the
EGL_EXT_image_dma_buf_import_modifiers extension is not supported. In this
case, the import will either fail in import_simple_dmabuf if the modifier
is zero, or in gl_renderer_import_dmabuf is the modifier is
DRM_FORMAT_MOD_I
Hi all,
Seeing Jonas effort to make xdg-shell stable, I'd like to clear something
up before this is done.
The set_fullscreen request documentation mentions:
If the surface doesn't cover the whole output, the compositor will
position the surface in the center of the output and compensate with
blac
It's been unused since the legacy (non-libinput) input backends have
been removed.
Signed-off-by: Arnaud Vrac
---
configure.ac| 4 ++--
libweston/libinput-device.c | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 517
dlopen.
This can be reproduced by configuring the build with:
CFLAGS="-fsanitize=address -fsanitize=undefined"
LDFLAGS="-fsanitize=address -fsanitize=undefined"
Signed-off-by: Arnaud Vrac
---
Makefile.am | 4 ++--
configure.ac | 3 ++-
2 files changed, 4 insertions(+), 3 deleti
Without this weston crashes when a client using xdg-shell-v5 is run.
Signed-off-by: Arnaud Vrac
---
libweston-desktop/xdg-shell-v5.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libweston-desktop/xdg-shell-v5.c b/libweston-desktop/xdg-shell-v5.c
index dd360862..ebe7940e 100644
--- a
Signed-off-by: Arnaud Vrac
---
libweston/gl-renderer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index da29b072..5768f05a 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -337,6 +337,7 @@ dmabuf_image_destroy(struct
On Mon, Feb 27, 2017 at 11:18 PM Daniel Stone wrote:
>
> Hi Fabien,
>
> On 6 February 2017 at 16:56, Fabien DESSENNE wrote:
> > I remember I used to get « weston-simple-egl -f » working fine.
> > But it does not work anymore : nothing is displayed. From the logs I can see
> > (among others) zxdg_
On Fri, Sep 16, 2016 at 5:19 PM, Joe Konno
wrote:
> On Fri, 16 Sep 2016 10:53:32 +0300
> Pekka Paalanen wrote:
>
> > On Thu, 15 Sep 2016 15:22:12 -0700
> > Joe Konno wrote:
> >
> > > From: Joe Konno
> > >
> > > In a cross-compilation environment with packages depending on
> > > wayland-scanner
On Mon, Sep 12, 2016 at 5:22 PM, Arnaud Vrac wrote:
> From: Arnaud Vrac
>
> The shell can request a specific size via a configure event when
> toggling fullscreen or maximizing the client. However, if the client
> already has the requested size, the client state is not updated,
&
> Signed-off-by: Quentin Glidic
> ---
> libweston-desktop/wl-shell.c | 4 ++--
> libweston-desktop/xdg-shell-v5.c | 8 +---
> libweston-desktop/xdg-shell-v6.c | 8 +---
> 3 files changed, 12 insertions(+), 8 deletions(-)
Reviewed-by: Arnaud Vrac
The bug can be reproduce
From: Arnaud Vrac
The shell can request a specific size via a configure event when
toggling fullscreen or maximizing the client. However, if the client
already has the requested size, the client state is not updated,
preventing the switch to fullscreen or maximized states.
Signed-off-by: Arnaud
> On 5 juil. 2016, at 22:11, Jan Arne Petersen wrote:
>
>
> On Wed, Jun 8, 2016 at 5:40 PM Arnaud Vrac wrote:
> The input method protocol should be updated next:
> * we need the input method panel geometry to be able to fill the
> * input_panel_state event parameter
Remove the output transform from the view transform list when its
surface is destroyed. The surface destruction also triggers the
freeing of its views, so the next access to the output transform link
could crash.
---
fullscreen-shell/fullscreen-shell.c | 2 ++
1 file changed, 2 insertions(+)
diff
The parent of a subsurface can be used as a sibling in the place_below
and place_above calls. However this did not work when the parent is
nested, so fix the sibling check and add a test to check this case.
---
src/compositor.c| 28 ++--
tests/subsurface-test.c | 44
Hi Jonas,
On Tue, Mar 15, 2016 at 2:14 PM, Jonas Ådahl wrote:
> This patch implements the wp_pointer_constraints protocol used for
> locking or confining a pointer. It consists of a new global object with
> two requests; one for locking the surface to a position, one for
> confining the pointer
On Fri, Oct 16, 2015 at 11:10 AM, Pekka Paalanen
wrote:
> On Fri, 16 Oct 2015 10:27:56 +0200
> Hardening wrote:
>
> > Le 16/10/2015 03:28, Bryce Harrington a écrit :
> > > On Tue, Oct 13, 2015 at 01:59:13PM +0200, Joaquim Duran wrote:
> > >> Hello,
> > >>
> > >> When configuring the Weston proje
On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre
wrote:
> On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho
> wrote:
> > On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
> >> What is the value of clients having this information?
> >
> > The same there is in having wl_touch.cancelled.
On Tue, Jun 16, 2015 at 5:47 PM, Jonas Ådahl wrote:
> On Tue, Jun 16, 2015 at 04:46:55PM +0200, Arnaud Vrac wrote:
> > Hi,
> >
> > I'm wondering if a behaviour of weston related to subsurfaces is either a
> > bug or intended. The protocol description is not
asper St. Pierre
wrote:
> Why can't you use the video as the main surface and an OSD as a subsurface?
>
> On Tue, Jun 16, 2015 at 11:09 AM, Arnaud Vrac wrote:
> > I'm not sure, but I find it very useful for a video player. The video is
> > stacked under the OSD a
asper St. Pierre
wrote:
> I was not aware you could stack subsurfaces under a parent surface at
> all. Is this intended protocol behavior? The fact that you might be
> able to do that at all in Weston might be a bug.
>
> On Tue, Jun 16, 2015 at 7:46 AM, Arnaud Vrac wrote:
> >
Hi,
I'm wondering if a behaviour of weston related to subsurfaces is either a
bug or intended. The protocol description is not clear on what happens in
the following cases:
Suppose I have a shell surface (BLUE) and two subsurfaces (RED, GREEN). I
want to stack them to I get RED, GREEN, BLUE from
On Tue, Jun 2, 2015 at 11:26 AM, Jonas Ådahl wrote:
> On Fri, May 29, 2015 at 05:07:08PM +0200, Arnaud Vrac wrote:
> > Hi Jonas,
>
> Hi,
>
> >
> > This patch makes the black_surface_get_label function crash. The black
> surface should track the fullscreen vi
col->interface_list, link) {
> printf("extern const struct wl_interface "
> - "%s_interface;\n", *p);
> - prev = *p;
> + "%s_interface;\n", i->name);
Hi Jonas,
This patch makes the black_surface_get_label function crash. The black surface
should track the fullscreen view in the configure_private field instead of the
black surface view.
See the attached patch for reference.
0001-desktop-shell-track-fullscreen-view-in-black-surface.patch
De
gt; > + ps->buffer_destroy_listener.notify =
> > + buffer_state_handle_buffer_destroy;
> > + wl_signal_add(&buffer->destroy_signal,
> > + &ps->buffer_destroy_listener);
> > }
> >
> > static void
> > @@ -506,7 +530,8 @@ pixman_renderer_surface_state_destroy(struct
> pixman_surface_state *ps)
> > {
> > wl_list_remove(&ps->surface_destroy_listener.link);
> > wl_list_remove(&ps->renderer_destroy_listener.link);
> > -
> > + if (ps->buffer_destroy_listener.notify)
> > + wl_list_remove(&ps->buffer_destroy_listener.link);
> >
> > ps->surface->renderer_state = NULL;
> >
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
--
Arnaud Vrac
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
From: Arnaud Vrac
A crash could happen when killing weston, since the wayland client of
the shell child process could be destroyed twice: once when the wayland
client disconnects (before sigchld is caught), and then again when
destroying the shell.
---
src/shell.c| 21
_
> >> wayland-devel mailing list
> >> wayland-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > ___
> > wayland-devel mailing list
&g
---
src/connection.c |4 +---
src/wayland-server.c |4 ++--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index 141875e..ed2666b 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -1015,10 +1015,8 @@ wl_closure_print(struct wl_c
wervr EGL drivers use EGL_SWAP_BEHAVIOR set to
EGL_BUFFER_PRESERVED
and you cannot change it without hacking the EGL backends. This means the
frontbuffer is copied to the backbuffer after each swap, which is obviously
slow. This can be avoided by calling glClear() at the start of the frame,
rendering the damage tracki
On 05/02/2012 01:17 PM, Arnaud Vrac wrote:
> This will avoid a race condition on the client side when thread safety
> is implemented. The destruction of a proxy might be done after the
> deletion of its object id in this case: the destruction of the proxy is
> done from the thread
This will avoid a race condition on the client side when thread safety
is implemented. The destruction of a proxy might be done after the
deletion of its object id in this case: the destruction of the proxy is
done from the thread in which the object was created, and the deletion
of the object id i
On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
wrote:
> On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>> Hello everyone,
>>
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I have written a custom EGL backe
On Tue, Apr 24, 2012 at 6:13 PM, Arnaud Vrac wrote:
> On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
> wrote:
>> On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>>> Hello everyone,
>>>
>>> I am hitting a bug when using Qt5 and wayland o
2012/4/24 Bill Spitzak :
> On 04/20/2012 03:27 PM, Kristian Høgsberg wrote:
>
>> "Initial assumption for wl_display and related objects was that it is
>> not going to be thread safe, and you have to lock access to the wl API
>> yourself if you're going to use it from multiple threads. It's a
>> va
On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
wrote:
> On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>> Hello everyone,
>>
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I have written a custom EGL backe
Thanks darxus, I don't mind posting a bug bug is anyone actually going
to use this bugtracker ? It's empty :)
>
> On 04/19, Arnaud Vrac wrote:
>> Hello everyone,
>>
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I h
Hello everyone,
I am hitting a bug when using Qt5 and wayland on an embedded platform,
for which I have written a custom EGL backend. The problem is that Qt5
(QtQuick2 actually) renders in a separate thread, when the wayland
display has been created in the main thread. I know there is a patch
for
76 matches
Mail list logo
