[PATCH weston 03/10] Use presentation timing protocol from wayland-protocols

[Jonas Ådahl]

On Thu, Nov 05, 2015 at 01:57:45PM +0200, Pekka Paalanen wrote:
> On Wed,  4 Nov 2015 16:49:52 +0800
> Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> > Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> > ---
> >  Makefile.am                      |  21 ++-
> >  clients/presentation-shm.c       |  65 +++++-----
> >  clients/weston-info.c            |  19 +--
> >  protocol/presentation_timing.xml | 274 ---------------------------------------
> >  src/compositor-drm.c             |  14 +-
> >  src/compositor-fbdev.c           |   2 +-
> >  src/compositor-headless.c        |   2 +-
> >  src/compositor-rpi.c             |   6 +-
> >  src/compositor-wayland.c         |   2 +-
> >  src/compositor-x11.c             |   2 +-
> >  src/compositor.c                 |  29 +++--
> >  tests/presentation-test.c        |  34 ++---
> >  12 files changed, 101 insertions(+), 369 deletions(-)
> >  delete mode 100644 protocol/presentation_timing.xml
> 
> > diff --git a/clients/presentation-shm.c b/clients/presentation-shm.c
> > index 120c40c..9083d8e 100644
> > --- a/clients/presentation-shm.c
> > +++ b/clients/presentation-shm.c
> > @@ -38,7 +38,7 @@
> >  #include <wayland-client.h>
> >  #include "shared/helpers.h"
> >  #include "shared/os-compatibility.h"
> > -#include "presentation_timing-client-protocol.h"
> > +#include "presentation-timing-unstable-v1-client-protocol.h"
> >  
> >  enum run_mode {
> >  	RUN_MODE_FEEDBACK,
> > @@ -67,7 +67,7 @@ struct display {
> >  	struct wl_shm *shm;
> >  	uint32_t formats;
> >  
> > -	struct presentation *presentation;
> > +	struct zwl_presentation1 *presentation;
> 
> Hi Jonas,
> 
> I see you added the prefix wl_ here. I think this is good, it is aiming
> to be a standard, generic extension usable everywhere where Wayland is.
> 
> What I am not so sure about is whether keeping it unstable is still necessary.
> https://phabricator.freedesktop.org/T43
> 
> Maybe we should just promote it stable while we are moving it, and
> avoid one round of renames. I don't know of anything that would need
> fixing or reconsidering in it, apart maybe from names (presentation?).
> 
> Hmm, maybe if someone makes the case that one really *really* does
> not need 64 bits for seconds value, it could use a break. However,
> 64-bit nanoseconds value does not necessarily fit in a 32-bit seconds +
> 32-bit nsecs value when nsec is limited to [0, 999999999], so I think
> it's good as is. (And the code is already written and been out there
> for a long time.)
> 
> What if we skipped this one with the unstable move?

If that what you think makes sense, and noone objects to it, I see no
reason not to. I haven't followed the details regarding the protocol
itself, so I have no opinion whether it is suitable or not.


Jonas

> 
> 
> Thanks,
> pq