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

[Pekka Paalanen]

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?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151105/e23d9f6c/attachment.sig>