Re: Unstable protocol name breakage

[Jan Arne Petersen]

Hi,

On 20/10/15 04:22, Jonas Ådahl wrote:
> input-method.xml: This one I think might actually be fine to just apply the
> naming schema, as the protocol itself has Wayland core principle violations
> that need to be solved, i.e. any implementor of this is already broken (by
> principle).
> 
> text.xml: This one I'm not so sure about. Has it ever been implemented outside
> of weston except only as a proof of concept? Would it be fine to use the same
> name?

I would suggest to just use zwl_...v1 names for both protocols for now.
We can decide later if we want to use a different stable name for them
(they both need to be fixed in a non backward compatible way anyways).

Regards
Jan Arne

-- 
Jan Arne Petersen | jan.peter...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 3/4] scanner: enforce correct argument type for enums

[Bryce Harrington]

On Mon, Oct 19, 2015 at 11:21:25PM +0100, Auke Booij wrote:
> The scanner now checks whether arguments that have an associated
>  have the right type.
> An argument with an enum attribute must be of type int or uint,
> and if the  with that name has the bitfield attribute
> set to true, then the argument must be of type uint.

Btw, thanks for pressing on with the work on this feature, despite the
difficulty finding common ground across the various programming
languages.
 
> Signed-off-by: Auke Booij 
> ---
>  src/scanner.c | 70 
> +++
>  1 file changed, 70 insertions(+)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index f456aa5..9856475 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -128,6 +128,7 @@ struct arg {
>   char *interface_name;
>   struct wl_list link;
>   char *summary;
> + char *enumeration_name;
>  };
>  
>  struct enumeration {
> @@ -136,6 +137,7 @@ struct enumeration {
>   struct wl_list entry_list;
>   struct wl_list link;
>   struct description *description;
> + int bitfield;

Looks like this code only sets this to 0 or 1; may as well make this bool.
Other places in scanner.c use bool, so seems to be perfectly allowable.

>  };
>  
>  struct entry {
> @@ -540,6 +542,8 @@ start_element(void *data, const char *element_name, const 
> char **atts)
>   const char *summary = NULL;
>   const char *since = NULL;
>   const char *allow_null = NULL;
> + const char *enumeration_name = NULL;
> + const char *bitfield = NULL;
>   int i, version = 0;
>  
>   ctx->loc.line_number = XML_GetCurrentLineNumber(ctx->parser);
> @@ -562,6 +566,10 @@ start_element(void *data, const char *element_name, 
> const char **atts)
>   since = atts[i + 1];
>   if (strcmp(atts[i], "allow-null") == 0)
>   allow_null = atts[i + 1];
> + if (strcmp(atts[i], "enum") == 0)
> + enumeration_name = atts[i + 1];
> + if (strcmp(atts[i], "bitfield") == 0)
> + bitfield = atts[i + 1];
>   }
>  
>   ctx->character_data_length = 0;
> @@ -655,6 +663,14 @@ start_element(void *data, const char *element_name, 
> const char **atts)
>"allow-null is only valid for objects, 
> strings, and arrays");
>   }
>  
> + if (enumeration_name == NULL || strcmp(enumeration_name, "") == 
> 0)
> + arg->enumeration_name = NULL;
> + else
> + arg->enumeration_name = xstrdup(enumeration_name);
> +
> + if (allow_null != NULL && !is_nullable_type(arg))
> + fail(>loc, "allow-null is only valid for objects, 
> strings, and arrays");
> +
>   if (summary)
>   arg->summary = xstrdup(summary);
>  
> @@ -665,6 +681,14 @@ start_element(void *data, const char *element_name, 
> const char **atts)
>   fail(>loc, "no enum name given");
>  
>   enumeration = create_enumeration(name);
> +
> + if (bitfield == NULL || strcmp(bitfield, "false") == 0)
> + enumeration->bitfield = 0;
> + else if (strcmp(bitfield, "true") == 0)
> + enumeration->bitfield =1;

Would it be worth allowing True/False as well?

> + else
> + fail(>loc, "invalid value for bitfield attribute 
> (%s)", bitfield);

May as well say here that only true/false are accepted in bitfields.
Might save anyone that hits this from a trip to the documentation.

> +
>   wl_list_insert(ctx->interface->enumeration_list.prev,
>  >link);
>  
> @@ -701,6 +725,46 @@ start_element(void *data, const char *element_name, 
> const char **atts)
>  }
>  
>  static void
> +verify_arguments(struct parse_context *ctx, 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;
> +
> + 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)
> + fail(>loc,
> +  "could not find enumeration %s",
> +  a->enumeration_name);
> +
> + switch (a->type) {
> + case INT:
> + if (f->bitfield)
> + fail(>loc,
> +

Re: [PATCH v2 0/4] Enum and bitfield XML attributes

[Auke Booij]

On 19 October 2015 at 23:21, Auke Booij  wrote:
> There has been plenty of discussion regarding the introduction of new XML
> attributes. This series of patches improves on my earlier attempt to find
> common ground in this.
>
> Major exclusions from these patches are:
>
> - Support for cross-interface enum referencing (e.g.
> wl_shm_pool::create_buffer::format to wl_shm::format, and
> wl_surface::set_buffer_transform::transform to wl_output::transform).

Just to be clear on this, I think there is consensus that this should
be added in a later stage.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] weston: implement inert objects for keyboard/pointer/touch

[Hardening]

Le 20/10/2015 10:24, Bryce Harrington a écrit :
> On Mon, Oct 19, 2015 at 03:47:19PM +0200, David FORT wrote:
>> This patch implements inert objects for wl_keyboard, wl_pointer and wl_touch.
>> The target case is when the server has just send a capability event about a
>> disappearing object, and the client binds the corresponding object. We bind 
>> an
>> inert object: an object does nothing when it is requested. If the client 
>> behave
>> correctly, this object should be released when the capability event is 
>> received
>> and treated (calling the corresponding release request).
>> As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to know
>> if the seat has the corresponding object.
> 
> This is a big patch but it looks like the vast bulk is merely adding in
> pointer checks for keyboard, pointer, etc. everywhere and subsequent
> retabbing.  If you broke that refactoring step out as a preliminary
> patch, it may make reviewing the pertinent changes (i.e. tracking and
> checking state for the input devices rather than just testing the
> reference count) a bit easier.

I'm not sure to understand, what should I do then ?

> 
> Thanks for tending to the test code too in the refactor; it would be
> grand to see a test case added to keyboard-test or devices-test to
> exercise the case of handling inert input objects.
> 

Such a test is already there in the existing tests. In
get_device_after_destroy of devices-test.c, we already exercise inert
objects.

Best regards

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: iio sensors, acceleration and gyro.

[Bastien Nocera]

On Tue, 2015-10-20 at 08:39 +1000, Peter Hutterer wrote:
> On Mon, Oct 19, 2015 at 12:20:27PM -0500, Mike Mestnik wrote:
> > Hello,
> >   I've been working on a project called iio-sensor-proxy, it's a
> > project to take sensor readings and make them available over
> > dbus.  I
> > feel that this takes away from the generic concept that everything
> > is
> > a file.
> > 
> > Does this code perhaps have a better home in libinput?
> > 
> > https://github.com/hadess/iio-sensor-proxy
> 
> I don't think so. iio-sensor-proxy is not at the same level as
> libinput, and
> the dbus API is there for a reason. in theory, a libinput-based
> solution
> would be for libinput to read the sensors and have iio-sensor-proxy
> wrap
> libinput to provide the dbus API that applications require.
> 
> That wouldn't add anything to the current solution though, it'd be
> mostly
> code churn for little benefit. so unless Bastian requests that we add
> this
> to libinput, I don't think this is worth pursuing.

It's at the wrong level (it needs to be system unique, as IIO doesn't
support concurrent uses), and having a single daemon allows us to share
code to support the other sensor types.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Unstable protocol name breakage

[Daniel Stone]

Hi,

On 20 October 2015 at 06:16, Jasper St. Pierre  wrote:
> On Mon, Oct 19, 2015 at 7:22 PM, Jonas Ådahl  wrote:
>> xdg-shell.xml: Should we bite the bullet and rename this one, or just 
>> continue
>> letting its stability state be non-discoverable? It's clearly already used, 
>> and
>> renaming it will be painful, so not sure about this one.
>
> People are clearly unhappy with the status quo, so I'd be fine to
> rename this one to zxdg_shell.

I'm not particularly happy with the status quo, but the reality is
that it's exposed by both Weston and Mutter, and we've been telling
clients to use it - e.g. GTK+ relies on it. If we're going to change
the name, I'd prefer to combine this with a breaking protocol change,
so we're not foisting further incompatibility on clients for no
particular reason.

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

Re: [PATCH] weston: implement inert objects for keyboard/pointer/touch

[Bryce Harrington]

On Mon, Oct 19, 2015 at 03:47:19PM +0200, David FORT wrote:
> This patch implements inert objects for wl_keyboard, wl_pointer and wl_touch.
> The target case is when the server has just send a capability event about a
> disappearing object, and the client binds the corresponding object. We bind an
> inert object: an object does nothing when it is requested. If the client 
> behave
> correctly, this object should be released when the capability event is 
> received
> and treated (calling the corresponding release request).
> As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to know
> if the seat has the corresponding object.

This is a big patch but it looks like the vast bulk is merely adding in
pointer checks for keyboard, pointer, etc. everywhere and subsequent
retabbing.  If you broke that refactoring step out as a preliminary
patch, it may make reviewing the pertinent changes (i.e. tracking and
checking state for the input devices rather than just testing the
reference count) a bit easier.

Thanks for tending to the test code too in the refactor; it would be
grand to see a test case added to keyboard-test or devices-test to
exercise the case of handling inert input objects.

Bryce

> ---
>  desktop-shell/exposay.c  |  16 ++--
>  desktop-shell/shell.c|  21 ++--
>  src/compositor-wayland.c |  10 +-
>  src/compositor-x11.c |  12 ++-
>  src/input.c  | 242 
> +++
>  src/libinput-device.c|   2 +-
>  src/screen-share.c   |   2 +
>  src/text-backend.c   |  44 +
>  src/zoom.c   |   7 +-
>  tests/weston-test.c  |  18 ++--
>  xwayland/dnd.c   |   3 +-
>  11 files changed, 224 insertions(+), 153 deletions(-)
> 
> diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
> index 08b86a3..d6919b3 100644
> --- a/desktop-shell/exposay.c
> +++ b/desktop-shell/exposay.c
> @@ -574,21 +574,23 @@ exposay_transition_active(struct desktop_shell *shell)
>   bool animate = false;
>  
>   shell->exposay.workspace = get_current_workspace(shell);
> - shell->exposay.focus_prev = get_default_view(keyboard->focus);
> - shell->exposay.focus_current = get_default_view(keyboard->focus);
> + if (keyboard) {
> + shell->exposay.focus_prev = get_default_view(keyboard->focus);
> + shell->exposay.focus_current = 
> get_default_view(keyboard->focus);
> + }
>   shell->exposay.clicked = NULL;
>   wl_list_init(>exposay.surface_list);
>  
>   lower_fullscreen_layer(shell, NULL);
>   shell->exposay.grab_kbd.interface = _kbd_grab;
> - weston_keyboard_start_grab(keyboard,
> ->exposay.grab_kbd);
> - weston_keyboard_set_focus(keyboard, NULL);
> + if (keyboard) {
> + weston_keyboard_start_grab(keyboard, >exposay.grab_kbd);
> + weston_keyboard_set_focus(keyboard, NULL);
> + }
>  
>   shell->exposay.grab_ptr.interface = _ptr_grab;
>   if (pointer) {
> - weston_pointer_start_grab(pointer,
> -   >exposay.grab_ptr);
> + weston_pointer_start_grab(pointer, >exposay.grab_ptr);
>   weston_pointer_clear_focus(pointer);
>   }
>   wl_list_for_each(shell_output, >output_list, link) {
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 3eb3f5c..cdddf09 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -380,7 +380,8 @@ shell_grab_start(struct shell_grab *grab,
>   struct desktop_shell *shell = shsurf->shell;
>   struct weston_touch *touch = weston_seat_get_touch(pointer->seat);
>  
> - popup_grab_end(pointer);
> + if (pointer)
> + popup_grab_end(pointer);
>   if (touch)
>   touch_popup_grab_end(touch);
>  
> @@ -391,11 +392,13 @@ shell_grab_start(struct shell_grab *grab,
> >shsurf_destroy_listener);
>  
>   shsurf->grabbed = 1;
> - weston_pointer_start_grab(pointer, >grab);
> + if (pointer)
> + weston_pointer_start_grab(pointer, >grab);
>   if (shell->child.desktop_shell) {
>   desktop_shell_send_grab_cursor(shell->child.desktop_shell,
>  cursor);
> - weston_pointer_set_focus(pointer,
> + if (pointer)
> + weston_pointer_set_focus(pointer,
>get_default_view(shell->grab_surface),
>wl_fixed_from_int(0),
>wl_fixed_from_int(0));
> @@ -925,12 +928,10 @@ restore_focus_state(struct desktop_shell *shell, struct 
> workspace *ws)
>   wl_list_insert(>compositor->seat_list,
>  >seat->link);
>  
> - if (!keyboard)
> - continue;
> -
>   surface = state->keyboard_focus;
>  
> - 

[PATCH weston v2 1/3] compositor: introduce structs to handle backends configuration

[Giulio Camuffo]

This commit introduces the structs weston_backend_config and
weston_backend_output_config, to prepare for the new config
system for the backends.
---

v2: use uints for the width and height

 src/compositor.h | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index 2e2a185..b065f11 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -610,9 +610,41 @@ enum weston_capability {
WESTON_CAP_VIEW_CLIP_MASK   = 0x0010,
 };
 
+/* Configuration struct for an output.
+ *
+ * This struct is used to pass the configuration for an output
+ * to the compositor backend when creating a new output.
+ * The backend can subclass this struct to handle backend
+ * specific data.
+ */
+struct weston_backend_output_config {
+   uint32_t transform;
+   uint32_t width;
+   uint32_t height;
+   int scale;
+};
+
+/* Configuration struct for a backend.
+ *
+ * This struct carries the configuration for a backend, and it's
+ * passed to the backend's init entry point. The backend will
+ * likely want to subclass this in order to handle backend specific
+ * data.
+ */
+struct weston_backend_config {
+};
+
 struct weston_backend {
-   void (*destroy)(struct weston_compositor *ec);
-   void (*restore)(struct weston_compositor *ec);
+   void (*destroy)(struct weston_compositor *compositor);
+   void (*restore)(struct weston_compositor *compositor);
+   /* vfunc to create a new output with a given name and config.
+* backends not supporting the functionality will set this
+* to NULL.
+*/
+   struct weston_output *
+   (*create_output)(struct weston_compositor *compositor,
+const char *name,
+struct weston_backend_output_config *config);
 };
 
 struct weston_compositor {
-- 
2.6.1

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

Re: [PATCH v2 2/4] protocol: specify enum and bitfield attributes

[Bryce Harrington]

On Mon, Oct 19, 2015 at 11:21:24PM +0100, Auke Booij wrote:
> Signed-off-by: Auke Booij 

Reviewed-by: Bryce Harrington 

> ---
>  protocol/wayland.xml | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 59819e9..a3e6900 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -367,7 +367,7 @@
>   can be used for buffers. Known formats include
>   argb and xrgb.
>
> -  
> +  
>  
>
>  
> @@ -774,7 +774,7 @@
>
>
>
> -  
> +  
>  
>  
>  
> @@ -785,7 +785,7 @@
>
>  
>  
> -
> +
>
>   These flags specify details of the expected behaviour
>   of transient surfaces. Used in the set_transient request.
> @@ -807,7 +807,7 @@
>
>
>
> -  
> +  
>  
>  
>  
> @@ -858,7 +858,7 @@
>   with the dimensions for the output on which the surface will
>   be made fullscreen.
>
> -  
> +  
>
> allow-null="true"/>
>  
> @@ -891,7 +891,7 @@
>
>
>
> -  
> +  
>  
>  
>  
> @@ -972,7 +972,7 @@
>   in surface local coordinates.
>
>  
> -  
> +  
>
>
>  
> @@ -1337,7 +1337,7 @@
>maintains a keyboard focus and a pointer focus.
>  
>  
> -
> +
>
>  This is a bitmask of capabilities this seat has; if a member is
>  set, then it is present on the seat.
> @@ -1353,7 +1353,7 @@
>   keyboard or touch capabilities.  The argument is a capability
>   enum containing the complete set of capabilities this seat has.
>
> -  
> +  
>  
>  
>  
> @@ -1530,7 +1530,7 @@
>
>
>
> -  
> +  
>  
>  
>  
> @@ -1562,7 +1562,7 @@
>
>  
>
> -  
> +  
>
>  
>  
> @@ -1602,7 +1602,7 @@
>   This event provides a file descriptor to the client which can be
>   memory-mapped to provide a keyboard mapping description.
>
> -  
> +  
>
>
>  
> @@ -1647,7 +1647,7 @@
>
>
>
> -  
> +  
>  
>  
>  
> @@ -1828,17 +1828,17 @@
>  summary="width in millimeters of the output"/>
>  summary="height in millimeters of the output"/>
> -   +summary="subpixel orientation of the output"/>
>  summary="textual description of the manufacturer"/>
>  summary="textual description of the model"/>
> -   +summary="transform that maps framebuffer to output"/>
>  
>  
> -
> +
>
>   These flags describe properties of an output mode.
>   They are used in the flags bitfield of the mode event.
> @@ -1865,7 +1865,7 @@
>  the output may be scaled, as described in wl_output.scale,
>  or transformed , as described in wl_output.transform.
>
> -  
> +  
>
>
>
> -- 
> 2.6.1
> 
> ___
> 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

Re: [PATCH v2 1/4] doc: document the enum and bitfield attributes

[Bryce Harrington]

On Tue, Oct 20, 2015 at 12:01:14AM -0700, Bryce Harrington wrote:
> On Mon, Oct 19, 2015 at 11:21:23PM +0100, Auke Booij wrote:
> > Introduce the enum and bitfield attributes, which allow you to refer to the 
> > enum
> > you are expecting in an argument, and specify which enums are to be thought 
> > of
> > as bitfields.
> > 
> > +  Additionally, the protocol can specify enums.  These 
> > are used
> > +  to list options for int and uint type 
> > arguments.
> > +  Arguments can refer to the specific enumeration that is semantically
> > +  implied.  Only in the case that the argument is of type 
> > uint,
> > +  it can be specified that the primary interface to its numeric value 
> > deals
> > +  with bitwise operations, for example when arbitrarily many choices 
> > of the
> > +  enum can be ORed together.
> > +
> > +
> > +  The purpose of the enum and bitfield 
> > attributes
> > +  is to document what arguments refer to which enums, and to document 
> > which
> > +  numeric enum values are primarily accessed using bitwise operations.
> > +  Additionally, the enum and bitfield attributes may be used by other 
> > code,
> > +  such as bindings to other languages, for example to enhance type 
> > safety of
> > +  code.  However, such usage is only supported if the following 
> > property is
> > +  satisfied: code written prior to the specification of these 
> > attributes
> > +  still works after their specification.  In other words, specifying an
> > +  attribute for an argument, that previously did not have an enum or
> > +  bitfield attribute, should not break API.  Code that does not 
> > satisfy this
> > +  rule is not guaranteed to obey backwards compatibility.
> 
> This next chunk gets a bit too jarringly technical too quickly.  I think
> your second paragraph gives a better intro to these attributes, but it
> doesn't work to simply swap them.  Let me take a shot at copyediting
> this a bit:
> 
> I think this is clearer, and hopefully hasn't lost any meaning.  I'm not
> sure it's improved the technicality of this prose...  perhaps this
> section would be better promoted to its own section, with maybe just a
> reference sentence included here?  Not sure.

I'm noticing now that I've misunderstood what the bitfield attribute is;
so the above text is incorrect.  Let me try again.
 
   Additionally, the protocol can specify enums which
   associate specific numeric enumeration values.  These are
   primarily just description in nature: at the wire format level
   enums are just integers.  But they also serve a secondary purpose
   to enhance type safety or otherwise add context for use in
   language bindings or other such code.  This latter usage is only
   supported so long as code written before these attributes were
   introduced still works after; in other words, adding an enum
   should not break API, otherwise it puts backwards compatibility
   at risk.

   enums can be defined as bitfields or just a set of
   integers.  This is specified via the bitfield
   boolean attribute in the enum definition.  If this
   attribute is true, the enum is intended to be accessed primarily
   using bitwise operations, for example when arbitrarily many
   choices of the enum can be ORed together; if it is false, or the
   attribute is omitted, then the enum arguments are a just a
   sequence of numerical values.

   The enum attribute can be used on either
   uint or int arguments, however if the
   enum is defined as a bitfield, it can
   only be used on uint args.

Bryce
 
> > +
> > +
> >The server sends back events to the client, each event is emitted 
> > from
> >an object.  Events can be error conditions.  The event includes the
> >object ID and the event opcode, from which the client can determine
> > @@ -62,14 +88,11 @@
> >The protocol is sent over a UNIX domain stream socket, where the 
> > endpoint
> >usually is named wayland-0
> >(although it can be changed via WAYLAND_DISPLAY
> > -  in the environment).  The protocol is message-based.  A
> > -  message sent by a client to the server is called request.  A message
> > -  from the server to a client is called event.  Every message is
> > -  structured as 32-bit words, values are represented in the host's
> > -  byte-order.
> > +  in the environment).
> >  
> >  
> > -  The message header has 2 words in it:
> > +  Every message is structured as 32-bit words, values are represented 
> > in the
> > +  host's byte-order.  The message header has 2 words in it:
> 
> The comma after "32-bit words" probably should be a semi-colon here.
> 
> Bryce
> 
> >
> > 
> >   
> > -- 
> > 2.6.1
> > 
> > ___
> > wayland-devel mailing list
> > 

Re: [RFC] weston: implement inert objects for keyboard/pointer/touch

[Derek Foreman]

On 19/10/15 08:47 AM, David FORT wrote:
> This is the second version. I have restored the ref counting of input devices,
> I think with the name weston_seat_init_pointer is not accurate, perhaps 
> weston_seat_add_pointer_device would be better. I'm really wondering if it's
> the weston core that should do that refcounting, or if the input backend 
> should
> do it itself. I can't see any case where we would have 2 input backends (which
> would be a justification for weston doing it).

I agree that weston_seat_init_* are bad names.  weston_seat_add_*_device
does seem more reasonable to me.

(weston_seat_release_* seems sensible enough as it is.)

> Note that with this patch, we don't save the last position of the pointer. I'm
> wondering why we wanna do this, does that mean that we want the same kind of 
> behaviour for other input devices (saving locks state for keyboard device for 
> example) ?

Michal Suchanek already explained this perfectly, but I'll chime in with
"me too" - we absolutely need to retain that stuff.

(I can almost hear Bryce recommending we test for retained pointer state
in devices_test...  that'd be good at some point but not a pre-requisite
for this work...)

Guess that leaves you in a bad place regarding keyboard/pointer/touch
destruction?  I think it's not insurmountable though - I think when a
*seat* is destroyed that information should be removed.

I think this also answers your question of who should do the
refcounting?  If weston core is storing the retained state, I think it
needs to be responsible for the refcounting?

The RDP back-end has seats that come and go, I don't think the DRM
compositor should ever actually destroy a seat...  Does that make sense
or am I crazy? :)

Oh, I also agree with Bryce that it looks like this is two patches
pushed together - one with a lot of "if (!keyboard) dont_crash()" stuff
that we could review and land as an independent patch.  That stuff will
be an easy review and it'll make the actual "inert object" stuff easier
to look at too.

> David FORT (1):
>   weston: implement inert objects for keyboard/pointer/touch
> 
>  desktop-shell/exposay.c  |  16 ++--
>  desktop-shell/shell.c|  21 ++--
>  src/compositor-wayland.c |  10 +-
>  src/compositor-x11.c |  12 ++-
>  src/input.c  | 242 
> +++
>  src/libinput-device.c|   2 +-
>  src/screen-share.c   |   2 +
>  src/text-backend.c   |  44 +
>  src/zoom.c   |   7 +-
>  tests/weston-test.c  |  18 ++--
>  xwayland/dnd.c   |   3 +-
>  11 files changed, 224 insertions(+), 153 deletions(-)
> 

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

[PATCH] dmabuf: get supported dmabuf formats from compositor backend

[Fabien Dessenne]

Add the possibility for the compositor backend to provide with the list
of supported pixel formats for dmabuf-based buffers.
This information is used by linux_dmabuf to inform clients when binding.

Signed-off-by: Fabien Dessenne 
---
 src/compositor.h   |  2 ++
 src/linux-dmabuf.c | 16 +---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index 2e2a185..f58e0cc 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -613,6 +613,8 @@ enum weston_capability {
 struct weston_backend {
void (*destroy)(struct weston_compositor *ec);
void (*restore)(struct weston_compositor *ec);
+   void (*get_dmabuf_formats)(struct weston_compositor *ec,
+  struct wl_array *formats);
 };
 
 struct weston_compositor {
diff --git a/src/linux-dmabuf.c b/src/linux-dmabuf.c
index 90c9757..ee02ea4 100644
--- a/src/linux-dmabuf.c
+++ b/src/linux-dmabuf.c
@@ -433,9 +433,19 @@ bind_linux_dmabuf(struct wl_client *client,
wl_resource_set_implementation(resource, _dmabuf_implementation,
   compositor, NULL);
 
-   /* EGL_EXT_image_dma_buf_import does not provide a way to query the
-* supported pixel formats. */
-   /* XXX: send formats */
+   if (compositor->backend->get_dmabuf_formats) {
+   struct wl_array dmabuf_formats;
+   uint32_t *p;
+
+   wl_array_init(_formats);
+
+   compositor->backend->get_dmabuf_formats(compositor,
+   _formats);
+   wl_array_for_each(p, _formats)
+   zlinux_dmabuf_send_format(resource, *p);
+
+   wl_array_release(_formats);
+   }
 }
 
 /** Advertise linux_dmabuf support
-- 
1.9.1

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

Re: [PATCH] dmabuf: get supported dmabuf formats from compositor backend

[Bryce Harrington]

On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote:
> Add the possibility for the compositor backend to provide with the list
> of supported pixel formats for dmabuf-based buffers.
> This information is used by linux_dmabuf to inform clients when binding.
> 
> Signed-off-by: Fabien Dessenne 

Reviewed-by 

There's not a way to verify the list is getting sent across to the
client is there?

Bryce

> ---
>  src/compositor.h   |  2 ++
>  src/linux-dmabuf.c | 16 +---
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/src/compositor.h b/src/compositor.h
> index 2e2a185..f58e0cc 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -613,6 +613,8 @@ enum weston_capability {
>  struct weston_backend {
>   void (*destroy)(struct weston_compositor *ec);
>   void (*restore)(struct weston_compositor *ec);
> + void (*get_dmabuf_formats)(struct weston_compositor *ec,
> +struct wl_array *formats);
>  };
>  
>  struct weston_compositor {
> diff --git a/src/linux-dmabuf.c b/src/linux-dmabuf.c
> index 90c9757..ee02ea4 100644
> --- a/src/linux-dmabuf.c
> +++ b/src/linux-dmabuf.c
> @@ -433,9 +433,19 @@ bind_linux_dmabuf(struct wl_client *client,
>   wl_resource_set_implementation(resource, _dmabuf_implementation,
>  compositor, NULL);
>  
> - /* EGL_EXT_image_dma_buf_import does not provide a way to query the
> -  * supported pixel formats. */
> - /* XXX: send formats */
> + if (compositor->backend->get_dmabuf_formats) {
> + struct wl_array dmabuf_formats;
> + uint32_t *p;
> +
> + wl_array_init(_formats);
> +
> + compositor->backend->get_dmabuf_formats(compositor,
> + _formats);
> + wl_array_for_each(p, _formats)
> + zlinux_dmabuf_send_format(resource, *p);
> +
> + wl_array_release(_formats);
> + }
>  }
>  
>  /** Advertise linux_dmabuf support
> -- 
> 1.9.1
> 
> ___
> 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

Re: [PATCH] weston: implement inert objects for keyboard/pointer/touch

[Hardening]

Le 20/10/2015 17:12, Bryce Harrington a écrit :
> On Tue, Oct 20, 2015 at 10:39:51AM +0200, Hardening wrote:
>> Le 20/10/2015 10:24, Bryce Harrington a écrit :
>>> On Mon, Oct 19, 2015 at 03:47:19PM +0200, David FORT wrote:
 This patch implements inert objects for wl_keyboard, wl_pointer and 
 wl_touch.
 The target case is when the server has just send a capability event about a
 disappearing object, and the client binds the corresponding object. We 
 bind an
 inert object: an object does nothing when it is requested. If the client 
 behave
 correctly, this object should be released when the capability event is 
 received
 and treated (calling the corresponding release request).
 As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to 
 know
 if the seat has the corresponding object.
>>>
>>> This is a big patch but it looks like the vast bulk is merely adding in
>>> pointer checks for keyboard, pointer, etc. everywhere and subsequent
>>> retabbing.  If you broke that refactoring step out as a preliminary
>>> patch, it may make reviewing the pertinent changes (i.e. tracking and
>>> checking state for the input devices rather than just testing the
>>> reference count) a bit easier.
>>
>> I'm not sure to understand, what should I do then ?
> 
> Create two patches, the first of which just adds all the "if
> (keyboard)..." checks, and the second (much smaller) patch which adds
> the inert_pointer_interface, inert_keyboard_interface, etc. parts which
> are what you actually need the review on.  The pointer checking is
> obviously a safe refactoring that can be landed with minimal review.
> 

Well I can do this way but the 2 patches are linked. In the current
code, once a keyboard has been created, you can't have a null
seat->keyboard_state. So in the current situation, I'm not sure the
checks are really needed .

>>> Thanks for tending to the test code too in the refactor; it would be
>>> grand to see a test case added to keyboard-test or devices-test to
>>> exercise the case of handling inert input objects.
>>>
>>
>> Such a test is already there in the existing tests. In
>> get_device_after_destroy of devices-test.c, we already exercise inert
>> objects.
> 
> Apparently it is not exercised sufficiently, because it passes already
> without your fix.
> 

Well you're right: in the current code input objects are never released,
so the calls are done on used objects without any visible side effect.
In fact, there's a side effect when calling wl_pointer.set_cursor on a
released pointer: the surface is given the mouse pointer role. Using
inert objects, you're just sure that there will be no side effect at
all. As I said It think it's also the first step to make it possible to
safely release the full seat.

> But you're right that this test case looks like a good place for you to
> add more coverage for this bug.  Does the current test pass without your
> fix because it is not making deep enough wayland calls?  I.e. does it
> need to do more than merely a wl_pointer_set_cursor call?
> 
> Also, it appears this test isn't doing the same checking for keyboard
> and touch as it does for pointer; even though internally all three are
> implemented the same way, there are three different protocol routines
> involved here (wl_seat_get_pointer, wl_seat_get_keyboard, and
> wl_seat_get_touch), any of which could present their own bugs, so proper
> test coverage should methodically check all three.
> 

+1 for testing all input objects.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] weston: implement inert objects for keyboard/pointer/touch

[Bryce Harrington]

On Tue, Oct 20, 2015 at 10:39:51AM +0200, Hardening wrote:
> Le 20/10/2015 10:24, Bryce Harrington a écrit :
> > On Mon, Oct 19, 2015 at 03:47:19PM +0200, David FORT wrote:
> >> This patch implements inert objects for wl_keyboard, wl_pointer and 
> >> wl_touch.
> >> The target case is when the server has just send a capability event about a
> >> disappearing object, and the client binds the corresponding object. We 
> >> bind an
> >> inert object: an object does nothing when it is requested. If the client 
> >> behave
> >> correctly, this object should be released when the capability event is 
> >> received
> >> and treated (calling the corresponding release request).
> >> As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to 
> >> know
> >> if the seat has the corresponding object.
> > 
> > This is a big patch but it looks like the vast bulk is merely adding in
> > pointer checks for keyboard, pointer, etc. everywhere and subsequent
> > retabbing.  If you broke that refactoring step out as a preliminary
> > patch, it may make reviewing the pertinent changes (i.e. tracking and
> > checking state for the input devices rather than just testing the
> > reference count) a bit easier.
> 
> I'm not sure to understand, what should I do then ?

Create two patches, the first of which just adds all the "if
(keyboard)..." checks, and the second (much smaller) patch which adds
the inert_pointer_interface, inert_keyboard_interface, etc. parts which
are what you actually need the review on.  The pointer checking is
obviously a safe refactoring that can be landed with minimal review.

> > Thanks for tending to the test code too in the refactor; it would be
> > grand to see a test case added to keyboard-test or devices-test to
> > exercise the case of handling inert input objects.
> > 
> 
> Such a test is already there in the existing tests. In
> get_device_after_destroy of devices-test.c, we already exercise inert
> objects.

Apparently it is not exercised sufficiently, because it passes already
without your fix.

But you're right that this test case looks like a good place for you to
add more coverage for this bug.  Does the current test pass without your
fix because it is not making deep enough wayland calls?  I.e. does it
need to do more than merely a wl_pointer_set_cursor call?

Also, it appears this test isn't doing the same checking for keyboard
and touch as it does for pointer; even though internally all three are
implemented the same way, there are three different protocol routines
involved here (wl_seat_get_pointer, wl_seat_get_keyboard, and
wl_seat_get_touch), any of which could present their own bugs, so proper
test coverage should methodically check all three.

Bryce

> Best regards
> 
> -- 
> David FORT
> website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] weston: implement inert objects for keyboard/pointer/touch

[Jonas Ådahl]

On Wed, Oct 21, 2015 at 12:23:10AM +0200, Hardening wrote:
> Le 20/10/2015 17:12, Bryce Harrington a écrit :
> > On Tue, Oct 20, 2015 at 10:39:51AM +0200, Hardening wrote:
> >> Le 20/10/2015 10:24, Bryce Harrington a écrit :
> >>> On Mon, Oct 19, 2015 at 03:47:19PM +0200, David FORT wrote:
>  This patch implements inert objects for wl_keyboard, wl_pointer and 
>  wl_touch.
>  The target case is when the server has just send a capability event 
>  about a
>  disappearing object, and the client binds the corresponding object. We 
>  bind an
>  inert object: an object does nothing when it is requested. If the client 
>  behave
>  correctly, this object should be released when the capability event is 
>  received
>  and treated (calling the corresponding release request).
>  As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to 
>  know
>  if the seat has the corresponding object.
> >>>
> >>> This is a big patch but it looks like the vast bulk is merely adding in
> >>> pointer checks for keyboard, pointer, etc. everywhere and subsequent
> >>> retabbing.  If you broke that refactoring step out as a preliminary
> >>> patch, it may make reviewing the pertinent changes (i.e. tracking and
> >>> checking state for the input devices rather than just testing the
> >>> reference count) a bit easier.
> >>
> >> I'm not sure to understand, what should I do then ?
> > 
> > Create two patches, the first of which just adds all the "if
> > (keyboard)..." checks, and the second (much smaller) patch which adds
> > the inert_pointer_interface, inert_keyboard_interface, etc. parts which
> > are what you actually need the review on.  The pointer checking is
> > obviously a safe refactoring that can be landed with minimal review.
> > 
> 
> Well I can do this way but the 2 patches are linked. In the current
> code, once a keyboard has been created, you can't have a null
> seat->keyboard_state. So in the current situation, I'm not sure the
> checks are really needed .

Note that for grabs, when you loose the seat i.e. the actual device, I
think it makes sense to cancel the grab before the device is destroyed
which means there may be places where added NULL checks are unnecessary
(i.e. everywhere in or calls originating from grab handlers).


Jonas

> 
> >>> Thanks for tending to the test code too in the refactor; it would be
> >>> grand to see a test case added to keyboard-test or devices-test to
> >>> exercise the case of handling inert input objects.
> >>>
> >>
> >> Such a test is already there in the existing tests. In
> >> get_device_after_destroy of devices-test.c, we already exercise inert
> >> objects.
> > 
> > Apparently it is not exercised sufficiently, because it passes already
> > without your fix.
> > 
> 
> Well you're right: in the current code input objects are never released,
> so the calls are done on used objects without any visible side effect.
> In fact, there's a side effect when calling wl_pointer.set_cursor on a
> released pointer: the surface is given the mouse pointer role. Using
> inert objects, you're just sure that there will be no side effect at
> all. As I said It think it's also the first step to make it possible to
> safely release the full seat.
> 
> > But you're right that this test case looks like a good place for you to
> > add more coverage for this bug.  Does the current test pass without your
> > fix because it is not making deep enough wayland calls?  I.e. does it
> > need to do more than merely a wl_pointer_set_cursor call?
> > 
> > Also, it appears this test isn't doing the same checking for keyboard
> > and touch as it does for pointer; even though internally all three are
> > implemented the same way, there are three different protocol routines
> > involved here (wl_seat_get_pointer, wl_seat_get_keyboard, and
> > wl_seat_get_touch), any of which could present their own bugs, so proper
> > test coverage should methodically check all three.
> > 
> 
> +1 for testing all input objects.
> 
> Best regards.
> 
> -- 
> David FORT
> website: http://www.hardening-consulting.com/
> 
> ___
> 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

Re: Unstable protocol name breakage

[Jonas Ådahl]

On Tue, Oct 20, 2015 at 09:51:34AM +0200, Jan Arne Petersen wrote:
> Hi,
> 
> On 20/10/15 04:22, Jonas Ådahl wrote:
> > input-method.xml: This one I think might actually be fine to just apply the
> > naming schema, as the protocol itself has Wayland core principle violations
> > that need to be solved, i.e. any implementor of this is already broken (by
> > principle).
> > 
> > text.xml: This one I'm not so sure about. Has it ever been implemented 
> > outside
> > of weston except only as a proof of concept? Would it be fine to use the 
> > same
> > name?
> 
> I would suggest to just use zwl_...v1 names for both protocols for now.
> We can decide later if we want to use a different stable name for them
> (they both need to be fixed in a non backward compatible way anyways).

Ok. I will try to remember to CC you on the corresponding weston patches
that does the renaming so you can ack or review the actual change.


Jonas

> 
> Regards
> Jan Arne
> 
> -- 
> Jan Arne Petersen | jan.peter...@kdab.com | Senior Software Engineer
> KDAB (Deutschland) GmbH KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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

Re: Unstable protocol name breakage

[Jonas Ådahl]

On Tue, Oct 20, 2015 at 06:42:24AM +0200, Mariusz Ceier wrote:
> On 20 October 2015 at 05:59, Jonas Ådahl  wrote:
> 
> > On Tue, Oct 20, 2015 at 05:26:45AM +0200, Mariusz Ceier wrote:
> > > Hi,
> > >
> > > On 20 October 2015 at 04:22, Jonas Ådahl  wrote:
> > >
> > > > Hi again,
> > > >
> > > > I was about to start migrating generic protocols away from weston into
> > > > wayland-protocols. The idea was to start with input-method.xml,
> > text.xml,
> > > > linux-dmabuf.xml, presentation_timing.xml, scaler.xml and
> > xdg-shell.xml.
> > > > The
> > > > question, however, is what to do with the names, because some names
> > already
> > > > have the form "wl_[name]", and renaming such an interface to
> > "zwl_[name]1"
> > > > during the unstable period, and then back to "wl_[name]" will cause
> > > > potential
> > > > breakage because some implementations in the wild might expect the
> > > > "wl_[name]"
> > > > to be the original (ancient) version.
> > > >
> > > > As mentioned before, I have already moved the fullscreen shell
> > protocol,
> > > > and
> > > > with the naming schema changes in place, it ended up with the protocol
> > name
> > > > "fullscreen-shell-unstable-v1", the interfaces zwl_fullscreen_shell1,
> > and
> > > > zwl_fullscreen_shell_mode_feedback1.
> > > >
> > > > linux-dmabuf.xml is also easy. Since it is already 'z' prefix, to
> > comply
> > > > with
> > > > the intended naming schema, I'd just need to rename the interfaces to
> > > > zlinux_dmabuf1 and zlinux_buffer_params1, and the protocol to
> > > > linux-dmabuf-unstable-v1.
> > > >
> > > > presentation_timing.xml: I suppose this one can be renamed without any
> > > > significant implications, since it currently is completely prefix
> > free. I
> > > > imagine it'd be zwl_presentation1 and zwl_presentation_feedback1 in a
> > > > presentation-timing-unstable-v1(.xml) protocol.
> > > >
> > > > The problem is the rest of the protocols, since they all already have
> > the
> > > > intended stable names. This means we cannot apply a naming schema that
> > > > intends
> > > > to finally remove the prefix and postfix when declaring stable, since
> > that
> > > > would collide with the initial name. How to deal with these names
> > needs to
> > > > be
> > > > decided, and probably so protocol by protocol.
> > > >
> > > > scalar.xml: As far as I know, Pekka has plans to change scalar.xml, and
> > > > plan to
> > > > do so with a name change. So as far as I understand, we need to rename
> > this
> > > > one.
> > > >
> > > > input-method.xml: This one I think might actually be fine to just
> > apply the
> > > > naming schema, as the protocol itself has Wayland core principle
> > violations
> > > > that need to be solved, i.e. any implementor of this is already broken
> > (by
> > > > principle).
> > > >
> > > >
> > > Since it's broken by principle, can't input-method.xml be marked as
> > > deprecated (e.g. by implementing/using top-level deprecated attribute ) ?
> > > Then leave it in weston as weston-specific protocol, that generates
> > > deprecation warnings during compilation and maybe when used by clients
> > > connecting to weston; and in wayland-protocols add new protocol that's
> > not
> > > broken by principle (but may be based on input-method).
> >
> > Not sure what you mean with top-level deprecated attribute (attributes
> > on some C code? or disable the text-backend by default whith a warning
> > if its enabled?).
> 
> 
> I meant adding deprecated attribute to top-level  element in .xml
> file, that would instruct
> wayland scanner to generate deprecated attributes for every interface
> that's defined in this xml file.

It will only make building weston produce lots of warnings. It won't
affect the third party clients since they still have their own copies.

> 
> If we disable it by default we'd just break third
> > party clients (and can just as well move and rename), and I don't think
> > we should have compiler warning by default.
> >
> >
> I didn't mean disabling it - just generate deprecation warning at runtime
> (in weston) and compile time when client uses deprecated protocol.
> 
> I don't know if it should be deprecated though; the broken-ness is that
> > it breaks the single-origin of object factories because it creates a
> > wl_keyboard, but that can be fixed.
> >
> >
> Will the fix most likely break existing clients ?

Yes.

> If yes - do we care about that (since protocol is not yet stable, we don't
> have to) ? If yes - IMO current input-method should be deprecated, left in
> weston (as weston-specific) and new protocol created in wayland-protocols.
> In all other situations - input-method.xml should be fixed, 'z' prefix
> added and such modified protocol moved to wayland-protocols.

This is the question I asked, and I was hoping the author / maintainer
of those protocols could make that call.


Jonas

> 
> If wl_input_method is no longer expected to be used by anyone, nor be
> > fixed, 

Re: [PATCH libinput 2/2] extend tools to print and display touch event properties

[Peter Hutterer]

On Sun, Sep 06, 2015 at 02:55:13PM +0200, Andreas Pokorny wrote:
> event-gui draws the touch contact as two concentric ellipses that indicate
> contact pressure through oppacity.
> 
> Signed-off-by: Andreas Pokorny 
> ---
>  tools/event-debug.c | 30 --
>  tools/event-gui.c   | 30 --
>  2 files changed, 56 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/event-debug.c b/tools/event-debug.c
> index 1ac0086..3ee9907 100644
> --- a/tools/event-debug.c
> +++ b/tools/event-debug.c
> @@ -300,14 +300,40 @@ print_touch_event_with_coords(struct libinput_event *ev)
>   double y = libinput_event_touch_get_y_transformed(t, screen_height);
>   double xmm = libinput_event_touch_get_x(t);
>   double ymm = libinput_event_touch_get_y(t);
> + double major = libinput_event_touch_get_major_transformed(
> + t,
> + screen_width,
> + screen_height);
> + double minor = libinput_event_touch_get_minor_transformed(
> + t,
> + screen_width,
> + screen_height);
> + double majormm = libinput_event_touch_get_major(t);
> + double minormm = libinput_event_touch_get_minor(t);
> + double pressure = libinput_event_touch_get_pressure(t);
> + double orientation = libinput_event_touch_get_orientation(t);
> + int has_major = libinput_event_touch_has_major(t);
> + int has_minor = libinput_event_touch_has_minor(t);
> + int has_orientation = libinput_event_touch_has_orientation(t);
> + int has_pressure = libinput_event_touch_has_pressure(t);
>  
>   print_event_time(libinput_event_touch_get_time(t));
>  
> - printf("%d (%d) %5.2f/%5.2f (%5.2f/%5.2fmm)\n",
> + printf("%d (%d) %5.2f/%5.2f (%5.2f/%5.2fmm) %5.2f/%5.2f "
> +"(%5.2f/%5.2fmm) %3.2f° %1.5f [%d%d%d%d]\n",
>  libinput_event_touch_get_slot(t),
>  libinput_event_touch_get_seat_slot(t),
>  x, y,
> -xmm, ymm);
> +xmm, ymm,
> +major, minor,
> +majormm, minormm,
> +orientation,
> +pressure,
> +has_major,
> +has_minor,
> +has_orientation,
> +has_pressure
> +);

whoah, this line gets quite confusing, especially the [1110] at the end (in
my case). can we split this up, so that you only print the values we
actually have?

I'm also going to argue that one decimal precision for the angle
is enough, and two decimals for pressure.

>  }
>  
>  static void
> diff --git a/tools/event-gui.c b/tools/event-gui.c
> index 0b0e9d7..7c2b546 100644
> --- a/tools/event-gui.c
> +++ b/tools/event-gui.c
> @@ -49,6 +49,9 @@ struct tools_context context;
>  struct touch {
>   int active;
>   int x, y;
> + double major, minor;
> + double angle;
> + double pressure;
>  };
>  
>  struct window {
> @@ -179,12 +182,21 @@ draw(GtkWidget *widget, cairo_t *cr, gpointer data)
>   cairo_restore(cr);
>  
>   /* touch points */
> - cairo_set_source_rgb(cr, .8, .2, .2);
>  
>   ARRAY_FOR_EACH(w->touches, t) {
>   cairo_save(cr);
> - cairo_arc(cr, t->x, t->y, 10, 0, 2 * M_PI);
> + /* paint a filled ellipse with the original major minor values 
> */
> + cairo_set_source_rgba(cr, .8, .2, .2, 0.5 + t->pressure / 2.);
> + cairo_translate (cr, t->x, t->y);
> + cairo_rotate(cr, t->angle * (M_PI / 180.0));
> + cairo_scale (cr, t->minor, t->major);

(event-gui:21643): Gtk-WARNING **: drawing failure for widget
`GtkDrawingArea': invalid matrix (not invertible)

(event-gui:21643): Gtk-WARNING **: drawing failure for widget `GtkWindow':
invalid matrix (not invertible)

minor/major are 0/0 here, mostly because my screen returns garbage for
major/minor (0.31mm) but this needs to be caught.

Cheers,
   Peter



> + cairo_arc(cr, 0., 0., 1., 0, 2 * M_PI);
>   cairo_fill(cr);
> +
> + /* paint a larger surrounding ellipse */
> + cairo_arc(cr, 0., 0., 4., 0, 2 * M_PI);
> + cairo_stroke(cr);
> +
>   cairo_restore(cr);
>   }
>  
> @@ -394,6 +406,8 @@ handle_event_touch(struct libinput_event *ev, struct 
> window *w)
>   int slot = libinput_event_touch_get_seat_slot(t);
>   struct touch *touch;
>   double x, y;
> + double major;
> + double minor;
>  
>   if (slot == -1 || slot >= (int) ARRAY_LENGTH(w->touches))
>   return;
> @@ -407,10 +421,22 @@ handle_event_touch(struct libinput_event *ev, struct 
> window *w)
>  
>   x = libinput_event_touch_get_x_transformed(t, w->width),
>   y = libinput_event_touch_get_y_transformed(t, w->height);
> + major = libinput_event_touch_get_major_transformed(t, w->width, 
> w->height);
> + minor = libinput_event_touch_get_minor_transformed(t, w->width, 
> w->height);
> +
> + 

[ANNOUNCE] libinput 1.0.2

[Peter Hutterer]

libinput 1.0.2 is now available.

This release contains two tapping fixes. A multitap (triple tap, quadruple
tap, ...) caused one too many click events, particularly noticable during a
double-tap-and-hold dragging process.

The second fix avoids erroneous click events when two fingers are placed on
the touchpad and one finger is released within the tap timeout. This can
happen when executing short but frequent two-finger scroll movements.

Peter Hutterer (3):
  touchpad: don't tap for 2fg down, followed by a single finger up
  touchpad: fix the number of button clicks in multitap
  configure.ac: libinput 1.0.2

git tag: 1.0.2

http://www.freedesktop.org/software/libinput/libinput-1.0.2.tar.xz
MD5:  ec3690c1770ec411192d4b43e73974f5  libinput-1.0.2.tar.xz
SHA1: ed0f9cfe0211cc5e751130fc3cfae30312c7087b  libinput-1.0.2.tar.xz
SHA256: a3d105f86bd21f8cfb7b97ed018ef025453b1cce98ff33bd57f564c4515cefb9  
libinput-1.0.2.tar.xz
PGP:  http://www.freedesktop.org/software/libinput/libinput-1.0.2.tar.xz.sig



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