This brings the latest released versions of all used Wayland protocol files into this repository, removing the need for the user to arrange a sufficiently new version of wayland-protocols. The wayland.xml protocol file was copied from wayland 1.22.0. The additional protocol files were copied from wayland-protocols 1.32. Because of how files are moved and renamed inside the wayland-protocols repository, it will not always be possible to update all our protocol files from a single release without also potentially updating related code (acceptable) and prematurely breaking compatibility with compositors that still only support an earlier incompatible version (unacceptable). The macro in src/CMakeLists.txt has been modified to hopefully make it easier to add new protocol files. This made it necessary to change the name of a few of the generated header files. Closes #2053master
Camilla Löwy
ago%!(EXTRA string=1 year)
parent
73948e6c0f
commit
2c3eb75748
14 changed files with 5502 additions and 122 deletions
@ -0,0 +1,83 @@ |
||||
<?xml version="1.0" encoding="UTF-8"?> |
||||
<protocol name="idle_inhibit_unstable_v1"> |
||||
|
||||
<copyright> |
||||
Copyright © 2015 Samsung Electronics Co., Ltd |
||||
|
||||
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_idle_inhibit_manager_v1" version="1"> |
||||
<description summary="control behavior when display idles"> |
||||
This interface permits inhibiting the idle behavior such as screen |
||||
blanking, locking, and screensaving. The client binds the idle manager |
||||
globally, then creates idle-inhibitor objects for each surface. |
||||
|
||||
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 idle inhibitor object"> |
||||
Destroy the inhibit manager. |
||||
</description> |
||||
</request> |
||||
|
||||
<request name="create_inhibitor"> |
||||
<description summary="create a new inhibitor object"> |
||||
Create a new inhibitor object associated with the given surface. |
||||
</description> |
||||
<arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/> |
||||
<arg name="surface" type="object" interface="wl_surface" |
||||
summary="the surface that inhibits the idle behavior"/> |
||||
</request> |
||||
|
||||
</interface> |
||||
|
||||
<interface name="zwp_idle_inhibitor_v1" version="1"> |
||||
<description summary="context object for inhibiting idle behavior"> |
||||
An idle inhibitor prevents the output that the associated surface is |
||||
visible on from being set to a state where it is not visually usable due |
||||
to lack of user interaction (e.g. blanked, dimmed, locked, set to power |
||||
save, etc.) Any screensaver processes are also blocked from displaying. |
||||
|
||||
If the surface is destroyed, unmapped, becomes occluded, loses |
||||
visibility, or otherwise becomes not visually relevant for the user, the |
||||
idle inhibitor will not be honored by the compositor; if the surface |
||||
subsequently regains visibility the inhibitor takes effect once again. |
||||
Likewise, the inhibitor isn't honored if the system was already idled at |
||||
the time the inhibitor was established, although if the system later |
||||
de-idles and re-idles the inhibitor will take effect. |
||||
</description> |
||||
|
||||
<request name="destroy" type="destructor"> |
||||
<description summary="destroy the idle inhibitor object"> |
||||
Remove the inhibitor effect from the associated wl_surface. |
||||
</description> |
||||
</request> |
||||
|
||||
</interface> |
||||
</protocol> |
||||
@ -0,0 +1,339 @@ |
||||
<?xml version="1.0" encoding="UTF-8"?> |
||||
<protocol name="pointer_constraints_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> |
||||
|
||||
<description summary="protocol for constraining pointer motions"> |
||||
This protocol specifies a set of interfaces used for adding constraints to |
||||
the motion of a pointer. Possible constraints include confining pointer |
||||
motions to a given region, or locking it to its current position. |
||||
|
||||
In order to constrain the pointer, a client must first bind the global |
||||
interface "wp_pointer_constraints" which, if a compositor supports pointer |
||||
constraints, is exposed by the registry. Using the bound global object, the |
||||
client uses the request that corresponds to the type of constraint it wants |
||||
to make. See wp_pointer_constraints for more details. |
||||
|
||||
Warning! The protocol described in this file is experimental and backward |
||||
incompatible changes may be made. Backward compatible changes may be added |
||||
together with the corresponding interface version bump. Backward |
||||
incompatible changes are done by bumping the version number in the protocol |
||||
and interface names and resetting the interface version. Once the protocol |
||||
is to be declared stable, the 'z' prefix and the version number in the |
||||
protocol and interface names are removed and the interface version number is |
||||
reset. |
||||
</description> |
||||
|
||||
<interface name="zwp_pointer_constraints_v1" version="1"> |
||||
<description summary="constrain the movement of a pointer"> |
||||
The global interface exposing pointer constraining functionality. It |
||||
exposes two requests: lock_pointer for locking the pointer to its |
||||
position, and confine_pointer for locking the pointer to a region. |
||||
|
||||
The lock_pointer and confine_pointer requests create the objects |
||||
wp_locked_pointer and wp_confined_pointer respectively, and the client can |
||||
use these objects to interact with the lock. |
||||
|
||||
For any surface, only one lock or confinement may be active across all |
||||
wl_pointer objects of the same seat. If a lock or confinement is requested |
||||
when another lock or confinement is active or requested on the same surface |
||||
and with any of the wl_pointer objects of the same seat, an |
||||
'already_constrained' error will be raised. |
||||
</description> |
||||
|
||||
<enum name="error"> |
||||
<description summary="wp_pointer_constraints error values"> |
||||
These errors can be emitted in response to wp_pointer_constraints |
||||
requests. |
||||
</description> |
||||
<entry name="already_constrained" value="1" |
||||
summary="pointer constraint already requested on that surface"/> |
||||
</enum> |
||||
|
||||
<enum name="lifetime"> |
||||
<description summary="constraint lifetime"> |
||||
These values represent different lifetime semantics. They are passed |
||||
as arguments to the factory requests to specify how the constraint |
||||
lifetimes should be managed. |
||||
</description> |
||||
<entry name="oneshot" value="1"> |
||||
<description summary="the pointer constraint is defunct once deactivated"> |
||||
A oneshot pointer constraint will never reactivate once it has been |
||||
deactivated. See the corresponding deactivation event |
||||
(wp_locked_pointer.unlocked and wp_confined_pointer.unconfined) for |
||||
details. |
||||
</description> |
||||
</entry> |
||||
<entry name="persistent" value="2"> |
||||
<description summary="the pointer constraint may reactivate"> |
||||
A persistent pointer constraint may again reactivate once it has |
||||
been deactivated. See the corresponding deactivation event |
||||
(wp_locked_pointer.unlocked and wp_confined_pointer.unconfined) for |
||||
details. |
||||
</description> |
||||
</entry> |
||||
</enum> |
||||
|
||||
<request name="destroy" type="destructor"> |
||||
<description summary="destroy the pointer constraints manager object"> |
||||
Used by the client to notify the server that it will no longer use this |
||||
pointer constraints object. |
||||
</description> |
||||
</request> |
||||
|
||||
<request name="lock_pointer"> |
||||
<description summary="lock pointer to a position"> |
||||
The lock_pointer request lets the client request to disable movements of |
||||
the virtual pointer (i.e. the cursor), effectively locking the pointer |
||||
to a position. This request may not take effect immediately; in the |
||||
future, when the compositor deems implementation-specific constraints |
||||
are satisfied, the pointer lock will be activated and the compositor |
||||
sends a locked event. |
||||
|
||||
The protocol provides no guarantee that the constraints are ever |
||||
satisfied, and does not require the compositor to send an error if the |
||||
constraints cannot ever be satisfied. It is thus possible to request a |
||||
lock that will never activate. |
||||
|
||||
There may not be another pointer constraint of any kind requested or |
||||
active on the surface for any of the wl_pointer objects of the seat of |
||||
the passed pointer when requesting a lock. If there is, an error will be |
||||
raised. See general pointer lock documentation for more details. |
||||
|
||||
The intersection of the region passed with this request and the input |
||||
region of the surface is used to determine where the pointer must be |
||||
in order for the lock to activate. It is up to the compositor whether to |
||||
warp the pointer or require some kind of user interaction for the lock |
||||
to activate. If the region is null the surface input region is used. |
||||
|
||||
A surface may receive pointer focus without the lock being activated. |
||||
|
||||
The request creates a new object wp_locked_pointer which is used to |
||||
interact with the lock as well as receive updates about its state. See |
||||
the the description of wp_locked_pointer for further information. |
||||
|
||||
Note that while a pointer is locked, the wl_pointer objects of the |
||||
corresponding seat will not emit any wl_pointer.motion events, but |
||||
relative motion events will still be emitted via wp_relative_pointer |
||||
objects of the same seat. wl_pointer.axis and wl_pointer.button events |
||||
are unaffected. |
||||
</description> |
||||
<arg name="id" type="new_id" interface="zwp_locked_pointer_v1"/> |
||||
<arg name="surface" type="object" interface="wl_surface" |
||||
summary="surface to lock pointer to"/> |
||||
<arg name="pointer" type="object" interface="wl_pointer" |
||||
summary="the pointer that should be locked"/> |
||||
<arg name="region" type="object" interface="wl_region" allow-null="true" |
||||
summary="region of surface"/> |
||||
<arg name="lifetime" type="uint" enum="lifetime" summary="lock lifetime"/> |
||||
</request> |
||||
|
||||
<request name="confine_pointer"> |
||||
<description summary="confine pointer to a region"> |
||||
The confine_pointer request lets the client request to confine the |
||||
pointer cursor to a given region. This request may not take effect |
||||
immediately; in the future, when the compositor deems implementation- |
||||
specific constraints are satisfied, the pointer confinement will be |
||||
activated and the compositor sends a confined event. |
||||
|
||||
The intersection of the region passed with this request and the input |
||||
region of the surface is used to determine where the pointer must be |
||||
in order for the confinement to activate. It is up to the compositor |
||||
whether to warp the pointer or require some kind of user interaction for |
||||
the confinement to activate. If the region is null the surface input |
||||
region is used. |
||||
|
||||
The request will create a new object wp_confined_pointer which is used |
||||
to interact with the confinement as well as receive updates about its |
||||
state. See the the description of wp_confined_pointer for further |
||||
information. |
||||
</description> |
||||
<arg name="id" type="new_id" interface="zwp_confined_pointer_v1"/> |
||||
<arg name="surface" type="object" interface="wl_surface" |
||||
summary="surface to lock pointer to"/> |
||||
<arg name="pointer" type="object" interface="wl_pointer" |
||||
summary="the pointer that should be confined"/> |
||||
<arg name="region" type="object" interface="wl_region" allow-null="true" |
||||
summary="region of surface"/> |
||||
<arg name="lifetime" type="uint" enum="lifetime" summary="confinement lifetime"/> |
||||
</request> |
||||
</interface> |
||||
|
||||
<interface name="zwp_locked_pointer_v1" version="1"> |
||||
<description summary="receive relative pointer motion events"> |
||||
The wp_locked_pointer interface represents a locked pointer state. |
||||
|
||||
While the lock of this object is active, the wl_pointer objects of the |
||||
associated seat will not emit any wl_pointer.motion events. |
||||
|
||||
This object will send the event 'locked' when the lock is activated. |
||||
Whenever the lock is activated, it is guaranteed that the locked surface |
||||
will already have received pointer focus and that the pointer will be |
||||
within the region passed to the request creating this object. |
||||
|
||||
To unlock the pointer, send the destroy request. This will also destroy |
||||
the wp_locked_pointer object. |
||||
|
||||
If the compositor decides to unlock the pointer the unlocked event is |
||||
sent. See wp_locked_pointer.unlock for details. |
||||
|
||||
When unlocking, the compositor may warp the cursor position to the set |
||||
cursor position hint. If it does, it will not result in any relative |
||||
motion events emitted via wp_relative_pointer. |
||||
|
||||
If the surface the lock was requested on is destroyed and the lock is not |
||||
yet activated, the wp_locked_pointer object is now defunct and must be |
||||
destroyed. |
||||
</description> |
||||
|
||||
<request name="destroy" type="destructor"> |
||||
<description summary="destroy the locked pointer object"> |
||||
Destroy the locked pointer object. If applicable, the compositor will |
||||
unlock the pointer. |
||||
</description> |
||||
</request> |
||||
|
||||
<request name="set_cursor_position_hint"> |
||||
<description summary="set the pointer cursor position hint"> |
||||
Set the cursor position hint relative to the top left corner of the |
||||
surface. |
||||
|
||||
If the client is drawing its own cursor, it should update the position |
||||
hint to the position of its own cursor. A compositor may use this |
||||
information to warp the pointer upon unlock in order to avoid pointer |
||||
jumps. |
||||
|
||||
The cursor position hint is double buffered. The new hint will only take |
||||
effect when the associated surface gets it pending state applied. See |
||||
wl_surface.commit for details. |
||||
</description> |
||||
<arg name="surface_x" type="fixed" |
||||
summary="surface-local x coordinate"/> |
||||
<arg name="surface_y" type="fixed" |
||||
summary="surface-local y coordinate"/> |
||||
</request> |
||||
|
||||
<request name="set_region"> |
||||
<description summary="set a new lock region"> |
||||
Set a new region used to lock the pointer. |
||||
|
||||
The new lock region is double-buffered. The new lock region will |
||||
only take effect when the associated surface gets its pending state |
||||
applied. See wl_surface.commit for details. |
||||
|
||||
For details about the lock region, see wp_locked_pointer. |
||||
</description> |
||||
<arg name="region" type="object" interface="wl_region" allow-null="true" |
||||
summary="region of surface"/> |
||||
</request> |
||||
|
||||
<event name="locked"> |
||||
<description summary="lock activation event"> |
||||
Notification that the pointer lock of the seat's pointer is activated. |
||||
</description> |
||||
</event> |
||||
|
||||
<event name="unlocked"> |
||||
<description summary="lock deactivation event"> |
||||
Notification that the pointer lock of the seat's pointer is no longer |
||||
active. If this is a oneshot pointer lock (see |
||||
wp_pointer_constraints.lifetime) this object is now defunct and should |
||||
be destroyed. If this is a persistent pointer lock (see |
||||
wp_pointer_constraints.lifetime) this pointer lock may again |
||||
reactivate in the future. |
||||
</description> |
||||
</event> |
||||
</interface> |
||||
|
||||
<interface name="zwp_confined_pointer_v1" version="1"> |
||||
<description summary="confined pointer object"> |
||||
The wp_confined_pointer interface represents a confined pointer state. |
||||
|
||||
This object will send the event 'confined' when the confinement is |
||||
activated. Whenever the confinement is activated, it is guaranteed that |
||||
the surface the pointer is confined to will already have received pointer |
||||
focus and that the pointer will be within the region passed to the request |
||||
creating this object. It is up to the compositor to decide whether this |
||||
requires some user interaction and if the pointer will warp to within the |
||||
passed region if outside. |
||||
|
||||
To unconfine the pointer, send the destroy request. This will also destroy |
||||
the wp_confined_pointer object. |
||||
|
||||
If the compositor decides to unconfine the pointer the unconfined event is |
||||
sent. The wp_confined_pointer object is at this point defunct and should |
||||
be destroyed. |
||||
</description> |
||||
|
||||
<request name="destroy" type="destructor"> |
||||
<description summary="destroy the confined pointer object"> |
||||
Destroy the confined pointer object. If applicable, the compositor will |
||||
unconfine the pointer. |
||||
</description> |
||||
</request> |
||||
|
||||
<request name="set_region"> |
||||
<description summary="set a new confine region"> |
||||
Set a new region used to confine the pointer. |
||||
|
||||
The new confine region is double-buffered. The new confine region will |
||||
only take effect when the associated surface gets its pending state |
||||
applied. See wl_surface.commit for details. |
||||
|
||||
If the confinement is active when the new confinement region is applied |
||||
and the pointer ends up outside of newly applied region, the pointer may |
||||
warped to a position within the new confinement region. If warped, a |
||||
wl_pointer.motion event will be emitted, but no |
||||
wp_relative_pointer.relative_motion event. |
||||
|
||||
The compositor may also, instead of using the new region, unconfine the |
||||
pointer. |
||||
|
||||
For details about the confine region, see wp_confined_pointer. |
||||
</description> |
||||
<arg name="region" type="object" interface="wl_region" allow-null="true" |
||||
summary="region of surface"/> |
||||
</request> |
||||
|
||||
<event name="confined"> |
||||
<description summary="pointer confined"> |
||||
Notification that the pointer confinement of the seat's pointer is |
||||
activated. |
||||
</description> |
||||
</event> |
||||
|
||||
<event name="unconfined"> |
||||
<description summary="pointer unconfined"> |
||||
Notification that the pointer confinement of the seat's pointer is no |
||||
longer active. If this is a oneshot pointer confinement (see |
||||
wp_pointer_constraints.lifetime) this object is now defunct and should |
||||
be destroyed. If this is a persistent pointer confinement (see |
||||
wp_pointer_constraints.lifetime) this pointer confinement may again |
||||
reactivate in the future. |
||||
</description> |
||||
</event> |
||||
</interface> |
||||
|
||||
</protocol> |
||||
@ -0,0 +1,136 @@ |
||||
<?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> |
||||
|
||||
<description summary="protocol for relative pointer motion events"> |
||||
This protocol specifies a set of interfaces used for making clients able to |
||||
receive relative pointer events not obstructed by barriers (such as the |
||||
monitor edge or other pointer barriers). |
||||
|
||||
To start receiving relative pointer events, a client must first bind the |
||||
global interface "wp_relative_pointer_manager" which, if a compositor |
||||
supports relative pointer motion events, is exposed by the registry. After |
||||
having created the relative pointer manager proxy object, the client uses |
||||
it to create the actual relative pointer object using the |
||||
"get_relative_pointer" request given a wl_pointer. The relative pointer |
||||
motion events will then, when applicable, be transmitted via the proxy of |
||||
the newly created relative pointer object. See the documentation of the |
||||
relative pointer interface for more details. |
||||
|
||||
Warning! The protocol described in this file is experimental and backward |
||||
incompatible changes may be made. Backward compatible changes may be added |
||||
together with the corresponding interface version bump. Backward |
||||
incompatible changes are done by bumping the version number in the protocol |
||||
and interface names and resetting the interface version. Once the protocol |
||||
is to be declared stable, the 'z' prefix and the version number in the |
||||
protocol and interface names are removed and the interface version number is |
||||
reset. |
||||
</description> |
||||
|
||||
<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 pointer. |
||||
</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 scenarios 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. |
||||
|
||||
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. |
||||
</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"/> |
||||
</event> |
||||
</interface> |
||||
|
||||
</protocol> |
||||
@ -0,0 +1,180 @@ |
||||
<?xml version="1.0" encoding="UTF-8"?> |
||||
<protocol name="viewporter"> |
||||
|
||||
<copyright> |
||||
Copyright © 2013-2016 Collabora, Ltd. |
||||
|
||||
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="wp_viewporter" version="1"> |
||||
<description summary="surface cropping and scaling"> |
||||
The global interface exposing surface cropping and scaling |
||||
capabilities is used to instantiate an interface extension for a |
||||
wl_surface object. This extended interface will then allow |
||||
cropping and scaling the surface contents, effectively |
||||
disconnecting the direct relationship between the buffer and the |
||||
surface size. |
||||
</description> |
||||
|
||||
<request name="destroy" type="destructor"> |
||||
<description summary="unbind from the cropping and scaling interface"> |
||||
Informs the server that the client will not be using this |
||||
protocol object anymore. This does not affect any other objects, |
||||
wp_viewport objects included. |
||||
</description> |
||||
</request> |
||||
|
||||
<enum name="error"> |
||||
<entry name="viewport_exists" value="0" |
||||
summary="the surface already has a viewport object associated"/> |
||||
</enum> |
||||
|
||||
<request name="get_viewport"> |
||||
<description summary="extend surface interface for crop and scale"> |
||||
Instantiate an interface extension for the given wl_surface to |
||||
crop and scale its content. If the given wl_surface already has |
||||
a wp_viewport object associated, the viewport_exists |
||||
protocol error is raised. |
||||
</description> |
||||
<arg name="id" type="new_id" interface="wp_viewport" |
||||
summary="the new viewport interface id"/> |
||||
<arg name="surface" type="object" interface="wl_surface" |
||||
summary="the surface"/> |
||||
</request> |
||||
</interface> |
||||
|
||||
<interface name="wp_viewport" version="1"> |
||||
<description summary="crop and scale interface to a wl_surface"> |
||||
An additional interface to a wl_surface object, which allows the |
||||
client to specify the cropping and scaling of the surface |
||||
contents. |
||||
|
||||
This interface works with two concepts: the source rectangle (src_x, |
||||
src_y, src_width, src_height), and the destination size (dst_width, |
||||
dst_height). The contents of the source rectangle are scaled to the |
||||
destination size, and content outside the source rectangle is ignored. |
||||
This state is double-buffered, and is applied on the next |
||||
wl_surface.commit. |
||||
|
||||
The two parts of crop and scale state are independent: the source |
||||
rectangle, and the destination size. Initially both are unset, that |
||||
is, no scaling is applied. The whole of the current wl_buffer is |
||||
used as the source, and the surface size is as defined in |
||||
wl_surface.attach. |
||||
|
||||
If the destination size is set, it causes the surface size to become |
||||
dst_width, dst_height. The source (rectangle) is scaled to exactly |
||||
this size. This overrides whatever the attached wl_buffer size is, |
||||
unless the wl_buffer is NULL. If the wl_buffer is NULL, the surface |
||||
has no content and therefore no size. Otherwise, the size is always |
||||
at least 1x1 in surface local coordinates. |
||||
|
||||
If the source rectangle is set, it defines what area of the wl_buffer is |
||||
taken as the source. If the source rectangle is set and the destination |
||||
size is not set, then src_width and src_height must be integers, and the |
||||
surface size becomes the source rectangle size. This results in cropping |
||||
without scaling. If src_width or src_height are not integers and |
||||
destination size is not set, the bad_size protocol error is raised when |
||||
the surface state is applied. |
||||
|
||||
The coordinate transformations from buffer pixel coordinates up to |
||||
the surface-local coordinates happen in the following order: |
||||
1. buffer_transform (wl_surface.set_buffer_transform) |
||||
2. buffer_scale (wl_surface.set_buffer_scale) |
||||
3. crop and scale (wp_viewport.set*) |
||||
This means, that the source rectangle coordinates of crop and scale |
||||
are given in the coordinates after the buffer transform and scale, |
||||
i.e. in the coordinates that would be the surface-local coordinates |
||||
if the crop and scale was not applied. |
||||
|
||||
If src_x or src_y are negative, the bad_value protocol error is raised. |
||||
Otherwise, if the source rectangle is partially or completely outside of |
||||
the non-NULL wl_buffer, then the out_of_buffer protocol error is raised |
||||
when the surface state is applied. A NULL wl_buffer does not raise the |
||||
out_of_buffer error. |
||||
|
||||
If the wl_surface associated with the wp_viewport is destroyed, |
||||
all wp_viewport requests except 'destroy' raise the protocol error |
||||
no_surface. |
||||
|
||||
If the wp_viewport object is destroyed, the crop and scale |
||||
state is removed from the wl_surface. The change will be applied |
||||
on the next wl_surface.commit. |
||||
</description> |
||||
|
||||
<request name="destroy" type="destructor"> |
||||
<description summary="remove scaling and cropping from the surface"> |
||||
The associated wl_surface's crop and scale state is removed. |
||||
The change is applied on the next wl_surface.commit. |
||||
</description> |
||||
</request> |
||||
|
||||
<enum name="error"> |
||||
<entry name="bad_value" value="0" |
||||
summary="negative or zero values in width or height"/> |
||||
<entry name="bad_size" value="1" |
||||
summary="destination size is not integer"/> |
||||
<entry name="out_of_buffer" value="2" |
||||
summary="source rectangle extends outside of the content area"/> |
||||
<entry name="no_surface" value="3" |
||||
summary="the wl_surface was destroyed"/> |
||||
</enum> |
||||
|
||||
<request name="set_source"> |
||||
<description summary="set the source rectangle for cropping"> |
||||
Set the source rectangle of the associated wl_surface. See |
||||
wp_viewport for the description, and relation to the wl_buffer |
||||
size. |
||||
|
||||
If all of x, y, width and height are -1.0, the source rectangle is |
||||
unset instead. Any other set of values where width or height are zero |
||||
or negative, or x or y are negative, raise the bad_value protocol |
||||
error. |
||||
|
||||
The crop and scale state is double-buffered state, and will be |
||||
applied on the next wl_surface.commit. |
||||
</description> |
||||
<arg name="x" type="fixed" summary="source rectangle x"/> |
||||
<arg name="y" type="fixed" summary="source rectangle y"/> |
||||
<arg name="width" type="fixed" summary="source rectangle width"/> |
||||
<arg name="height" type="fixed" summary="source rectangle height"/> |
||||
</request> |
||||
|
||||
<request name="set_destination"> |
||||
<description summary="set the surface size for scaling"> |
||||
Set the destination size of the associated wl_surface. See |
||||
wp_viewport for the description, and relation to the wl_buffer |
||||
size. |
||||
|
||||
If width is -1 and height is -1, the destination size is unset |
||||
instead. Any other pair of values for width and height that |
||||
contains zero or negative values raises the bad_value protocol |
||||
error. |
||||
|
||||
The crop and scale state is double-buffered state, and will be |
||||
applied on the next wl_surface.commit. |
||||
</description> |
||||
<arg name="width" type="int" summary="surface width"/> |
||||
<arg name="height" type="int" summary="surface height"/> |
||||
</request> |
||||
</interface> |
||||
|
||||
</protocol> |
||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,156 @@ |
||||
<?xml version="1.0" encoding="UTF-8"?> |
||||
<protocol name="xdg_decoration_unstable_v1"> |
||||
<copyright> |
||||
Copyright © 2018 Simon Ser |
||||
|
||||
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="zxdg_decoration_manager_v1" version="1"> |
||||
<description summary="window decoration manager"> |
||||
This interface allows a compositor to announce support for server-side |
||||
decorations. |
||||
|
||||
A window decoration is a set of window controls as deemed appropriate by |
||||
the party managing them, such as user interface components used to move, |
||||
resize and change a window's state. |
||||
|
||||
A client can use this protocol to request being decorated by a supporting |
||||
compositor. |
||||
|
||||
If compositor and client do not negotiate the use of a server-side |
||||
decoration using this protocol, clients continue to self-decorate as they |
||||
see fit. |
||||
|
||||
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 decoration manager object"> |
||||
Destroy the decoration manager. This doesn't destroy objects created |
||||
with the manager. |
||||
</description> |
||||
</request> |
||||
|
||||
<request name="get_toplevel_decoration"> |
||||
<description summary="create a new toplevel decoration object"> |
||||
Create a new decoration object associated with the given toplevel. |
||||
|
||||
Creating an xdg_toplevel_decoration from an xdg_toplevel which has a |
||||
buffer attached or committed is a client error, and any attempts by a |
||||
client to attach or manipulate a buffer prior to the first |
||||
xdg_toplevel_decoration.configure event must also be treated as |
||||
errors. |
||||
</description> |
||||
<arg name="id" type="new_id" interface="zxdg_toplevel_decoration_v1"/> |
||||
<arg name="toplevel" type="object" interface="xdg_toplevel"/> |
||||
</request> |
||||
</interface> |
||||
|
||||
<interface name="zxdg_toplevel_decoration_v1" version="1"> |
||||
<description summary="decoration object for a toplevel surface"> |
||||
The decoration object allows the compositor to toggle server-side window |
||||
decorations for a toplevel surface. The client can request to switch to |
||||
another mode. |
||||
|
||||
The xdg_toplevel_decoration object must be destroyed before its |
||||
xdg_toplevel. |
||||
</description> |
||||
|
||||
<enum name="error"> |
||||
<entry name="unconfigured_buffer" value="0" |
||||
summary="xdg_toplevel has a buffer attached before configure"/> |
||||
<entry name="already_constructed" value="1" |
||||
summary="xdg_toplevel already has a decoration object"/> |
||||
<entry name="orphaned" value="2" |
||||
summary="xdg_toplevel destroyed before the decoration object"/> |
||||
</enum> |
||||
|
||||
<request name="destroy" type="destructor"> |
||||
<description summary="destroy the decoration object"> |
||||
Switch back to a mode without any server-side decorations at the next |
||||
commit. |
||||
</description> |
||||
</request> |
||||
|
||||
<enum name="mode"> |
||||
<description summary="window decoration modes"> |
||||
These values describe window decoration modes. |
||||
</description> |
||||
<entry name="client_side" value="1" |
||||
summary="no server-side window decoration"/> |
||||
<entry name="server_side" value="2" |
||||
summary="server-side window decoration"/> |
||||
</enum> |
||||
|
||||
<request name="set_mode"> |
||||
<description summary="set the decoration mode"> |
||||
Set the toplevel surface decoration mode. This informs the compositor |
||||
that the client prefers the provided decoration mode. |
||||
|
||||
After requesting a decoration mode, the compositor will respond by |
||||
emitting an xdg_surface.configure event. The client should then update |
||||
its content, drawing it without decorations if the received mode is |
||||
server-side decorations. The client must also acknowledge the configure |
||||
when committing the new content (see xdg_surface.ack_configure). |
||||
|
||||
The compositor can decide not to use the client's mode and enforce a |
||||
different mode instead. |
||||
|
||||
Clients whose decoration mode depend on the xdg_toplevel state may send |
||||
a set_mode request in response to an xdg_surface.configure event and wait |
||||
for the next xdg_surface.configure event to prevent unwanted state. |
||||
Such clients are responsible for preventing configure loops and must |
||||
make sure not to send multiple successive set_mode requests with the |
||||
same decoration mode. |
||||
</description> |
||||
<arg name="mode" type="uint" enum="mode" summary="the decoration mode"/> |
||||
</request> |
||||
|
||||
<request name="unset_mode"> |
||||
<description summary="unset the decoration mode"> |
||||
Unset the toplevel surface decoration mode. This informs the compositor |
||||
that the client doesn't prefer a particular decoration mode. |
||||
|
||||
This request has the same semantics as set_mode. |
||||
</description> |
||||
</request> |
||||
|
||||
<event name="configure"> |
||||
<description summary="suggest a surface change"> |
||||
The configure event asks the client to change its decoration mode. The |
||||
configured state should not be applied immediately. Clients must send an |
||||
ack_configure in response to this event. See xdg_surface.configure and |
||||
xdg_surface.ack_configure for details. |
||||
|
||||
A configure event can be sent at any time. The specified mode must be |
||||
obeyed by the client. |
||||
</description> |
||||
<arg name="mode" type="uint" enum="mode" summary="the decoration mode"/> |
||||
</event> |
||||
</interface> |
||||
</protocol> |
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue