Re: [PATCH v2 wayland] protocol: add support for cross-interface enum attributes

[Bill Spitzak]

Looks correct to me.

I had a slightly different patch in patchwork which changes
protocol-to-docbook. It puts the enumeration into it's own statement,
rather than a nested if statement, and it adds the object:: prefix to the
documentation for all enumerations, not just the cross-object ones.

On Sun, Nov 29, 2015 at 5:54 AM, Auke Booij  wrote:

> The enum attribute, for which scanner support was introduced in
> 1771299, can be used to link message arguments to s. However,
> some arguments refer to s in a different .
>
> This adds scanner support for referring to an  in a different
>  using dot notation. It also sets the attributes in this
> style in the wayland XML protocol (wl_shm_pool::create_buffer::format
> to wl_shm::format, and wl_surface::set_buffer_transform::transform to
> wl_output::transform), and updates the documentation XSL so that this
> new style is supported.
>
> Changes since v1:
>  - several implementation bugs fixed
>
> Signed-off-by: Auke Booij 
> ---
>  doc/publican/protocol-to-docbook.xsl | 17 +--
>  protocol/wayland.xml |  4 +--
>  src/scanner.c| 59
> +++-
>  3 files changed, 61 insertions(+), 19 deletions(-)
>
> diff --git a/doc/publican/protocol-to-docbook.xsl
> b/doc/publican/protocol-to-docbook.xsl
> index fad207a..1fa066d 100644
> --- a/doc/publican/protocol-to-docbook.xsl
> +++ b/doc/publican/protocol-to-docbook.xsl
> @@ -103,9 +103,20 @@
>  
>  
>
> -
> -  
> -
> +
> +  
> +
> +  
> +  ::
> +  
> +
> +  
> +  
> +
> +  
> +
> +  
> +
>  
>
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f9e6d76..0873553 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -229,7 +229,7 @@
>
>
>
> -  
> +  
>  
>
>  
> @@ -1292,7 +1292,7 @@
> wl_output.transform enum the invalid_transform protocol error
> is raised.
>
> -  
> +  
>  
>
>  
> diff --git a/src/scanner.c b/src/scanner.c
> index 406519f..e69bd2a 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -785,32 +785,62 @@ start_element(void *data, const char *element_name,
> const char **atts)
> }
>  }
>
> +static struct enumeration *
> +find_enumeration(struct protocol *protocol, struct interface *interface,
> char *enum_attribute)
> +{
> +   struct interface *i;
> +   struct enumeration *e, *f = NULL;
> +   char *enum_name;
> +   int idx = 0, j;
> +
> +for (j = 0; j + 1 < (int)strlen(enum_attribute); j++) {
> +   if (enum_attribute[j] == '.') {
> +   idx = j;
> +   }
> +   }
> +
> +   if (idx > 0) {
> +   enum_name = enum_attribute + idx + 1;
> +
> +   wl_list_for_each(i, >interface_list, link)
> +   if (strncmp(i->name, enum_attribute, idx) == 0)
> +   wl_list_for_each(e, >enumeration_list,
> link)
> +   if(strcmp(e->name, enum_name) == 0)
> +   f = e;
> +   } else if (interface) {
> +   enum_name = enum_attribute;
> +
> +   wl_list_for_each(e, >enumeration_list, link)
> +   if(strcmp(e->name, enum_name) == 0)
> +   f = e;
> +   }
> +
> +   return f;
> +}
> +
>  static void
> -verify_arguments(struct parse_context *ctx, struct wl_list *messages,
> struct wl_list *enumerations)
> +verify_arguments(struct parse_context *ctx, struct interface *interface,
> struct wl_list *messages, struct wl_list *enumerations)
>  {
> struct message *m;
> wl_list_for_each(m, messages, link) {
> struct arg *a;
> wl_list_for_each(a, >arg_list, link) {
> -   struct enumeration *e, *f;
> +   struct enumeration *e;
>
> if (!a->enumeration_name)
> continue;
>
> -   f = NULL;
> -   wl_list_for_each(e, enumerations, link) {
> -   if(strcmp(e->name, a->enumeration_name) ==
> 0)
> -   f = e;
> -   }
>
> -   if (f == NULL)
> +   e = find_enumeration(ctx->protocol, interface,
> a->enumeration_name);
> +
> +   if (e == NULL)
> fail(>loc,
>  "could not find enumeration %s",
>  a->enumeration_name);
>
>  

Re: [PATCH wayland] protocol: specify behavior of get_pointer when capabilities change

[Bill Spitzak]

On Mon, Nov 30, 2015 at 3:32 PM, Peter Hutterer 
wrote:

> On Mon, Nov 30, 2015 at 09:46:36PM +, Daniel Stone wrote:
>
> > > +   If a seat regains the pointer capability and a client has a
> pointer
> > > +   object obtained previously, that object may start sending
> pointer
> > > +   events. This behavior is implementation-dependent and must not
> be
> > > +   relied upon.
> >
> > Urgh, I don't really like having this there as a bit of a get-out
> > clause. Can we just strengthen the 'client should destroy the
> > wl_pointer objects' to a 'must'? Especially since this paragraph
> > contradicts the immediately previous one ('No further pointer events
> > will be received on these objects'). Maybe we could fold bits of this
> > paragraph in to replace that problematic sentence, but couple with a
> > recommendation that compositors should not send events to stale
> > objects - and bump that to a must for compositors advertising whatever
> > our next version of wl_seat ends up being.
>
> if the per-version behaviour works correctly we can add this, otherwise we
> still have to keep this paragraph in, otherwise we're retroactively
> disallowing current working implementations. The same goes for the
> should/must, we already have implementations doing this.
>

I don't think you want this text. An existing implementation that sends
pointer events after the loss/gain is broken. People wrote lots of other
bugs into existing implementations, that does not mean all descriptions
have to allow any existing bug.

A more practical reason for being more insistent is that if a popular
compositor does this, it is quite likely to be relied on by some clients
(due to the fact that it is much easier to write a client that relies on
this), quickly leading to this being a required behaviour of all
compositors. Explicitly saying that is wrong may encourage the compositors
to not do this, though of course it does not guarantee it.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets

[Bill Spitzak]

On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer 
wrote:

>
> +   switch (tool->type) {
> +   case LIBINPUT_TABLET_TOOL_TYPE_PEN:
> +   strtype = "PEN";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_BRUSH:
> +   strtype = "BRUSH";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_AIRBRUSH:
> +   strtype = "AIRBRUSH";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_PENCIL:
> +   strtype = "PENCIL";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_ERASER:
> +   strtype = "RUBBER";
> +   break;
>
> Is there a good reason for this inconsistency in the strings? Ie why isn't
the last strtype "ERASER".
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 wayland] protocol: add support for cross-interface enum attributes

[Nils Chr. Brause]

On Wed, Dec 2, 2015 at 11:48 AM, Auke Booij  wrote:
> I'd be happy to rebase against that, but since that hasn't been merged
> yet, I thought I'd take the current tree as a a basis.
>
> If you think having the interface:: prefix everywhere makes sense, I
> can change that if you want.

I think that would be very nice for consistency. :)

>
> On 2 December 2015 at 03:09, Bill Spitzak  wrote:
>> Looks correct to me.
>>
>> I had a slightly different patch in patchwork which changes
>> protocol-to-docbook. It puts the enumeration into it's own statement, rather
>> than a nested if statement, and it adds the object:: prefix to the
>> documentation for all enumerations, not just the cross-object ones.
>>
>> On Sun, Nov 29, 2015 at 5:54 AM, Auke Booij  wrote:
>>>
>>> The enum attribute, for which scanner support was introduced in
>>> 1771299, can be used to link message arguments to s. However,
>>> some arguments refer to s in a different .
>>>
>>> This adds scanner support for referring to an  in a different
>>>  using dot notation. It also sets the attributes in this
>>> style in the wayland XML protocol (wl_shm_pool::create_buffer::format
>>> to wl_shm::format, and wl_surface::set_buffer_transform::transform to
>>> wl_output::transform), and updates the documentation XSL so that this
>>> new style is supported.
>>>
>>> Changes since v1:
>>>  - several implementation bugs fixed
>>>
>>> Signed-off-by: Auke Booij 
>>> ---
>>>  doc/publican/protocol-to-docbook.xsl | 17 +--
>>>  protocol/wayland.xml |  4 +--
>>>  src/scanner.c| 59
>>> +++-
>>>  3 files changed, 61 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/doc/publican/protocol-to-docbook.xsl
>>> b/doc/publican/protocol-to-docbook.xsl
>>> index fad207a..1fa066d 100644
>>> --- a/doc/publican/protocol-to-docbook.xsl
>>> +++ b/doc/publican/protocol-to-docbook.xsl
>>> @@ -103,9 +103,20 @@
>>>  
>>>  
>>>
>>> -
>>> -  
>>> -
>>> +
>>> +  
>>> +
>>> +  
>>> +  ::
>>> +  
>>> +
>>> +  
>>> +  
>>> +
>>> +  
>>> +
>>> +  
>>> +
>>>  
>>>
>>>
>>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>>> index f9e6d76..0873553 100644
>>> --- a/protocol/wayland.xml
>>> +++ b/protocol/wayland.xml
>>> @@ -229,7 +229,7 @@
>>>
>>>
>>>
>>> -  
>>> +  
>>>  
>>>
>>>  
>>> @@ -1292,7 +1292,7 @@
>>> wl_output.transform enum the invalid_transform protocol error
>>> is raised.
>>>
>>> -  
>>> +  
>>>  
>>>
>>>  
>>> diff --git a/src/scanner.c b/src/scanner.c
>>> index 406519f..e69bd2a 100644
>>> --- a/src/scanner.c
>>> +++ b/src/scanner.c
>>> @@ -785,32 +785,62 @@ start_element(void *data, const char *element_name,
>>> const char **atts)
>>> }
>>>  }
>>>
>>> +static struct enumeration *
>>> +find_enumeration(struct protocol *protocol, struct interface *interface,
>>> char *enum_attribute)
>>> +{
>>> +   struct interface *i;
>>> +   struct enumeration *e, *f = NULL;
>>> +   char *enum_name;
>>> +   int idx = 0, j;
>>> +
>>> +for (j = 0; j + 1 < (int)strlen(enum_attribute); j++) {
>>> +   if (enum_attribute[j] == '.') {
>>> +   idx = j;
>>> +   }
>>> +   }
>>> +
>>> +   if (idx > 0) {
>>> +   enum_name = enum_attribute + idx + 1;
>>> +
>>> +   wl_list_for_each(i, >interface_list, link)
>>> +   if (strncmp(i->name, enum_attribute, idx) == 0)
>>> +   wl_list_for_each(e, >enumeration_list,
>>> link)
>>> +   if(strcmp(e->name, enum_name) ==
>>> 0)
>>> +   f = e;
>>> +   } else if (interface) {
>>> +   enum_name = enum_attribute;
>>> +
>>> +   wl_list_for_each(e, >enumeration_list, link)
>>> +   if(strcmp(e->name, enum_name) == 0)
>>> +   f = e;
>>> +   }
>>> +
>>> +   return f;
>>> +}
>>> +
>>>  static void
>>> -verify_arguments(struct parse_context *ctx, struct wl_list *messages,
>>> struct wl_list *enumerations)
>>> +verify_arguments(struct parse_context *ctx, struct interface *interface,
>>> struct wl_list *messages, struct wl_list *enumerations)
>>>  {
>>> struct message *m;
>>> wl_list_for_each(m, messages, link) {
>>> struct arg *a;
>>> wl_list_for_each(a, >arg_list, link) {
>>> -   struct enumeration *e, *f;
>>> +   struct enumeration *e;
>>>
>>>   

[PATCH weston 1/2] compositor: Be more careful about setting buffer_viewport.changed

[Derek Foreman]

We've been setting it every time a client does something that can change
the viewport (as opposed to something that does change the viewport).

However, as an example, a client could be calling set_buffer_scale() with
the same value every commit.  This would lead us to performing operations
only required when the viewport changes when it didn't actually change
at all.

Signed-off-by: Derek Foreman 
---
 src/compositor.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/src/compositor.c b/src/compositor.c
index 8bf55dc..33d500e 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -2861,6 +2861,10 @@ surface_set_buffer_transform(struct wl_client *client,
return;
}
 
+   if (surface->pending.buffer_viewport.buffer.transform ==
+   (unsigned int)transform)
+   return;
+
surface->pending.buffer_viewport.buffer.transform = transform;
surface->pending.buffer_viewport.changed = 1;
 }
@@ -2880,6 +2884,9 @@ surface_set_buffer_scale(struct wl_client *client,
return;
}
 
+   if (surface->pending.buffer_viewport.buffer.scale == scale)
+   return;
+
surface->pending.buffer_viewport.buffer.scale = scale;
surface->pending.buffer_viewport.changed = 1;
 }
@@ -4221,6 +4228,14 @@ viewport_set(struct wl_client *client,
return;
}
 
+   if (surface->pending.buffer_viewport.buffer.src_x == src_x &&
+   surface->pending.buffer_viewport.buffer.src_y == src_y &&
+   surface->pending.buffer_viewport.buffer.src_width == src_width &&
+   surface->pending.buffer_viewport.buffer.src_height == src_height &&
+   surface->pending.buffer_viewport.surface.width == dst_width &&
+   surface->pending.buffer_viewport.surface.height == dst_height)
+   return;
+
surface->pending.buffer_viewport.buffer.src_x = src_x;
surface->pending.buffer_viewport.buffer.src_y = src_y;
surface->pending.buffer_viewport.buffer.src_width = src_width;
@@ -4261,6 +4276,12 @@ viewport_set_source(struct wl_client *client,
return;
}
 
+   if (surface->pending.buffer_viewport.buffer.src_x == src_x &&
+   surface->pending.buffer_viewport.buffer.src_y == src_y &&
+   surface->pending.buffer_viewport.buffer.src_width == src_width &&
+   surface->pending.buffer_viewport.buffer.src_height == src_height)
+   return;
+
surface->pending.buffer_viewport.buffer.src_x = src_x;
surface->pending.buffer_viewport.buffer.src_y = src_y;
surface->pending.buffer_viewport.buffer.src_width = src_width;
@@ -4294,6 +4315,10 @@ viewport_set_destination(struct wl_client *client,
return;
}
 
+   if (surface->pending.buffer_viewport.surface.width == dst_width &&
+   surface->pending.buffer_viewport.surface.height == dst_height)
+   return;
+
surface->pending.buffer_viewport.surface.width = dst_width;
surface->pending.buffer_viewport.surface.height = dst_height;
surface->pending.buffer_viewport.changed = 1;
-- 
2.6.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 2/2] compositor: Damage the whole surface if the viewport changes

[Derek Foreman]

Surface damage has a curious relationship with buffer damage.  If we
change our buffer orientation, the whole buffer contents will likely
change.  The application is really only supposed to tell us what parts
of the surface changed, which could still just be a subset.

Since the gl renderer uses the damage rectangles for texture uploads, it
won't upload the entire buffer contents after an orientation change.

To deal with this we just damage the entire surface any time the buffer
viewport changes.

This fixes weston_simple_damage --rotating-transform when using the gl
renderer.

Signed-off-by: Derek Foreman 
---
 src/compositor.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compositor.c b/src/compositor.c
index 33d500e..5a2f3aa 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -2761,6 +2761,10 @@ weston_surface_commit_state(struct weston_surface 
*surface,
surface->configure(surface, state->sx, state->sy);
}
 
+   if (state->buffer_viewport.changed)
+   pixman_region32_union_rect(>damage, >damage,
+  0, 0, INT32_MAX, INT32_MAX);
+
state->sx = 0;
state->sy = 0;
state->newly_attached = 0;
-- 
2.6.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] gl-renderer: Dilate damage when output is zoomed or scaled

[Derek Foreman]

When we zoom or scale an output it's possible for a single buffer
pixel to be stretched over multiple output pixels.

When this happens, if a client is sending exact damage rectangles
we can end up with incomplete updates - the client doesn't know
that the previous frame resulted in some pixel bleeding, and
can't reasonably get damage right.

To fix this, we'll dilate the damage region by a little bit all
around.  We may be dilating a little too much, but a pixel or two
too far is better than being too small.

The problem is easily seen with weston_simple_damage when the
output is zoomed, or when running with a lower buffer scale
than the output scale.  The moving circle will leave trails.

Signed-off-by: Derek Foreman 
---
 src/gl-renderer.c | 53 +++--
 1 file changed, 47 insertions(+), 6 deletions(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index ae72f32..eb18931 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1006,6 +1006,33 @@ output_rotate_damage(struct weston_output *output,
go->border_damage[go->buffer_damage_index] = border_status;
 }
 
+static void
+region_dilate(pixman_region32_t *region, double size)
+{
+pixman_box32_t *src_rects, *dest_rects;
+int nrects, i;
+
+src_rects = pixman_region32_rectangles(region, );
+dest_rects = malloc(nrects * sizeof(*dest_rects));
+if (!dest_rects)
+return;
+
+for (i = 0; i < nrects; i++) {
+   dest_rects[i].x1 = src_rects[i].x1 - size;
+   if (dest_rects[i].x1 < 0)
+   dest_rects[i].x1 = 0;
+   dest_rects[i].x2 = src_rects[i].x2 + size;
+   dest_rects[i].y1 = src_rects[i].y1 - size;
+   if (dest_rects[i].y1 < 0)
+   dest_rects[i].y1 = 0;
+   dest_rects[i].y2 = src_rects[i].y2 + size;
+   }
+
+pixman_region32_clear(region);
+pixman_region32_init_rects(region, dest_rects, nrects);
+free(dest_rects);
+}
+
 /* NOTE: We now allow falling back to ARGB gl visuals when XRGB is
  * unavailable, so we're assuming the background has no transparency
  * and that everything with a blend, like drop shadows, will have something
@@ -1016,7 +1043,7 @@ output_rotate_damage(struct weston_output *output,
  */
 static void
 gl_renderer_repaint_output(struct weston_output *output,
- pixman_region32_t *output_damage)
+ pixman_region32_t *output_damage_in)
 {
struct gl_output_state *go = get_output_state(output);
struct weston_compositor *compositor = output->compositor;
@@ -1028,12 +1055,25 @@ gl_renderer_repaint_output(struct weston_output *output,
EGLint *egl_damage, *d;
pixman_box32_t *rects;
 #endif
+   pixman_region32_t output_damage;
pixman_region32_t buffer_damage, total_damage;
enum gl_border_status border_damage = BORDER_STATUS_CLEAN;
 
if (use_output(output) < 0)
return;
 
+   pixman_region32_init(_damage);
+   pixman_region32_copy(_damage, output_damage_in);
+
+   /* When the output is scaled or zoomed a single buffer
+* pixel may be spread across multiple output pixels.
+* Therefore, if damage is exact in buffer space there may
+* be bleeding into neighbouring output pixels.  We dilate
+* the damage region to compensate.
+*/
+   if (output->zoom.active || output->current_scale > 1)
+   region_dilate(_damage, output->current_scale);
+
/* Calculate the viewport */
glViewport(go->borders[GL_RENDERER_BORDER_LEFT].width,
   go->borders[GL_RENDERER_BORDER_BOTTOM].height,
@@ -1056,7 +1096,7 @@ gl_renderer_repaint_output(struct weston_output *output,
pixman_region32_t undamaged;
pixman_region32_init();
pixman_region32_subtract(, >region,
-output_damage);
+_damage);
gr->fan_debug = 0;
repaint_views(output, );
gr->fan_debug = 1;
@@ -1067,9 +1107,9 @@ gl_renderer_repaint_output(struct weston_output *output,
pixman_region32_init(_damage);
 
output_get_damage(output, _damage, _damage);
-   output_rotate_damage(output, output_damage, go->border_status);
+   output_rotate_damage(output, _damage, go->border_status);
 
-   pixman_region32_union(_damage, _damage, output_damage);
+   pixman_region32_union(_damage, _damage, _damage);
border_damage |= go->border_status;
 
repaint_views(output, _damage);
@@ -1079,7 +1119,7 @@ gl_renderer_repaint_output(struct weston_output *output,
 
draw_output_borders(output, border_damage);
 
-   pixman_region32_copy(>previous_damage, output_damage);
+   pixman_region32_copy(>previous_damage, 

Re: [PATCH wayland v2 1/5] server: Add new api for add socket for fd

[Pekka Paalanen]

Hi,

I don't really understand the underlying use case, but I can imagine
adding listening sockects to wl_display by fd being useful, so I have
no objections to this feature in general.

More below.


On Mon, 23 Nov 2015 19:59:19 -0800
Bryce Harrington  wrote:

> From: Sangjin Lee 
> 
> Currently the server can add a socket by name.  To support an embedded
> compositor in a Simplified Mandatory Access Control Kernel (Smack)
> enabled environment, the embedded compositor should use the socket that
> it gets from the system or session compositor.
> 
> Signed-off-by: Sangjin Lee 
> Acked-by: Sung-Jin Park 
> Reviewed-by: Bryce Harrington 
> Signed-off-by: Bryce Harrington 
> ---
>  src/wayland-os.c  | 12 
>  src/wayland-os.h  |  2 ++
>  src/wayland-server-core.h |  6 
>  src/wayland-server.c  | 76 
> ++-
>  4 files changed, 68 insertions(+), 28 deletions(-)
> 
> diff --git a/src/wayland-os.c b/src/wayland-os.c
> index 93b6f5f..31114f6 100644
> --- a/src/wayland-os.c
> +++ b/src/wayland-os.c
> @@ -27,6 +27,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -73,6 +74,17 @@ wl_os_socket_cloexec(int domain, int type, int protocol)
>  }
>  
>  int
> +wl_os_socket_check_cloexec(int fd)
> +{
> + struct stat buf;
> +
> + if (fd < 0 || fstat(fd, ) < 0 || !S_ISSOCK(buf.st_mode))
> + return -1;
> +
> + return set_cloexec_or_close(fd);
> +}

Why is setting cloexec baked into this check?

It is fundamentally impossible to write an OS helper function that
would guarantee there is no race in setting the cloexec vs. forks,
because you already have the fd open.

That's why I think it would be better to just expose the
set_cloexec_or_close() with a namespaced name, rather than this new
function.

It seems there is nothing OS-specific in the ISSOCK check, or at least
you are not accounting for any, so it doesn't belong in wayland-os.c.

> +
> +int
>  wl_os_dupfd_cloexec(int fd, long minfd)
>  {
>   int newfd;
> diff --git a/src/wayland-os.h b/src/wayland-os.h
> index f51efaa..e3e7bf0 100644
> --- a/src/wayland-os.h
> +++ b/src/wayland-os.h
> @@ -41,6 +41,8 @@ wl_os_epoll_create_cloexec(void);
>  int
>  wl_os_accept_cloexec(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
>  
> +int
> +wl_os_socket_check_cloexec(int fd);
>  
>  /*
>   * The following are for wayland-os.c and the unit tests.
> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index 85b4b9e..9710609 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -128,9 +128,15 @@ wl_display_get_event_loop(struct wl_display *display);
>  int
>  wl_display_add_socket(struct wl_display *display, const char *name);
>  
> +int
> +wl_display_add_socket_fd(struct wl_display *display, const char *name, int 
> sock_fd);
> +
>  const char *
>  wl_display_add_socket_auto(struct wl_display *display);
>  
> +const char *
> +wl_display_add_socket_fd_auto(struct wl_display *display, int sock_fd);

These two API additions are strange, more of them below.

IMHO much better would be to add just one:

int
wl_display_add_socket_fd(struct wl_display *display, int sock_fd);

which will simply fail if sock_fd is not open and valid.

> +
>  void
>  wl_display_terminate(struct wl_display *display);
>  
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 0f04f66..bac98bf 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1133,8 +1133,12 @@ _wl_display_add_socket(struct wl_display *display, 
> struct wl_socket *s)
>  {
>   socklen_t size;
>  
> - s->fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> - if (s->fd < 0) {
> + if (s->fd == -1) {
> + s->fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> + if (s->fd < 0) {
> + return -1;
> + }
> + } else if (wl_os_socket_check_cloexec(s->fd) < 0) {

It would make sense to restructure _wl_display_add_socket() to take an
explicit fd argument and perhaps move the wl_os_socket_cloexec() to the
callers, but since that's minor internal details I won't fight over it.

>   return -1;
>   }
>  
> @@ -1161,7 +1165,7 @@ _wl_display_add_socket(struct wl_display *display, 
> struct wl_socket *s)
>  }
>  
>  WL_EXPORT const char *
> -wl_display_add_socket_auto(struct wl_display *display)
> +wl_display_add_socket_fd_auto(struct wl_display *display, int sock_fd)

This makes a very strange public API: depending on sock_fd, this is
either "fd" or "auto" behaviour.

I'd prefer this to be a helper that the public entry points called, so
that wl_display_add_socket_fd() would ensure the given fd is valid or
fail. It should not silently fall back to creating a new socket file
just if sock_fd happens to be -1 due to an 

Re: [PATCH libinput] Ignore BTN_TOOL_* events when posting button events

[Hans de Goede]

Hi,

On 01-12-15 23:52, Peter Hutterer wrote:

These aren't real button events and they are handled elsewhere, either through
proper touch events on touchscreen or through custom handling in the touchpad
case.

Signed-off-by: Peter Hutterer 


Looks good:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  src/evdev.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/evdev.c b/src/evdev.c
index ec3abc6..4933185 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -439,8 +439,22 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
  static enum evdev_key_type
  get_key_type(uint16_t code)
  {
-   if (code == BTN_TOUCH)
+   switch (code) {
+   case BTN_TOOL_PEN:
+   case BTN_TOOL_RUBBER:
+   case BTN_TOOL_BRUSH:
+   case BTN_TOOL_PENCIL:
+   case BTN_TOOL_AIRBRUSH:
+   case BTN_TOOL_MOUSE:
+   case BTN_TOOL_LENS:
+   case BTN_TOOL_QUINTTAP:
+   case BTN_TOOL_DOUBLETAP:
+   case BTN_TOOL_TRIPLETAP:
+   case BTN_TOOL_QUADTAP:
+   case BTN_TOOL_FINGER:
+   case BTN_TOUCH:
return EVDEV_KEY_TYPE_NONE;
+   }

if (code >= KEY_ESC && code <= KEY_MICMUTE)
return EVDEV_KEY_TYPE_KEY;


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 3/8] tablet: drop pressure when either pressure or distance changed

[Hans de Goede]

Hi,

On 02-12-15 02:46, Peter Hutterer wrote:

Keep pressure and distance mutually exclusive regardless which one of the two
updates.

Signed-off-by: Peter Hutterer 
---
  src/evdev-tablet.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 82029a9..395cbef 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -853,7 +853,8 @@ sanitize_tablet_axes(struct tablet_dispatch *tablet)
pressure = libevdev_get_abs_info(tablet->device->evdev, ABS_PRESSURE);

/* Keep distance and pressure mutually exclusive */
-   if (bit_is_set(tablet->changed_axes, LIBINPUT_TABLET_TOOL_AXIS_DISTANCE) 
&&
+   if ((bit_is_set(tablet->changed_axes, 
LIBINPUT_TABLET_TOOL_AXIS_DISTANCE) ||
+bit_is_set(tablet->changed_axes, LIBINPUT_TABLET_TOOL_AXIS_DISTANCE)) 
&&


Your checking the same bit twice here, I believe you need to 
s/DISTANCE/PRESSURE/
in the second check.

The rest of the series looks good, so the series, and this one with this fixed 
is:

Reviewed-by: Hans de Goede 

Regards,

Hans



distance->value > distance->minimum &&
pressure->value > pressure->minimum) {
clear_bit(tablet->changed_axes, 
LIBINPUT_TABLET_TOOL_AXIS_DISTANCE);


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 3/3] touchpad: don't try to position fake touches when no fingers are down

[Peter Hutterer]

If all fingers are released in the same frame, we won't be able to find the
top-most touch.

https://bugs.freedesktop.org/show_bug.cgi?id=93204

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad.c |  3 ++-
 test/touchpad.c | 26 ++
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 8804658..4fba147 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -832,7 +832,8 @@ tp_position_fake_touches(struct tp_dispatch *tp)
struct tp_touch *topmost = NULL;
unsigned int start, i;
 
-   if (tp_fake_finger_count(tp) <= tp->num_slots)
+   if (tp_fake_finger_count(tp) <= tp->num_slots ||
+   tp->nfingers_down == 0)
return;
 
/* We have at least one fake touch down. Find the top-most real
diff --git a/test/touchpad.c b/test/touchpad.c
index 9f5e5a9..e024ace 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -1703,6 +1703,31 @@ START_TEST(touchpad_semi_mt_hover_2fg_1fg_down)
 }
 END_TEST
 
+START_TEST(touchpad_semi_mt_hover_2fg_up)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput *li = dev->libinput;
+
+   litest_touch_down(dev, 0, 70, 50);
+   litest_touch_down(dev, 1, 50, 50);
+
+   litest_push_event_frame(dev);
+   litest_touch_move(dev, 0, 72, 50);
+   litest_touch_move(dev, 1, 52, 50);
+   litest_event(dev, EV_KEY, BTN_TOUCH, 0);
+   litest_pop_event_frame(dev);
+
+   litest_event(dev, EV_ABS, ABS_MT_SLOT, 0);
+   litest_event(dev, EV_ABS, ABS_MT_TRACKING_ID, -1);
+   litest_event(dev, EV_ABS, ABS_MT_SLOT, 1);
+   litest_event(dev, EV_ABS, ABS_MT_TRACKING_ID, -1);
+   litest_event(dev, EV_KEY, BTN_TOOL_DOUBLETAP, 0);
+   litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+   litest_drain_events(li);
+}
+END_TEST
+
 START_TEST(touchpad_hover_noevent)
 {
struct litest_device *dev = litest_current_device();
@@ -3521,6 +3546,7 @@ litest_setup_tests(void)
litest_add_for_device("touchpad:semi-mt-hover", 
touchpad_semi_mt_hover_down_hover_down, LITEST_SYNAPTICS_HOVER_SEMI_MT);
litest_add_for_device("touchpad:semi-mt-hover", 
touchpad_semi_mt_hover_2fg_noevent, LITEST_SYNAPTICS_HOVER_SEMI_MT);
litest_add_for_device("touchpad:semi-mt-hover", 
touchpad_semi_mt_hover_2fg_1fg_down, LITEST_SYNAPTICS_HOVER_SEMI_MT);
+   litest_add_for_device("touchpad:semi-mt-hover", 
touchpad_semi_mt_hover_2fg_up, LITEST_SYNAPTICS_HOVER_SEMI_MT);
 
litest_add("touchpad:hover", touchpad_hover_noevent, 
LITEST_TOUCHPAD|LITEST_HOVER, LITEST_ANY);
litest_add("touchpad:hover", touchpad_hover_down, 
LITEST_TOUCHPAD|LITEST_HOVER, LITEST_ANY);
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/6] linux-dmabuf: Move the attributes part of linux_dmabuf_buffer into its own struct

[Derek Foreman]

On 24/11/15 01:28 PM, Emmanuel Gil Peyrot wrote:
> This allows renderers to use that struct to create their own dmabufs,
> in case they can’t import the one provided by the client directly but
> know how to convert it into a format they can render.
> 
> Signed-off-by: Emmanuel Gil Peyrot 
> Reviewed-by: Pekka Paalanen 
> Reviewed-by: Daniel Stone 

Me too, me too.

Reviewed-by: Derek Foreman 

And I'll push it.

> Differential Revision: https://phabricator.freedesktop.org/D332
> ---
>  src/compositor-drm.c | 12 +--
>  src/gl-renderer.c| 50 ++--
>  src/linux-dmabuf.c   | 58 
> ++--
>  src/linux-dmabuf.h   | 14 -
>  4 files changed, 69 insertions(+), 65 deletions(-)
> 
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index a84d869..55bc187 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -983,14 +983,14 @@ drm_output_prepare_overlay_view(struct drm_output 
> *output,
>* support a mix of gbm_bos and drmfbs.
>*/
>   struct gbm_import_fd_data gbm_dmabuf = {
> - .fd = dmabuf->dmabuf_fd[0],
> - .width  = dmabuf->width,
> - .height = dmabuf->height,
> - .stride = dmabuf->stride[0],
> - .format = dmabuf->format
> + .fd = dmabuf->attributes.fd[0],
> + .width  = dmabuf->attributes.width,
> + .height = dmabuf->attributes.height,
> + .stride = dmabuf->attributes.stride[0],
> + .format = dmabuf->attributes.format
>   };
>  
> - if (dmabuf->n_planes != 1 || dmabuf->offset[0] != 0)
> + if (dmabuf->attributes.n_planes != 1 || 
> dmabuf->attributes.offset[0] != 0)
>   return NULL;
>  
>   bo = gbm_bo_import(b->gbm, GBM_BO_IMPORT_FD, _dmabuf,
> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> index ae72f32..d5356b6 100644
> --- a/src/gl-renderer.c
> +++ b/src/gl-renderer.c
> @@ -1446,38 +1446,38 @@ import_dmabuf(struct gl_renderer *gr,
>*/
>  
>   attribs[atti++] = EGL_WIDTH;
> - attribs[atti++] = dmabuf->width;
> + attribs[atti++] = dmabuf->attributes.width;
>   attribs[atti++] = EGL_HEIGHT;
> - attribs[atti++] = dmabuf->height;
> + attribs[atti++] = dmabuf->attributes.height;
>   attribs[atti++] = EGL_LINUX_DRM_FOURCC_EXT;
> - attribs[atti++] = dmabuf->format;
> + attribs[atti++] = dmabuf->attributes.format;
>   /* XXX: Add modifier here when supported */
>  
> - if (dmabuf->n_planes > 0) {
> + if (dmabuf->attributes.n_planes > 0) {
>   attribs[atti++] = EGL_DMA_BUF_PLANE0_FD_EXT;
> - attribs[atti++] = dmabuf->dmabuf_fd[0];
> + attribs[atti++] = dmabuf->attributes.fd[0];
>   attribs[atti++] = EGL_DMA_BUF_PLANE0_OFFSET_EXT;
> - attribs[atti++] = dmabuf->offset[0];
> + attribs[atti++] = dmabuf->attributes.offset[0];
>   attribs[atti++] = EGL_DMA_BUF_PLANE0_PITCH_EXT;
> - attribs[atti++] = dmabuf->stride[0];
> + attribs[atti++] = dmabuf->attributes.stride[0];
>   }
>  
> - if (dmabuf->n_planes > 1) {
> + if (dmabuf->attributes.n_planes > 1) {
>   attribs[atti++] = EGL_DMA_BUF_PLANE1_FD_EXT;
> - attribs[atti++] = dmabuf->dmabuf_fd[1];
> + attribs[atti++] = dmabuf->attributes.fd[1];
>   attribs[atti++] = EGL_DMA_BUF_PLANE1_OFFSET_EXT;
> - attribs[atti++] = dmabuf->offset[1];
> + attribs[atti++] = dmabuf->attributes.offset[1];
>   attribs[atti++] = EGL_DMA_BUF_PLANE1_PITCH_EXT;
> - attribs[atti++] = dmabuf->stride[1];
> + attribs[atti++] = dmabuf->attributes.stride[1];
>   }
>  
> - if (dmabuf->n_planes > 2) {
> + if (dmabuf->attributes.n_planes > 2) {
>   attribs[atti++] = EGL_DMA_BUF_PLANE2_FD_EXT;
> - attribs[atti++] = dmabuf->dmabuf_fd[2];
> + attribs[atti++] = dmabuf->attributes.fd[2];
>   attribs[atti++] = EGL_DMA_BUF_PLANE2_OFFSET_EXT;
> - attribs[atti++] = dmabuf->offset[2];
> + attribs[atti++] = dmabuf->attributes.offset[2];
>   attribs[atti++] = EGL_DMA_BUF_PLANE2_PITCH_EXT;
> - attribs[atti++] = dmabuf->stride[2];
> + attribs[atti++] = dmabuf->attributes.stride[2];
>   }
>  
>   attribs[atti++] = EGL_NONE;
> @@ -1507,14 +1507,14 @@ gl_renderer_import_dmabuf(struct weston_compositor 
> *ec,
>  
>   assert(gr->has_dmabuf_import);
>  
> - for (i = 0; i < dmabuf->n_planes; i++) {
> + for (i = 0; i < dmabuf->attributes.n_planes; i++) {
>  

[PATCH libinput 2/3] test: if we're hovering, don't send BTN_TOUCH

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 test/litest.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/test/litest.c b/test/litest.c
index e235bc9..ba3a308 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -1317,9 +1317,9 @@ litest_auto_assign_value(struct litest_device *d,
 }
 
 static void
-send_btntool(struct litest_device *d)
+send_btntool(struct litest_device *d, bool hover)
 {
-   litest_event(d, EV_KEY, BTN_TOUCH, d->ntouches_down != 0);
+   litest_event(d, EV_KEY, BTN_TOUCH, d->ntouches_down != 0 && !hover);
litest_event(d, EV_KEY, BTN_TOOL_FINGER, d->ntouches_down == 1);
litest_event(d, EV_KEY, BTN_TOOL_DOUBLETAP, d->ntouches_down == 2);
litest_event(d, EV_KEY, BTN_TOOL_TRIPLETAP, d->ntouches_down == 3);
@@ -1340,7 +1340,7 @@ litest_slot_start(struct litest_device *d,
assert(d->ntouches_down >= 0);
d->ntouches_down++;
 
-   send_btntool(d);
+   send_btntool(d, !touching);
 
if (d->interface->touch_down) {
d->interface->touch_down(d, slot, x, y);
@@ -1395,7 +1395,7 @@ litest_touch_up(struct litest_device *d, unsigned int 
slot)
litest_assert_int_gt(d->ntouches_down, 0);
d->ntouches_down--;
 
-   send_btntool(d);
+   send_btntool(d, false);
 
if (d->interface->touch_up) {
d->interface->touch_up(d, slot);
@@ -1559,7 +1559,7 @@ litest_hover_end(struct litest_device *d, unsigned int 
slot)
litest_assert_int_gt(d->ntouches_down, 0);
d->ntouches_down--;
 
-   send_btntool(d);
+   send_btntool(d, true);
 
if (d->interface->touch_up) {
d->interface->touch_up(d, slot);
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 3/8] tablet: drop pressure when either pressure or distance changed

[Peter Hutterer]

On Wed, Dec 02, 2015 at 10:22:56AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 02-12-15 02:46, Peter Hutterer wrote:
> >Keep pressure and distance mutually exclusive regardless which one of the two
> >updates.
> >
> >Signed-off-by: Peter Hutterer 
> >---
> >  src/evdev-tablet.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> >index 82029a9..395cbef 100644
> >--- a/src/evdev-tablet.c
> >+++ b/src/evdev-tablet.c
> >@@ -853,7 +853,8 @@ sanitize_tablet_axes(struct tablet_dispatch *tablet)
> > pressure = libevdev_get_abs_info(tablet->device->evdev, ABS_PRESSURE);
> >
> > /* Keep distance and pressure mutually exclusive */
> >-if (bit_is_set(tablet->changed_axes, 
> >LIBINPUT_TABLET_TOOL_AXIS_DISTANCE) &&
> >+if ((bit_is_set(tablet->changed_axes, 
> >LIBINPUT_TABLET_TOOL_AXIS_DISTANCE) ||
> >+ bit_is_set(tablet->changed_axes, 
> >LIBINPUT_TABLET_TOOL_AXIS_DISTANCE)) &&
> 
> Your checking the same bit twice here, I believe you need to 
> s/DISTANCE/PRESSURE/
> in the second check.
> 
> The rest of the series looks good, so the series, and this one with this 
> fixed is:
> 
> Reviewed-by: Hans de Goede 

whoops, thanks. I had to also modify the condition to 
if (distance &&


since some tablets don't have distance, which was previously papered over by
the changed_axis bit never being set.

thanks for the review

Cheers,
   Peter

> 
> > distance->value > distance->minimum &&
> > pressure->value > pressure->minimum) {
> > clear_bit(tablet->changed_axes, 
> > LIBINPUT_TABLET_TOOL_AXIS_DISTANCE);
> >
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] xdg-shell: Bump unstable version to 6

[Mike Blumenkrantz]

On Wed, 02 Dec 2015 20:03:27 -0500
Mike Blumenkrantz  wrote:

> This copies the version 5 of the XML to a new version 6 version, while
> at the same time the interface names are changed to use the unstable
> naming convention.
> 
> A whitespace cleanup was done as no git-blame:ability would be lost
> anyway.
> 
> Reviewed-by: Mike Blumenkrantz 
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am  |   1 +
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624
> +++ 2 files changed, 625 insertions(+)
>  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 5926a41..4a2974d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5,6 +5,7 @@ unstable_protocols
> = \
> unstable/text-input/text-input-unstable-v1.xml
> \
> unstable/input-method/input-method-unstable-v1.xml
> \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml
> \
> +
> unstable/xdg-shell/xdg-shell-unstable-v6.xml
> \ $(NULL) 
>  nobase_dist_pkgdata_DATA
> = \ diff --git
> a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml new file mode 100644
> index 000..196c332 --- /dev/null
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -0,0 +1,624 @@
> +
> +
> +
> +  
> +Copyright © 2008-2013 Kristian Høgsberg
> +Copyright © 2013  Rafael Antognolli
> +Copyright © 2013  Jasper St. Pierre
> +Copyright © 2010-2013 Intel Corporation
> +
> +Permission is hereby granted, free of charge, to any person
> obtaining a
> +copy of this software and associated documentation files (the
> "Software"),
> +to deal in the Software without restriction, including without
> limitation
> +the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> +and/or sell copies of the Software, and to permit persons to whom
> the
> +Software is furnished to do so, subject to the following
> conditions: +
> +The above copyright notice and this permission notice (including
> the next
> +paragraph) shall be included in all copies or substantial portions
> of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
> OR OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  xdg_shell allows clients to turn a wl_surface into a "real
> window"
> +  which can be dragged, resized, stacked, and moved around by the
> +  user. Everything about this interface is suited towards
> traditional
> +  desktop environments.
> +
> +
> +
> +  
> + The 'current' member of this enum gives the version of the
> + protocol.  Implementations can compare this to the version
> + they implement using static_assert to ensure the protocol and
> + implementation versions match.
> +  
> +  
> +
> +
> +
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> + Destroy this xdg_shell object.
> +
> + Destroying a bound xdg_shell object while there are surfaces
> + still alive created by this xdg_shell object instance is
> illegal
> + and will result in a protocol error.
> +  
> +
> +
> +
> +  
> + Negotiate the unstable version of the interface.  This
> + mechanism is in place to ensure client and server agree on the
> + unstable versions of the protocol that they speak or exit
> + cleanly if they don't agree.  This request will go away once
> + the xdg-shell protocol is stable.
> +  
> +  
> +
> +
> +
> +  
> + This creates an xdg_surface for the given surface and gives it
> the
> + xdg_surface role. A wl_surface can only be given an
> xdg_surface role
> + once. If get_xdg_surface is called with a wl_surface that
> already has
> + an active xdg_surface associated with it, or if it had any
> other role,
> + an error is raised.
> +
> + See the documentation of xdg_surface for more details about
> what an
> + xdg_surface is and how it is used.
> +  
> +  
> +  
> +
> +
> +
> +  
> + This creates an xdg_popup for the given surface and gives it
> the
> + xdg_popup role. A wl_surface can only be given an xdg_popup
> role
> + once. If get_xdg_popup is called with a wl_surface that
> already has
> + an active xdg_popup associated with it, or if it had any other
> 

[PATCH 1/2] xdg-shell: Bump unstable version to 6

[Mike Blumenkrantz]

This copies the version 5 of the XML to a new version 6 version, while
at the same time the interface names are changed to use the unstable
naming convention.

A whitespace cleanup was done as no git-blame:ability would be lost
anyway.

Reviewed-by: Mike Blumenkrantz 
Signed-off-by: Jonas Ådahl 
---
 Makefile.am  |   1 +
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624 +++
 2 files changed, 625 insertions(+)
 create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml

diff --git a/Makefile.am b/Makefile.am
index 5926a41..4a2974d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@ unstable_protocols =
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
+   unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
$(NULL)
 
 nobase_dist_pkgdata_DATA = 
\
diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
new file mode 100644
index 000..196c332
--- /dev/null
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -0,0 +1,624 @@
+
+
+
+  
+Copyright © 2008-2013 Kristian Høgsberg
+Copyright © 2013  Rafael Antognolli
+Copyright © 2013  Jasper St. Pierre
+Copyright © 2010-2013 Intel Corporation
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  xdg_shell allows clients to turn a wl_surface into a "real window"
+  which can be dragged, resized, stacked, and moved around by the
+  user. Everything about this interface is suited towards traditional
+  desktop environments.
+
+
+
+  
+   The 'current' member of this enum gives the version of the
+   protocol.  Implementations can compare this to the version
+   they implement using static_assert to ensure the protocol and
+   implementation versions match.
+  
+  
+
+
+
+  
+  
+  
+  
+
+
+
+  
+   Destroy this xdg_shell object.
+
+   Destroying a bound xdg_shell object while there are surfaces
+   still alive created by this xdg_shell object instance is illegal
+   and will result in a protocol error.
+  
+
+
+
+  
+   Negotiate the unstable version of the interface.  This
+   mechanism is in place to ensure client and server agree on the
+   unstable versions of the protocol that they speak or exit
+   cleanly if they don't agree.  This request will go away once
+   the xdg-shell protocol is stable.
+  
+  
+
+
+
+  
+   This creates an xdg_surface for the given surface and gives it the
+   xdg_surface role. A wl_surface can only be given an xdg_surface role
+   once. If get_xdg_surface is called with a wl_surface that already has
+   an active xdg_surface associated with it, or if it had any other role,
+   an error is raised.
+
+   See the documentation of xdg_surface for more details about what an
+   xdg_surface is and how it is used.
+  
+  
+  
+
+
+
+  
+   This creates an xdg_popup for the given surface and gives it the
+   xdg_popup role. A wl_surface can only be given an xdg_popup role
+   once. If get_xdg_popup is called with a wl_surface that already has
+   an active xdg_popup associated with it, or if it had any other role,
+   an error is raised.
+
+   This request must be used in response to some sort of user action
+   like a button press, key press, or touch down event.
+
+   See the documentation 

[PATCH 2/2] xdg-shell: clarify xdg_surface creation semantics regarding buffers

[Mike Blumenkrantz]

this change ensures that the client will set its initial state
before performing any drawing, ensuring that there is no mismatch
when creating a surface with a non-default state
(eg. maximize, fullscreen, ...)

looking at the following event flows:
1) wl_surface.attach, wl_surface.commit, xdg_shell.get_xdg_surface

2) wl_surface.attach, xdg_shell.get_xdg_surface, wl_surface.commit

3) xdg_shell.get_xdg_surface, wl_surface.commit, xdg_surface.configure,
   wl_surface.attach, wl_surface.commit

only 3) is now valid, while 1) and 2) will trigger errors as a result
of handling buffers prior to creating the xdg surface

Reviewed-by: Jasper St. Pierre 
Signed-off-by: Mike Blumenkrantz 
Signed-off-by: Jonas Ådahl 
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 196c332..a03a615 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -147,14 +147,12 @@
   them, and associate metadata like title and app id.
 
   The client must call wl_surface.commit on the corresponding wl_surface
-  for the xdg_surface state to take effect. Prior to committing the new
-  state, it can set up initial configuration, such as maximizing or setting
-  a window geometry.
-
-  Even without attaching a buffer the compositor must respond to initial
-  committed configuration, for instance sending a configure event with
-  expected window geometry if the client maximized its surface during
-  initialization.
+  for the xdg_surface state to take effect.
+
+  Creating an xdg_surface from a wl_surface which has a buffer attached or
+  committed is a client error, and any attempts by a client to attach or
+  manipulate a buffer prior to the first xdg_surface.configure call must
+  also be treated as errors.
 
   For a surface to be mapped by the compositor the client must have
   committed both an xdg_surface state and a buffer.
-- 
2.4.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets

[Jason Gerecke]

On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer  wrote:
> If a tool wears out, it may have a pre-loaded pressure offset. In that case,
> even when the tool is not physically in contact with the tablet surface it
> will send pressure events.
>
> The X.Org wacom driver has automatic pressure preload detection, but it is
> unreliable. A quick tap can trigger the detection, making the pen unusable
> (see xf86-input-wacom-0.23.0-43-g10cc765).
>
> Since this is a hardware-specific property, add a new udev property with the
> prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through the
> hwdb or some other process. Use the value of this property to offset any
> incoming pressure values and scale into the original normalized axis range.
>
> Signed-off-by: Peter Hutterer 

I've been asked by Ping (who is going to be OOO for the next few days)
to try and express some of her concerns about how libinput will handle
pen pressure. The two of us have had some lengthy discussions, and
though I'm not sure I agree on all points, I'll try to argue them as
best I can.

The idea behind the X driver's automatic preload detection was to
provide a way to handle the pen-specific pressure offsets without
requiring the user to configure or calibrate anything. The minimum
pressure seen from a pen is a fairly reliable measure of the offset,
and the X driver attempts to measure this as the pen hovers in
proximity. This works well in most circumstances, but obviously fails
if the pen is "stabbed" at the tablet so quickly that it comes into
contact before it can report an unloaded pressure value. This kind of
wanton hardware abuse isn't something we encourage ;)

Making the pressure offset a configuration option like you propose
here doesn't suffer from mis-detection, but does require the user to
periodically run a tool to update the UDEV HWDB. Updates to the DB
won't take immediate effect[1], won't propagate across systems[2], and
are incapable of distinguishing between tools without a serial number.

One change that could be made to the automatic method that would make
it a bit more reliable would be to define a maximum pressure that it
would consider to be a sane preload. A 'stabbed' pen would almost
certainly overshoot the ceiling and we could simply assume an
arbitrary preload of our choosing (zero? the ceiling?). A very light
'stab' could still cause issues, but its quite difficult to both move
the pen quickly enough to enter and exit prox at a high enough speed
to not get an unloaded pressure reading *and* only lightly come into
contact with the surface.


A second issue that Ping brought up is the tying of pressure
information to the "down" state (patch 4). Its possible that a user
would want to have the maximum possible dynamic range for pressure
(after accounting for the preload) in a drawing app so that the
lightest strokes were useful, while simultaneously wanting UI elements
like buttons and menus to only respond to more deliberate (and
high-pressure) pen events. In terms of protocol and library, this
would mean allowing applications to see non-zero pressure values even
before the pen is "down". If we want to do this, we would have to be
very deliberate in documenting that the behavior so that programmers
understand the pressure data is useful and should not be discarded (or
if absolutely necessary, rescaled so that the click threshold is
reported as 0 pressure). Right now I don't think any toolkits or
applications make use of pressure prior to click, though TBH I haven't
actually checked...


[1]: I know you can use `udevadm --reload`, but that doesn't affect
already-connected devices
[2]: The automatic detection doesn't require re-calibrating a pen on
every system its used on

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours

> ---
>  doc/device-configuration-via-udev.dox|   4 +
>  doc/tablet-support.dox   |  30 ++
>  src/evdev-tablet.c   |  71 +-
>  src/libinput-private.h   |   2 +
>  test/litest-device-wacom-intuos-tablet.c |  12 +++
>  test/tablet.c| 155 
> ++-
>  6 files changed, 270 insertions(+), 4 deletions(-)
>
> diff --git a/doc/device-configuration-via-udev.dox 
> b/doc/device-configuration-via-udev.dox
> index f615cc1..ba44e58 100644
> --- a/doc/device-configuration-via-udev.dox
> +++ b/doc/device-configuration-via-udev.dox
> @@ -63,6 +63,10 @@ libinput_pointer_get_axis_source() for details.
>  POINTINGSTICK_CONST_ACCEL
>  A constant (linear) acceleration factor to apply to pointingstick deltas
>  to normalize them.
> +TABLET_TOOL_PRESSURE_OFFSET_*
> +Specifies the pressure offset in device coordinates for the tool whose
> +name is given as part of the 

[PATCH 1/2] xdg-shell: Bump unstable version to 6

[Mike Blumenkrantz]

This copies the version 5 of the XML to a new version 6 version, while
at the same time the interface names are changed to use the unstable
naming convention.

A whitespace cleanup was done as no git-blame:ability would be lost
anyway.

Reviewed-by: Mike Blumenkrantz 
Signed-off-by: Jonas Ådahl 
---
 Makefile.am  |   1 +
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624
+++ 2 files changed, 625 insertions(+)
 create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml

diff --git a/Makefile.am b/Makefile.am
index 5926a41..4a2974d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@ unstable_protocols
=   \
unstable/text-input/text-input-unstable-v1.xml
\
unstable/input-method/input-method-unstable-v1.xml
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
+
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\ $(NULL) 
 nobase_dist_pkgdata_DATA
=   \ diff --git
a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml new file mode 100644
index 000..196c332 --- /dev/null
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -0,0 +1,624 @@
+
+
+
+  
+Copyright © 2008-2013 Kristian Høgsberg
+Copyright © 2013  Rafael Antognolli
+Copyright © 2013  Jasper St. Pierre
+Copyright © 2010-2013 Intel Corporation
+
+Permission is hereby granted, free of charge, to any person
obtaining a
+copy of this software and associated documentation files (the
"Software"),
+to deal in the Software without restriction, including without
limitation
+the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+and/or sell copies of the Software, and to permit persons to whom
the
+Software is furnished to do so, subject to the following
conditions: +
+The above copyright notice and this permission notice (including
the next
+paragraph) shall be included in all copies or substantial portions
of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  xdg_shell allows clients to turn a wl_surface into a "real
window"
+  which can be dragged, resized, stacked, and moved around by the
+  user. Everything about this interface is suited towards
traditional
+  desktop environments.
+
+
+
+  
+   The 'current' member of this enum gives the version of the
+   protocol.  Implementations can compare this to the version
+   they implement using static_assert to ensure the protocol and
+   implementation versions match.
+  
+  
+
+
+
+  
+  
+  
+  
+
+
+
+  
+   Destroy this xdg_shell object.
+
+   Destroying a bound xdg_shell object while there are surfaces
+   still alive created by this xdg_shell object instance is
illegal
+   and will result in a protocol error.
+  
+
+
+
+  
+   Negotiate the unstable version of the interface.  This
+   mechanism is in place to ensure client and server agree on the
+   unstable versions of the protocol that they speak or exit
+   cleanly if they don't agree.  This request will go away once
+   the xdg-shell protocol is stable.
+  
+  
+
+
+
+  
+   This creates an xdg_surface for the given surface and gives it
the
+   xdg_surface role. A wl_surface can only be given an
xdg_surface role
+   once. If get_xdg_surface is called with a wl_surface that
already has
+   an active xdg_surface associated with it, or if it had any
other role,
+   an error is raised.
+
+   See the documentation of xdg_surface for more details about
what an
+   xdg_surface is and how it is used.
+  
+  
+  
+
+
+
+  
+   This creates an xdg_popup for the given surface and gives it
the
+   xdg_popup role. A wl_surface can only be given an xdg_popup
role
+   once. If get_xdg_popup is called with a wl_surface that
already has
+   an active xdg_popup associated with it, or if it had any other
role,
+   an error is raised.
+
+   This request must be used in response to some sort of user
action
+   like a button press, key press, or touch down event.
+
+   See the documentation of xdg_popup for more details about what
an
+   xdg_popup is and how it is used.
+  
+  
+  
+  
+  
+  
+  
+ 

Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets

[Peter Hutterer]

On Wed, Dec 02, 2015 at 04:21:56PM -0800, Jason Gerecke wrote:
> On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer  
> wrote:
> > If a tool wears out, it may have a pre-loaded pressure offset. In that case,
> > even when the tool is not physically in contact with the tablet surface it
> > will send pressure events.
> >
> > The X.Org wacom driver has automatic pressure preload detection, but it is
> > unreliable. A quick tap can trigger the detection, making the pen unusable
> > (see xf86-input-wacom-0.23.0-43-g10cc765).
> >
> > Since this is a hardware-specific property, add a new udev property with the
> > prefix TABLET_TOOL_PRESSURE_OFFSET_ and let it be set system-wide through 
> > the
> > hwdb or some other process. Use the value of this property to offset any
> > incoming pressure values and scale into the original normalized axis range.
> >
> > Signed-off-by: Peter Hutterer 
> 
> I've been asked by Ping (who is going to be OOO for the next few days)
> to try and express some of her concerns about how libinput will handle
> pen pressure. The two of us have had some lengthy discussions, and
> though I'm not sure I agree on all points, I'll try to argue them as
> best I can.
> 
> The idea behind the X driver's automatic preload detection was to
> provide a way to handle the pen-specific pressure offsets without
> requiring the user to configure or calibrate anything. The minimum
> pressure seen from a pen is a fairly reliable measure of the offset,
> and the X driver attempts to measure this as the pen hovers in
> proximity. This works well in most circumstances, but obviously fails
> if the pen is "stabbed" at the tablet so quickly that it comes into
> contact before it can report an unloaded pressure value. This kind of
> wanton hardware abuse isn't something we encourage ;)
> 
> Making the pressure offset a configuration option like you propose
> here doesn't suffer from mis-detection, but does require the user to
> periodically run a tool to update the UDEV HWDB. Updates to the DB
> won't take immediate effect[1], won't propagate across systems[2], and
> are incapable of distinguishing between tools without a serial number.

a couple of questions here:
* how common is this pressure preload?
* does it affect all pens or only specific pens?
* is there a maximum observed threshold for this pen preload? 

The last one is specifically: is there a point where we can throw up our
hands and tell the user to just buy a new pen rather than needing automatic
detection *and* the udev property for anything that exceeds that threshold?
 
> One change that could be made to the automatic method that would make
> it a bit more reliable would be to define a maximum pressure that it
> would consider to be a sane preload. A 'stabbed' pen would almost
> certainly overshoot the ceiling and we could simply assume an
> arbitrary preload of our choosing (zero? the ceiling?). A very light
> 'stab' could still cause issues, but its quite difficult to both move
> the pen quickly enough to enter and exit prox at a high enough speed
> to not get an unloaded pressure reading *and* only lightly come into
> contact with the surface.

at least on the tablets that do distance we can combine the maximum pressure
threshold with the distance measurement. It's harder to do that on tablets
without distance though.

> A second issue that Ping brought up is the tying of pressure
> information to the "down" state (patch 4). Its possible that a user
> would want to have the maximum possible dynamic range for pressure
> (after accounting for the preload) in a drawing app so that the
> lightest strokes were useful, while simultaneously wanting UI elements
> like buttons and menus to only respond to more deliberate (and
> high-pressure) pen events. In terms of protocol and library, this
> would mean allowing applications to see non-zero pressure values even
> before the pen is "down". If we want to do this, we would have to be
> very deliberate in documenting that the behavior so that programmers
> understand the pressure data is useful and should not be discarded (or
> if absolutely necessary, rescaled so that the click threshold is
> reported as 0 pressure). Right now I don't think any toolkits or
> applications make use of pressure prior to click, though TBH I haven't
> actually checked...

long-term I want the tip down/up to match a distance 0 and have anything
with distance not send any pressure. The current BTN_TOUCH handling isn't
ideal because it discards lower pressure values, I think we should use a
libinput-internal pressure threshold here and fake the BTN_TOUCH based on
that. And the range between max(threshold, preload)-axis_max will then be
mapped into the normalised range.

So the logic will likely be tilted towards the pressure, with finer-grained
distance measuring:
* if the distance > threshold and pressure != 0 -> pressure preload
* if the distance < other threshold and 

Re: [PATCH 1/2] xdg-shell: Bump unstable version to 6

[Jonas Ådahl]

On Wed, Dec 02, 2015 at 06:31:48PM -0800, Jasper St. Pierre wrote:
> While we're doing this, can we remove the use_unstable_version request?

Good point. Will send a patch.


Jonas

> 
> On Wed, Dec 2, 2015 at 5:06 PM, Mike Blumenkrantz  wrote:
> > This copies the version 5 of the XML to a new version 6 version, while
> > at the same time the interface names are changed to use the unstable
> > naming convention.
> >
> > A whitespace cleanup was done as no git-blame:ability would be lost
> > anyway.
> >
> > Reviewed-by: Mike Blumenkrantz 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  Makefile.am  |   1 +
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624 
> > +++
> >  2 files changed, 625 insertions(+)
> >  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 5926a41..4a2974d 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -5,6 +5,7 @@ unstable_protocols =
> > \
> > unstable/text-input/text-input-unstable-v1.xml  
> > \
> > unstable/input-method/input-method-unstable-v1.xml  
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > \
> > +   unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > \
> > $(NULL)
> >
> >  nobase_dist_pkgdata_DATA = 
> > \
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > new file mode 100644
> > index 000..196c332
> > --- /dev/null
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -0,0 +1,624 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2008-2013 Kristian Høgsberg
> > +Copyright © 2013  Rafael Antognolli
> > +Copyright © 2013  Jasper St. Pierre
> > +Copyright © 2010-2013 Intel Corporation
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +copy of this software and associated documentation files (the 
> > "Software"),
> > +to deal in the Software without restriction, including without 
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute, 
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to whom the
> > +Software is furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice (including the 
> > next
> > +paragraph) shall be included in all copies or substantial portions of 
> > the
> > +Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > EXPRESS OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > SHALL
> > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > +DEALINGS IN THE SOFTWARE.
> > +  
> > +
> > +  
> > +
> > +  xdg_shell allows clients to turn a wl_surface into a "real window"
> > +  which can be dragged, resized, stacked, and moved around by the
> > +  user. Everything about this interface is suited towards traditional
> > +  desktop environments.
> > +
> > +
> > +
> > +  
> > +   The 'current' member of this enum gives the version of the
> > +   protocol.  Implementations can compare this to the version
> > +   they implement using static_assert to ensure the protocol and
> > +   implementation versions match.
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   Destroy this xdg_shell object.
> > +
> > +   Destroying a bound xdg_shell object while there are surfaces
> > +   still alive created by this xdg_shell object instance is illegal
> > +   and will result in a protocol error.
> > +  
> > +
> > +
> > +
> > +  
> > +   Negotiate the unstable version of the interface.  This
> > +   mechanism is in place to ensure client and server agree on the
> > +   unstable versions of the protocol that they speak or exit
> > +   cleanly if they don't agree.  This request will go away once
> > +   the xdg-shell protocol is stable.
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   This creates an xdg_surface for the given surface and gives it the
> > +   xdg_surface role. A wl_surface can only be given an xdg_surface role
> > +   once. If get_xdg_surface is called with a 

[PATCH wayland-protocols] xdg-shell: Remove the old unstable version enum and request

[Jonas Ådahl]

As of version 6, the new unstable protocol discovery semantics are
used, so lets remove the enum and request that made up the old one.

Signed-off-by: Jonas Ådahl 
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 21 -
 1 file changed, 21 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 196c332..2ad6d1d 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -35,16 +35,6 @@
   desktop environments.
 
 
-
-  
-   The 'current' member of this enum gives the version of the
-   protocol.  Implementations can compare this to the version
-   they implement using static_assert to ensure the protocol and
-   implementation versions match.
-  
-  
-
-
 
   
   
@@ -62,17 +52,6 @@
   
 
 
-
-  
-   Negotiate the unstable version of the interface.  This
-   mechanism is in place to ensure client and server agree on the
-   unstable versions of the protocol that they speak or exit
-   cleanly if they don't agree.  This request will go away once
-   the xdg-shell protocol is stable.
-  
-  
-
-
 
   
This creates an xdg_surface for the given surface and gives it the
-- 
2.4.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol

[Jonas Ådahl]

This patch introduces a new protocol for locking and 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 to a
given region.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Peter Hutterer 
Reviewed-by: Derek Foreman 
---

Hi,

Sending these two to the list again to get people a chance to look at the
introductory descriptions added in this version. I also noticed I had
missed adding a destructor to the global in this protocol, so please be
aware.

No need for the ones who already gave their RBs to re-give, and I will push
these two patches in a couple of days if noone objects.

To get an up to date version of the weston patches, please use the
wip/pointer-constraints branch on g...@github.com:jadahl/weston.git
repository.


Changes since v1:

Added an introduction description.

Fixed documentation issues brought up during review.

Added a destroy request on the global interface.


Jonas


 Makefile.am|   1 +
 unstable/pointer-constraints/README|   4 +
 .../pointer-constraints-unstable-v1.xml| 308 +
 3 files changed, 313 insertions(+)
 create mode 100644 unstable/pointer-constraints/README
 create mode 100644 
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e3b60ad..44041a6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6,6 +6,7 @@ unstable_protocols =
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
+   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
\
$(NULL)
 
 nobase_dist_pkgdata_DATA = 
\
diff --git a/unstable/pointer-constraints/README 
b/unstable/pointer-constraints/README
new file mode 100644
index 000..8a242f8
--- /dev/null
+++ b/unstable/pointer-constraints/README
@@ -0,0 +1,4 @@
+Pointer constraints protocol
+
+Maintainers:
+Jonas Ådahl 
diff --git a/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml 
b/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
new file mode 100644
index 000..3d9719b
--- /dev/null
+++ b/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
@@ -0,0 +1,308 @@
+
+
+
+  
+This protocol specifies a set of interfaces used for adding constraints to
+the motion of a pointer. Possible constraints include confining pointer
+motions to a given region, or locking it to its current position.
+
+In order to contrain the pointer, a client must first bind the global
+interface "wp_pointer_constraints" which, if a compositor supports pointer
+constraints, is exposed by the registry. Using the bound global object, the
+client uses the request that corresponds to the type of constraint it wants
+to make. See wp_pointer_constraints for more details.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump.  Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version.  Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+
+  
+Copyright © 2014  Jonas Ådahl
+Copyright © 2015  Red Hat Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE 

[PATCH wayland-protocols v2 1/2] Introduce wp_relative_pointer interface

[Jonas Ådahl]

The wp_relative_pointer interface is an extension to the wl_pointer
interface created from wl_seat. It has the same focus, but adds the
functionality of sending relative pointer motions unhindered by
constraints such as monitor edges or other barriers. It also contains
unaccelerated pointer motion information.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Peter Hutterer 
Reviewed-by: Derek Foreman 
---

Changes since v1:

Added introduction description.

Fixed documentation issues brought up during review.


Jonas


 Makefile.am|   1 +
 unstable/relative-pointer/README   |   4 +
 .../relative-pointer-unstable-v1.xml   | 138 +
 3 files changed, 143 insertions(+)
 create mode 100644 unstable/relative-pointer/README
 create mode 100644 unstable/relative-pointer/relative-pointer-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 5926a41..e3b60ad 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@ unstable_protocols =
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
+   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
$(NULL)
 
 nobase_dist_pkgdata_DATA = 
\
diff --git a/unstable/relative-pointer/README b/unstable/relative-pointer/README
new file mode 100644
index 000..64c42a1
--- /dev/null
+++ b/unstable/relative-pointer/README
@@ -0,0 +1,4 @@
+Relative pointer protocol
+
+Maintainers:
+Jonas Ådahl 
diff --git a/unstable/relative-pointer/relative-pointer-unstable-v1.xml 
b/unstable/relative-pointer/relative-pointer-unstable-v1.xml
new file mode 100644
index 000..df85352
--- /dev/null
+++ b/unstable/relative-pointer/relative-pointer-unstable-v1.xml
@@ -0,0 +1,138 @@
+
+
+
+  
+This protocol specifies a set of interfaces used for making clients able to
+receive relative pointer events not obstructed by barriers (such as the
+monitor edge or other pointer barriers).
+
+To start receiving relative pointer events, a client must first bind the
+global interface "wp_relative_pointer_manager" which, if a compositor
+supports relative pointer motion events, is exposed by the registry. After
+having created the relative pointer manager proxy object, the client uses
+it to create the actual relative pointer object using the
+"get_relative_pointer" request given a wl_pointer. The relative pointer
+motion events will then, when applicable, be transmitted via the proxy of
+the newly created relative pointer object. See the documentation of the
+relative pointer interface for more details.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump.  Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version.  Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+
+  
+Copyright © 2014  Jonas Ådahl
+Copyright © 2015  Red Hat Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  A global interface used for getting the relative pointer object for a
+  given pointer.
+
+
+
+  
+   Used by the client to notify the server that it 

Re: [PATCH wayland] protocol: specify behavior of get_pointer when capabilities change

[Jonas Ådahl]

On Wed, Dec 02, 2015 at 02:44:02PM +, Daniel Stone wrote:
> Hi,
> 
> On 2 December 2015 at 03:04, Bill Spitzak  wrote:
> > On Mon, Nov 30, 2015 at 3:32 PM, Peter Hutterer 
> > wrote:
> >> On Mon, Nov 30, 2015 at 09:46:36PM +, Daniel Stone wrote:
> >>
> >> > > +   If a seat regains the pointer capability and a client has a
> >> > > pointer
> >> > > +   object obtained previously, that object may start sending
> >> > > pointer
> >> > > +   events. This behavior is implementation-dependent and must not
> >> > > be
> >> > > +   relied upon.
> >> >
> >> > Urgh, I don't really like having this there as a bit of a get-out
> >> > clause. Can we just strengthen the 'client should destroy the
> >> > wl_pointer objects' to a 'must'? Especially since this paragraph
> >> > contradicts the immediately previous one ('No further pointer events
> >> > will be received on these objects'). Maybe we could fold bits of this
> >> > paragraph in to replace that problematic sentence, but couple with a
> >> > recommendation that compositors should not send events to stale
> >> > objects - and bump that to a must for compositors advertising whatever
> >> > our next version of wl_seat ends up being.
> >>
> >> if the per-version behaviour works correctly we can add this, otherwise we
> >> still have to keep this paragraph in, otherwise we're retroactively
> >> disallowing current working implementations. The same goes for the
> >> should/must, we already have implementations doing this.
> >
> > I don't think you want this text. An existing implementation that sends
> > pointer events after the loss/gain is broken. People wrote lots of other
> > bugs into existing implementations, that does not mean all descriptions have
> > to allow any existing bug.
> 
> 'Broken' is subjective; certainly had we specified from the beginning
> that it must not happen, they would be objectively broken.
> 'Undesirable behaviour' is pretty clear in this case, but when we're
> talking about compliance to a spec which was silent on the matter ...
> 
> > A more practical reason for being more insistent is that if a popular
> > compositor does this, it is quite likely to be relied on by some clients
> > (due to the fact that it is much easier to write a client that relies on
> > this), quickly leading to this being a required behaviour of all
> > compositors.
> 
> Yeah, exactly this. If it turns out that no serious client (so, not
> toytoolkit) relies on this, then brilliant. If we're banning
> compositors from implementing behaviour that real-world clients rely
> on, then not so great.

How do we determine the list of serious enough real-world clients?

Are proprietary clients shipped in various places using Wayland serious?
We can't check those very easily.


Jonas

> 
> Cheers,
> Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/6] gl-renderer: introduce a new struct dmabuf_image

[Derek Foreman]

On 24/11/15 01:28 PM, Emmanuel Gil Peyrot wrote:
> This struct serves as renderer data for linux-dmabuf buffers, and can
> contain multiple struct egl_image, simplifying this latter in the
> common non-dmabuf case.
> 
> Signed-off-by: Emmanuel Gil Peyrot 
> Reviewed-by: Pekka Paalanen 
> Reviewed-by: Daniel Stone 
> 
> Differential Revision: https://phabricator.freedesktop.org/D333
> ---
>  src/gl-renderer.c | 167 
> +++---
>  1 file changed, 109 insertions(+), 58 deletions(-)
> 
> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> index d5356b6..90e4842 100644
> --- a/src/gl-renderer.c
> +++ b/src/gl-renderer.c
> @@ -99,9 +99,12 @@ struct egl_image {
>   struct gl_renderer *renderer;
>   EGLImageKHR image;
>   int refcount;
> +};
>  
> - /* Only used for dmabuf imported buffer */
> +struct dmabuf_image {
>   struct linux_dmabuf_buffer *dmabuf;
> + int num_images;
> + struct egl_image *images[3];
>   struct wl_list link;
>  };
>  
> @@ -191,6 +194,13 @@ struct gl_renderer {
>  
>  static PFNEGLGETPLATFORMDISPLAYEXTPROC get_platform_display = NULL;
>  
> +static inline const char *
> +dump_format(uint32_t *format)
> +{
> + // FIXME: this won’t work properly on big-endian.

Tiny style complaint, we don't use c++ style comments in weston...

This whole function's pretty scary really - I realize it's just an error
log and it's very hard to hit, but it seems like it's pretty simple to
just fix the FIXME and do it "right"?

Other than that, the important parts look correct, so with this bit fixed,

Reviewed-by: Derek Foreman 
> + return (const char *)format;
> +}
> +
>  static inline struct gl_output_state *
>  get_output_state(struct weston_output *output)
>  {
> @@ -222,7 +232,6 @@ egl_image_create(struct gl_renderer *gr, EGLenum target,
>   struct egl_image *img;
>  
>   img = zalloc(sizeof *img);
> - wl_list_init(>link);
>   img->renderer = gr;
>   img->refcount = 1;
>   img->image = gr->create_image(gr->egl_display, EGL_NO_CONTEXT,
> @@ -255,16 +264,37 @@ egl_image_unref(struct egl_image *image)
>   if (image->refcount > 0)
>   return image->refcount;
>  
> - if (image->dmabuf)
> - linux_dmabuf_buffer_set_user_data(image->dmabuf, NULL, NULL);
> -
>   gr->destroy_image(gr->egl_display, image->image);
> - wl_list_remove(>link);
>   free(image);
>  
>   return 0;
>  }
>  
> +static struct dmabuf_image*
> +dmabuf_image_create(void)
> +{
> + struct dmabuf_image *img;
> +
> + img = zalloc(sizeof *img);
> + wl_list_init(>link);
> +
> + return img;
> +}
> +
> +static void
> +dmabuf_image_destroy(struct dmabuf_image *image)
> +{
> + int i;
> +
> + for (i = 0; i < image->num_images; ++i)
> + egl_image_unref(image->images[i]);
> +
> + if (image->dmabuf)
> + linux_dmabuf_buffer_set_user_data(image->dmabuf, NULL, NULL);
> +
> + wl_list_remove(>link);
> +}
> +
>  static const char *
>  egl_error_string(EGLint code)
>  {
> @@ -1420,23 +1450,19 @@ gl_renderer_attach_egl(struct weston_surface *es, 
> struct weston_buffer *buffer,
>  static void
>  gl_renderer_destroy_dmabuf(struct linux_dmabuf_buffer *dmabuf)
>  {
> - struct egl_image *image = dmabuf->user_data;
> + struct dmabuf_image *image = dmabuf->user_data;
>  
> - egl_image_unref(image);
> + dmabuf_image_destroy(image);
>  }
>  
>  static struct egl_image *
> -import_dmabuf(struct gl_renderer *gr,
> -   struct linux_dmabuf_buffer *dmabuf)
> +import_simple_dmabuf(struct gl_renderer *gr,
> + struct dmabuf_attributes *attributes)
>  {
>   struct egl_image *image;
>   EGLint attribs[30];
>   int atti = 0;
>  
> - image = linux_dmabuf_buffer_get_user_data(dmabuf);
> - if (image)
> - return egl_image_ref(image);
> -
>   /* This requires the Mesa commit in
>* Mesa 10.3 (08264e5dad4df448e7718e782ad9077902089a07) or
>* Mesa 10.2.7 (55d28925e6109a4afd61f109e845a8a51bd17652).
> @@ -1446,38 +1472,38 @@ import_dmabuf(struct gl_renderer *gr,
>*/
>  
>   attribs[atti++] = EGL_WIDTH;
> - attribs[atti++] = dmabuf->attributes.width;
> + attribs[atti++] = attributes->width;
>   attribs[atti++] = EGL_HEIGHT;
> - attribs[atti++] = dmabuf->attributes.height;
> + attribs[atti++] = attributes->height;
>   attribs[atti++] = EGL_LINUX_DRM_FOURCC_EXT;
> - attribs[atti++] = dmabuf->attributes.format;
> + attribs[atti++] = attributes->format;
>   /* XXX: Add modifier here when supported */
>  
> - if (dmabuf->attributes.n_planes > 0) {
> + if (attributes->n_planes > 0) {
>   attribs[atti++] = EGL_DMA_BUF_PLANE0_FD_EXT;
> - attribs[atti++] = dmabuf->attributes.fd[0];
> + attribs[atti++] = 

Re: [PATCH 3/6] gl-renderer: Add support for a few YUV dmabuf formats

[Derek Foreman]

On 24/11/15 01:28 PM, Emmanuel Gil Peyrot wrote:
> Namely the single-planar YUYV, the two-planar NV12, and the
> three-planar YUV420, using the shaders already present in Weston.
> 
> Signed-off-by: Emmanuel Gil Peyrot 
> 
> Maniphest Tasks: T13
> 
> Differential Revision: https://phabricator.freedesktop.org/D334
> ---
>  src/gl-renderer.c | 280 
> +-
>  1 file changed, 237 insertions(+), 43 deletions(-)
> 
> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> index 90e4842..cce93ee 100644
> --- a/src/gl-renderer.c
> +++ b/src/gl-renderer.c
> @@ -101,11 +101,36 @@ struct egl_image {
>   int refcount;
>  };
>  
> +enum import_type {
> + IMPORT_TYPE_INVALID,
> + IMPORT_TYPE_DIRECT,
> + IMPORT_TYPE_GL_CONVERSION
> +};
> +
>  struct dmabuf_image {
>   struct linux_dmabuf_buffer *dmabuf;
>   int num_images;
>   struct egl_image *images[3];
>   struct wl_list link;
> +
> + enum import_type import_type;
> + GLenum target;
> + struct gl_shader *shader;
> +};
> +
> +struct yuv_plane_descriptor {
> + int width_divisor;
> + int height_divisor;
> + uint32_t format;
> + int plane_index;
> +};
> +
> +struct yuv_format_descriptor {
> + uint32_t format;
> + int input_planes;
> + int output_planes;
> + int texture_type;
> + struct yuv_plane_descriptor plane[4];
>  };
>  
>  struct gl_surface_state {
> @@ -197,7 +222,7 @@ static PFNEGLGETPLATFORMDISPLAYEXTPROC 
> get_platform_display = NULL;
>  static inline const char *
>  dump_format(uint32_t *format)
>  {
> - // FIXME: this won’t work properly on big-endian.
> + /* FIXME: this won’t work properly on big-endian. */

mumble mumble unrelated, see patch 2 comment. ;)


>   return (const char *)format;
>  }
>  
> @@ -1514,6 +1539,171 @@ import_simple_dmabuf(struct gl_renderer *gr,
>   return image;
>  }
>  
> +struct yuv_format_descriptor yuv_formats[] = {
> + {
> + .format = DRM_FORMAT_YUYV,
> + .input_planes = 1,
> + .output_planes = 2,
> + .texture_type = EGL_TEXTURE_Y_XUXV_WL,
> + {{
> + .width_divisor = 1,
> + .height_divisor = 1,
> + .format = DRM_FORMAT_GR88,
> + .plane_index = 0
> + }, {
> + .width_divisor = 2,
> + .height_divisor = 1,
> + .format = DRM_FORMAT_ARGB,
> + .plane_index = 0
> + }}
> + }, {
> + .format = DRM_FORMAT_NV12,
> + .input_planes = 2,
> + .output_planes = 2,
> + .texture_type = EGL_TEXTURE_Y_UV_WL,
> + {{
> + .width_divisor = 1,
> + .height_divisor = 1,
> + .format = DRM_FORMAT_R8,
> + .plane_index = 0
> + }, {
> + .width_divisor = 2,
> + .height_divisor = 2,
> + .format = DRM_FORMAT_GR88,
> + .plane_index = 1
> + }}
> + }, {
> + .format = DRM_FORMAT_YUV420,
> + .input_planes = 3,
> + .output_planes = 3,
> + .texture_type = EGL_TEXTURE_Y_U_V_WL,
> + {{
> + .width_divisor = 1,
> + .height_divisor = 1,
> + .format = DRM_FORMAT_R8,
> + .plane_index = 0
> + }, {
> + .width_divisor = 2,
> + .height_divisor = 2,
> + .format = DRM_FORMAT_R8,
> + .plane_index = 1
> + }, {
> + .width_divisor = 2,
> + .height_divisor = 2,
> + .format = DRM_FORMAT_R8,
> + .plane_index = 2
> + }}
> + }
> +};
> +
> +static struct egl_image *
> +import_dmabuf_single_plane(struct gl_renderer *gr,
> +   const struct dmabuf_attributes *attributes,
> +   struct yuv_plane_descriptor *descriptor)
> +{
> + struct dmabuf_attributes plane;
> + struct egl_image *image;
> +
> + plane.width = attributes->width / descriptor->width_divisor;
> + plane.height = attributes->height / descriptor->height_divisor;
> + plane.format = descriptor->format;
> + plane.n_planes = 1;
> + plane.fd[0] = attributes->fd[descriptor->plane_index];
> + plane.offset[0] = attributes->offset[descriptor->plane_index];
> + plane.stride[0] = attributes->stride[descriptor->plane_index];
> + plane.modifier[0] = attributes->modifier[descriptor->plane_index];
> +
> + image = import_simple_dmabuf(gr, );
> + if (!image) {
> + weston_log("Failed to import plane %d as %.4s\n",
> +

[PATCH libinput] tablet: handle custom proximity handling

[Peter Hutterer]

For the puck/lens cursor tool we need to artificially reduce proximity
detection. These tools are usually used in a relative mode (i.e. like a mouse)
and thus require lifting and resetting the tool multiple times to move across
the screen. The tablets' distance detection goes too far, requiring the user
to lift the device several cm on every move. This is uncomfortable.

Introduce an artificial distance threshold for the devices with the default
value taken from the X.Org wacom driver. If a tool is in proximity but outside
of this range, fake proximity events accordingly.

If a button was pressed while we were out of range we discard that event and
send it later when we enter proximity again.

This is the simple implementation that only takes one proximity out value (the
one from the wacom driver) and applies it to all. Those devices that support a
button/lens tool and have a different default threshold are well out of date.

Signed-off-by: Peter Hutterer 
---
 src/evdev-tablet.c | 103 -
 src/evdev-tablet.h |   3 +
 test/litest.c  |  18 +
 test/litest.h  |   3 +-
 test/tablet.c  | 221 +
 5 files changed, 346 insertions(+), 2 deletions(-)

diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 7e3298c..777ffad 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -67,6 +67,22 @@ tablet_get_released_buttons(struct tablet_dispatch *tablet,
~(state->stylus_buttons[i]);
 }
 
+/* Merge the previous state with the current one so all buttons look like
+ * they just got pressed in this frame */
+static inline void
+tablet_force_button_presses(struct tablet_dispatch *tablet)
+{
+   struct button_state *state = >button_state,
+   *prev_state = >prev_button_state;
+   size_t i;
+
+   for (i = 0; i < sizeof(state->stylus_buttons); i++) {
+   state->stylus_buttons[i] = state->stylus_buttons[i] |
+   prev_state->stylus_buttons[i];
+   prev_state->stylus_buttons[i] = 0;
+   }
+}
+
 static int
 tablet_device_has_axis(struct tablet_dispatch *tablet,
   enum libinput_tablet_tool_axis axis)
@@ -994,6 +1010,62 @@ sanitize_tablet_axes(struct tablet_dispatch *tablet)
 }
 
 static void
+tablet_update_proximity_state(struct tablet_dispatch *tablet,
+ struct evdev_device *device)
+{
+   const struct input_absinfo *distance;
+   int dist_max = tablet->cursor_proximity_threshold;
+   int dist;
+
+   distance = libevdev_get_abs_info(tablet->device->evdev, ABS_DISTANCE);
+   if (!distance)
+   return;
+
+   dist = distance->value;
+   if (dist == 0)
+   return;
+
+   /* Tool got into permitted range */
+   if (dist < dist_max &&
+   (tablet_has_status(tablet, TABLET_TOOL_OUT_OF_RANGE) ||
+tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY))) {
+   tablet_unset_status(tablet,
+   TABLET_TOOL_OUT_OF_RANGE);
+   tablet_unset_status(tablet,
+   TABLET_TOOL_OUT_OF_PROXIMITY);
+   tablet_set_status(tablet, TABLET_TOOL_ENTERING_PROXIMITY);
+   tablet_mark_all_axes_changed(tablet, device);
+
+   tablet_set_status(tablet, TABLET_BUTTONS_PRESSED);
+   tablet_force_button_presses(tablet);
+   return;
+   }
+
+   if (dist < dist_max)
+   return;
+
+   /* Still out of range/proximity */
+   if (tablet_has_status(tablet, TABLET_TOOL_OUT_OF_RANGE) ||
+   tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY))
+   return;
+
+   /* Tool entered prox but is outside of permitted range */
+   if (tablet_has_status(tablet,
+ TABLET_TOOL_ENTERING_PROXIMITY)) {
+   tablet_set_status(tablet,
+ TABLET_TOOL_OUT_OF_RANGE);
+   tablet_unset_status(tablet,
+   TABLET_TOOL_ENTERING_PROXIMITY);
+   return;
+   }
+
+   /* Tool was in prox and is now outside of range. Set leaving
+* proximity, on the next event it will be OUT_OF_PROXIMITY and thus
+* caught by the above conditions */
+   tablet_set_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY);
+}
+
+static void
 tablet_flush(struct tablet_dispatch *tablet,
 struct evdev_device *device,
 uint64_t time)
@@ -1004,7 +1076,12 @@ tablet_flush(struct tablet_dispatch *tablet,
tablet->current_tool_id,
tablet->current_tool_serial);
 
-   if (tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY))
+   if (tool->type == LIBINPUT_TABLET_TOOL_TYPE_MOUSE ||
+   tool->type == 

Re: [PATCH v2 wayland] protocol: add support for cross-interface enum attributes

[Auke Booij]

I'd be happy to rebase against that, but since that hasn't been merged
yet, I thought I'd take the current tree as a a basis.

If you think having the interface:: prefix everywhere makes sense, I
can change that if you want.

On 2 December 2015 at 03:09, Bill Spitzak  wrote:
> Looks correct to me.
>
> I had a slightly different patch in patchwork which changes
> protocol-to-docbook. It puts the enumeration into it's own statement, rather
> than a nested if statement, and it adds the object:: prefix to the
> documentation for all enumerations, not just the cross-object ones.
>
> On Sun, Nov 29, 2015 at 5:54 AM, Auke Booij  wrote:
>>
>> The enum attribute, for which scanner support was introduced in
>> 1771299, can be used to link message arguments to s. However,
>> some arguments refer to s in a different .
>>
>> This adds scanner support for referring to an  in a different
>>  using dot notation. It also sets the attributes in this
>> style in the wayland XML protocol (wl_shm_pool::create_buffer::format
>> to wl_shm::format, and wl_surface::set_buffer_transform::transform to
>> wl_output::transform), and updates the documentation XSL so that this
>> new style is supported.
>>
>> Changes since v1:
>>  - several implementation bugs fixed
>>
>> Signed-off-by: Auke Booij 
>> ---
>>  doc/publican/protocol-to-docbook.xsl | 17 +--
>>  protocol/wayland.xml |  4 +--
>>  src/scanner.c| 59
>> +++-
>>  3 files changed, 61 insertions(+), 19 deletions(-)
>>
>> diff --git a/doc/publican/protocol-to-docbook.xsl
>> b/doc/publican/protocol-to-docbook.xsl
>> index fad207a..1fa066d 100644
>> --- a/doc/publican/protocol-to-docbook.xsl
>> +++ b/doc/publican/protocol-to-docbook.xsl
>> @@ -103,9 +103,20 @@
>>  
>>  
>>
>> -
>> -  
>> -
>> +
>> +  
>> +
>> +  
>> +  ::
>> +  
>> +
>> +  
>> +  
>> +
>> +  
>> +
>> +  
>> +
>>  
>>
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index f9e6d76..0873553 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -229,7 +229,7 @@
>>
>>
>>
>> -  
>> +  
>>  
>>
>>  
>> @@ -1292,7 +1292,7 @@
>> wl_output.transform enum the invalid_transform protocol error
>> is raised.
>>
>> -  
>> +  
>>  
>>
>>  
>> diff --git a/src/scanner.c b/src/scanner.c
>> index 406519f..e69bd2a 100644
>> --- a/src/scanner.c
>> +++ b/src/scanner.c
>> @@ -785,32 +785,62 @@ start_element(void *data, const char *element_name,
>> const char **atts)
>> }
>>  }
>>
>> +static struct enumeration *
>> +find_enumeration(struct protocol *protocol, struct interface *interface,
>> char *enum_attribute)
>> +{
>> +   struct interface *i;
>> +   struct enumeration *e, *f = NULL;
>> +   char *enum_name;
>> +   int idx = 0, j;
>> +
>> +for (j = 0; j + 1 < (int)strlen(enum_attribute); j++) {
>> +   if (enum_attribute[j] == '.') {
>> +   idx = j;
>> +   }
>> +   }
>> +
>> +   if (idx > 0) {
>> +   enum_name = enum_attribute + idx + 1;
>> +
>> +   wl_list_for_each(i, >interface_list, link)
>> +   if (strncmp(i->name, enum_attribute, idx) == 0)
>> +   wl_list_for_each(e, >enumeration_list,
>> link)
>> +   if(strcmp(e->name, enum_name) ==
>> 0)
>> +   f = e;
>> +   } else if (interface) {
>> +   enum_name = enum_attribute;
>> +
>> +   wl_list_for_each(e, >enumeration_list, link)
>> +   if(strcmp(e->name, enum_name) == 0)
>> +   f = e;
>> +   }
>> +
>> +   return f;
>> +}
>> +
>>  static void
>> -verify_arguments(struct parse_context *ctx, struct wl_list *messages,
>> struct wl_list *enumerations)
>> +verify_arguments(struct parse_context *ctx, struct interface *interface,
>> struct wl_list *messages, struct wl_list *enumerations)
>>  {
>> struct message *m;
>> wl_list_for_each(m, messages, link) {
>> struct arg *a;
>> wl_list_for_each(a, >arg_list, link) {
>> -   struct enumeration *e, *f;
>> +   struct enumeration *e;
>>
>> if (!a->enumeration_name)
>> continue;
>>
>> -   f = NULL;
>> -   wl_list_for_each(e, enumerations, link) {
>> -   if(strcmp(e->name, a->enumeration_name) ==
>> 

Re: [PATCH wayland v2 1/5] server: Add new api for add socket for fd

[Pekka Paalanen]

On Wed, 2 Dec 2015 10:51:21 +0200
Pekka Paalanen  wrote:

> Hi,
> 
> I don't really understand the underlying use case, but I can imagine
> adding listening sockects to wl_display by fd being useful, so I have
> no objections to this feature in general.
> 
> More below.
> 
> 
> On Mon, 23 Nov 2015 19:59:19 -0800
> Bryce Harrington  wrote:
> 
> > From: Sangjin Lee 
> > 
> > Currently the server can add a socket by name.  To support an embedded
> > compositor in a Simplified Mandatory Access Control Kernel (Smack)
> > enabled environment, the embedded compositor should use the socket that
> > it gets from the system or session compositor.
> > 
> > Signed-off-by: Sangjin Lee 
> > Acked-by: Sung-Jin Park 
> > Reviewed-by: Bryce Harrington 
> > Signed-off-by: Bryce Harrington 
> > ---
> >  src/wayland-os.c  | 12 
> >  src/wayland-os.h  |  2 ++
> >  src/wayland-server-core.h |  6 
> >  src/wayland-server.c  | 76 
> > ++-
> >  4 files changed, 68 insertions(+), 28 deletions(-)
> > 

> > --- a/src/wayland-server-core.h
> > +++ b/src/wayland-server-core.h
> > @@ -128,9 +128,15 @@ wl_display_get_event_loop(struct wl_display *display);
> >  int
> >  wl_display_add_socket(struct wl_display *display, const char *name);
> >  
> > +int
> > +wl_display_add_socket_fd(struct wl_display *display, const char *name, int 
> > sock_fd);
> > +
> >  const char *
> >  wl_display_add_socket_auto(struct wl_display *display);
> >  
> > +const char *
> > +wl_display_add_socket_fd_auto(struct wl_display *display, int sock_fd);  
> 
> These two API additions are strange, more of them below.
> 
> IMHO much better would be to add just one:
> 
> int
> wl_display_add_socket_fd(struct wl_display *display, int sock_fd);
> 
> which will simply fail if sock_fd is not open and valid.
> 

> 
> I think the new public API could be better, so NAK.

To be clear, if you fix the public API and the wayland-os part, this
would have good chances of getting accepted.

The API as proposed is a no-go for me without thorough explanation of
why you would need it the way you wrote it.


Thanks,
pq


pgpMI5ugYKvXw.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Introduce the authorizer protocol

[Giulio Camuffo]

2015-11-26 10:21 GMT+02:00 Pekka Paalanen :
> On Wed, 25 Nov 2015 17:39:25 +0100
> Mariusz Ceier  wrote:
>
>> Hi,
>>
>> On 25 November 2015 at 16:14, Pekka Paalanen  wrote:
>>
>> > On Tue, 24 Nov 2015 18:07:34 +0100
>> > Mariusz Ceier  wrote:
>> >
>> > > Hi,
>> > >
>> > > On 24 November 2015 at 17:35, Giulio Camuffo 
>> > > wrote:
>> > >
>> > > > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier :
>> > > > > Hi,
>> > > > >   How the clients will know:
>> > > > > a) which interface is restricted and which is not ?
>> > > >
>> > > > It doesn't, but does it need to know it? It can still ask for
>> > > > authorization even if the interface is not.
>> > > >
>> > > >
>> > > I think it should - otherwise client, that wants to run on as many
>> > > compositors as possible, would have to send authorize requests for every
>> > > interface, since different compositors can implement different policies
>> > and
>> > > interface in one compositor can be unrestricted while in another
>> > > restricted.
>> >
>> > Why should we separate restricted interfaces in the registry level? Or
>> > at all?
>> >
>> >
>> Because binding restricted interface kills client and since interface
>> specification doesn't tell if that interface is restricted or not, binding
>> would be a gamble for client. Also to authorize the client to use of
>> restricted interface, authorizer object needs to be created - that means
>> restricted interfaces can't be bound before authorizer object is announced,
>> and that means restricted interfaces can't be announced before authorizer
>> is announced, unless client can bind them later (which I don't think is a
>> case).
>
> As said, all clients must be able to deal with arbitrary advertising
> orders. There is nothing hard with that, even toytoolkit supports it.

Agreed.

>
>> The interface specification needs to say whether it is restricted or
>> > not. If a compositor does not care about restricting it, it'll just
>> > always answer "yes."
>> >
>>
>> Even if interface specification would include information whether it's
>> restricted or not, that information would have to be included in protocol -
>> since later versions of protocol can become restricted.
>
> If later versions become restricted, that changes nothing here. Clients
> using earlier versions will bind an earlier version and avoid the
> security check. A client implementing support for the restricted version
> obviously also implements support for getting the authorization,
> because that is part of the spec.
>
> If you mean retroactively restricting, see below.
>
>> > When you design a new protocol extension, I can't imagine that you
>> > would not know if it needs to be restricted or not. Do you have any
>> > example to the contrary?
>> >
>>
>> I think it may be the case during development and even after it gets
>> stabilized.
>> It may be unrestricted at first, but then someone might find security bug
>> (in design) or request requiring privileged access could be added - in
>> these cases compositors probably would like to restrict access to that
>> interface.
>> In v1 of authorizer that would mean, that clients which assumed that
>> specific interfaces are unrestricted would be killed by compositor.
>> And in v2 authorizer clients would know that they need to send authorize
>> request first - since interface wouldn't be available in wl_registry but
>> only in wl_restricted_registry.
>
> Ok, that makes some sense, but I'm still skeptical.
>
> If there is an app using a global Foo, that is then discovered insecure
> and becomes retroactively restricted, it would no longer be advertised
> in the normal registry. If the app relied on Foo, it no longer works
> without changes. If Foo was optional for the app, the app continues to
> work without it, but getting it back would again require changes in the
> app to get it to look for it from the restricted registry. If it has
> code to look in the restricted registry, it could still be denied the
> authorization.

However if an app can work even without the Foo global, or just wants
to display a nice user friendly dialog saying Foo is not available
instead of just dying, moving the global from wl_registry to
wp_restricted_registry would allow the app to realize Foo is not
available, while just making the global in wl_registry restricted
would mean the app would unknowingly try to bind it and it would get
killed. So i'd say the restricted registry is more app/user friendly
here.

>
> So this would work like a per-client selective interface deprecation
> assuming that clients support searching for globals from both
> registries.
>
> It is a nice mechanism, but I have the feeling that this is a too
> generic solution to a problem that is only hand-waving at this point.
>
> Continuing with the speculation, what if the authorization request
> would need interface 

[PATCH weston v3] xwm: let the shells decide the position of X windows

[Giulio Camuffo]

The xwm used to automatically send to Xwayland the position of X windows
when that changed, using the x,y of the primary view of the surface.
This works fine for the desktop shell but less so for others.
This patch adds a 'send_position' vfunc to the weston_shell_client that
the shell will call when it wants to let Xwayland know what the position
of a window is.
The logic used by the desktop-shell for that is exactly the same the xwm
used to have.
---

v3: rebased, no actual change

 desktop-shell/shell.c | 40 +++---
 desktop-shell/shell.h |  1 +
 src/compositor.h  |  4 +--
 xwayland/window-manager.c | 72 +--
 xwayland/xwayland.h   |  1 -
 5 files changed, 64 insertions(+), 54 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 780902d..85664c6 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1813,7 +1813,8 @@ send_configure(struct weston_surface *surface, int32_t 
width, int32_t height)
 }
 
 static const struct weston_shell_client shell_client = {
-   send_configure
+   send_configure,
+   NULL
 };
 
 static void
@@ -3704,12 +3705,6 @@ create_shell_surface(void *shell, struct weston_surface 
*surface,
return create_common_surface(NULL, shell, surface, client);
 }
 
-static struct weston_view *
-get_primary_view(void *shell, struct shell_surface *shsurf)
-{
-   return shsurf->view;
-}
-
 static void
 shell_get_shell_surface(struct wl_client *client,
struct wl_resource *resource,
@@ -3995,7 +3990,8 @@ xdg_send_configure(struct weston_surface *surface,
 }
 
 static const struct weston_shell_client xdg_client = {
-   xdg_send_configure
+   xdg_send_configure,
+   NULL
 };
 
 static void
@@ -4119,7 +4115,8 @@ xdg_popup_send_configure(struct weston_surface *surface,
 }
 
 static const struct weston_shell_client xdg_popup_client = {
-   xdg_popup_send_configure
+   xdg_popup_send_configure,
+   NULL
 };
 
 static struct shell_surface *
@@ -5412,6 +5409,27 @@ wake_handler(struct wl_listener *listener, void *data)
 }
 
 static void
+transform_handler(struct wl_listener *listener, void *data)
+{
+   struct weston_surface *surface = data;
+   struct shell_surface *shsurf = get_shell_surface(surface);
+   struct weston_view *view;;
+   int x, y;
+
+   if (!shsurf || !shsurf->client->send_position)
+   return;
+
+   view = shsurf->view;
+   if (!view || !weston_view_is_mapped(view))
+   return;
+
+   x = view->geometry.x;
+   y = view->geometry.y;
+
+   shsurf->client->send_position(surface, x, y);
+}
+
+static void
 center_on_output(struct weston_view *view, struct weston_output *output)
 {
int32_t surf_x, surf_y, width, height;
@@ -6379,6 +6397,7 @@ shell_destroy(struct wl_listener *listener, void *data)
 
wl_list_remove(>idle_listener.link);
wl_list_remove(>wake_listener.link);
+   wl_list_remove(>transform_listener.link);
 
text_backend_destroy(shell->text_backend);
input_panel_destroy(shell);
@@ -6520,10 +6539,11 @@ module_init(struct weston_compositor *ec,
wl_signal_add(>idle_signal, >idle_listener);
shell->wake_listener.notify = wake_handler;
wl_signal_add(>wake_signal, >wake_listener);
+   shell->transform_listener.notify = transform_handler;
+   wl_signal_add(>transform_signal, >transform_listener);
 
ec->shell_interface.shell = shell;
ec->shell_interface.create_shell_surface = create_shell_surface;
-   ec->shell_interface.get_primary_view = get_primary_view;
ec->shell_interface.set_toplevel = set_toplevel;
ec->shell_interface.set_transient = set_transient;
ec->shell_interface.set_fullscreen = shell_interface_set_fullscreen;
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index 2ef23f4..c55a225 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -121,6 +121,7 @@ struct desktop_shell {
 
struct wl_listener idle_listener;
struct wl_listener wake_listener;
+   struct wl_listener transform_listener;
struct wl_listener destroy_listener;
struct wl_listener show_input_panel_listener;
struct wl_listener hide_input_panel_listener;
diff --git a/src/compositor.h b/src/compositor.h
index 1d04481..56713cc 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -86,6 +86,7 @@ struct weston_mode {
 
 struct weston_shell_client {
void (*send_configure)(struct weston_surface *surface, int32_t width, 
int32_t height);
+   void (*send_position)(struct weston_surface *surface, int32_t x, 
int32_t y);
 };
 
 struct weston_shell_interface {
@@ -94,9 +95,6 @@ struct weston_shell_interface {
struct shell_surface *(*create_shell_surface)(void *shell,
  struct weston_surface 
*surface,

Re: [PATCH 1/2] xdg-shell: Bump unstable version to 6

[Jasper St. Pierre]

While we're doing this, can we remove the use_unstable_version request?

On Wed, Dec 2, 2015 at 5:06 PM, Mike Blumenkrantz  wrote:
> This copies the version 5 of the XML to a new version 6 version, while
> at the same time the interface names are changed to use the unstable
> naming convention.
>
> A whitespace cleanup was done as no git-blame:ability would be lost
> anyway.
>
> Reviewed-by: Mike Blumenkrantz 
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am  |   1 +
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624 
> +++
>  2 files changed, 625 insertions(+)
>  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 5926a41..4a2974d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5,6 +5,7 @@ unstable_protocols =  
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> +   unstable/xdg-shell/xdg-shell-unstable-v6.xml  
>   \
> $(NULL)
>
>  nobase_dist_pkgdata_DATA =   
>   \
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> new file mode 100644
> index 000..196c332
> --- /dev/null
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -0,0 +1,624 @@
> +
> +
> +
> +  
> +Copyright © 2008-2013 Kristian Høgsberg
> +Copyright © 2013  Rafael Antognolli
> +Copyright © 2013  Jasper St. Pierre
> +Copyright © 2010-2013 Intel Corporation
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  xdg_shell allows clients to turn a wl_surface into a "real window"
> +  which can be dragged, resized, stacked, and moved around by the
> +  user. Everything about this interface is suited towards traditional
> +  desktop environments.
> +
> +
> +
> +  
> +   The 'current' member of this enum gives the version of the
> +   protocol.  Implementations can compare this to the version
> +   they implement using static_assert to ensure the protocol and
> +   implementation versions match.
> +  
> +  
> +
> +
> +
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> +   Destroy this xdg_shell object.
> +
> +   Destroying a bound xdg_shell object while there are surfaces
> +   still alive created by this xdg_shell object instance is illegal
> +   and will result in a protocol error.
> +  
> +
> +
> +
> +  
> +   Negotiate the unstable version of the interface.  This
> +   mechanism is in place to ensure client and server agree on the
> +   unstable versions of the protocol that they speak or exit
> +   cleanly if they don't agree.  This request will go away once
> +   the xdg-shell protocol is stable.
> +  
> +  
> +
> +
> +
> +  
> +   This creates an xdg_surface for the given surface and gives it the
> +   xdg_surface role. A wl_surface can only be given an xdg_surface role
> +   once. If get_xdg_surface is called with a wl_surface that already has
> +   an active xdg_surface associated with it, or if it had any other role,
> +   an error is raised.
> +
> +   See the documentation of xdg_surface for more details about what an
> +   xdg_surface is and how it is used.
> +  
> +  
> +  
> +
> +
> +
> +  
> +   This creates an xdg_popup for the given surface and gives it the

Re: [PATCH libinput] tablet: handle custom proximity handling

[Bill Spitzak]

On Wed, Dec 2, 2015 at 3:57 PM, Peter Hutterer 
wrote:

> For the puck/lens cursor tool we need to artificially reduce proximity
> detection. These tools are usually used in a relative mode (i.e. like a
> mouse)
> and thus require lifting and resetting the tool multiple times to move
> across
> the screen. The tablets' distance detection goes too far, requiring the
> user
> to lift the device several cm on every move. This is uncomfortable.
>
> Introduce an artificial distance threshold for the devices with the default
> value taken from the X.Org wacom driver. If a tool is in proximity but
> outside
> of this range, fake proximity events accordingly.
>
>
You will want something like this for pens and all other tools, as it is
possible to use them in a relative mode (very common if the tablet is
smaller than the screen). I think rather than typing this to the type of
tool, you need to tie it to whether relative motion is being used or not.
Not sure where in libinput or wayland that would be, though.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] install pkg-config file to /usr/share

[Bryce Harrington]

Hi Quentin,

Wayland has some Ubuntu PPA nightly builds set up, which I'm updating to
include wayland-protocols, which weston now needs to build.  However,
one of the targets for these PPAs is the Ubuntu LTS 14.04, which shipped
with an older pkg-config (version 0.26) that lacks support for
PKG_NOARCH_INSTALLDIR (or, at least, it fails build with a message about
noarch_pkgconfigdir being undefined.)

I'm not sure what to do here; Derek suggested asking your advice.  Now,
I could just toss a newer pkg-config package into the PPA to use with
14.04; this would be an easy solution but is just a crutch and wouldn't
help anyone else that might want to build on Ubuntu 14.04.  Another
solution might be to modify wayland-protocols to not require this
feature, at least not when older pkg-config is present; but I'm not sure
whether such a patch would be accepted or how it should be written.
Third option would be to just not worry about supporting packages for
the 14.04 LTS anymore... but the 16.04 LTS is still months off.

Bryce

On Sun, Nov 22, 2015 at 07:48:38PM +0100, Quentin Glidic wrote:
> On 22/11/2015 13:31, Igor Gnatenko wrote:
> >It is arch-independent, so no need to install it to /usr/lib*
> >
> >Signed-off-by: Igor Gnatenko 
> >---
> >  Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/Makefile.am b/Makefile.am
> >index a32e977..71b8799 100644
> >--- a/Makefile.am
> >+++ b/Makefile.am
> >@@ -15,5 +15,5 @@ dist_noinst_DATA = 
> >\
> > $(sort $(foreach p,$(unstable_protocols),$(dir $p)README))  
> > \
> > $(NULL)
> >
> >-pkgconfigdir = $(libdir)/pkgconfig
> >+pkgconfigdir = $(datadir)/pkgconfig
> >  pkgconfig_DATA = wayland-protocols.pc
> >
> 
> 
> Ideally, we should use PKG_NOARCH_INSTALLDIR (in configure.ac) and
> drop the *dir from Makefile.am.
> 
> If that is not wanted, this patch is fine:
> Reviewed-by: Quentin Glidic 
> 
> (Sorry for the duplicate mail Igor.)
> 
> -- 
> 
> Quentin “Sardem FF7” Glidic
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel