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

[Bill Spitzak]

On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone  wrote:

> Hi,
>
> On 12 January 2016 at 22:28, Bill Spitzak  wrote:
> > There should *only* be "one shot" requests, which are very quickly
> accepted
> > or denied by the compositor. The client creates it in response to an
> input
> > event, and it includes the input event id.
> >
> > Most/all things that triggers pointer lock (the mouse entering the
> region,
> > the mouse being pressed in the region, a press+release in the region, a
> > keystroke) could be implemented by clients and it does not do any pointer
> > lock protocol until after it has detected the triggering event, and thus
> can
> > include the event id.
>
> For what it's worth - post-hoc expansion on my reasoning - I think
> Bill has the genesis of a point here. Usually, our requests have
> followed one of two patterns: either you request activation in
> response to a specific event (button or key event allows you to create
> a selection), or retained state (creating a wl_data_device gets you
> selection/etc events on that seat until you destroy it).
>
> The proposed one-shot-but-delayed request to me felt like a really
> awkward compromise between the two, and not really one backed up by a
> strong enough usecase to justify a third (delayed but not retained)
> model for requests taking effect.
>
> It's entirely possible that there's something I'm missing here, but
> for consistency if nothing else, having the split instead be between
> these two classic methods (oneshot-immediate vs. fully-retained,
> rather than oneshot-delayed vs. fully-retained) could be good for
> future versions.
>

I would agree there is something missing here.

I do not see any reason for anything other than a "one shot" which is
created by the client *AFTER* it receives the possibly-triggering input
event. I am still waiting for a description of how one of these pre-set
locks is triggered, I have serious doubts that any possible trigger could
be something other than an action that would send an event to the client,
or at a moment the client is doing something like configuring the surface.

Nor do I see any problem with race conditions provided the one-shot request
has an id for the triggering event:

- Client gets event that it thinks should trigger pointer-lock/confine

- Client sends pointer-lock/confine request which includes the event serial
number (and creates the pointer-lock proxy object)

- Client can read relative motion events (these are identical whether or
not pointer lock works, and also correct for motion before the pointer lock
request was received by the compositor). Client can also read absolute
pointer motion events, but it needs to know these change depending on
whether they are before or after the accept event.

- Client can change the confinement region (ie it can move the cursor).
These are ignored if pointer lock has been rejected or has expired

- Client (may) get an accepted event stating that pointer lock worked.

- Client gets a cancelled event. If it did not get an accepted event then
it knows pointer lock did not work.

Imagine the compositor cancels pointer-lock on the next mouse-up event, and
a client tries to grab pointer-lock on mouse down. Normal event sequence
(--> indicates requests)

  button-down event
  --> pointer lock request
  --> set cursor image
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  accepted event
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  button-up event
  cancelled event
  motion/enter/exit events due to grab being lost
  --> set cursor image

Now imagine the simplest race, where the compositor sees the mouse button
being released before it gets the pointer-lock request:

  button-down event
  --> pointer lock request
  --> set cursor image
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  button-up event
  motion/enter/exit events due to grab being lost
  cancelled event (due to compositor finally seeing the pointer lock
request)
  --> set cursor image

Client can tell this happened because it did not get an accepted event. But
it is also interesting that a client may not care: it should act exactly
the same and to the user it looks like the pointer-lock gesture worked,
except the end position of the cursor is different.

I can imagine schemes where the end cursor position is correct, but I think
it requires putting an event serial number on the cursor motion requests.
The idea is that if the mouse button has not been pressed again, it is
warped back to the set position plus the result of any later motion events.
Compositor sends accepted+cancelled to indicate this happened. Not sure if
it is worth the complexity however.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

Re: [PATCH wayland v10 2/2] protocol: Add DnD actions

[Bill Spitzak]

> +   While managing an "ask" action, the destination drag-and-drop
> client
> +   may perform further wl_data_offer.receive requests, and is expected
> +   to perform one last wl_data_offer.set_actions request with a
> preferred
> +   action other than "ask" (and optionally wl_data_offer.accept)
> before
> +   requesting wl_data_offer.finish, in order to convey the action
> selected
> +   by the user. If the preferred action is not in the
> +   wl_data_offer.source_actions mask, an error will be raised.
>

Sorry, this is still not answering the question.

Please describe exactly what happens when a source sends COPY+MOVE, and
contrast it with exactly what happens when a source sends COPY+MOVE+ASK.

My current guess is that the only effect of ASK is to stop the compositor
from restricting the set if there are no modifiers down.

A much more tedious and complete answer that might solve some of this
mystery:

There are three sets of actions in the api:

- The source supplied set
- The destination supplied set
- The compositor-produced intersection of these sets, further modified by
modifier keys.

There are also six different sets of actions of interest:

- The empty set
- A single action other than ASK
- More than one action but without ASK
- ASK by itself
- ASK with a single other action
- ASK with more than one other action

For all eighteen possible combinations of the above three parts of the api
and six types of sets, can you answer:

- Is it valid (can a correctly-operating source, destination, and
compositor produce them?)
- What does it mean? Basically contrast it with what happens if the ASK bit
is inverted.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 5/7] tablet: add support for relative x/y motion deltas

[Bill Spitzak]

Isn't dx_unaccelerated exactly equal to the differences between x values?

If not then I suspect the only difference is a linear scaling (ie between
tablet-width/height or mm or whatever the xy are using and the pointer-like
coordinates the dx are using).

I think it would be less confusing if everything used the same coordinate
space. However having the driver indicate how big a "pointer like unit" is
in this coordinate system is useful. A client can use this to automatically
switch between absolute and relative mode depending on whether the scaling
from pointer motion in absolute mode exceeds this value too much, or if the
aspect ratio differs too much.


On Thu, Jan 14, 2016 at 4:26 PM, Peter Hutterer 
wrote:

> Instead of an explicit tablet mode that device must be changed into, let
> the
> caller decide which coordinates are preferred. The tablet mode may be
> application-specific and usually depends on the tool as well.
>
> This patch adds an interface to get a motion delta for the x/y axes in
> pixel-like coordinates and as raw unaccelerated delta. In the former case,
> libinput will provide some magic to convert the tablet data into something
> that resembles pixels from a mouse motion. In the latter case, we normalize
> to the x resolution so the caller doesn't have to account for uneven
> resolutions, but otherwise leave the data untouched.
> A caller can either query the x resolution and base the rest on that, or
> just
> guess a magic factor to apply.
>
> Signed-off-by: Peter Hutterer 
> ---
>  doc/normalization-of-relative-motion.dox |  4 ++
>  doc/tablet-support.dox   | 29 +++
>  src/libinput-private.h   |  2 +
>  src/libinput.c   | 52 ++
>  src/libinput.h   | 63
> 
>  src/libinput.sym |  4 ++
>  6 files changed, 154 insertions(+)
>
> diff --git a/doc/normalization-of-relative-motion.dox
> b/doc/normalization-of-relative-motion.dox
> index 31596a9..478e727 100644
> --- a/doc/normalization-of-relative-motion.dox
> +++ b/doc/normalization-of-relative-motion.dox
> @@ -38,6 +38,10 @@ libinput scales unaccelerated touchpad motion to the
> resolution of the
>  touchpad's x axis, i.e. the unaccelerated value for the y axis is:
>   y = (x / resolution_x) * resolution_y
>
> +@section motion_normalization_tablet Normalization of tablet coordinates
> +
> +See @ref tablet-relative-motion
> +
>  @section Setting custom DPI settings
>
>  Devices usually do not advertise their resolution and libinput relies on
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index 7207a47..1bc8733 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -52,6 +52,35 @@ Note that the pressure threshold to trigger a logical
> tip event may be zero
>  on some devices. On tools without pressure sensitivity, determining when a
>  tip is down is device-specific.
>
> +@section tablet-relative-motion Relative motion for tablet tools
> +
> +libinput calculates the relative motion vector for each event and converts
> +it to the same coordinate space that a normal mouse device would use. For
> +the caller, this means that the delta coordinates returned by
> +libinput_event_tablet_tool_get_dx() and
> +libinput_event_tablet_tool_get_dy() can be used identical to the delta
> +coordinates from any other pointer event. Any resolution differences
> between
> +the x and y axes are accommodated for, a delta of N/N represents a 45
> degree
> +diagonal move on the tablet.
> +
> +The delta coordinates are available for all tablet events, it is up to the
> +caller to decide when a tool should be used in relative mode. It is
> +recommended that mouse and lens cursor tool default to relative mode and
> +all pen-like tools to absolute mode.
> +
> +If a tool in relative mode must not use pointer acceleration, a caller
> +should use the delta coordinates returned by
> +libinput_event_tablet_tool_get_dx_unaccelerated() and
> +libinput_event_tablet_tool_get_dy_unaccelerated() instead. These
> +deltas are in raw device coordinates, it is up to the caller to map the
> raw
> +device units into pixel movements. libinput normalizes the coordinates to
> +the resolution of the x axis. Thus, an unaccelerated delta of N/N
> represents
> +a 45 degree diagonal move on the tablet.
> +
> +Callers that require exact physical distance should use the
> +absolute coordinates provided by libinput_event_tablet_tool_get_x() and
> +libinput_event_tablet_tool_get_y() and calculate the delta themselves.
> +
>  @section tablet-axes Special axes on tablet tools
>
>  A tablet tool usually provides additional information beyond x/y
> positional
> diff --git a/src/libinput-private.h b/src/libinput-private.h
> index ff43d00..1e6ae90 100644
> --- a/src/libinput-private.h
> +++ b/src/libinput-private.h
> @@ -71,6 +71,8 @@ 

[PATCH wayland] protocol: Add note about per version requirements to wl_data_device_manager

[Jonas Ådahl]

Add a note to the wl_data_device_manager global interface about the
different requirements for operating the objects created from the bound
global.

Signed-off-by: Jonas Ådahl 
---

Pekka suggested we should add a note about the per version requirements
(wl_data_source.set_actions, wl_data_offer.accept and wl_data_offer.finish
during DND), see here is such a paragraph.


Jonas


 protocol/wayland.xml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index b223bb4..8739cd3 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -910,6 +910,11 @@
   copy-and-paste and drag-and-drop.  These mechanisms are tied to
   a wl_seat and this interface lets a client get a wl_data_device
   corresponding to a wl_seat.
+
+  Depending on the version bound, the objects created from the bound
+  wl_data_device_manager object will have different requirements for
+  functioning properly. See wl_data_source.set_actions,
+  wl_data_offer.accept and wl_data_offer.finish for details.
 
 
 
-- 
2.4.3

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

[PATCH wayland v4] tests: Test proxy versions

[Derek Foreman]

Add a test that confirms that proxy versions are always 0 for display
and correct otherwise.

Signed-off-by: Derek Foreman 
---
Patch broke when Jonas added user data to client_create, so I took
the hint and re-implemented using user data instead of a global variable.


 tests/display-test.c | 125 +++
 1 file changed, 116 insertions(+), 9 deletions(-)

diff --git a/tests/display-test.c b/tests/display-test.c
index 0d25ca3..1a6c345 100644
--- a/tests/display-test.c
+++ b/tests/display-test.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "wayland-private.h"
 #include "wayland-server.h"
@@ -102,16 +103,48 @@ TEST(tc_leaks_tests)
display_destroy(d);
 }
 
+/* This is how pre proxy-version registry binds worked,
+ * this should create a proxy that shares the display's
+ * version number: 0 */
+static void *
+old_registry_bind(struct wl_registry *wl_registry,
+ uint32_t name,
+ const struct wl_interface *interface,
+ uint32_t version)
+{
+   struct wl_proxy *id;
+
+   id = wl_proxy_marshal_constructor(
+   (struct wl_proxy *) wl_registry, WL_REGISTRY_BIND,
+   interface, name, interface->name, version, NULL);
+
+   return (void *) id;
+}
+
+struct handler_info {
+   struct wl_seat *seat;
+   uint32_t bind_version;
+   bool use_unversioned;
+};
+
 static void
 registry_handle_globals(void *data, struct wl_registry *registry,
uint32_t id, const char *intf, uint32_t ver)
 {
-   struct wl_seat **seat = data;
+   struct handler_info *hi = data;
+
+   /* This is only for the proxy version test */
+   if (hi->bind_version)
+   ver = hi->bind_version;
 
if (strcmp(intf, "wl_seat") == 0) {
-   *seat = wl_registry_bind(registry, id,
-_seat_interface, ver);
-   assert(*seat);
+   if (hi->use_unversioned)
+   hi->seat = old_registry_bind(registry, id,
+_seat_interface, ver);
+   else
+   hi->seat = wl_registry_bind(registry, id,
+   _seat_interface, ver);
+   assert(hi->seat);
}
 }
 
@@ -121,19 +154,31 @@ static const struct wl_registry_listener 
registry_listener = {
 };
 
 static struct wl_seat *
-client_get_seat(struct client *c)
+client_get_seat_with_info(struct client *c, struct handler_info *hi)
 {
-   struct wl_seat *seat;
struct wl_registry *reg = wl_display_get_registry(c->wl_display);
assert(reg);
 
-   wl_registry_add_listener(reg, _listener, );
+   assert(hi);
+   hi->seat = NULL;
+   wl_registry_add_listener(reg, _listener, hi);
wl_display_roundtrip(c->wl_display);
-   assert(seat);
+   assert(hi->seat);
 
wl_registry_destroy(reg);
 
-   return seat;
+   return hi->seat;
+}
+
+static struct wl_seat *
+client_get_seat(struct client *c)
+{
+   struct handler_info hi;
+
+   hi.use_unversioned = false;
+   hi.bind_version = 0;
+
+   return client_get_seat_with_info(c, );
 }
 
 static void
@@ -769,3 +814,65 @@ TEST(error_code_after_epipe)
 
display_destroy(d);
 }
+
+static void
+check_seat_versions(struct wl_seat *seat, uint32_t ev)
+{
+   struct wl_pointer *pointer;
+
+   assert(wl_proxy_get_version((struct wl_proxy *) seat) == ev);
+   assert(wl_seat_get_version(seat) == ev);
+
+   pointer = wl_seat_get_pointer(seat);
+   assert(wl_pointer_get_version(pointer) == ev);
+   assert(wl_proxy_get_version((struct wl_proxy *) pointer) == ev);
+   wl_proxy_destroy((struct wl_proxy *) pointer);
+}
+
+/* Normal client with proxy versions available. */
+static void
+seat_version(void *data)
+{
+   struct handler_info *hi = data;
+   struct client *c = client_connect();
+   struct wl_seat *seat;
+
+   /* display proxy should always be version 0 */
+   assert(wl_proxy_get_version((struct wl_proxy *) c->wl_display) == 0);
+
+   seat = client_get_seat_with_info(c, hi);
+   if (hi->use_unversioned)
+   check_seat_versions(seat, 0);
+   else
+   check_seat_versions(seat, hi->bind_version);
+
+   wl_proxy_destroy((struct wl_proxy *) seat);
+
+   client_disconnect_nocheck(c);
+}
+
+TEST(versions)
+{
+   struct display *d = display_create();
+   struct wl_global *global;
+   int i;
+
+   global = wl_global_create(d->wl_display, _seat_interface,
+ 5, d, bind_seat);
+
+   for (i = 1; i <= 5; i++) {
+   struct handler_info hi;
+
+   hi.bind_version = i;
+   hi.use_unversioned = false;
+   client_create(d, seat_version, );
+   hi.use_unversioned 

Re: [PATCH libinput 5/7] tablet: add support for relative x/y motion deltas

[Bill Spitzak]

On 01/17/2016 02:26 PM, Peter Hutterer wrote:

On Fri, Jan 15, 2016 at 12:06:27PM -0800, Bill Spitzak wrote:

Isn't dx_unaccelerated exactly equal to the differences between x values?


hah, yes. indeed. that actually means we can drop it from the API since a
client can use the mm value instead, they are effectively equivalent (but
more useful) than the raw device coordinates and account for uneven
resolution better anyway.


I think the following text is confusing and is what led me to think that 
the coordinate systems might be different:


>>> +libinput calculates the relative motion vector for each event and 
converts

>>> +it to the same coordinate space that a normal mouse device would use.

I guess that all coordianates except for raw ones are "converted to the 
space that a normal mouse device would use" but this seems to imply that 
dx/dy are special. Maybe this text can be moved somewhere to make it 
clear it applies to everything other than raw output.



Whether you use the device in an absolute or relative mode is a very
user-specific thing, I doubt you can handle this automatically. mode is also
a very tool-specific thing, you may want the mouse to be in relative mode
but the pen in absolute mode.


Although some devices such as the mouse may want to be in relative mode 
all the time, I believe the "absolute" devices will want to be in 
relative mode if the mapping from the tablet to the screen is either too 
large of a scale-up (ie the screen is much larger than the tablet) or 
the aspect ratio is significantly different (though this might just mean 
that one dimension is scaled beyond a maximum). This is certainly true 
of my current setup and I can't believe it is uncommon. Absolute mode on 
this tablet is completely useless! Except for programs that restrict the 
motion to a smaller window that is about the shape of the tablet.


I think this would also help it guess the correct mode automatically 
when the user changes their tablet or their screens.



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

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

[Daniel Stone]

Hi,

On 15 January 2016 at 19:30, Bill Spitzak  wrote:
> On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone  wrote:
>> The proposed one-shot-but-delayed request to me felt like a really
>> awkward compromise between the two, and not really one backed up by a
>> strong enough usecase to justify a third (delayed but not retained)
>> model for requests taking effect.
>>
>> It's entirely possible that there's something I'm missing here, but
>> for consistency if nothing else, having the split instead be between
>> these two classic methods (oneshot-immediate vs. fully-retained,
>> rather than oneshot-delayed vs. fully-retained) could be good for
>> future versions.
>
> I would agree there is something missing here.
>
> I do not see any reason for anything other than a "one shot" which is
> created by the client *AFTER* it receives the possibly-triggering input
> event.

I can see the reasoning behind it, at least. I'm not sure I agree, but
those aren't the same thing.

> I am still waiting for a description of how one of these pre-set
> locks is triggered, I have serious doubts that any possible trigger could be
> something other than an action that would send an event to the client, or at
> a moment the client is doing something like configuring the surface.

Yes, the triggers would involve events being sent to clients indeed.
Codifying every exact trigger would be borderline impossible, and
unnecessarily restrictive to compositors, so I don't think there's any
need to do that.

> Nor do I see any problem with race conditions provided the one-shot request
> has an id for the triggering event:

The race here is that if you react on pointer entry, having a one-shot
request will mean that the events you get in between entry and the
request activating, won't be relative. I can imagine that being
frustrating to users.

> - Client can read relative motion events (these are identical whether or not
> pointer lock works,

???

Relative motion does not occur without lock.

Anyway, I think we all largely agree on the details, so let's look for
the implementations (compositor and client) both, and see what
real-world feedback falls out of those.

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

Re: [PATCH wayland] protocol: Add note about per version requirements to wl_data_device_manager

[Carlos Garnacho]

Hey Jonas,

On Mon, Jan 18, 2016 at 11:18 AM, Jonas Ådahl  wrote:
> Add a note to the wl_data_device_manager global interface about the
> different requirements for operating the objects created from the bound
> global.
>
> Signed-off-by: Jonas Ådahl 
> ---
>
> Pekka suggested we should add a note about the per version requirements
> (wl_data_source.set_actions, wl_data_offer.accept and wl_data_offer.finish
> during DND), see here is such a paragraph.

Oh indeed. Makes sense to mention this in wl_data_device_manager docs,

Reviewed-by: Carlos Garnacho 

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

Re: [PATCH weston v4 07/20] libinput: Expose unaccelerated motion deltas in motion event struct

[Daniel Stone]

Hi,

On 17 November 2015 at 10:10, Jonas Ådahl  wrote:
> Signed-off-by: Jonas Ådahl 

Apparently I just noted this locally, rather than on the list, but:
Reviewed-by: Daniel Stone 

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

Re: [PATCH wayland-protocols 3/3] xdg-shell: Introduce xdg_tooltip

[Mike Blumenkrantz]

On Sun, 17 Jan 2016 10:37:09 +0800
Jonas Ådahl  wrote:

> On Sat, Jan 16, 2016 at 03:07:00PM -0500, Mike Blumenkrantz wrote:
> > On Sat, 16 Jan 2016 10:28:20 +0800
> > Jonas Ådahl  wrote:
> >   
> > > On Fri, Jan 15, 2016 at 09:19:34PM -0500, Mike Blumenkrantz wrote:  
> > > > Hi,
> > > > 
> > > > I have some suggestions which I've inlined below:
> > > > 
> > > > On Tue, 12 Jan 2016 16:16:49 +0800
> > > > Jonas Ådahl  wrote:
> > > > 
> > > > > An xdg_tooltip is a new window type used to implement tooltip like
> > > > > surfaces. See the interface documentation for details.
> > > > > 
> > > > > Signed-off-by: Jonas Ådahl 
> > > > > ---
> > > > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 47 
> > > > > 
> > > > >  1 file changed, 47 insertions(+)
> > > > > 
> > > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > index 276d9fc..91f657a 100644
> > > > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > @@ -183,6 +183,23 @@
> > > > >
> > > > >  
> > > > >  
> > > > > +
> > > > > +  
> > > > > + This creates an xdg_tooltip for the given xdg_surface and gives 
> > > > > the
> > > > > + associated wl_surface the xdg_tooltip role. A wl_surface can 
> > > > > only have
> > > > > + one xdg_tooltip role. If the wl_surface is given the 
> > > > > xdg_tooltip role
> > > > > + while it already has an active xdg_tooltip role, or if it has 
> > > > > been given
> > > > > + any other role before, an error is raised.
> > > > 
> > > > I think my comment on the first patch proves its relevance here as this 
> > > > section could
> > > > be greatly shortened by specifying singular surface role semantics in 
> > > > xdg_surface.
> > > > 
> > > > > +
> > > > > + See the documentation of xdg_tooltip for more details about 
> > > > > what an
> > > > > + xdg_tooltip is and how it is used.
> > > > > +  
> > > > > +  
> > > > > +  
> > > > > +  
> > > > > +  
> > > > > +
> > > > > +
> > > > >  
> > > > >
> > > > >   The window geometry of a surface is its "visible bounds" from 
> > > > > the
> > > > > @@ -666,4 +683,34 @@
> > > > >  
> > > > >
> > > > >  
> > > > > +  
> > > > > +
> > > > > +  This interface defines an xdg_tooltip role that provides 
> > > > > functionality
> > > > > +  related to tooltip like surfaces.
> > > > > +
> > > > > +  An xdg_tooltip is temporary a surface that is part of another 
> > > > > xdg_surface
> > > > > +  (such as xdg_toplevel or xdg_popup) such as a tooltip above a 
> > > > > UI widget. It
> > > > > +  will always be mapped above both its parent and if the parent 
> > > > > has a
> > > > > +  xdg_popup child it will also be mapped above that and all 
> > > > > other possible
> > > > > +  chained xdg_popup surfaces.
> > > > 
> > > > "An xdg_tooltip is a temporary surface which is displayed over its 
> > > > parent xdg_surface.
> > > > The last-created xdg_tooltip surface will always be the top-most child 
> > > > of the parent xdg_surface."
> > > > 
> > > > > +
> > > > > +  The parent surface must either have the surface role 
> > > > > xdg_toplevel,
> > > > > +  xdg_popup or xdg_tooltip.
> > > > > +
> > > > > +  Being different from xdg_popup, it does not take an active 
> > > > > grab while
> > > > > +  being mapped, and it will never be automatically dismissed by 
> > > > > any
> > > > > +  predefined user interaction. The client must itself unmap it 
> > > > > using the
> > > > > +  xdg_tooltip.destroy request.
> > > > 
> > > > Wouldn't it be enough to have
> > > > 
> > > > "An xdg_tooltip does not take an active grab while mapped. xdg_tooltip 
> > > > surfaces are
> > > > either directly unmapped by clients using the xdg_tooltip.destroy 
> > > > request or indirectly
> > > > unmapped when their parent surface is unmapped."
> > > > 
> > > > > +
> > > > > +  An xdg_tooltip can receive input assuming it has an input 
> > > > > region.
> > > > 
> > > > "An xdg_tooltip obeys normal input region semantics." or similar ?
> > > > 
> > > > > +
> > > > > +  If for some reason its parent is unmapped, for example if the 
> > > > > parent is a
> > > > > +  popup being dismissed, the tooltip will be unmapped as well.   
> > > > >  
> > > > 
> > > > I think this is now covered a few lines up?
> > > 
> > > Hmm. You mean about "always be made top-most child"? It doesn't make it
> > > clear what happens if the parent is unmapped though.  
> > 
> > I'm not sure exactly what you mean by this. I think stating that a tooltip 
> > will be
> > "unmapped when their parent surface is unmapped" is fairly clear, no?  
> 
> I mean that the only place that adds "unmapped 

[PATCH v2 libinput 6/7] tablet: hook up relative motion events

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
Acked-by: Jason Gerecke 
---
Changes to v1:
- updated for removal of the dx/dy unaccel coordinates

 doc/pointer-acceleration.dox |   6 ++
 src/evdev-tablet.c   | 116 +---
 src/evdev.c  |  13 +++
 src/evdev.h  |   4 +
 src/filter.c |  94 
 src/filter.h |   3 +
 src/libinput-util.h  |  10 +++
 test/tablet.c| 204 +++
 8 files changed, 440 insertions(+), 10 deletions(-)

diff --git a/doc/pointer-acceleration.dox b/doc/pointer-acceleration.dox
index 7ec5e74..2fbb4cc 100644
--- a/doc/pointer-acceleration.dox
+++ b/doc/pointer-acceleration.dox
@@ -124,4 +124,10 @@ velocity of the pointer and each delta (dx, dy) results in 
an accelerated delta
 (dx * factor, dy * factor). This provides 1:1 movement between the device
 and the pointer on-screen.
 
+@section ptraccel-tablet Pointer acceleration on tablets
+
+Pointer acceleration for relative motion on tablet devices is a flat
+acceleration, with the speed seeting slowing down or speeding up the pointer
+motion by a constant factor. Tablets do not allow for switchable profiles.
+
 */
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 1870e7e..ae20550 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -285,19 +285,29 @@ normalize_wheel(struct tablet_dispatch *tablet,
return value * device->scroll.wheel_click_angle;
 }
 
-static inline struct device_coords
-tablet_handle_xy(struct tablet_dispatch *tablet, struct evdev_device *device)
+static inline void
+tablet_handle_xy(struct tablet_dispatch *tablet,
+struct evdev_device *device,
+struct device_coords *point_out,
+struct device_coords *delta_out)
 {
struct device_coords point;
+   struct device_coords delta = { 0, 0 };
const struct input_absinfo *absinfo;
+   int value;
 
if (bit_is_set(tablet->changed_axes, LIBINPUT_TABLET_TOOL_AXIS_X)) {
absinfo = libevdev_get_abs_info(device->evdev, ABS_X);
 
if (device->left_handed.enabled)
-   tablet->axes.point.x = invert_axis(absinfo);
+   value = invert_axis(absinfo);
else
-   tablet->axes.point.x = absinfo->value;
+   value = absinfo->value;
+
+   if (!tablet_has_status(tablet,
+  TABLET_TOOL_ENTERING_PROXIMITY))
+   delta.x = value - tablet->axes.point.x;
+   tablet->axes.point.x = value;
}
point.x = tablet->axes.point.x;
 
@@ -305,15 +315,41 @@ tablet_handle_xy(struct tablet_dispatch *tablet, struct 
evdev_device *device)
absinfo = libevdev_get_abs_info(device->evdev, ABS_Y);
 
if (device->left_handed.enabled)
-   tablet->axes.point.y = invert_axis(absinfo);
+   value = invert_axis(absinfo);
else
-   tablet->axes.point.y = absinfo->value;
+   value = absinfo->value;
+
+   if (!tablet_has_status(tablet,
+  TABLET_TOOL_ENTERING_PROXIMITY))
+   delta.y = value - tablet->axes.point.y;
+   tablet->axes.point.y = value;
}
point.y = tablet->axes.point.y;
 
evdev_transform_absolute(device, );
+   evdev_transform_relative(device, );
 
-   return point;
+   *delta_out = delta;
+   *point_out = point;
+}
+
+static inline struct normalized_coords
+tablet_process_delta(struct tablet_dispatch *tablet,
+const struct evdev_device *device,
+const struct device_coords *delta,
+uint64_t time)
+{
+   struct normalized_coords accel;
+
+   /* The tablet accel code uses mm as input */
+   accel.x = 1.0 * delta->x/device->abs.absinfo_x->resolution;
+   accel.y = 1.0 * delta->y/device->abs.absinfo_y->resolution;
+
+   if (normalized_is_zero(accel))
+   return accel;
+
+   return filter_dispatch(device->pointer.filter,
+  , tablet, time);
 }
 
 static inline double
@@ -445,19 +481,22 @@ static bool
 tablet_check_notify_axes(struct tablet_dispatch *tablet,
 struct evdev_device *device,
 struct libinput_tablet_tool *tool,
-struct tablet_axes *axes_out)
+struct tablet_axes *axes_out,
+uint64_t time)
 {
struct tablet_axes axes = {0};
const char tmp[sizeof(tablet->changed_axes)] = {0};
+   struct device_coords delta;
 
if (memcmp(tmp, tablet->changed_axes, sizeof(tmp)) == 0)
return false;
 
-   

[PATCH libinput] touchpad: disable MT for all semi-mt devices

[Peter Hutterer]

Synaptics, Elantech and Alps semi-mt devices all have issues with reporting
correct MT data, even the bounding box which semi-mt devices are supposed to
report is wrong.

Synaptics devices have massive jumps with two fingers down. Elantech devices
may open slots without coordinate data. Alps devices may send 0/0 coordinates
as initial slot position.

All these may be addressable with specific quirks, but the actual benefit is
largely restricted to better palm detection (though even with quirks this is
unlikely to work) and support for pinch gestures (again, lack of coordinates
makes supporting those hard anyway).

Elantech: https://bugs.freedesktop.org/show_bug.cgi?id=93583
Alps: https://bugzilla.redhat.com/show_bug.cgi?id=1295073

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad-gestures.c |  6 ++
 src/evdev-mt-touchpad.c  | 21 +
 test/gestures.c  |  2 +-
 test/litest.h| 10 --
 test/touchpad-tap.c  |  2 +-
 5 files changed, 17 insertions(+), 24 deletions(-)

diff --git a/src/evdev-mt-touchpad-gestures.c b/src/evdev-mt-touchpad-gestures.c
index 80aa89f..24f6a6d 100644
--- a/src/evdev-mt-touchpad-gestures.c
+++ b/src/evdev-mt-touchpad-gestures.c
@@ -568,10 +568,8 @@ tp_gesture_handle_state(struct tp_dispatch *tp, uint64_t 
time)
 int
 tp_init_gesture(struct tp_dispatch *tp)
 {
-   if (tp->device->model_flags & EVDEV_MODEL_JUMPING_SEMI_MT)
-   tp->gesture.enabled = false;
-   else
-   tp->gesture.enabled = true;
+   /* semi-mt devices are too unreliable to do pinch gestures */
+   tp->gesture.enabled = !tp->semi_mt;
 
tp->gesture.twofinger_state = GESTURE_2FG_STATE_NONE;
 
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 62087fb..7f5bbf5 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1490,17 +1490,22 @@ tp_init_slots(struct tp_dispatch *tp,
 
tp->semi_mt = libevdev_has_property(device->evdev, INPUT_PROP_SEMI_MT);
 
-   /* This device has a terrible resolution when two fingers are down,
+   /* Semi-mt devices are not reliable for true multitouch data, so we
+* simply pretend they're single touch touchpads with BTN_TOOL bits.
+* Synaptics:
+* Terrible resolution when two fingers are down,
 * causing scroll jumps. The single-touch emulation ABS_X/Y is
 * accurate but the ABS_MT_POSITION touchpoints report the bounding
-* box and that causes jumps.  So we simply pretend it's a single
-* touch touchpad with the BTN_TOOL bits.
-* See https://bugzilla.redhat.com/show_bug.cgi?id=1235175 for an
-* explanation.
+* box and that causes jumps. See https://bugzilla.redhat.com/1235175
+* Elantech:
+* On three-finger taps/clicks, one slot doesn't get a coordinate
+* assigned. See https://bugs.freedesktop.org/show_bug.cgi?id=93583
+* Alps:
+* If three fingers are set down in the same frame, one slot has the
+* coordinates 0/0 and may not get updated for several frames.
+* See https://bugzilla.redhat.com/show_bug.cgi?id=1295073
 */
-   if (tp->semi_mt &&
-   (device->model_flags &
-(EVDEV_MODEL_JUMPING_SEMI_MT|EVDEV_MODEL_ELANTECH_TOUCHPAD))) {
+   if (tp->semi_mt) {
tp->num_slots = 1;
tp->slot = 0;
tp->has_mt = false;
diff --git a/test/gestures.c b/test/gestures.c
index 9fc73b9..0fc3964 100644
--- a/test/gestures.c
+++ b/test/gestures.c
@@ -34,7 +34,7 @@ START_TEST(gestures_cap)
struct litest_device *dev = litest_current_device();
struct libinput_device *device = dev->libinput_device;
 
-   if (litest_is_synaptics_semi_mt(dev))
+   if (libevdev_has_property(dev->evdev, INPUT_PROP_SEMI_MT))
ck_assert(!libinput_device_has_capability(device,
  LIBINPUT_DEVICE_CAP_GESTURE));
else
diff --git a/test/litest.h b/test/litest.h
index e74e923..61b1b01 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -552,16 +552,6 @@ litest_enable_buttonareas(struct litest_device *dev)
litest_assert_int_eq(status, expected);
 }
 
-static inline int
-litest_is_synaptics_semi_mt(struct litest_device *dev)
-{
-   struct libevdev *evdev = dev->evdev;
-
-   return libevdev_has_property(evdev, INPUT_PROP_SEMI_MT) &&
-   libevdev_get_id_vendor(evdev) == 0x2 &&
-   libevdev_get_id_product(evdev) == 0x7;
-}
-
 static inline void
 litest_enable_drag_lock(struct libinput_device *device)
 {
diff --git a/test/touchpad-tap.c b/test/touchpad-tap.c
index 4450ec3..7a7e64c 100644
--- a/test/touchpad-tap.c
+++ b/test/touchpad-tap.c
@@ -241,7 +241,7 @@ START_TEST(touchpad_1fg_multitap_n_drag_2fg)
int range = _i,
ntaps;
 
-   if (litest_is_synaptics_semi_mt(dev))
+   if 

[PATCH v2 libinput 5/7] tablet: add support for relative x/y motion deltas

[Peter Hutterer]

Instead of an explicit tablet mode that device must be changed into, let the
caller decide which coordinates are preferred. The tablet mode may be
application-specific and usually depends on the tool as well.

This patch adds an interface to get a motion delta for the x/y axes in
pixel-like coordinates. libinput provides some magic to convert the tablet
data into something that resembles pixels from a mouse motion.
For unaccelerated relative motion, the caller should use the mm values from
the tablet and calculate deltas manually.

Signed-off-by: Peter Hutterer 
Acked-by: Jason Gerecke 
---
Changes to v1:
- dropped the unaccel events. there was no useful value in them, manually
  calculating a delta from the mm values yielded the same result

 doc/normalization-of-relative-motion.dox |  4 
 doc/tablet-support.dox   | 22 +
 src/libinput-private.h   |  1 +
 src/libinput.c   | 26 
 src/libinput.h   | 34 
 src/libinput.sym |  2 ++
 6 files changed, 89 insertions(+)

diff --git a/doc/normalization-of-relative-motion.dox 
b/doc/normalization-of-relative-motion.dox
index 31596a9..478e727 100644
--- a/doc/normalization-of-relative-motion.dox
+++ b/doc/normalization-of-relative-motion.dox
@@ -38,6 +38,10 @@ libinput scales unaccelerated touchpad motion to the 
resolution of the
 touchpad's x axis, i.e. the unaccelerated value for the y axis is:
  y = (x / resolution_x) * resolution_y
 
+@section motion_normalization_tablet Normalization of tablet coordinates
+
+See @ref tablet-relative-motion
+
 @section Setting custom DPI settings
 
 Devices usually do not advertise their resolution and libinput relies on
diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
index 7207a47..cc5d409 100644
--- a/doc/tablet-support.dox
+++ b/doc/tablet-support.dox
@@ -52,6 +52,28 @@ Note that the pressure threshold to trigger a logical tip 
event may be zero
 on some devices. On tools without pressure sensitivity, determining when a
 tip is down is device-specific.
 
+@section tablet-relative-motion Relative motion for tablet tools
+
+libinput calculates the relative motion vector for each event and converts
+it to the same coordinate space that a normal mouse device would use. For
+the caller, this means that the delta coordinates returned by
+libinput_event_tablet_tool_get_dx() and
+libinput_event_tablet_tool_get_dy() can be used identical to the delta
+coordinates from any other pointer event. Any resolution differences between
+the x and y axes are accommodated for, a delta of N/N represents a 45 degree
+diagonal move on the tablet.
+
+The delta coordinates are available for all tablet events, it is up to the
+caller to decide when a tool should be used in relative mode. It is
+recommended that mouse and lens cursor tool default to relative mode and
+all pen-like tools to absolute mode.
+
+If a tool in relative mode must not use pointer acceleration, callers
+should use the absolute coordinates returned by
+libinput_event_tablet_tool_get_x() and libinput_event_tablet_tool_get_y()
+and calculate the delta themselves. Callers that require exact physical
+distance should also use these functions to calculate delta movements.
+
 @section tablet-axes Special axes on tablet tools
 
 A tablet tool usually provides additional information beyond x/y positional
diff --git a/src/libinput-private.h b/src/libinput-private.h
index ff43d00..d78be64 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -71,6 +71,7 @@ struct threshold {
 
 struct tablet_axes {
struct device_coords point;
+   struct normalized_coords delta;
double distance;
double pressure;
struct normalized_range_coords tilt;
diff --git a/src/libinput.c b/src/libinput.c
index 2f80f03..a0dc6d6 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1090,6 +1090,32 @@ libinput_event_tablet_tool_get_y(struct 
libinput_event_tablet_tool *event)
 }
 
 LIBINPUT_EXPORT double
+libinput_event_tablet_tool_get_dx(struct libinput_event_tablet_tool *event)
+{
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_TOOL_AXIS,
+  LIBINPUT_EVENT_TABLET_TOOL_TIP,
+  LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY);
+
+   return event->axes.delta.x;
+}
+
+LIBINPUT_EXPORT double
+libinput_event_tablet_tool_get_dy(struct libinput_event_tablet_tool *event)
+{
+   require_event_type(libinput_event_get_context(>base),
+  event->base.type,
+  0,
+  LIBINPUT_EVENT_TABLET_TOOL_AXIS,
+  LIBINPUT_EVENT_TABLET_TOOL_TIP,
+  

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

[Jonas Ådahl]

On Mon, Jan 18, 2016 at 06:28:29PM +, Daniel Stone wrote:
> Hi,
> 
> On 15 January 2016 at 19:30, Bill Spitzak  wrote:
> > On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone  wrote:
> >> The proposed one-shot-but-delayed request to me felt like a really
> >> awkward compromise between the two, and not really one backed up by a
> >> strong enough usecase to justify a third (delayed but not retained)
> >> model for requests taking effect.
> >>
> >> It's entirely possible that there's something I'm missing here, but
> >> for consistency if nothing else, having the split instead be between
> >> these two classic methods (oneshot-immediate vs. fully-retained,
> >> rather than oneshot-delayed vs. fully-retained) could be good for
> >> future versions.
> >
> > I would agree there is something missing here.
> >
> > I do not see any reason for anything other than a "one shot" which is
> > created by the client *AFTER* it receives the possibly-triggering input
> > event.
> 
> I can see the reasoning behind it, at least. I'm not sure I agree, but
> those aren't the same thing.
> 
> > I am still waiting for a description of how one of these pre-set
> > locks is triggered, I have serious doubts that any possible trigger could be
> > something other than an action that would send an event to the client, or at
> > a moment the client is doing something like configuring the surface.
> 
> Yes, the triggers would involve events being sent to clients indeed.
> Codifying every exact trigger would be borderline impossible, and
> unnecessarily restrictive to compositors, so I don't think there's any
> need to do that.

If we limit lock activation to only happen as replies to events we'd
limit the compositors ability to decide when such locks should activate.
It might not always result in any input event (timeout of being within a
surface, compositor keybinding for accpeting a lock for example).

> 
> > Nor do I see any problem with race conditions provided the one-shot request
> > has an id for the triggering event:
> 
> The race here is that if you react on pointer entry, having a one-shot
> request will mean that the events you get in between entry and the
> request activating, won't be relative. I can imagine that being
> frustrating to users.
> 
> > - Client can read relative motion events (these are identical whether or not
> > pointer lock works,
> 
> ???
> 
> Relative motion does not occur without lock.

Yes they do. wp_relative_pointer is a completely separate thing. It will
emit events no matter the lock/confine situation.

> 
> Anyway, I think we all largely agree on the details, so let's look for
> the implementations (compositor and client) both, and see what
> real-world feedback falls out of those.

Yes. We should concentrate on real world applications for a while, and
luckily we can change the protocol if we see the need for it.


Jonas

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

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

[Peter Hutterer]

On Fri, Jan 15, 2016 at 04:08:57PM +, Daniel Stone wrote:
> Hi,
> 
> On 12 January 2016 at 22:28, Bill Spitzak  wrote:
> > There should *only* be "one shot" requests, which are very quickly accepted
> > or denied by the compositor. The client creates it in response to an input
> > event, and it includes the input event id.
> >
> > Most/all things that triggers pointer lock (the mouse entering the region,
> > the mouse being pressed in the region, a press+release in the region, a
> > keystroke) could be implemented by clients and it does not do any pointer
> > lock protocol until after it has detected the triggering event, and thus can
> > include the event id.
> 
> For what it's worth - post-hoc expansion on my reasoning - I think
> Bill has the genesis of a point here. Usually, our requests have
> followed one of two patterns: either you request activation in
> response to a specific event (button or key event allows you to create
> a selection), or retained state (creating a wl_data_device gets you
> selection/etc events on that seat until you destroy it).
> 
> The proposed one-shot-but-delayed request to me felt like a really
> awkward compromise between the two, and not really one backed up by a
> strong enough usecase to justify a third (delayed but not retained)
> model for requests taking effect.

tbh, I think this is just a difference in how we view the approach. I never
saw it as a "oneshot-delayed" approach, I thought of it as a "need it once"
vs "need it forever".

however, the main issue I see is that there is always a race condition. with
any delayed trigger you're guaranteed that if you request the lock, you'll
get it when appropriate. Without the immediate approach, you are racing the
user and compositor to request the lock before the trigger is undone again
(e.g.  moved out of the window). I don't know how much that will be an issue
in practice though.

Cheers,
   Peter

> 
> It's entirely possible that there's something I'm missing here, but
> for consistency if nothing else, having the split instead be between
> these two classic methods (oneshot-immediate vs. fully-retained,
> rather than oneshot-delayed vs. fully-retained) could be good for
> future versions.
> 
> Cheers,
> Daniel
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC v3 libinput 2/2] buttonset: implement buttonset handling for Wacom tablet pads

[Peter Hutterer]

Same approach as evdev-tablet (started as copy/paste), with axis and buttons
adjusted. Wacom's handling of pad devices requires a lot of non-obvious
handling, e.g. ABS_THROTTLE is the second ring, ABS_RX is the strip, etc.

This is not generic buttonset code, if we start supporting other devices for
buttonsets we'll factor out a couple of the functions.

The wheel and strip events are a bit of a problem: Wacom sends a 0 event on the
axis when the finger is released. We can detect this if there is an ABS_MISC 0
present in the same event and suppress it.  Won't work if any finger is down
on any other wheel, strip or button but that's a kernel bug we'll fix once we
figure out how.

Signed-off-by: Peter Hutterer 
---
Changes to v2:
- reworked for the per-axis type API
- squashed heaps of fixes piled on after the last version into this patch.
  Note, this is not a final version yet, it just serves to illustrate the
  implementation.

 src/Makefile.am |   2 +
 src/evdev-buttonset-wacom.c | 602 
 src/evdev-buttonset-wacom.h |  67 +
 src/evdev-mt-touchpad.c |   3 +
 src/evdev-tablet.c  |   3 +
 src/evdev.c |  84 ++-
 src/evdev.h |  32 +++
 src/libinput-private.h  |  29 +++
 src/libinput.c  | 105 ++--
 9 files changed, 898 insertions(+), 29 deletions(-)
 create mode 100644 src/evdev-buttonset-wacom.c
 create mode 100644 src/evdev-buttonset-wacom.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 343e75c..723f7d6 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -11,6 +11,8 @@ libinput_la_SOURCES = \
libinput-private.h  \
evdev.c \
evdev.h \
+   evdev-buttonset-wacom.c \
+   evdev-buttonset-wacom.h \
evdev-middle-button.c   \
evdev-mt-touchpad.c \
evdev-mt-touchpad.h \
diff --git a/src/evdev-buttonset-wacom.c b/src/evdev-buttonset-wacom.c
new file mode 100644
index 000..7dec3e8
--- /dev/null
+++ b/src/evdev-buttonset-wacom.c
@@ -0,0 +1,602 @@
+/*
+ * Copyright © 2015 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission.  The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "config.h"
+#include "evdev-buttonset-wacom.h"
+
+#include 
+#include 
+#include 
+
+#define buttonset_set_status(buttonset_,s_) (buttonset_)->status |= (s_)
+#define buttonset_unset_status(buttonset_,s_) (buttonset_)->status &= ~(s_)
+#define buttonset_has_status(buttonset_,s_) (!!((buttonset_)->status & (s_)))
+
+static void
+buttonset_get_buttons_pressed(struct buttonset_dispatch *buttonset,
+ unsigned long buttons_pressed[NLONGS(KEY_CNT)])
+{
+   struct button_state *state = >button_state;
+   struct button_state *prev_state = >prev_button_state;
+   unsigned int i;
+
+   for (i = 0; i < NLONGS(KEY_CNT); i++)
+   buttons_pressed[i] = state->buttons[i]
+   & ~(prev_state->buttons[i]);
+}
+
+static void
+buttonset_get_buttons_released(struct buttonset_dispatch *buttonset,
+  unsigned long buttons_released[NLONGS(KEY_CNT)])
+{
+   struct button_state *state = >button_state;
+   struct button_state *prev_state = >prev_button_state;
+   unsigned int i;
+
+   for (i = 0; i < NLONGS(KEY_CNT); i++)
+   buttons_released[i] = prev_state->buttons[i]
+   & ~(state->buttons[i]);
+}
+
+static inline bool
+buttonset_button_is_down(const struct buttonset_dispatch *buttonset,
+uint32_t button)
+{
+   return long_bit_is_set(buttonset->button_state.buttons, button);
+}
+
+static inline void
+buttonset_button_set_down(struct 

[RFC v3 libinput 1/2] buttonset: Add a "buttonset" interface for button-only devices

[Peter Hutterer]

A generic interface for devices that provide buttons and axes, but don't
control the pointer. This caters for the Pad part of Wacom graphics tablets
but could eventually also deal with remote controls, 3D mice and other
devices.

This patch adds a new interface "buttonset" with a new capability and two
events AXIS and BUTTON. The interface is largely modelled after the
tablet interface, but with different axes and a few different behaviors.
Notably, axes are numbered, with an axis type. The button events do the
obvious, axis events can be queried for the respective value, which depends on
the type.

Signed-off-by: Peter Hutterer 
---
This is a revamped version the buttonset interface. The main change is the
switch to more specific axis handling, similar to what we just did in the
tablet support branch:
Previously, you'd run libinput_event_buttonset_get_axis_value(event, axis)
and the value was axis-specific. Now you have to call the correct call for
the axis, e.g. libinput_event_buttonset_get_ring_position(event, axis). This
allows libinput to detect bugs quicker (e.g. if axis isn't a ring axis) and
it's more expressive and flexible.

The rest stays the same, a device has N axes, each of them has a type that
decides how to use the API.

Note: the axes supported here are quite a few to illustrate how things
should look like, but I think the buttonset version eventually merged should
just provide the ones we actually support, i.e. ring and strip for pads. The
rest can be added later, as we add support for specific devices.


 doc/Makefile.am|   1 +
 doc/buttonsets.dox |  53 ++
 src/libinput-private.h |   2 +
 src/libinput.c | 410 +++
 src/libinput.h | 508 +
 src/libinput.sym   |  34 
 test/litest.c  |   6 +
 tools/event-debug.c|  66 +++
 tools/event-gui.c  |   3 +
 9 files changed, 1083 insertions(+)
 create mode 100644 doc/buttonsets.dox

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 7a7c6cf..0ec9586 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -11,6 +11,7 @@ header_files = \
$(top_srcdir)/src/libinput.h \
$(top_srcdir)/README.txt \
$(srcdir)/absolute-axes.dox \
+   $(srcdir)/buttonsets.dox \
$(srcdir)/clickpad-softbuttons.dox \
$(srcdir)/device-configuration-via-udev.dox \
$(srcdir)/faqs.dox \
diff --git a/doc/buttonsets.dox b/doc/buttonsets.dox
new file mode 100644
index 000..5c25bc6
--- /dev/null
+++ b/doc/buttonsets.dox
@@ -0,0 +1,53 @@
+/**
+@page buttonsets Buttonset devices
+
+Devices with the @ref LIBINPUT_DEVICE_CAP_BUTTONSET capability are so-called
+buttonsets, devices that have axes, buttons or keys but are are auxiliary
+devices that do not control the pointer or the keyboard.
+Examples for buttonset devices are the physical tablet ("pad") of Wacom
+graphics tablets, the Griffin PowerMate or the 3Dconnexion SpacePilot Pro.
+
+A buttonset device may have axes and even x and y axes but those axes are
+not used to control the pointer. Joysticks and gamepads are not buttonset
+devices, libinput currently does not support those.
+
+libinput expects additional knowledge about the device to live in the
+callers, it merely abstracts the interfaces and provides a coherent API to
+the callers. A caller should know about the device in advance and thus be
+able to interpret the various axes, buttons and keys correctly.
+
+@section buttonset_buttons
+
+The set of buttons on a device is device-specific. libinput uses the Linux
+kernel's button names (BTN_* from linux/input.h) to identify buttons.
+Linux forces semantic naming on buttons (e.g. BTN_LEFT) but some devices
+have merely numbered buttons (e.g. the XKeys Pro). It is the caller's
+responsibility to detect such devices and interpret the button numbers
+correctly.
+
+libinput does not provide a function to enumerate all buttons on a device,
+instead the caller is expected to check for the buttons or keys it needs to
+handle. For example, a caller that cares about multimedia keys should check
+for the set of multimedia keys it handles rather than traversing the entire
+key space.
+
+@section buttonset_axes Buttonset axes
+
+Axes on a buttonset are numbered sequentially, zero-indexed. The index is
+the main identifier of the axis, the order of axes is not guaranteed. A
+device may gain additional axes with future releases of libinput.
+
+Each axis has a type (see @ref libinput_buttonset_axis_type). libinput does
+not guarantee the order of the types, but it does guarantee a stable order of
+axes with the same type. If a device's axes i an j are of type @ref
+LIBINPUT_BUTTONSET_AXIS_RING, libinput guarantees that i < j even when the
+number or order of axes changes.  In other words, if the left ring was the
+first ring in the axis list, it will always be the first ring in the axis
+list.
+
+A buttonset device may 

Re: [PATCH weston] compositor-rdp: update link to wheel delta explanation

[Jonas Ådahl]

Reviewed (well checked the link) and push this one.


Jonas

On Mon, Jan 18, 2016 at 01:54:19PM +1000, Peter Hutterer wrote:
> The previous one is a 404 now.
> ---
>  src/compositor-rdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 33805c1..1bf744c 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -975,7 +975,7 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
> UINT16 y)
>* The RDP specs says the lower bits of flags contains the "the 
> number of rotation
>* units the mouse wheel was rotated".
>*
> -  * 
> http://blogs.msdn.com/b/oldnewthing/archive/2013/01/23/10387366.aspx explains 
> the 120 value
> +  * 
> https://blogs.msdn.microsoft.com/oldnewthing/20130123-00/?p=5473 explains the 
> 120 value
>*/
>   axis = (DEFAULT_AXIS_STEP_DISTANCE * (flags & 0xff)) / 120;
>   if (flags & PTR_FLAGS_WHEEL_NEGATIVE)
> -- 
> 2.5.0
> 
> ___
> 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 v9] data-device: Implement DnD actions

[Jonas Ådahl]

Have tested this with both old wl_data_device_manager users and new
wl_data_device_manager users and it seems to work. So this, and the rest
of the most recent version of the series it was part of is now pushed.


Jonas

On Mon, Jan 18, 2016 at 11:52:12PM +0100, Carlos Garnacho wrote:
> The policy in weston in order to determine the chosen DnD action is
> deliberately simple, and is probably the minimals that any compositor
> should be doing here.
> 
> Besides honoring the set_actions requests on both wl_data_source and
> wl_data_offer, weston now will emit the newly added "action" events
> notifying both source and dest of the chosen action.
> 
> The "dnd" client has been updated too (although minimally), so it
> notifies the compositor of a "move" action on both sides.
> 
> Changes since v8:
>   - Add back wl_data_offer.source_actions emission, gone during last
> code shuffling. Fix nits found in review.
> 
> Changes since v7:
>   - Fixes spotted during review. Add client-side version checks.
> Implement .action emission as specified in protocol patch v11.
> 
> Changes since v6:
>   - Emit errors as defined in DnD actions patch v10.
> 
> Changes since v5:
>   - Use enum types and values for not-a-bitfield stored values.
> handle errors when finding unexpected dnd_actions values.
> 
> Changes since v4:
>   - Added compositor-side version checks. Spaces vs tabs fixes.
> Fixed resource versioning. Initialized new weston_data_source/offer
> fields.
> 
> Changes since v3:
>   - Put data_source.action to use in the dnd client, now updates
> the dnd surface like data_source.target events do.
> 
> Changes since v2:
>   - Split from DnD progress notification changes.
> 
> Changes since v1:
>   - Updated to v2 of DnD actions protocol changes, implement
> wl_data_offer.source_actions.
>   - Fixed coding style issues.
> 
> Signed-off-by: Carlos Garnacho 
> Reviewed-by: Michael Catanzaro 
> Reviewed-by: Jonas Ådahl 
> ---
>  clients/dnd.c |  36 +--
>  clients/window.c  |  34 ++
>  clients/window.h  |   3 +
>  src/compositor.h  |   6 ++
>  src/data-device.c | 182 
> --
>  5 files changed, 252 insertions(+), 9 deletions(-)
> 
> diff --git a/clients/dnd.c b/clients/dnd.c
> index 974429b..d32655d 100644
> --- a/clients/dnd.c
> +++ b/clients/dnd.c
> @@ -72,6 +72,7 @@ struct dnd_drag {
>   struct item *item;
>   int x_offset, y_offset;
>   int width, height;
> + uint32_t dnd_action;
>   const char *mime_type;
>  
>   struct wl_surface *drag_surface;
> @@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
>  }
>  
>  static void
> -data_source_target(void *data,
> -struct wl_data_source *source, const char *mime_type)
> +dnd_drag_update_surface(struct dnd_drag *dnd_drag)
>  {
> - struct dnd_drag *dnd_drag = data;
>   struct dnd *dnd = dnd_drag->dnd;
>   cairo_surface_t *surface;
>   struct wl_buffer *buffer;
>  
> - dnd_drag->mime_type = mime_type;
> - if (mime_type)
> + if (dnd_drag->mime_type && dnd_drag->dnd_action)
>   surface = dnd_drag->opaque;
>   else
>   surface = dnd_drag->translucent;
> @@ -288,6 +286,16 @@ data_source_target(void *data,
>  }
>  
>  static void
> +data_source_target(void *data,
> +struct wl_data_source *source, const char *mime_type)
> +{
> + struct dnd_drag *dnd_drag = data;
> +
> + dnd_drag->mime_type = mime_type;
> + dnd_drag_update_surface(dnd_drag);
> +}
> +
> +static void
>  data_source_send(void *data, struct wl_data_source *source,
>const char *mime_type, int32_t fd)
>  {
> @@ -360,12 +368,22 @@ data_source_dnd_finished(void *data, struct 
> wl_data_source *source)
>   dnd_drag_destroy(dnd_drag);
>  }
>  
> +static void
> +data_source_action(void *data, struct wl_data_source *source, uint32_t 
> dnd_action)
> +{
> + struct dnd_drag *dnd_drag = data;
> +
> + dnd_drag->dnd_action = dnd_action;
> + dnd_drag_update_surface(dnd_drag);
> +}
> +
>  static const struct wl_data_source_listener data_source_listener = {
>   data_source_target,
>   data_source_send,
>   data_source_cancelled,
>   data_source_dnd_drop_performed,
>   data_source_dnd_finished,
> + data_source_action,
>  };
>  
>  static cairo_surface_t *
> @@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
>   dnd_drag->item = item;
>   dnd_drag->x_offset = x - item->x;
>   dnd_drag->y_offset = y - item->y;
> + dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
> + dnd_drag->mime_type = NULL;
>  
>   for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
>   if (item == dnd->items[i]){
> @@ -456,6 +476,12 @@ create_drag_source(struct dnd *dnd,
>  

Re: [PATCH v5 weston 2/2] Support axis source, axis discrete, frame and axis stop events

[Jonas Ådahl]

This one is now also pushed, with a couple of fixes (resource version
checks before sending wl_pointer.frame when changing pointer focus).


Jonas


On Mon, Jan 18, 2016 at 04:38:22PM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer 
> ---
> Changes to v2:
> - don't send frames after focus events, notify_pointer_focus() takes
>   care of that
> - add frame events to screen-share
> 
>  clients/eventdemo.c   |  57 -
>  clients/window.c  |  97 -
>  clients/window.h  |  31 +
>  desktop-shell/exposay.c   |  12 
>  desktop-shell/shell.c |  33 ++
>  ivi-shell/hmi-controller.c|  15 +
>  src/compositor-rdp.c  |  20 --
>  src/compositor-wayland.c  |  84 -
>  src/compositor-x11.c  |  10 +++
>  src/compositor.h  |  16 +
>  src/data-device.c |  12 
>  src/input.c   |  93 ---
>  src/libinput-device.c | 128 
> --
>  src/screen-share.c|   4 ++
>  tests/weston-test-client-helper.c |  32 ++
>  15 files changed, 596 insertions(+), 48 deletions(-)
> 
> diff --git a/clients/eventdemo.c b/clients/eventdemo.c
> index bdad6fd..e323aa5 100644
> --- a/clients/eventdemo.c
> +++ b/clients/eventdemo.c
> @@ -259,6 +259,54 @@ axis_handler(struct widget *widget, struct input *input, 
> uint32_t time,
>  wl_fixed_to_double(value));
>  }
>  
> +static void
> +pointer_frame_handler(struct widget *widget, struct input *input, void *data)
> +{
> + printf("pointer frame\n");
> +}
> +
> +static void
> +axis_source_handler(struct widget *widget, struct input *input,
> + uint32_t source, void *data)
> +{
> + const char *axis_source;
> +
> + switch (source) {
> + case WL_POINTER_AXIS_SOURCE_WHEEL:
> + axis_source = "wheel";
> + break;
> + case WL_POINTER_AXIS_SOURCE_FINGER:
> + axis_source = "finger";
> + break;
> + case WL_POINTER_AXIS_SOURCE_CONTINUOUS:
> + axis_source = "continuous";
> + break;
> + default:
> + axis_source = "";
> + break;
> + }
> +
> + printf("axis source: %s\n", axis_source);
> +}
> +
> +static void
> +axis_stop_handler(struct widget *widget, struct input *input,
> +   uint32_t time, uint32_t axis,
> +   void *data)
> +{
> + printf("axis stop time: %d, axis: %s\n",
> +time,
> +axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
> +  "horizontal");
> +}
> +
> +static void
> +axis_discrete_handler(struct widget *widget, struct input *input,
> +   uint32_t axis, int32_t discrete, void *data)
> +{
> + printf("axis discrete axis: %d value: %d\n", axis, discrete);
> +}
> +
>  /**
>   * \brief CALLBACK function, Waylands informs about pointer motion
>   * \param widget widget
> @@ -347,8 +395,15 @@ eventdemo_create(struct display *d)
>   /* Set the callback motion handler for the window */
>   widget_set_motion_handler(e->widget, motion_handler);
>  
> + /* Set the callback pointer frame handler for the window */
> + widget_set_pointer_frame_handler(e->widget, pointer_frame_handler);
> +
>   /* Set the callback axis handler for the window */
> - widget_set_axis_handler(e->widget, axis_handler);
> + widget_set_axis_handlers(e->widget,
> +  axis_handler,
> +  axis_source_handler,
> +  axis_stop_handler,
> +  axis_discrete_handler);
>  
>   /* Initial drawing of the window */
>   window_schedule_resize(e->window, width, height);
> diff --git a/clients/window.c b/clients/window.c
> index 5d69116..7d45acd 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -282,6 +282,10 @@ struct widget {
>   widget_touch_frame_handler_t touch_frame_handler;
>   widget_touch_cancel_handler_t touch_cancel_handler;
>   widget_axis_handler_t axis_handler;
> + widget_pointer_frame_handler_t pointer_frame_handler;
> + widget_axis_source_handler_t axis_source_handler;
> + widget_axis_stop_handler_t axis_stop_handler;
> + widget_axis_discrete_handler_t axis_discrete_handler;
>   void *user_data;
>   int opaque;
>   int tooltip_count;
> @@ -1930,6 +1934,26 @@ widget_set_axis_handler(struct widget *widget,
>   widget->axis_handler = handler;
>  }
>  
> +void
> +widget_set_pointer_frame_handler(struct widget *widget,
> +  widget_pointer_frame_handler_t handler)
> +{
> + widget->pointer_frame_handler = handler;
> +}
> +
> +void
> +widget_set_axis_handlers(struct 

Re: [PATCH libinput 5/7] tablet: add support for relative x/y motion deltas

[Peter Hutterer]

On Mon, Jan 18, 2016 at 09:54:09AM -0800, Bill Spitzak wrote:
> On 01/17/2016 02:26 PM, Peter Hutterer wrote:
> >On Fri, Jan 15, 2016 at 12:06:27PM -0800, Bill Spitzak wrote:
> >>Isn't dx_unaccelerated exactly equal to the differences between x values?
> >
> >hah, yes. indeed. that actually means we can drop it from the API since a
> >client can use the mm value instead, they are effectively equivalent (but
> >more useful) than the raw device coordinates and account for uneven
> >resolution better anyway.
> 
> I think the following text is confusing and is what led me to think that the
> coordinate systems might be different:
> 
> >>> +libinput calculates the relative motion vector for each event and
> converts
> >>> +it to the same coordinate space that a normal mouse device would use.
> 
> I guess that all coordianates except for raw ones are "converted to the
> space that a normal mouse device would use" but this seems to imply that
> dx/dy are special. Maybe this text can be moved somewhere to make it clear
> it applies to everything other than raw output.

Please send a patch rewording/moving this.

> >Whether you use the device in an absolute or relative mode is a very
> >user-specific thing, I doubt you can handle this automatically. mode is also
> >a very tool-specific thing, you may want the mouse to be in relative mode
> >but the pen in absolute mode.
> 
> Although some devices such as the mouse may want to be in relative mode all
> the time, I believe the "absolute" devices will want to be in relative mode
> if the mapping from the tablet to the screen is either too large of a
> scale-up (ie the screen is much larger than the tablet) or the aspect ratio
> is significantly different (though this might just mean that one dimension
> is scaled beyond a maximum). This is certainly true of my current setup and
> I can't believe it is uncommon. Absolute mode on this tablet is completely
> useless! Except for programs that restrict the motion to a smaller window
> that is about the shape of the tablet.
> 
> I think this would also help it guess the correct mode automatically when
> the user changes their tablet or their screens.

mapping aspect ratio will be the job of the compositor. In reality, this
will mean that one of the axes will be shortened to match the ratio.
if absolute mode on your tablet is "completely useless" that would indicate
you never looked at wacom(4) or any instructions on how to fix this. We've
had config options to adjust this for years.
 
Cheers,
   Peter

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

[PATCH weston v9] data-device: Implement DnD actions

[Carlos Garnacho]

The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.

Besides honoring the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
notifying both source and dest of the chosen action.

The "dnd" client has been updated too (although minimally), so it
notifies the compositor of a "move" action on both sides.

Changes since v8:
  - Add back wl_data_offer.source_actions emission, gone during last
code shuffling. Fix nits found in review.

Changes since v7:
  - Fixes spotted during review. Add client-side version checks.
Implement .action emission as specified in protocol patch v11.

Changes since v6:
  - Emit errors as defined in DnD actions patch v10.

Changes since v5:
  - Use enum types and values for not-a-bitfield stored values.
handle errors when finding unexpected dnd_actions values.

Changes since v4:
  - Added compositor-side version checks. Spaces vs tabs fixes.
Fixed resource versioning. Initialized new weston_data_source/offer
fields.

Changes since v3:
  - Put data_source.action to use in the dnd client, now updates
the dnd surface like data_source.target events do.

Changes since v2:
  - Split from DnD progress notification changes.

Changes since v1:
  - Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
  - Fixed coding style issues.

Signed-off-by: Carlos Garnacho 
Reviewed-by: Michael Catanzaro 
Reviewed-by: Jonas Ådahl 
---
 clients/dnd.c |  36 +--
 clients/window.c  |  34 ++
 clients/window.h  |   3 +
 src/compositor.h  |   6 ++
 src/data-device.c | 182 --
 5 files changed, 252 insertions(+), 9 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index 974429b..d32655d 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -72,6 +72,7 @@ struct dnd_drag {
struct item *item;
int x_offset, y_offset;
int width, height;
+   uint32_t dnd_action;
const char *mime_type;
 
struct wl_surface *drag_surface;
@@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
 }
 
 static void
-data_source_target(void *data,
-  struct wl_data_source *source, const char *mime_type)
+dnd_drag_update_surface(struct dnd_drag *dnd_drag)
 {
-   struct dnd_drag *dnd_drag = data;
struct dnd *dnd = dnd_drag->dnd;
cairo_surface_t *surface;
struct wl_buffer *buffer;
 
-   dnd_drag->mime_type = mime_type;
-   if (mime_type)
+   if (dnd_drag->mime_type && dnd_drag->dnd_action)
surface = dnd_drag->opaque;
else
surface = dnd_drag->translucent;
@@ -288,6 +286,16 @@ data_source_target(void *data,
 }
 
 static void
+data_source_target(void *data,
+  struct wl_data_source *source, const char *mime_type)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->mime_type = mime_type;
+   dnd_drag_update_surface(dnd_drag);
+}
+
+static void
 data_source_send(void *data, struct wl_data_source *source,
 const char *mime_type, int32_t fd)
 {
@@ -360,12 +368,22 @@ data_source_dnd_finished(void *data, struct 
wl_data_source *source)
dnd_drag_destroy(dnd_drag);
 }
 
+static void
+data_source_action(void *data, struct wl_data_source *source, uint32_t 
dnd_action)
+{
+   struct dnd_drag *dnd_drag = data;
+
+   dnd_drag->dnd_action = dnd_action;
+   dnd_drag_update_surface(dnd_drag);
+}
+
 static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled,
data_source_dnd_drop_performed,
data_source_dnd_finished,
+   data_source_action,
 };
 
 static cairo_surface_t *
@@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
dnd_drag->item = item;
dnd_drag->x_offset = x - item->x;
dnd_drag->y_offset = y - item->y;
+   dnd_drag->dnd_action = WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
+   dnd_drag->mime_type = NULL;
 
for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
if (item == dnd->items[i]){
@@ -456,6 +476,12 @@ create_drag_source(struct dnd *dnd,
 text_mime_type);
}
 
+   if (display_get_data_device_manager_version(display) >=
+   WL_DATA_SOURCE_SET_ACTIONS_SINCE_VERSION) {
+   wl_data_source_set_actions(dnd_drag->data_source,
+  
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE);
+   }
+
wl_data_device_start_drag(input_get_data_device(input),