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

[Derek Foreman]

On 23/11/15 03:24 PM, Derek Foreman wrote:
> On 17/11/15 04:09 AM, Jonas Ådahl wrote:
>> The wp_relative_pointer interface is an extension to the wl_pointer
>> interface created from wl_seat. It has the same focus, but adds the
>> functionality of sending relative pointer motions unhindered by
>> constraints such as monitor edges or other barriers. It also contains
>> unaccelerated pointer motion information.
>>
>> Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
>> ---
>>
>> There has alreay been RBs on this protocol, but I'd like to get them
>> explicitly re-RB:ed considering that the protocol has changed some, even
>> though the changes have not been major ones.
>>
>>
>> Changes since the last version sent as weston patches:
>>
>> Interfaces and protocol renamed according to wayland-protocols naming
>> conventions.
>>
>> Accelerated and unaccelerated motion deltas have the data type
>> wl_fixed_t now again. 64 bit fixed point deltas was deemed unnecessary,
>> and wl_double_fixed_t was dropped.
>>
>> 64 bit timestamp argument name suffix changed from msb/lsb to hi/lo.
>>
>> Various other minor changes.
>>
>>
>> Jonas
>>
>>
>>  Makefile.am                                        |   1 +
>>  unstable/relative-pointer/README                   |   4 +
>>  .../relative-pointer-unstable-v1.xml               | 122 +++++++++++++++++++++
>>  3 files changed, 127 insertions(+)
>>  create mode 100644 unstable/relative-pointer/README
>>  create mode 100644 unstable/relative-pointer/relative-pointer-unstable-v1.xml
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index f1bac16..2db6bd5 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -5,6 +5,7 @@ nobase_dist_pkgdata_DATA =							\
>>  	unstable/text-input/text-input-unstable-v1.xml				\
>>  	unstable/input-method/input-method-unstable-v1.xml			\
>>  	unstable/xdg-shell/xdg-shell-unstable-v5.xml				\
>> +	unstable/relative-pointer/relative-pointer-unstable-v1.xml		\
>>  	$(NULL)
>>  
>>  pkgconfigdir = $(libdir)/pkgconfig
>> diff --git a/unstable/relative-pointer/README b/unstable/relative-pointer/README
>> new file mode 100644
>> index 0000000..64c42a1
>> --- /dev/null
>> +++ b/unstable/relative-pointer/README
>> @@ -0,0 +1,4 @@
>> +Relative pointer protocol
>> +
>> +Maintainers:
>> +Jonas Ådahl <jadahl at gmail.com>
>> diff --git a/unstable/relative-pointer/relative-pointer-unstable-v1.xml b/unstable/relative-pointer/relative-pointer-unstable-v1.xml
>> new file mode 100644
>> index 0000000..0411d1f
>> --- /dev/null
>> +++ b/unstable/relative-pointer/relative-pointer-unstable-v1.xml
>> @@ -0,0 +1,122 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<protocol name="relative_pointer_unstable_v1">
>> +
>> +  <copyright>
>> +    Copyright © 2014      Jonas Ådahl
>> +    Copyright © 2015      Red Hat Inc.
>> +
>> +    Permission is hereby granted, free of charge, to any person obtaining a
>> +    copy of this software and associated documentation files (the "Software"),
>> +    to deal in the Software without restriction, including without limitation
>> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> +    and/or sell copies of the Software, and to permit persons to whom the
>> +    Software is furnished to do so, subject to the following conditions:
>> +
>> +    The above copyright notice and this permission notice (including the next
>> +    paragraph) shall be included in all copies or substantial portions of the
>> +    Software.
>> +
>> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> +    DEALINGS IN THE SOFTWARE.
>> +  </copyright>
>> +
>> +  <interface name="zwp_relative_pointer_manager_v1" version="1">
>> +    <description summary="get relative pointer objects">
>> +      A global interface used for getting the relative pointer object for a
>> +      given seat.
> 
> for a given pointer?  (I don't see any place here where we're passing a
> seat...)
> 
>> +
>> +      Warning! The protocol described in this file is experimental and backward
>> +      incompatible changes may be made. Backward compatible changes may be added
>> +      together with the corresponding interface version bump.  Backward
>> +      incompatible changes are done by bumping the version number in the
>> +      protocol and interface names and resetting the interface version.  Once
>> +      the protocol is to be declared stable, the 'z' prefix and the version
>> +      number in the protocol and interface names are removed and the interface
>> +      version number is reset.
>> +    </description>
>> +
>> +    <request name="destroy" type="destructor">
>> +      <description summary="destroy the relative pointer manager object">
>> +	Used by the client to notify the server that it will no longer use this
>> +	relative pointer manager object.
>> +      </description>
>> +    </request>
>> +
>> +    <request name="get_relative_pointer">
>> +      <description summary="get a relative pointer object">
>> +	Create a relative pointer interface given a wl_pointer object. See the
>> +	wp_relative_pointer interface for more details.
>> +      </description>
>> +
>> +      <arg name="id" type="new_id" interface="zwp_relative_pointer_v1"/>
>> +      <arg name="pointer" type="object" interface="wl_pointer"/>
>> +    </request>
>> +  </interface>
>> +
>> +  <interface name="zwp_relative_pointer_v1" version="1">
>> +    <description summary="relative pointer object">
>> +      A wp_relative_pointer object is an extension to the wl_pointer interface
>> +      used for emitting relative pointer events. It shares the same focus as
>> +      wl_pointer objects of the same seat and will only emit events when it has
>> +      focus.
>> +    </description>
>> +
>> +    <request name="destroy" type="destructor">
>> +      <description summary="release the relative pointer object"/>
>> +    </request>
>> +
>> +    <event name="relative_motion">
>> +      <description summary="relative pointer motion">
>> +	Relative x/y pointer motion from the pointer of the seat associated with
>> +	this object.
>> +
>> +	A relative motion is in the same dimension as regular wl_pointer motion
>> +	events, except they do not represent an absolute position. For example,
>> +	moving a pointer from (x, y) to (x', y') would have the equivalent
>> +	relative motion (x' - x, y' - y). If a pointer motion caused the
>> +	absolute pointer position to be clipped by for example the edge of the
>> +	monitor, the relative motion is unaffected by the clipping and will
>> +	represent the unclipped motion.
>> +
>> +	This event also contains non-accelerated motion deltas. The
>> +	non-accelerated delta is, when applicable, the regular pointer motion
>> +	delta as it was before having applied motion acceleration and other
>> +	transformations such as normalization.
>> +
>> +	Note that the non-accelerated delta does not represent 'raw' events as
>> +	they were read from some device. Pointer motion acceleration is device-
>> +	and configuration-specific and non-accelerated deltas and accelerated
>> +	deltas may have the same value on some devices.
>> +
>> +	Relative motions are not coupled to wl_pointer.motion events, and can be
>> +	sent in combination with such events, but also independently. There may
>> +	also be scenarious where wl_pointer.motion is sent, but there is no
>> +	relative motion. The order of an absolute and relative motion event
>> +	originating from the same physical motion is not guaranteed.
> 
> It still makes me a little grumpy that we're potentially going to post a
> pile of absolute events (potentially 1000+ per second with a ridiculous
> gamer mouse) that a client ignores, but still get sent and trigger a
> callback.  I think it would be nice to have a way to disable the
> absolute motion events, possibly as a side effect of creating a relative
> pointer.

I'm a fool, just got around to reading pointer lock and the interaction
makes perfect sense (locked pointer no longer generated abs motion).
Ignore that complaint entirely.

>> +
>> +	If the client needs button events or focus state, it can receive them
>> +	from a wl_pointer object of the same seat that the wp_relative_pointer
>> +	object is associated with.
> 
> button presses are still strictly ordered though, right?  That is, I
> might see
> 
> rel
> abs
> button
> 
> or:
> abs
> rel
> button
> 
> but I'll never see
> abs
> button
> rel
> 
> for a situation where the button occurred after the rel motion?
> 
> I liked the discussion about framing rel pointer events inside
> wl_pointer.frame... I think that's something that can be bolted on later
> without breaking any backwards compatibility?
> 
> I guess a stream where wl_pointer didn't generate anything and
> wp_relative_pointer did could potentially look weird to an application
> not expecting it.
> 
> I hope there won't be any problems stemming from button presses coming
> with 32 bit timestamps while rel motion comes with 64 bit.  These could
> appear to be non-monotonic to a client?
> 
>> +      </description>
>> +
>> +      <arg name="utime_hi" type="uint"
>> +	   summary="high 32 bits of a 64 bit timestamp with microsecond granularity"/>
>> +      <arg name="utime_lo" type="uint"
>> +	   summary="low 32 bits of a 64 bit timestamp with microsecond granularity"/>
>> +      <arg name="dx" type="fixed"
>> +	   summary="the x component of the motion vector"/>
>> +      <arg name="dy" type="fixed"
>> +	   summary="the y component of the motion vector"/>
>> +      <arg name="dx_unaccel" type="fixed"
>> +	   summary="the x component of the unaccelerated motion vector"/>
>> +      <arg name="dy_unaccel" type="fixed"
>> +	   summary="the y component of the unaccelerated motion vector"/>
> 
> Utterly worthless bike shed painting:
> Personally, I'd like to see the unaccelerated deltas posted as "dx" and
> "dy" and the accelerated ones as "dx_accel" or "dy_accel", since if
> you're using the rel pointer interface there's a good chance you're
> writing a first person game where accelerated deltas are terrible.
> 
> Qualifying all the names would be fine too, and have nothing simply
> called "dx" and "dy", then developers are more likely to think for 5
> seconds instead of just grabbing dx and dy.
> 
> Anyway, low priority whining aside, this looks really good to me, and
> closes a functional hole we've had for far too long.
> 
> Reviewed-By: Derek Foreman <derekf at osg.samsung.com>
> 
> 
>> +    </event>
>> +  </interface>
>> +
>> +</protocol>
>>
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>