Hi Daniel,
It would be great to have this patch in weston 2.0.
We made a similar patch to fix this issue for Renesas Gen3 boards.
Best regards
Emre Ucan
Software Group I (ADITG/SW1)
Tel. +49 5121 49 6937
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-
> boun...@lists.
If we're building with EGL support generally, but without Cairo/GLESv2,
building the clients fail, because window.c defines the EGL native
types, however platform.h also brings these in.
Signed-off-by: Daniel Stone
Cc: Emil Velikov
Cc: Bryce Harrington
---
clients/window.c | 2 +-
1 file chang
Don't try to dereference the seat if it's NULL.
Signed-off-by: Daniel Stone
---
compositor/screen-share.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compositor/screen-share.c b/compositor/screen-share.c
index bcb9def..069da1d 100644
--- a/compositor/screen-share.c
+++
Destroying the shared seat removes the link from so->seat_list.
Signed-off-by: Daniel Stone
---
compositor/screen-share.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/compositor/screen-share.c b/compositor/screen-share.c
index 069da1d..a6f82b1 100644
--- a/compositor/s
Hi,
the subject should say "timer", not "hook" I presume.
For some background, here is first an explanation of how upstream
Weston works currently.
weston_output_schedule_repaint() gets called from all over the place,
including as a response to any damage caused. It gets called directly
from re
Hi,
On 16 February 2017 at 14:31, Pekka Paalanen wrote:
> On Tue, 14 Feb 2017 13:18:05 +
> Daniel Stone wrote:
>> On startup, we cannot lock on to the repaint timer because it is unknown
>> to us. We deal with this by claiming that the moment of entry into the
>> repaint loop is the moment a
On Tue, 14 Feb 2017 13:18:05 +
Daniel Stone wrote:
> On startup, we cannot lock on to the repaint timer because it is unknown
> to us. We deal with this by claiming that the moment of entry into the
> repaint loop is the moment a frame returned, causing finish_frame to
> delay our initial rep
On Tue, 14 Feb 2017 13:18:04 +
Daniel Stone wrote:
> Rather than determining the time until next-frame repaint in relative
> space (time until repaint), determine it first in absolute space, and
> then later convert this to relative.
>
> This will later allow us to store these per-output, so
On Wed, 15 Feb 2017 11:49:33 -0600
Derek Foreman wrote:
> On 15/02/17 06:50 AM, Pekka Paalanen wrote:
> > On Wed, 15 Feb 2017 12:17:10 +0800
> > Jonas Ã…dahl wrote:
> >
> >> On Tue, Feb 14, 2017 at 10:20:06AM -0600, Derek Foreman wrote:
> >>> Attaching a NULL wl_buffer to a surface is not alw