Mon Sep 17 00:00:00 2001
From: Tomek Bury <tomek.b...@broadcom.com>
Date: Tue, 4 Jul 2017 13:14:17 +0100
Subject: [PATCH] Use sysroot prefix for pkgdatadir variable
The pc_sysroot is automatically added to cflags and libs but not
to 'pkg-config --variable'
---
wayland-protocols.pc.in | 2 +-
1
From: Tomek Bury <tomek.b...@broadcom.com>
The pc_sysroot is automatically added to cflags and libs but not
to 'pkg-config --variable'
---
wayland-protocols.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wayland-protocols.pc.in b/wayland-protocols.pc.in
index a
Sorry for a delay, broke my leg :(
I'll send a patch without the extra "/" using git send-mail as soon as I
got that one configured.
Cheers,
Tomek
On Thu, Jul 20, 2017 at 10:45 AM Quentin Glidic <
sardemff7+wayl...@sardemff7.net> wrote:
> On 7/20/17 11:25 AM, Daniel Stone wrote:
> > Hi,
> >
>
The pc_sysroot is automatically added to cflags and libs but not
to 'pkg-config --variable'
---
wayland-protocols.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wayland-protocols.pc.in b/wayland-protocols.pc.in
index a26744c..379be06 100644
--- a/wayland-protocols.pc.in
Thanks!
On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis <
alexandros.frant...@collabora.com> wrote:
> On Mon, Nov 12, 2018 at 12:39:58PM +0000, Tomek Bury wrote:
> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone
> wrote:
> >
> > > On Fri, 9 Nov 2018
HI Daniel,
Where can I find the work-in-progress implementation? I'd like to try it
out with Broadcom driver which doesn't have implicit cross-process sync. I
can add the explicit sync protocol implementation on the driver side but
I'd need a reference to test it against.
Cheers,
Tomek
On Mon,
Thanks! That looks better than my patch.
On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis <
alexandros.frant...@collabora.com> wrote:
> On Monday, December 17, 2018 12:44 GMT, Tomek Bury
> wrote:
> > On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote:
> > > Hi Pek
Hi Pekka, Alexandros,
Here's a patch containing all I had to do in order to test the explicit
sync support Alexandros has implemented in Weston.
Thanks,
Tomek
On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote:
> Hi Pekka,
>
> > I suppose the compositor-side copy of buffers y
ever means to
put those pixels on screen.
Cheers,
Tomek
On Tue, 13 Nov 2018 at 09:33, Tomek Bury wrote:
> Thanks!
>
> On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis <
> alexandros.frant...@collabora.com> wrote:
>
>> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek
n Fri, 23 Nov 2018 13:07:37 +0000
> Tomek Bury wrote:
>
> > Hi Alexandros,
> >
> > Sorry for a delay. I've finally got an end-to-end system to test it out.
> It
> > took some time because Weston backend I wrote a while back needed serious
> > rework to catch u
> On Fri, 23 Nov 2018 16:26:19 +
> Tomek Bury wrote:
>
> > Hi Pekka,
> >
> > > I presume you have a driver stack that relies on the opaque EGL
> buffers
> > and not zwp_linux_dmabuf any time soon?
> > Yes, exactly. I've added a protocol extension
cation, by the EGL or
Vulkan driver. And some of those wl_buffer types will be known to the
compositor, some to the 3D driver and perhaps some to both. At least that's
my understanding.
Cheers,
Tomek
On Tue, 27 Nov 2018 at 08:53, Pekka Paalanen wrote:
> On Mon, 26 Nov 2018 15:14:45 +000
Hi Pekka,
> I suppose the compositor-side copy of buffers you mentioned is for the
> lack of release fences, not acquire fences?
Yes, the lack of release fences is the very reason for the copy. I could
cook something up for the acquire fence, but that wouldn't synchronise the
buffer access
an, if we could get this stable
> and everywhere.
>
> --Jason
>
> On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury wrote:
>
>> Thanks! That looks better than my patch.
>>
>> On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis <
>> alexandros.frant...@collabora.
Hi Jason,
I've been wrestling with the sync problems in Wayland some time ago, but
only with regards to 3D drivers.
The guarantee given by the GL/GLES spec is limited to a single graphics
context. If the same buffer is accessed by 2 contexts the outcome is
unspecified. The cross-context and
> As long as we can fall back to not using fences then we should be fine.
Buffers written by the camera are trivial because you control what
happens - just don't attach fence, so that the capture can be used
immediately. For recycled buffers there's an extra bit of work to do
because won't be up
> GL and GLES are not relevant. What is relevant is EGL, which defines
> interfaces to make things work on the native platform.
Yes and no. This is what EGL spec says about sharing a texture between contexts:
"OpenGL and OpenGL ES makes no attempt to synchronize access to
texture objects. If a
> vkAcquireNextImageKHR() [...] it's the application's decision whether it
> wants a fence, a semaphore, both or none
Correction: "or none" is not allowed
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
> That's not true; you can post back a sync token every time the client
> buffer is used by the compositor.
Technically, yes but it's very cumbersome and invasive to the point
where it becomes impractical. Explicit sync is much cleaner solution.
> For instance, Mesa adds the `wl_drm` extension,
19 matches
Mail list logo
