DeCarabas/oden
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Vendor things

Browse source
This commit is contained in:
John Doty 2024-03-08 11:03:01 -08:00
parent 5deceec006
commit 977e3c17e5
19434 changed files with 10682014 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
third-party/vendor/wayland-protocols/.cargo-checksum.json vendored Normal file
View file

File diff suppressed because one or more lines are too long

59
third-party/vendor/wayland-protocols/Cargo.toml vendored Normal file
View file

@ -0,0 +1,59 @@
# THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
#
# When uploading crates to the registry Cargo will automatically
# "normalize" Cargo.toml files for maximal compatibility
# with all versions of Cargo and also rewrite `path` dependencies
# to registry (e.g., crates.io) dependencies.
#
# If you are reading this file be aware that the original Cargo.toml
# will likely look very different (and much more reasonable).
# See Cargo.toml.orig for the original contents.
[package]
edition = "2018"
name = "wayland-protocols"
version = "0.29.5"
authors = ["Victor Berger <victor.berger@m4x.org>"]
build = "build.rs"
description = "Generated API for the officials wayland protocol extensions"
documentation = "https://smithay.github.io/wayland-rs/wayland_protocols/"
readme = "README.md"
keywords = [
"wayland",
"client",
"server",
"protocol",
"extension",
]
categories = [
"gui",
"api-bindings",
]
license = "MIT"
repository = "https://github.com/smithay/wayland-rs"
[package.metadata.docs.rs]
all-features = true
[dependencies.bitflags]
version = "1.0"
[dependencies.wayland-client]
version = "0.29.5"
optional = true
[dependencies.wayland-commons]
version = "0.29.5"
[dependencies.wayland-server]
version = "0.29.5"
optional = true
[build-dependencies.wayland-scanner]
version = "0.29.5"
[features]
client = ["wayland-client"]
server = ["wayland-server"]
staging_protocols = []
unstable_protocols = []

19
third-party/vendor/wayland-protocols/LICENSE.txt vendored Normal file
View file

@ -0,0 +1,19 @@
Copyright (c) 2015 Victor Berger
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 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.

27
third-party/vendor/wayland-protocols/README.md vendored Normal file
View file

@ -0,0 +1,27 @@
[![crates.io](https://img.shields.io/crates/v/wayland-protocols.svg)](https://crates.io/crates/wayland-protocols)
[![docs.rs](https://docs.rs/wayland-protocols/badge.svg)](https://docs.rs/wayland-protocols)
[![Continuous Integration](https://github.com/Smithay/wayland-rs/workflows/Continuous%20Integration/badge.svg)](https://github.com/Smithay/wayland-rs/actions?query=workflow%3A%22Continuous+Integration%22)
[![codecov](https://codecov.io/gh/Smithay/wayland-rs/branch/master/graph/badge.svg)](https://codecov.io/gh/Smithay/wayland-rs)
# wayland-protocols
This crate provides Wayland object definitions for many of the Wayland protocol extensions available.
It is meant to be used in addition to `wayland-client` or `wayland-server`.
This crate provides bindings for the following protocols extensions:
- The standard ["wayland-protocols"](https://gitlab.freedesktop.org/wayland/wayland-protocols) extensions
- The ["wlr-protocols"](https://github.com/swaywm/wlr-protocols) extensions from wlroots
- A few other misc protocols:
- `gtk_primary_selection`
The provided objects are controlled by cargo features:
- the `client` and `server` cargo features respectively enable the generation of client-side
and server-side objects
- the `staging_protocols` enable the generation of protocols in the staging process and will soon become stable.
- the `unstable_protocols` enable the generation of not-yet-stabilized protocols
If you wish for other protocols to be integrated, please open an issue on Github. Only protocols that
are meant to be stabilized and largely used are in scope of this crate. If you wish to generate
bindings for your own internal protocol, you can directly use `wayland-scanner`.

181
third-party/vendor/wayland-protocols/build.rs vendored Normal file
View file

@ -0,0 +1,181 @@
extern crate wayland_scanner;
use std::env::var;
use std::path::Path;
use wayland_scanner::*;
#[rustfmt::skip]
type StableProtocol<'a> = (&'a str, &'a [(&'a str, &'a str)]);
type VersionedProtocol<'a> = (&'a str, &'a [(&'a str, &'a [(&'a str, &'a str)])]);
// ^ ^ ^ ^ ^ ^
// | | | | | |
// Name | | | | Name of event to specify as
// Versions | | | destructor
// Version | |
// | Interface the event is belongs to
// |
// Events to specify as destructors
static STABLE_PROTOCOLS: &[StableProtocol] =
&[("presentation-time", &[]), ("viewporter", &[]), ("xdg-shell", &[])];
static STAGING_PROTOCOLS: &[VersionedProtocol] = &[("xdg-activation", &[("v1", &[])])];
static UNSTABLE_PROTOCOLS: &[VersionedProtocol] = &[
("fullscreen-shell", &[("v1", &[])]),
("idle-inhibit", &[("v1", &[])]),
("input-method", &[("v1", &[])]),
("input-timestamps", &[("v1", &[])]),
("keyboard-shortcuts-inhibit", &[("v1", &[])]),
("linux-dmabuf", &[("v1", &[])]),
(
"linux-explicit-synchronization",
&[(
"v1",
&[
("zwp_linux_buffer_release_v1", "fenced_release"),
("zwp_linux_buffer_release_v1", "immediate_release"),
],
)],
),
("pointer-constraints", &[("v1", &[])]),
("pointer-gestures", &[("v1", &[])]),
("primary-selection", &[("v1", &[])]),
("relative-pointer", &[("v1", &[])]),
("tablet", &[("v1", &[]), ("v2", &[])]),
("text-input", &[("v1", &[]), ("v3", &[])]),
("xdg-decoration", &[("v1", &[])]),
("xdg-foreign", &[("v1", &[]), ("v2", &[])]),
("xdg-output", &[("v1", &[])]),
("xdg-shell", &[("v5", &[]), ("v6", &[])]),
("xwayland-keyboard-grab", &[("v1", &[])]),
];
static WLR_UNSTABLE_PROTOCOLS: &[VersionedProtocol] = &[
("wlr-data-control", &[("v1", &[])]),
("wlr-export-dmabuf", &[("v1", &[])]),
("wlr-foreign-toplevel-management", &[("v1", &[])]),
("wlr-gamma-control", &[("v1", &[])]),
("wlr-input-inhibitor", &[("v1", &[])]),
("wlr-layer-shell", &[("v1", &[])]),
("wlr-output-management", &[("v1", &[])]),
("wlr-output-power-management", &[("v1", &[])]),
("wlr-screencopy", &[("v1", &[])]),
("wlr-virtual-pointer", &[("v1", &[])]),
];
static MISC_PROTOCOLS: &[StableProtocol] = &[
("gtk-primary-selection", &[]),
("input-method-unstable-v2", &[]),
("server-decoration", &[]),
];
fn generate_protocol(
name: &str,
protocol_file: &Path,
out_dir: &Path,
client: bool,
server: bool,
dest_events: &[(&str, &str)],
) {
println!("cargo:rerun-if-changed={}", protocol_file.display());
if client {
generate_code_with_destructor_events(
&protocol_file,
out_dir.join(&format!("{}_client_api.rs", name)),
Side::Client,
dest_events,
);
}
if server {
generate_code_with_destructor_events(
&protocol_file,
out_dir.join(&format!("{}_server_api.rs", name)),
Side::Server,
dest_events,
);
}
}
fn main() {
println!("cargo:rerun-if-changed-env=CARGO_FEATURE_CLIENT");
println!("cargo:rerun-if-changed-env=CARGO_FEATURE_SERVER");
println!("cargo:rerun-if-changed-env=CARGO_FEATURE_UNSTABLE_PROTOCOLS");
let out_dir_str = var("OUT_DIR").unwrap();
let out_dir = Path::new(&out_dir_str);
let client = var("CARGO_FEATURE_CLIENT").ok().is_some();
let server = var("CARGO_FEATURE_SERVER").ok().is_some();
for &(name, dest_events) in STABLE_PROTOCOLS {
let file = format!("{name}/{name}.xml", name = name);
generate_protocol(
name,
&Path::new("./protocols/stable").join(&file),
out_dir,
client,
server,
dest_events,
);
}
if var("CARGO_FEATURE_STAGING_PROTOCOLS").ok().is_some() {
for &(name, versions) in STAGING_PROTOCOLS {
for &(version, dest_events) in versions {
let file = format!("{name}/{name}-{version}.xml", name = name, version = version);
generate_protocol(
&format!("{name}-{version}", name = name, version = version),
&Path::new("./protocols/staging").join(&file),
out_dir,
client,
server,
dest_events,
);
}
}
}
for &(name, dest_events) in MISC_PROTOCOLS {
let file = format!("{name}.xml", name = name);
generate_protocol(
name,
&Path::new("./misc").join(&file),
out_dir,
client,
server,
dest_events,
);
}
if var("CARGO_FEATURE_UNSTABLE_PROTOCOLS").ok().is_some() {
for &(name, versions) in UNSTABLE_PROTOCOLS {
for &(version, dest_events) in versions {
let file =
format!("{name}/{name}-unstable-{version}.xml", name = name, version = version);
generate_protocol(
&format!("{name}-{version}", name = name, version = version),
&Path::new("./protocols/unstable").join(file),
out_dir,
client,
server,
dest_events,
);
}
}
for &(name, versions) in WLR_UNSTABLE_PROTOCOLS {
for &(version, dest_events) in versions {
let file = format!("{name}-unstable-{version}.xml", name = name, version = version);
generate_protocol(
&format!("{name}-{version}", name = name, version = version),
&Path::new("./wlr-protocols/unstable").join(file),
out_dir,
client,
server,
dest_events,
);
}
}
}
}

225
third-party/vendor/wayland-protocols/misc/gtk-primary-selection.xml vendored Normal file
View file

@ -0,0 +1,225 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="gtk_primary_selection">
<copyright>
Copyright © 2015, 2016 Red Hat
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="Primary selection protocol">
This protocol provides the ability to have a primary selection device to
match that of the X server. This primary selection is a shortcut to the
common clipboard selection, where text just needs to be selected in order
to allow copying it elsewhere. The de facto way to perform this action
is the middle mouse button, although it is not limited to this one.
Clients wishing to honor primary selection should create a primary
selection source and set it as the selection through
wp_primary_selection_device.set_selection whenever the text selection
changes. In order to minimize calls in pointer-driven text selection,
it should happen only once after the operation finished. Similarly,
a NULL source should be set when text is unselected.
wp_primary_selection_offer objects are first announced through the
wp_primary_selection_device.data_offer event. Immediately after this event,
the primary data offer will emit wp_primary_selection_offer.offer events
to let know of the mime types being offered.
When the primary selection changes, the client with the keyboard focus
will receive wp_primary_selection_device.selection events. Only the client
with the keyboard focus will receive such events with a non-NULL
wp_primary_selection_offer. Across keyboard focus changes, previously
focused clients will receive wp_primary_selection_device.events with a
NULL wp_primary_selection_offer.
In order to request the primary selection data, the client must pass
a recent serial pertaining to the press event that is triggering the
operation, if the compositor deems the serial valid and recent, the
wp_primary_selection_source.send event will happen in the other end
to let the transfer begin. The client owning the primary selection
should write the requested data, and close the file descriptor
immediately.
If the primary selection owner client disappeared during the transfer,
the client reading the data will receive a
wp_primary_selection_device.selection event with a NULL
wp_primary_selection_offer, the client should take this as a hint
to finish the reads related to the no longer existing offer.
The primary selection owner should be checking for errors during
writes, merely cancelling the ongoing transfer if any happened.
</description>
<interface name="gtk_primary_selection_device_manager" version="1">
<description summary="X primary selection emulation">
The primary selection device manager is a singleton global object that
provides access to the primary selection. It allows to create
wp_primary_selection_source objects, as well as retrieving the per-seat
wp_primary_selection_device objects.
</description>
<request name="create_source">
<description summary="create a new primary selection source">
Create a new primary selection source.
</description>
<arg name="id" type="new_id" interface="gtk_primary_selection_source"/>
</request>
<request name="get_device">
<description summary="create a new primary selection device">
Create a new data device for a given seat.
</description>
<arg name="id" type="new_id" interface="gtk_primary_selection_device"/>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection device manager">
Destroy the primary selection device manager.
</description>
</request>
</interface>
<interface name="gtk_primary_selection_device" version="1">
<request name="set_selection">
<description summary="set the primary selection">
Replaces the current selection. The previous owner of the primary selection
will receive a wp_primary_selection_source.cancelled event.
To unset the selection, set the source to NULL.
</description>
<arg name="source" type="object" interface="gtk_primary_selection_source" allow-null="true"/>
<arg name="serial" type="uint" summary="serial of the event that triggered this request"/>
</request>
<event name="data_offer">
<description summary="introduce a new wp_primary_selection_offer">
Introduces a new wp_primary_selection_offer object that may be used
to receive the current primary selection. Immediately following this
event, the new wp_primary_selection_offer object will send
wp_primary_selection_offer.offer events to describe the offered mime
types.
</description>
<arg name="offer" type="new_id" interface="gtk_primary_selection_offer"/>
</event>
<event name="selection">
<description summary="advertise a new primary selection">
The wp_primary_selection_device.selection event is sent to notify the
client of a new primary selection. This event is sent after the
wp_primary_selection.data_offer event introducing this object, and after
the offer has announced its mimetypes through
wp_primary_selection_offer.offer.
The data_offer is valid until a new offer or NULL is received
or until the client loses keyboard focus. The client must destroy the
previous selection data_offer, if any, upon receiving this event.
</description>
<arg name="id" type="object" interface="gtk_primary_selection_offer" allow-null="true"/>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection device">
Destroy the primary selection device.
</description>
</request>
</interface>
<interface name="gtk_primary_selection_offer" version="1">
<description summary="offer to transfer primary selection contents">
A wp_primary_selection_offer represents an offer to transfer the contents
of the primary selection clipboard to the client. Similar to
wl_data_offer, the offer also describes the mime types that the source
will transferthat the
data can be converted to and provides the mechanisms for transferring the
data directly to the client.
</description>
<request name="receive">
<description summary="request that the data is transferred">
To transfer the contents of the primary selection clipboard, the client
issues this request and indicates the mime type that it wants to
receive. The transfer happens through the passed file descriptor
(typically created with the pipe system call). The source client writes
the data in the mime type representation requested and then closes the
file descriptor.
The receiving client reads from the read end of the pipe until EOF and
closes its end, at which point the transfer is complete.
</description>
<arg name="mime_type" type="string"/>
<arg name="fd" type="fd"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection offer">
Destroy the primary selection offer.
</description>
</request>
<event name="offer">
<description summary="advertise offered mime type">
Sent immediately after creating announcing the wp_primary_selection_offer
through wp_primary_selection_device.data_offer. One event is sent per
offered mime type.
</description>
<arg name="mime_type" type="string"/>
</event>
</interface>
<interface name="gtk_primary_selection_source" version="1">
<description summary="offer to replace the contents of the primary selection">
The source side of a wp_primary_selection_offer, it provides a way to
describe the offered data and respond to requests to transfer the
requested contents of the primary selection clipboard.
</description>
<request name="offer">
<description summary="add an offered mime type">
This request adds a mime type to the set of mime types advertised to
targets. Can be called several times to offer multiple types.
</description>
<arg name="mime_type" type="string"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection source">
Destroy the primary selection source.
</description>
</request>
<event name="send">
<description summary="send the primary selection contents">
Request for the current primary selection contents from the client.
Send the specified mime type over the passed file descriptor, then
close it.
</description>
<arg name="mime_type" type="string"/>
<arg name="fd" type="fd"/>
</event>
<event name="cancelled">
<description summary="request for primary selection contents was canceled">
This primary selection source is no longer valid. The client should
clean up and destroy this primary selection source.
</description>
</event>
</interface>
</protocol>

490
third-party/vendor/wayland-protocols/misc/input-method-unstable-v2.xml vendored Normal file
View file

@ -0,0 +1,490 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="input_method_unstable_v2">
<copyright>
Copyright © 2008-2011 Kristian Høgsberg
Copyright © 2010-2011 Intel Corporation
Copyright © 2012-2013 Collabora, Ltd.
Copyright © 2012, 2013 Intel Corporation
Copyright © 2015, 2016 Jan Arne Petersen
Copyright © 2017, 2018 Red Hat, Inc.
Copyright © 2018 Purism SPC
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 creating input methods">
This protocol allows applications to act as input methods for compositors.
An input method context is used to manage the state of the input method.
Text strings are UTF-8 encoded, their indices and lengths are in bytes.
This document adheres to the RFC 2119 when using words like "must",
"should", "may", etc.
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_input_method_v2" version="1">
<description summary="input method">
An input method object allows for clients to compose text.
The objects connects the client to a text input in an application, and
lets the client to serve as an input method for a seat.
The zwp_input_method_v2 object can occupy two distinct states: active and
inactive. In the active state, the object is associated to and
communicates with a text input. In the inactive state, there is no
associated text input, and the only communication is with the compositor.
Initially, the input method is in the inactive state.
Requests issued in the inactive state must be accepted by the compositor.
Because of the serial mechanism, and the state reset on activate event,
they will not have any effect on the state of the next text input.
There must be no more than one input method object per seat.
</description>
<event name="activate">
<description summary="input method has been requested">
Notification that a text input focused on this seat requested the input
method to be activated.
This event serves the purpose of providing the compositor with an
active input method.
This event resets all state associated with previous enable, disable,
surrounding_text, text_change_cause, and content_type events, as well
as the state associated with set_preedit_string, commit_string, and
delete_surrounding_text requests. In addition, it marks the
zwp_input_method_v2 object as active, and makes any existing
zwp_input_popup_surface_v2 objects visible.
The surrounding_text, and content_type events must follow before the
next done event if the text input supports the respective
functionality.
State set with this event is double-buffered. It will get applied on
the next zwp_input_method_v2.done event, and stay valid until changed.
</description>
</event>
<event name="deactivate">
<description summary="deactivate event">
Notification that no focused text input currently needs an active
input method on this seat.
This event marks the zwp_input_method_v2 object as inactive. The
compositor must make all existing zwp_input_popup_surface_v2 objects
invisible until the next activate event.
State set with this event is double-buffered. It will get applied on
the next zwp_input_method_v2.done event, and stay valid until changed.
</description>
</event>
<event name="surrounding_text">
<description summary="surrounding text event">
Updates the surrounding plain text around the cursor, excluding the
preedit text.
If any preedit text is present, it is replaced with the cursor for the
purpose of this event.
The argument text is a buffer containing the preedit string, and must
include the cursor position, and the complete selection. It should
contain additional characters before and after these. There is a
maximum length of wayland messages, so text can not be longer than 4000
bytes.
cursor is the byte offset of the cursor within the text buffer.
anchor is the byte offset of the selection anchor within the text
buffer. If there is no selected text, anchor must be the same as
cursor.
If this event does not arrive before the first done event, the input
method may assume that the text input does not support this
functionality and ignore following surrounding_text events.
Values set with this event are double-buffered. They will get applied
and set to initial values on the next zwp_input_method_v2.done
event.
The initial state for affected fields is empty, meaning that the text
input does not support sending surrounding text. If the empty values
get applied, subsequent attempts to change them may have no effect.
</description>
<arg name="text" type="string"/>
<arg name="cursor" type="uint"/>
<arg name="anchor" type="uint"/>
</event>
<event name="text_change_cause">
<description summary="indicates the cause of surrounding text change">
Tells the input method why the text surrounding the cursor changed.
Whenever the client detects an external change in text, cursor, or
anchor position, it must issue this request to the compositor. This
request is intended to give the input method a chance to update the
preedit text in an appropriate way, e.g. by removing it when the user
starts typing with a keyboard.
cause describes the source of the change.
The value set with this event is double-buffered. It will get applied
and set to its initial value on the next zwp_input_method_v2.done
event.
The initial value of cause is input_method.
</description>
<arg name="cause" type="uint" enum="zwp_text_input_v3.change_cause"/>
</event>
<event name="content_type">
<description summary="content purpose and hint">
Indicates the content type and hint for the current
zwp_input_method_v2 instance.
Values set with this event are double-buffered. They will get applied
on the next zwp_input_method_v2.done event.
The initial value for hint is none, and the initial value for purpose
is normal.
</description>
<arg name="hint" type="uint" enum="zwp_text_input_v3.content_hint"/>
<arg name="purpose" type="uint" enum="zwp_text_input_v3.content_purpose"/>
</event>
<event name="done">
<description summary="apply state">
Atomically applies state changes recently sent to the client.
The done event establishes and updates the state of the client, and
must be issued after any changes to apply them.
Text input state (content purpose, content hint, surrounding text, and
change cause) is conceptually double-buffered within an input method
context.
Events modify the pending state, as opposed to the current state in use
by the input method. A done event atomically applies all pending state,
replacing the current state. After done, the new pending state is as
documented for each related request.
Events must be applied in the order of arrival.
Neither current nor pending state are modified unless noted otherwise.
</description>
</event>
<request name="commit_string">
<description summary="commit string">
Send the commit string text for insertion to the application.
Inserts a string at current cursor position (see commit event
sequence). The string to commit could be either just a single character
after a key press or the result of some composing.
The argument text is a buffer containing the string to insert. There is
a maximum length of wayland messages, so text can not be longer than
4000 bytes.
Values set with this event are double-buffered. They must be applied
and reset to initial on the next zwp_text_input_v3.commit request.
The initial value of text is an empty string.
</description>
<arg name="text" type="string"/>
</request>
<request name="set_preedit_string">
<description summary="pre-edit string">
Send the pre-edit string text to the application text input.
Place a new composing text (pre-edit) at the current cursor position.
Any previously set composing text must be removed. Any previously
existing selected text must be removed. The cursor is moved to a new
position within the preedit string.
The argument text is a buffer containing the preedit string. There is
a maximum length of wayland messages, so text can not be longer than
4000 bytes.
The arguments cursor_begin and cursor_end are counted in bytes relative
to the beginning of the submitted string buffer. Cursor should be
hidden by the text input when both are equal to -1.
cursor_begin indicates the beginning of the cursor. cursor_end
indicates the end of the cursor. It may be equal or different than
cursor_begin.
Values set with this event are double-buffered. They must be applied on
the next zwp_input_method_v2.commit event.
The initial value of text is an empty string. The initial value of
cursor_begin, and cursor_end are both 0.
</description>
<arg name="text" type="string"/>
<arg name="cursor_begin" type="int"/>
<arg name="cursor_end" type="int"/>
</request>
<request name="delete_surrounding_text">
<description summary="delete text">
Remove the surrounding text.
before_length and after_length are the number of bytes before and after
the current cursor index (excluding the preedit text) to delete.
If any preedit text is present, it is replaced with the cursor for the
purpose of this event. In effect before_length is counted from the
beginning of preedit text, and after_length from its end (see commit
event sequence).
Values set with this event are double-buffered. They must be applied
and reset to initial on the next zwp_input_method_v2.commit request.
The initial values of both before_length and after_length are 0.
</description>
<arg name="before_length" type="uint"/>
<arg name="after_length" type="uint"/>
</request>
<request name="commit">
<description summary="apply state">
Apply state changes from commit_string, set_preedit_string and
delete_surrounding_text requests.
The state relating to these events is double-buffered, and each one
modifies the pending state. This request replaces the current state
with the pending state.
The connected text input is expected to proceed by evaluating the
changes in the following order:
1. Replace existing preedit string with the cursor.
2. Delete requested surrounding text.
3. Insert commit string with the cursor at its end.
4. Calculate surrounding text to send.
5. Insert new preedit text in cursor position.
6. Place cursor inside preedit text.
The serial number reflects the last state of the zwp_input_method_v2
object known to the client. The value of the serial argument must be
equal to the number of done events already issued by that object. When
the compositor receives a commit request with a serial different than
the number of past done events, it must proceed as normal, except it
should not change the current state of the zwp_input_method_v2 object.
</description>
<arg name="serial" type="uint"/>
</request>
<request name="get_input_popup_surface">
<description summary="create popup surface">
Creates a new zwp_input_popup_surface_v2 object wrapping a given
surface.
The surface gets assigned the "input_popup" role. If the surface
already has an assigned role, the compositor must issue a protocol
error.
</description>
<arg name="id" type="new_id" interface="zwp_input_popup_surface_v2"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="grab_keyboard">
<description summary="grab hardware keyboard">
Allow an input method to receive hardware keyboard input and process
key events to generate text events (with pre-edit) over the wire. This
allows input methods which compose multiple key events for inputting
text like it is done for CJK languages.
The compositor should send all keyboard events on the seat to the grab
holder via the returned wl_keyboard object. Nevertheless, the
compositor may decide not to forward any particular event. The
compositor must not further process any event after it has been
forwarded to the grab holder.
Releasing the resulting wl_keyboard object releases the grab.
</description>
<arg name="keyboard" type="new_id"
interface="zwp_input_method_keyboard_grab_v2"/>
</request>
<event name="unavailable">
<description summary="input method unavailable">
The input method ceased to be available.
The compositor must issue this event as the only event on the object if
there was another input_method object associated with the same seat at
the time of its creation.
The compositor must issue this request when the object is no longer
useable, e.g. due to seat removal.
The input method context becomes inert and should be destroyed after
deactivation is handled. Any further requests and events except for the
destroy request must be ignored.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the text input">
Destroys the zwp_text_input_v2 object and any associated child
objects, i.e. zwp_input_popup_surface_v2 and
zwp_input_method_keyboard_grab_v2.
</description>
</request>
</interface>
<interface name="zwp_input_popup_surface_v2" version="1">
<description summary="popup surface">
This interface marks a surface as a popup for interacting with an input
method.
The compositor should place it near the active text input area. It must
be visible if and only if the input method is in the active state.
The client must not destroy the underlying wl_surface while the
zwp_input_popup_surface_v2 object exists.
</description>
<event name="text_input_rectangle">
<description summary="set text input area position">
Notify about the position of the area of the text input expressed as a
rectangle in surface local coordinates.
This is a hint to the input method telling it the relative position of
the text being entered.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</event>
<request name="destroy" type="destructor"/>
</interface>
<interface name="zwp_input_method_keyboard_grab_v2" version="1">
<!-- Closely follows wl_keyboard version 6 -->
<description summary="keyboard grab">
The zwp_input_method_keyboard_grab_v2 interface represents an exclusive
grab of the wl_keyboard interface associated with the seat.
</description>
<event name="keymap">
<description summary="keyboard mapping">
This event provides a file descriptor to the client which can be
memory-mapped to provide a keyboard mapping description.
</description>
<arg name="format" type="uint" enum="wl_keyboard.keymap_format"
summary="keymap format"/>
<arg name="fd" type="fd" summary="keymap file descriptor"/>
<arg name="size" type="uint" summary="keymap size, in bytes"/>
</event>
<event name="key">
<description summary="key event">
A key was pressed or released.
The time argument is a timestamp with millisecond granularity, with an
undefined base.
</description>
<arg name="serial" type="uint" summary="serial number of the key event"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="key" type="uint" summary="key that produced the event"/>
<arg name="state" type="uint" enum="wl_keyboard.key_state"
summary="physical state of the key"/>
</event>
<event name="modifiers">
<description summary="modifier and group state">
Notifies clients that the modifier and/or group state has changed, and
it should update its local state.
</description>
<arg name="serial" type="uint" summary="serial number of the modifiers event"/>
<arg name="mods_depressed" type="uint" summary="depressed modifiers"/>
<arg name="mods_latched" type="uint" summary="latched modifiers"/>
<arg name="mods_locked" type="uint" summary="locked modifiers"/>
<arg name="group" type="uint" summary="keyboard layout"/>
</event>
<request name="release" type="destructor">
<description summary="release the grab object"/>
</request>
<event name="repeat_info">
<description summary="repeat rate and delay">
Informs the client about the keyboard's repeat rate and delay.
This event is sent as soon as the zwp_input_method_keyboard_grab_v2
object has been created, and is guaranteed to be received by the
client before any key press event.
Negative values for either rate or delay are illegal. A rate of zero
will disable any repeating (regardless of the value of delay).
This event can be sent later on as well with a new value if necessary,
so clients should continue listening for the event past the creation
of zwp_input_method_keyboard_grab_v2.
</description>
<arg name="rate" type="int"
summary="the rate of repeating keys in characters per second"/>
<arg name="delay" type="int"
summary="delay in milliseconds since key down until repeating starts"/>
</event>
</interface>
<interface name="zwp_input_method_manager_v2" version="1">
<description summary="input method manager">
The input method manager allows the client to become the input method on
a chosen seat.
No more than one input method must be associated with any seat at any
given time.
</description>
<request name="get_input_method">
<description summary="request an input method object">
Request a new input zwp_input_method_v2 object associated with a given
seat.
</description>
<arg name="seat" type="object" interface="wl_seat"/>
<arg name="input_method" type="new_id" interface="zwp_input_method_v2"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the input method manager">
Destroys the zwp_input_method_manager_v2 object.
The zwp_input_method_v2 objects originating from it remain valid.
</description>
</request>
</interface>
</protocol>

85
third-party/vendor/wayland-protocols/misc/server-decoration.xml vendored Normal file
View file

@ -0,0 +1,85 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="server_decoration">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2015 Martin Gräßlin
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="org_kde_kwin_server_decoration_manager" version="1">
<description summary="Server side window decoration manager">
This interface allows to coordinate whether the server should create
a server-side window decoration around a wl_surface representing a
shell surface (wl_shell_surface or similar). By announcing support
for this interface the server indicates that it supports server
side decorations.
Use in conjunction with zxdg_decoration_manager_v1 is undefined.
</description>
<request name="create">
<description summary="Create a server-side decoration object for a given surface">
When a client creates a server-side decoration object it indicates
that it supports the protocol. The client is supposed to tell the
server whether it wants server-side decorations or will provide
client-side decorations.
If the client does not create a server-side decoration object for
a surface the server interprets this as lack of support for this
protocol and considers it as client-side decorated. Nevertheless a
client-side decorated surface should use this protocol to indicate
to the server that it does not want a server-side deco.
</description>
<arg name="id" type="new_id" interface="org_kde_kwin_server_decoration"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<enum name="mode">
<description summary="Possible values to use in request_mode and the event mode."/>
<entry name="None" value="0" summary="Undecorated: The surface is not decorated at all, neither server nor client-side. An example is a popup surface which should not be decorated."/>
<entry name="Client" value="1" summary="Client-side decoration: The decoration is part of the surface and the client."/>
<entry name="Server" value="2" summary="Server-side decoration: The server embeds the surface into a decoration frame."/>
</enum>
<event name="default_mode">
<description summary="The default mode used on the server">
This event is emitted directly after binding the interface. It contains
the default mode for the decoration. When a new server decoration object
is created this new object will be in the default mode until the first
request_mode is requested.
The server may change the default mode at any time.
</description>
<arg name="mode" type="uint" enum="mode" summary="The default decoration mode applied to newly created server decorations."/>
</event>
</interface>
<interface name="org_kde_kwin_server_decoration" version="1">
<request name="release" type="destructor">
<description summary="release the server decoration object"/>
</request>
<enum name="mode">
<description summary="Possible values to use in request_mode and the event mode."/>
<entry name="None" value="0" summary="Undecorated: The surface is not decorated at all, neither server nor client-side. An example is a popup surface which should not be decorated."/>
<entry name="Client" value="1" summary="Client-side decoration: The decoration is part of the surface and the client."/>
<entry name="Server" value="2" summary="Server-side decoration: The server embeds the surface into a decoration frame."/>
</enum>
<request name="request_mode">
<description summary="The decoration mode the surface wants to use."/>
<arg name="mode" type="uint" enum="mode" summary="The mode this surface wants to use."/>
</request>
<event name="mode">
<description summary="The new decoration mode applied by the server">
This event is emitted directly after the decoration is created and
represents the base decoration policy by the server. E.g. a server
which wants all surfaces to be client-side decorated will send Client,
a server which wants server-side decoration will send Server.
The client can request a different mode through the decoration request.
The server will acknowledge this by another event with the same mode. So
even if a server prefers server-side decoration it's possible to force a
client-side decoration.
The server may emit this event at any time. In this case the client can
again request a different mode. It's the responsibility of the server to
prevent a feedback loop.
</description>
<arg name="mode" type="uint" enum="mode" summary="The decoration mode applied to the surface by the server."/>
</event>
</interface>
</protocol>

33
third-party/vendor/wayland-protocols/protocols/COPYING vendored Normal file
View file

@ -0,0 +1,33 @@
Copyright © 2008-2013 Kristian Høgsberg
Copyright © 2010-2013 Intel Corporation
Copyright © 2013 Rafael Antognolli
Copyright © 2013 Jasper St. Pierre
Copyright © 2014 Jonas Ådahl
Copyright © 2014 Jason Ekstrand
Copyright © 2014-2015 Collabora, Ltd.
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.
---
The above is the version of the MIT "Expat" License used by X.org:
http://cgit.freedesktop.org/xorg/xserver/tree/COPYING

149
third-party/vendor/wayland-protocols/protocols/GOVERNANCE.md vendored Normal file
View file

@ -0,0 +1,149 @@
# wayland-protocols governance
This document governs the maintenance of wayland-protocols and serves to outline
the broader process for standardization of protocol extensions in the Wayland
ecosystem.
## 1. Membership
Membership in wayland-protocols is offered to stakeholders in the Wayland
ecosystem who have an interest in participating in protocol extension
standardization.
### 1.1. Membership requirements
1. Membership is extended to projects, rather than individuals.
2. Members represent general-purpose projects with a stake in multiple Wayland
protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose
applications with a stake in only one or two.
3. Each project must provide one or two named individuals as points-of-contact
for that project who can be reached to discuss protocol-related matters.
4. During a vote, if two points-of-contact for the same member disagree, the
member's vote is considered blank.
### 1.2. Becoming a member
1. New members who meet the criteria outlined in 1.1 are established by
invitation from an existing member. Projects hoping to join should reach out
to an existing member asking for this invitation.
2. New members shall write to the wayland-devel mailing list stating their
intention of joining and their sponsor.
3. The sponsor shall respond acknowledging their sponsorship of the membership.
4. A 14 day discussion period for comments from wayland-protocols members will
be held.
5. At the conclusion of the discussion period, the new membership is established
unless their application was NACKed by a 1/2 majority of all existing members.
### 1.3. Ceasing membership
1. A member may step down by writing their intention to do so to the
wayland-devel mailing list.
2. A removal vote may be called for by an existing member by posting to the
wayland-devel mailing list. This begins a 14 day voting & discussion
period.
3. At the conclusion of the voting period, the member is removed if the votes
total 2/3rds of all current members.
4. Removed members are not eligible to apply for membership again for a period
of 1 year.
5. Following a failed vote, the member who called for the vote cannot
call for a re-vote or propose any other removal for 90 days.
## 2. Protocols
### 2.1. Protocol namespaces
1. Namespaces are implemented in practice by prefixing each interface name in a
protocol definition (XML) with the namespace name, and an underscore (e.g.
"xdg_wm_base").
2. Protocols in a namespace may optionally use the namespace followed by a dash
in the name (e.g. "xdg-shell").
3. The "xdg" namespace is established for protocols letting clients
configure its surfaces as "windows", allowing clients to affect how they
are managed.
4. The "wp" namespace is established for protocols generally useful to Wayland
implementations (i.e. "plumbing" protocols).
5. The "ext" namespace is established as a general catch-all for protocols that
fit into no other namespace.
### 2.2. Protocol inclusion requirements
1. All protocols found in the "xdg" and "wp" namespaces at the time of writing
are grandfathered into their respective namespace without further discussion.
2. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if
ACKed by at least 3 members.
3. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if
if NACKed by any member.
4. Protocols in the "xdg" and "wp" namespaces must have at least 3 open-source
implementations (either 1 client + 2 servers, or 2 clients + 1 server) to be
eligible for inclusion.
5. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by
at least one other member.
6. Protocols in the "ext" namespace must have at least one open-source client &
one open-source server implementation to be eligible for inclusion.
7. "Open-source" is defined as distributed with an Open Source Initiative
approved license.
### 2.3. Introducing new protocols
1. A new protocol may be proposed by submitting a merge request to the
wayland-protocols Gitlab repository.
2. Protocol proposal posts must include justification for their inclusion in
their namespace per the requirements outlined in section 2.2.
3. An indefinite discussion period for comments from wayland-protocols members
will be held, with a minimum duration of 30 days. Protocols which require a
certain level of implementation status, ACKs from members, and so on, should
use this time to acquire them.
4. When the proposed protocol meets all requirements for inclusion per section
2.2, and the minimum discussion period has elapsed, the sponsoring member may
merge their changes in the wayland-protocol repository.
5. Amendments to existing protocols may be proposed by the same process, with
no minimum discussion period.
6. Declaring a protocol stable may be proposed by the same process, with the
regular 30 day minimum discussion period.
## 3. Protocol adoption documentation
### 3.1. Adoption website
1. This section is informational.
2. A website will be made available for interested parties to browse the
implementation status of protocols included in wayland-protocols.
3. A statement from each member of wayland-protocols will be included on the
site.
4. Each protocol will be listed along with its approval status from each member.
5. The approval statuses are:
1. NACK, or "negative acknowledgement", meaning that the member is opposed to
the protocol in principle.
2. NOPP, or "no opposition", meaning that the member is not opposed to the
protocol in principle, but does not provide an implementation.
3. ACK, or "acknowledged", meaning that the member supports the protocol in
principle, but does not provide an implementation.
4. IMPL, or "implemented", meaning that the member supports the protocol and
provides an implementation.
6. Each member may write a short statement expanding on the rationale for their
approval status, which will be included on the site.
7. A supplementary list of implementations will also be provided on the site,
which may include implementations supported by non-members.
### 3.2. Changes to the adoption website
1. This section is informational.
2. A new protocol is added to the website by the sponsoring member at the
conclusion of the discussion period (section 2.3.3).
3. During the discussion period (section 2.3.3), interested parties may express
their approval status on the Gitlab merge request. The default approval
status for members who do not participate in the discussion is "NOPP".
4. Members may change their acknowledgement status or support statement at any
time after the discussion period (section 2.3.3) has closed by simply merging
their update in the wayland-protocols repository.
## 4. Amending this document
1. An amendment to this document may be proposed any member by
submitting a merge request on Gitlab.
2. A 30 day discussion period for comments from wayland-protocols members will
be held.
3. At the conclusion of the discussion period, an amendment will become
effective if it's ACKed by at least 2/3rds of all wayland-protocols members,
and NACKed by none. The sponsoring member may merge their change to the
wayland-protocols repository at this point.

13
third-party/vendor/wayland-protocols/protocols/MEMBERS.md vendored Normal file
View file

@ -0,0 +1,13 @@
# wayland-protocols members
- EFL/Enlightenment: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
- GTK/Mutter: Jonas Ådahl <jadahl@gmail.com>,
Carlos Garnacho <carlosg@gnome.org>
- KWin: Eike Hein <hein@kde.org>,
David Edmundson <david@davidedmundson.co.uk>
- Mir: Christopher James Halse Rogers <raof@ubuntu.com>,
Alan Griffiths <alan.griffiths@canonical.com>
- Qt: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
- Weston: Pekka Paalanen <pekka.paalanen@collabora.com>,
Daniel Stone <daniel@fooishbar.org>
- wlroots/Sway: Drew DeVault <sir@cmpwn.com>, Simon Ser <contact@emersion.fr>

72
third-party/vendor/wayland-protocols/protocols/Makefile.am vendored Normal file
View file

@ -0,0 +1,72 @@
ACLOCAL_AMFLAGS = -I m4
unstable_protocols = \
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml \
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml \
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml \
unstable/text-input/text-input-unstable-v1.xml \
unstable/text-input/text-input-unstable-v3.xml \
unstable/input-method/input-method-unstable-v1.xml \
unstable/xdg-shell/xdg-shell-unstable-v5.xml \
unstable/xdg-shell/xdg-shell-unstable-v6.xml \
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v2.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml \
unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml \
unstable/input-timestamps/input-timestamps-unstable-v1.xml \
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \
unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
unstable/primary-selection/primary-selection-unstable-v1.xml \
$(NULL)
stable_protocols = \
stable/presentation-time/presentation-time.xml \
stable/viewporter/viewporter.xml \
stable/xdg-shell/xdg-shell.xml \
$(NULL)
staging_protocols = \
staging/xdg-activation/xdg-activation-v1.xml \
$(NULL)
misc_documentation = \
staging/xdg-activation/x11-interoperation.rst \
$(NULL)
nobase_dist_pkgdata_DATA = \
$(unstable_protocols) \
$(stable_protocols) \
$(staging_protocols) \
$(NULL)
dist_noinst_DATA = \
$(sort $(foreach p,$(unstable_protocols),$(dir $p)README)) \
$(sort $(foreach p,$(stable_protocols),$(dir $p)README)) \
$(sort $(foreach p,$(staging_protocols),$(dir $p)README)) \
$(misc_documentation) \
README.md \
GOVERNANCE.md \
MEMBERS.md \
meson.build \
meson_options.txt \
tests/meson.build \
tests/build-cxx.cc.in \
tests/build-pedantic.c.in \
tests/replace.py \
tests/scan.sh \
$(NULL)
noarch_pkgconfig_DATA = wayland-protocols.pc
dist_check_SCRIPTS = tests/scan.sh
TESTS = $(unstable_protocols) $(stable_protocols) $(staging_protocols)
TEST_EXTENSIONS = .xml
AM_TESTS_ENVIRONMENT = SCANNER='$(wayland_scanner)'; export SCANNER;
XML_LOG_COMPILER = $(srcdir)/tests/scan.sh

233
third-party/vendor/wayland-protocols/protocols/README.md vendored Normal file
View file

@ -0,0 +1,233 @@
# Wayland protocols
wayland-protocols contains Wayland protocols that add functionality not
available in the Wayland core protocol. Such protocols either add
completely new functionality, or extend the functionality of some other
protocol either in Wayland core, or some other protocol in
wayland-protocols.
A protocol in wayland-protocols consists of a directory containing a set
of XML files containing the protocol specification, and a README file
containing detailed state and a list of maintainers.
## Protocol phases
Protocols in general has three phases: the development phase, the testing
phase, and the stable phase.
In the development phase, a protocol is not officially part of
wayland-protocols, but is actively being developed, for example by
iterating over it in a
[merge
request](https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests),
or planning it in an
[issue](https://gitlab.freedesktop.org/wayland/wayland-protocols/issues).
During this phase, patches for clients and compositors are written as a test
vehicle. Such patches must not be merged in clients and compositors, because
the protocol can still change.
When a protocol has reached a stage where it is ready for wider adoption,
and after the [GOVERNANCE section
2.3](GOVERNANCE.md#2.3-introducing-new-protocols) requirements have been
met, it enters the "testing" phase. At this point, the protocol is added
to `staging/` directory of wayland-protocols and made part of a release.
What this means is that implementation is encouraged in clients and
compositors where the functionality it specifies is wanted.
Extensions in staging cannot have backward incompatible changes, in that
sense they are equal to stable extensions. However, they may be completely
replaced with a new major version, or a different protocol extension all
together, if design flaws are found in the testing phase.
After a staging protocol has been sufficiently tested in the wild and
proven adequate, its maintainers and the community at large may declare it
"stable", meaning it is unexpected to become superseded by a new major
version.
## Deprecation
A protocol may be deprecated, if it has been replaced by some other
protocol, or declared undesirable for some other reason. No more changes
will be made to a deprecated protocol.
## Legacy protocol phases
An "unstable" protocol refers to a protocol categorization policy
previously used by wayland-protocols, where protocols initially
placed in the `unstable/` directory had certain naming conventions were
applied, requiring a backward incompatible change to be declared "stable".
During this phase, protocol extension interface names were in addition to
the major version postfix also prefixed with `z` to distinguish from
stable protocols.
## Protocol directory tree structure
Depending on which stage a protocol is in, the protocol is placed within
the toplevel directory containing the protocols with the same stage.
Stable protocols are placed in the `stable/` directory, staging protocols
are placed in the `staging/` directory, and deprecated protocols are
placed in the `deprecated/` directory.
Unstable protocols (see [Legacy protocol phases](#legacy-protocol-phases))
can be found in the `unstable/` directory, but new ones should never be
placed here.
## Protocol development procedure
To propose a new protocol, create a GitLab merge request adding the
relevant files and Makefile.am entry to the repository with the
explanation and motivation in the commit message. Protocols are
organized in namespaces describing their scope ("wp", "xdg" and "ext").
There are different requirements for each namespace, see [GOVERNANCE
section 2](GOVERNANCE.md#2-protocols) for more information.
If the new protocol is just an idea, open an issue on the GitLab issue
tracker. If the protocol isn't ready for complete review yet and is an
RFC, create a merge request and add the "WIP:" prefix in the title.
To propose changes to existing protocols, create a GitLab merge request.
## Interface naming convention
All protocols should avoid using generic namespaces or no namespaces in
the protocol interface names in order to minimize risk that the generated
C API collides with other C API. Interface names that may collide with
interface names from other protocols should also be avoided.
For generic protocols not limited to certain configurations (such as
specific desktop environment or operating system) the `wp_` prefix
should be used on all interfaces in the protocol.
For protocols allowing clients to configure how their windows are
managed, the `xdg_` prefix should be used.
For operating system specific protocols, the interfaces should be
prefixed with both `wp_` and the operating system, for example
`wp_linux_`, or `wp_freebsd_`, etc.
For more information about namespaces, see [GOVERNANCE section 2.1
](GOVERNANCE.md#21-protocol-namespaces).
Each new protocol XML file must include a major version postfix, starting
with `-v1`. The purpose of this postfix is to make it possible to
distinguish between backward incompatible major versions of the same
protocol.
The interfaces in the protocol XML file should as well have the same
major version postfix in their names.
For example, the protocol `foo-bar` may have a XML file
`foo-bar/foo-bar-v1.xml`, consisting of the interface `wp_foo_bar_v1`,
corresponding to the major version 1, as well as the newer version
`foo-bar/foo-bar-v2.xml` consisting of the interface `wp_foo_bar_v2`,
corresponding to the major version 2.
## Include a disclaimer
Include the following disclaimer:
```
Warning! The protocol described in this file is currently in the testing
phase. Backward compatible changes may be added together with the
corresponding interface version bump. Backward incompatible changes can
only be done by creating a new major version of the extension.
```
## Backward compatible protocol changes
A protocol may receive backward compatible additions and changes. This
is to be done in the general Wayland way, using `version` and `since` XML
element attributes.
## Backward incompatible protocol changes
While not preferred, a protocol may at any stage, especially during the
testing phase, when it is located in the `staging/` directory, see
backward incompatible changes.
Assuming a backward incompatible change is needed, the procedure for how to
do so is the following:
- Make a copy of the XML file with the major version increased by 1.
- Increase the major version number in the protocol XML by 1.
- Increase the major version number in all of the interfaces in the
XML by 1.
- Reset the interface version number (interface version attribute) of all
the interfaces to 1.
- Remove all of the `since` attributes.
## Declaring a protocol stable
Once it has been concluded that a protocol been proven adequate in
production, and that it is deemed unlikely to receive any backward
incompatible changes, it may be declared stable.
The procedure of doing this is the following:
- Create a new directory in the `stable/` toplevel directory with the
same name as the protocol directory in the `staging/` directory.
- Copy the final version of the XML that is the version that was
decided to be declared stable into the new directory. The target name
should be the same name as the protocol directory but with the `.xml`
suffix.
- Remove the disclaimer about the protocol being in the testing phase.
- Update the `README` file in the staging directory and create a new
`README` file in the new directory.
- Replace the disclaimer in the protocol files left in the staging/
directory with the following:
```
Disclaimer: This protocol extension has been marked stable. This copy is
no longer used and only retained for backwards compatibility. The
canonical version can be found in the stable/ directory.
```
Note that the major version of the stable protocol extension, as well as
all the interface versions and names, must remain unchanged.
There are other requirements for declaring a protocol stable, see
[GOVERNANCE section 2.3](GOVERNANCE.md#23-introducing-new-protocols).
## Releases
Each release of wayland-protocols finalizes the version of the protocols
to their state they had at that time.
## Gitlab conventions
### Triaging merge requests
New merge requests should be triaged. Doing so requires the one doing the
triage to add a set of initial labels:
~"New Protocol" - For a new protocol being added. If it's an amendment to
an existing protocol, apply the label of the corresponding protocol
instead. If none exist, create it.
~"Needs acks" - If the protocol needs one or more acknowledgements.
~"Needs implementations" - If there are not enough implementations of the
protocol.
~"Needs review" - If the protocol is in need of review.
~"In 30 day discussion period" - If the protocol needs a 30 day discussion
period.
For the meaning and requirement of acknowledgments and available
implementations, see the GOVERNANCE.md document.
### Managing merge requests
When merge requests get their needed feedback and items, remove the
corresponding label that marks it as needing something. For example, if a
merge request receives all the required acknowledgments, remove the ~"Needs
acks" label, or if 30 days passed since opening, remove any ~"In 30 days
discussion period" label.
### Nacking a merge request
If the inclusion of a merge request is denied due to one or more Nacks, add
the ~Nacked label.

9
third-party/vendor/wayland-protocols/protocols/autogen.sh vendored Executable file
View file

@ -0,0 +1,9 @@
#!/bin/sh
test -n "$srcdir" || srcdir=`dirname "$0"`
test -n "$srcdir" || srcdir=.
(
cd "$srcdir" &&
autoreconf --force -v --install
) || exit
test -n "$NOCONFIGURE" || "$srcdir/configure" "$@"

45
third-party/vendor/wayland-protocols/protocols/configure.ac vendored Normal file
View file

@ -0,0 +1,45 @@
AC_PREREQ([2.64])
m4_define([wayland_protocols_major_version], [1])
m4_define([wayland_protocols_minor_version], [21])
m4_define([wayland_protocols_version],
[wayland_protocols_major_version.wayland_protocols_minor_version])
AC_INIT([wayland-protocols],
[wayland_protocols_version],
[https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=wayland&version=unspecified],
[wayland-protocols],
[http://wayland.freedesktop.org/])
AC_CONFIG_MACRO_DIR([m4])
AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
AC_ARG_VAR([wayland_scanner], [The wayland-scanner executable])
AC_PATH_PROG([wayland_scanner], [wayland-scanner])
if test x$wayland_scanner = x; then
if test "x$cross_compiling" != "xyes"; then
PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
else
AC_MSG_WARN([You are cross compiling without wayland-scanner in your path. make check will fail.])
fi
fi
AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz tar-ustar])
AM_SILENT_RULES([yes])
PKG_NOARCH_INSTALLDIR
AC_CONFIG_FILES([
Makefile
wayland-protocols.pc
wayland-protocols-uninstalled.pc
])
AC_OUTPUT
AC_MSG_RESULT([
Version ${WAYLAND_PROTOCOLS_VERSION}
Prefix ${prefix}
])

12
third-party/vendor/wayland-protocols/protocols/m4/compat.m4 vendored Normal file
View file

@ -0,0 +1,12 @@
dnl noarch_pkgconfigdir only available in pkg-config 0.27 and newer
dnl http://lists.freedesktop.org/archives/pkg-config/2012-July/000875.html
dnl Ubuntu 14.04 provides only pkg-config 0.26 so lacks this function.
dnl
dnl The Wayland project maintains automated builds for Ubuntu 14.04 in
dnl a Launchpad PPA. 14.04 is a Long Term Support distro release, which
dnl will reach EOL April 2019, however the Wayland PPA may stop targeting
dnl it some time after the next LTS release (April 2016).
m4_ifndef([PKG_NOARCH_INSTALLDIR], [AC_DEFUN([PKG_NOARCH_INSTALLDIR], [
noarch_pkgconfigdir='${datadir}'/pkgconfig
AC_SUBST([noarch_pkgconfigdir])
])])

111
third-party/vendor/wayland-protocols/protocols/meson.build vendored Normal file
View file

@ -0,0 +1,111 @@
project('wayland-protocols',
version: '1.21',
meson_version: '>= 0.53.0',
license: 'MIT/Expat',
)
wayland_protocols_version = meson.project_version()
fs = import('fs')
dep_scanner = dependency('wayland-scanner', native: true)
stable_protocols = [
'presentation-time',
'viewporter',
'xdg-shell',
]
unstable_protocols = {
'fullscreen-shell': ['v1'],
'idle-inhibit': ['v1'],
'input-method': ['v1'],
'input-timestamps': ['v1'],
'keyboard-shortcuts-inhibit': ['v1'],
'linux-dmabuf': ['v1'],
'linux-explicit-synchronization': ['v1'],
'pointer-constraints': ['v1'],
'pointer-gestures': ['v1'],
'primary-selection': ['v1'],
'relative-pointer': ['v1'],
'tablet': ['v1', 'v2'],
'text-input': ['v1', 'v3'],
'xdg-decoration': ['v1'],
'xdg-foreign': ['v1', 'v2'],
'xdg-output': ['v1'],
'xdg-shell': ['v5', 'v6'],
'xwayland-keyboard-grab': ['v1'],
}
staging_protocols = {
'xdg-activation': ['v1'],
}
protocol_files = []
foreach name : stable_protocols
protocol_files += ['stable/@0@/@0@.xml'.format(name)]
endforeach
foreach name : staging_protocols.keys()
foreach version : staging_protocols.get(name)
protocol_files += [
'staging/@0@/@0@-@1@.xml'.format(name, version)
]
endforeach
endforeach
foreach name : unstable_protocols.keys()
foreach version : unstable_protocols.get(name)
protocol_files += [
'unstable/@0@/@0@-unstable-@1@.xml'.format(name, version)
]
endforeach
endforeach
# Check that each protocol has a README
foreach protocol_file : protocol_files
dir = fs.parent(protocol_file)
if not fs.is_file(dir + '/README')
error('Missing README in @0@'.format(protocol_file))
endif
endforeach
foreach protocol_file : protocol_files
protocol_install_dir = fs.parent(join_paths(
get_option('datadir'),
'wayland-protocols',
protocol_file,
))
install_data(
protocol_file,
install_dir: protocol_install_dir,
)
endforeach
wayland_protocols_srcdir = meson.current_source_dir()
pkgconfig_configuration = configuration_data()
pkgconfig_configuration.set('prefix', get_option('prefix'))
pkgconfig_configuration.set('datarootdir', '${prefix}/@0@'.format(get_option('datadir')))
pkgconfig_configuration.set('abs_top_srcdir', wayland_protocols_srcdir)
pkgconfig_configuration.set('PACKAGE', 'wayland-protocols')
pkgconfig_configuration.set('WAYLAND_PROTOCOLS_VERSION', wayland_protocols_version)
pkg_install_dir = join_paths(get_option('datadir'), 'pkgconfig')
configure_file(
input: 'wayland-protocols.pc.in',
output: 'wayland-protocols.pc',
configuration: pkgconfig_configuration,
install_dir: pkg_install_dir,
)
configure_file(
input: 'wayland-protocols-uninstalled.pc.in',
output: 'wayland-protocols-uninstalled.pc',
configuration: pkgconfig_configuration,
)
if get_option('tests')
subdir('tests')
endif

4
third-party/vendor/wayland-protocols/protocols/meson_options.txt vendored Normal file
View file

@ -0,0 +1,4 @@
option('tests',
type: 'boolean',
value: true,
description: 'Build the tests')

5
third-party/vendor/wayland-protocols/protocols/stable/presentation-time/README vendored Normal file
View file

@ -0,0 +1,5 @@
Presentation time protocol
Maintainers:
Pekka Paalanen <pekka.paalanen@collabora.co.uk>

266
third-party/vendor/wayland-protocols/protocols/stable/presentation-time/presentation-time.xml vendored Normal file
View file

@ -0,0 +1,266 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="presentation_time">
<!-- wrap:70 -->
<copyright>
Copyright © 2013-2014 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_presentation" version="1">
<description summary="timed presentation related wl_surface requests">
<!-- Introduction -->
The main feature of this interface is accurate presentation
timing feedback to ensure smooth video playback while maintaining
audio/video synchronization. Some features use the concept of a
presentation clock, which is defined in the
presentation.clock_id event.
A content update for a wl_surface is submitted by a
wl_surface.commit request. Request 'feedback' associates with
the wl_surface.commit and provides feedback on the content
update, particularly the final realized presentation time.
<!-- Completing presentation -->
When the final realized presentation time is available, e.g.
after a framebuffer flip completes, the requested
presentation_feedback.presented events are sent. The final
presentation time can differ from the compositor's predicted
display update time and the update's target time, especially
when the compositor misses its target vertical blanking period.
</description>
<enum name="error">
<description summary="fatal presentation errors">
These fatal protocol errors may be emitted in response to
illegal presentation requests.
</description>
<entry name="invalid_timestamp" value="0"
summary="invalid value in tv_nsec"/>
<entry name="invalid_flag" value="1"
summary="invalid flag"/>
</enum>
<request name="destroy" type="destructor">
<description summary="unbind from the presentation interface">
Informs the server that the client will no longer be using
this protocol object. Existing objects created by this object
are not affected.
</description>
</request>
<request name="feedback">
<description summary="request presentation feedback information">
Request presentation feedback for the current content submission
on the given surface. This creates a new presentation_feedback
object, which will deliver the feedback information once. If
multiple presentation_feedback objects are created for the same
submission, they will all deliver the same information.
For details on what information is returned, see the
presentation_feedback interface.
</description>
<arg name="surface" type="object" interface="wl_surface"
summary="target surface"/>
<arg name="callback" type="new_id" interface="wp_presentation_feedback"
summary="new feedback object"/>
</request>
<event name="clock_id">
<description summary="clock ID for timestamps">
This event tells the client in which clock domain the
compositor interprets the timestamps used by the presentation
extension. This clock is called the presentation clock.
The compositor sends this event when the client binds to the
presentation interface. The presentation clock does not change
during the lifetime of the client connection.
The clock identifier is platform dependent. On Linux/glibc,
the identifier value is one of the clockid_t values accepted
by clock_gettime(). clock_gettime() is defined by
POSIX.1-2001.
Timestamps in this clock domain are expressed as tv_sec_hi,
tv_sec_lo, tv_nsec triples, each component being an unsigned
32-bit value. Whole seconds are in tv_sec which is a 64-bit
value combined from tv_sec_hi and tv_sec_lo, and the
additional fractional part in tv_nsec as nanoseconds. Hence,
for valid timestamps tv_nsec must be in [0, 999999999].
Note that clock_id applies only to the presentation clock,
and implies nothing about e.g. the timestamps used in the
Wayland core protocol input events.
Compositors should prefer a clock which does not jump and is
not slewed e.g. by NTP. The absolute value of the clock is
irrelevant. Precision of one millisecond or better is
recommended. Clients must be able to query the current clock
value directly, not by asking the compositor.
</description>
<arg name="clk_id" type="uint" summary="platform clock identifier"/>
</event>
</interface>
<interface name="wp_presentation_feedback" version="1">
<description summary="presentation time feedback event">
A presentation_feedback object returns an indication that a
wl_surface content update has become visible to the user.
One object corresponds to one content update submission
(wl_surface.commit). There are two possible outcomes: the
content update is presented to the user, and a presentation
timestamp delivered; or, the user did not see the content
update because it was superseded or its surface destroyed,
and the content update is discarded.
Once a presentation_feedback object has delivered a 'presented'
or 'discarded' event it is automatically destroyed.
</description>
<event name="sync_output">
<description summary="presentation synchronized to this output">
As presentation can be synchronized to only one output at a
time, this event tells which output it was. This event is only
sent prior to the presented event.
As clients may bind to the same global wl_output multiple
times, this event is sent for each bound instance that matches
the synchronized output. If a client has not bound to the
right wl_output global at all, this event is not sent.
</description>
<arg name="output" type="object" interface="wl_output"
summary="presentation output"/>
</event>
<enum name="kind" bitfield="true">
<description summary="bitmask of flags in presented event">
These flags provide information about how the presentation of
the related content update was done. The intent is to help
clients assess the reliability of the feedback and the visual
quality with respect to possible tearing and timings. The
flags are:
VSYNC:
The presentation was synchronized to the "vertical retrace" by
the display hardware such that tearing does not happen.
Relying on user space scheduling is not acceptable for this
flag. If presentation is done by a copy to the active
frontbuffer, then it must guarantee that tearing cannot
happen.
HW_CLOCK:
The display hardware provided measurements that the hardware
driver converted into a presentation timestamp. Sampling a
clock in user space is not acceptable for this flag.
HW_COMPLETION:
The display hardware signalled that it started using the new
image content. The opposite of this is e.g. a timer being used
to guess when the display hardware has switched to the new
image content.
ZERO_COPY:
The presentation of this update was done zero-copy. This means
the buffer from the client was given to display hardware as
is, without copying it. Compositing with OpenGL counts as
copying, even if textured directly from the client buffer.
Possible zero-copy cases include direct scanout of a
fullscreen surface and a surface on a hardware overlay.
</description>
<entry name="vsync" value="0x1" summary="presentation was vsync'd"/>
<entry name="hw_clock" value="0x2"
summary="hardware provided the presentation timestamp"/>
<entry name="hw_completion" value="0x4"
summary="hardware signalled the start of the presentation"/>
<entry name="zero_copy" value="0x8"
summary="presentation was done zero-copy"/>
</enum>
<event name="presented">
<description summary="the content update was displayed">
The associated content update was displayed to the user at the
indicated time (tv_sec_hi/lo, tv_nsec). For the interpretation of
the timestamp, see presentation.clock_id event.
The timestamp corresponds to the time when the content update
turned into light the first time on the surface's main output.
Compositors may approximate this from the framebuffer flip
completion events from the system, and the latency of the
physical display path if known.
This event is preceded by all related sync_output events
telling which output's refresh cycle the feedback corresponds
to, i.e. the main output for the surface. Compositors are
recommended to choose the output containing the largest part
of the wl_surface, or keeping the output they previously
chose. Having a stable presentation output association helps
clients predict future output refreshes (vblank).
The 'refresh' argument gives the compositor's prediction of how
many nanoseconds after tv_sec, tv_nsec the very next output
refresh may occur. This is to further aid clients in
predicting future refreshes, i.e., estimating the timestamps
targeting the next few vblanks. If such prediction cannot
usefully be done, the argument is zero.
If the output does not have a constant refresh rate, explicit
video mode switches excluded, then the refresh argument must
be zero.
The 64-bit value combined from seq_hi and seq_lo is the value
of the output's vertical retrace counter when the content
update was first scanned out to the display. This value must
be compatible with the definition of MSC in
GLX_OML_sync_control specification. Note, that if the display
path has a non-zero latency, the time instant specified by
this counter may differ from the timestamp's.
If the output does not have a concept of vertical retrace or a
refresh cycle, or the output device is self-refreshing without
a way to query the refresh count, then the arguments seq_hi
and seq_lo must be zero.
</description>
<arg name="tv_sec_hi" type="uint"
summary="high 32 bits of the seconds part of the presentation timestamp"/>
<arg name="tv_sec_lo" type="uint"
summary="low 32 bits of the seconds part of the presentation timestamp"/>
<arg name="tv_nsec" type="uint"
summary="nanoseconds part of the presentation timestamp"/>
<arg name="refresh" type="uint" summary="nanoseconds till next refresh"/>
<arg name="seq_hi" type="uint"
summary="high 32 bits of refresh counter"/>
<arg name="seq_lo" type="uint"
summary="low 32 bits of refresh counter"/>
<arg name="flags" type="uint" enum="kind" summary="combination of 'kind' values"/>
</event>
<event name="discarded">
<description summary="the content update was not displayed">
The content update was never displayed to the user.
</description>
</event>
</interface>
</protocol>

7
third-party/vendor/wayland-protocols/protocols/stable/viewporter/README vendored Normal file
View file

@ -0,0 +1,7 @@
Viewporter: cropping and scaling extension for surface contents
Previously known as wl_scaler.
Maintainers:
Pekka Paalanen <pekka.paalanen@collabora.co.uk>

186
third-party/vendor/wayland-protocols/protocols/stable/viewporter/viewporter.xml vendored Normal file
View file

@ -0,0 +1,186 @@
<?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.
The x, y arguments of wl_surface.attach are applied as normal to
the surface. They indicate how many pixels to remove from the
surface size from the left and the top. In other words, they are
still in the surface-local coordinate system, just like dst_width
and dst_height are.
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>

5
third-party/vendor/wayland-protocols/protocols/stable/xdg-shell/README vendored Normal file
View file

@ -0,0 +1,5 @@
xdg shell protocol
Maintainers:
Jonas Ådahl <jadahl@gmail.com>
Mike Blumenkrantz <michael.blumenkrantz@gmail.com>

1249
third-party/vendor/wayland-protocols/protocols/stable/xdg-shell/xdg-shell.xml vendored Normal file
View file

File diff suppressed because it is too large Load diff

4
third-party/vendor/wayland-protocols/protocols/staging/xdg-activation/README vendored Normal file
View file

@ -0,0 +1,4 @@
XDG Activation protocol
Maintainers:
Aleix Pol Gonzalez <aleixpol@kde.org>

64
third-party/vendor/wayland-protocols/protocols/staging/xdg-activation/x11-interoperation.rst vendored Normal file
View file

@ -0,0 +1,64 @@
Interoperation with X11
=======================
*This document is non-normative.*
The former X11 startup-notification standard
(https://cgit.freedesktop.org/startup-notification/tree/doc/startup-notification.txt)
defines the use of the DESKTOP_STARTUP_ID environment variable to propagate
startup sequences ("activation tokens" in this protocol) between launcher and
launchee.
These startup sequence IDs are defined as a globally unique string with a
`[unique]_TIME[timestamp]` format, where the ID as a whole is used for startup
notification and the timestamp is used for focus requests and focus stealing
prevention.
In order to observe mixed usage scenarios where Wayland and X11 clients might
be launching each other, it is possible for a compositor to manage a shared
pool of activation tokens.
Scenario 1. Wayland client spawns X11 client
--------------------------------------------
1. Wayland client requests token.
2. Wayland client spawns X11 client, sets `$DESKTOP_STARTUP_ID` in its
environment with the token string.
3. X11 client starts.
4. X11 client sends startup-notification `remove` message with the activation
`$DESKTOP_STARTUP_ID` content.
5. Compositor receives startup notification message, matches ID with
the common pool.
6. The startup feedback is finished.
7. X11 client requests focus.
8. Compositor applies internal policies to allow/deny focus switch.
Scenario 2. X11 client spawns Wayland client
--------------------------------------------
1. X11 client builds a "globally unique" ID
2. X11 client sends startup-notification `new` message with the ID.
3. Compositor receives startup notification message, adds the ID to
the common pool.
4. X11 client spawns Wayland client, sets `$DESKTOP_STARTUP_ID` in its
environment.
5. Wayland client starts.
6. Wayland client sets the activation token, as received from
`$DESKTOP_STARTUP_ID`.
7. Compositor receives the request, matches ID with the common pool
8. The startup feedback is finished.
9. Wayland client requests surface activation.
10. Compositor applies internal policies to allow/deny focus switch.
Caveats
-------
- For legacy reasons, the usage of `$DESKTOP_STARTUP_ID` (even if as a
fallback) should be observed in compositors and clients that are
concerned with X11 interoperation.
- Depending on the X11 startup-notification implementation in use by the
compositor, the usage of the `_TIME[timestamp]` suffix may be mandatory
for its correct behavior in the first scenario, the startup-notification
reference library is one such implementation. Compositors may work
this around by adding a matching suffix to the generated activation tokens.

186
third-party/vendor/wayland-protocols/protocols/staging/xdg-activation/xdg-activation-v1.xml vendored Normal file
View file

@ -0,0 +1,186 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="xdg_activation_v1">
<copyright>
Copyright © 2020 Aleix Pol Gonzalez &lt;aleixpol@kde.org&gt;
Copyright © 2020 Carlos Garnacho &lt;carlosg@gnome.org&gt;
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 requesting activation of surfaces">
The way for a client to pass focus to another toplevel is as follows.
The client that intends to activate another toplevel uses the
xdg_activation_v1.get_activation_token request to get an activation token.
This token is then passed to the client to be activated through a separate
band of communication. The client to be activated will then pass the token
it received to the xdg_activation_v1.activate request. The compositor can
then use this token to decide how to react to the activation request.
The token the activating client gets may be ineffective either already at
the time it receives it, for example if it was not focused, for focus
stealing prevention. The activating client will have no way to discover
the validity of the token, and may still forward it to the to be activated
client.
The created activation token may optionally get information attached to it
that can be used by the compositor to identify the application that we
intend to activate. This can for example be used to display a visual hint
about what application is being started.
Warning! The protocol described in this file is currently in the testing
phase. Backward compatible changes may be added together with the
corresponding interface version bump. Backward incompatible changes can
only be done by creating a new major version of the extension.
</description>
<interface name="xdg_activation_v1" version="1">
<description summary="interface for activating surfaces">
A global interface used for informing the compositor about applications
being activated or started, or for applications to request to be
activated.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_activation object">
Notify the compositor that the xdg_activation object will no longer be
used.
The child objects created via this interface are unaffected and should
be destroyed separately.
</description>
</request>
<request name="get_activation_token">
<description summary="requests a token">
Creates an xdg_activation_token_v1 object that will provide
the initiating client with a unique token for this activation. This
token should be offered to the clients to be activated.
</description>
<arg name="id" type="new_id" interface="xdg_activation_token_v1"/>
</request>
<request name="activate">
<description summary="notify new interaction being available">
Requests surface activation. It's up to the compositor to display
this information as desired, for example by placing the surface above
the rest.
The compositor may know who requested this by checking the activation
token and might decide not to follow through with the activation if it's
considered unwanted.
Compositors can ignore unknown presentation tokens when an invalid
token is passed.
</description>
<arg name="token" type="string" summary="the activation token of the initiating client"/>
<arg name="surface" type="object" interface="wl_surface"
summary="the wl_surface to activate"/>
</request>
</interface>
<interface name="xdg_activation_token_v1" version="1">
<description summary="an exported activation handle">
An object for setting up a token and receiving a token handle that can
be passed as an activation token to another client.
The object is created using the xdg_activation_v1.get_activation_token
request. This object should then be populated with the app_id, surface
and serial information and committed. The compositor shall then issue a
done event with the token. In case the request's parameters are invalid,
the compositor will provide an invalid token.
</description>
<enum name="error">
<entry name="already_used" value="0"
summary="The token has already been used previously"/>
</enum>
<request name="set_serial">
<description summary="specifies the seat and serial of the activating event">
Provides information about the seat and serial event that requested the
token.
Must be sent before commit. This information is optional.
</description>
<arg name="serial" type="uint"
summary="the serial of the event that triggered the activation"/>
<arg name="seat" type="object" interface="wl_seat"
summary="the wl_seat of the event"/>
</request>
<request name="set_app_id">
<description summary="specifies the application being activated">
The requesting client can specify an app_id to associate the token
being created with it.
Must be sent before commit. This information is optional.
</description>
<arg name="app_id" type="string"
summary="the application id of the client being activated."/>
</request>
<request name="set_surface">
<description summary="specifies the application being activated">
The requesting client can specify a surface to associate the token
being created with it.
Must be triggered before commit. This information is optional.
</description>
<arg name="surface" type="object" interface="wl_surface"
summary="the requesting surface"/>
</request>
<request name="commit">
<description summary="issues the token request">
Requests an activation token based on the different parameters that
have been offered through set_serial, set_surface and set_app_id.
</description>
</request>
<event name="done">
<description summary="the exported activation token">
The 'done' event contains the unique token of this activation request
and notifies that the provider is done.
Applications will typically receive the token through the
XDG_ACTIVATION_TOKEN environment variable as set by its launcher, and
should unset the environment variable right after this request, in
order to avoid propagating it to child processes.
Applications implementing the D-Bus interface org.freedesktop.Application
should get their token under XDG_ACTIVATION_TOKEN on their platform_data.
Presentation tokens may be transferred across clients through means not
described in this protocol.
</description>
<arg name="token" type="string" summary="the exported activation token"/>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_activation_token_v1 object">
Notify the compositor that the xdg_activation_token_v1 object will no
longer be used.
</description>
</request>
</interface>
</protocol>

12
third-party/vendor/wayland-protocols/protocols/tests/build-cxx.cc.in vendored Normal file
View file

@ -0,0 +1,12 @@
#include "@PROTOCOL_CLIENT_INCLUDE_FILE@"
#include "@PROTOCOL_SERVER_INCLUDE_FILE@"
/* This is a build-test only */
using namespace std;
int
main(int argc, char **argv)
{
return 0;
}

10
third-party/vendor/wayland-protocols/protocols/tests/build-pedantic.c.in vendored Normal file
View file

@ -0,0 +1,10 @@
#include "@PROTOCOL_CLIENT_INCLUDE_FILE@"
#include "@PROTOCOL_SERVER_INCLUDE_FILE@"
/* This is a build-test only */
int
main(int argc, char **argv)
{
return 0;
}

141
third-party/vendor/wayland-protocols/protocols/tests/meson.build vendored Normal file
View file

@ -0,0 +1,141 @@
prog_scan_sh = find_program('scan.sh')
prog_scanner = find_program(dep_scanner.get_pkgconfig_variable('wayland_scanner'))
libwayland = [
dependency('wayland-client'),
dependency('wayland-server'),
]
# Check that each protocol passes through the scanner
foreach protocol_file : protocol_files
protocol_path = join_paths(wayland_protocols_srcdir, protocol_file)
test_name = 'scan-@0@'.format(protocol_file.underscorify())
test(test_name, prog_scan_sh,
args: protocol_path,
env: [
'SCANNER=@0@'.format(prog_scanner.path()),
]
)
endforeach
# Check buildability
add_languages('c', 'cpp')
replace = find_program('replace.py')
foreach protocol_file : protocol_files
xml_file = fs.name(protocol_file)
xml_components = xml_file.split('.')
protocol_base_file_name = xml_components[0]
protocol_path = files(join_paths(wayland_protocols_srcdir, protocol_file))
client_header_path = '@0@-client.h'.format(protocol_base_file_name)
server_header_path = '@0@-server.h'.format(protocol_base_file_name)
code_path = '@0@-code.c'.format(protocol_base_file_name)
client_header = custom_target(
client_header_path,
output: client_header_path,
input: protocol_path,
command: [
prog_scanner,
'--strict',
'client-header',
'@INPUT@',
'@OUTPUT@',
],
install: false,
)
server_header = custom_target(
server_header_path,
output: server_header_path,
input: protocol_path,
command: [
prog_scanner,
'--strict',
'server-header',
'@INPUT@',
'@OUTPUT@',
],
install: false,
)
code = custom_target(
code_path,
output: code_path,
input: protocol_path,
command: [
prog_scanner,
'--strict',
'private-code',
'@INPUT@',
'@OUTPUT@',
],
install: false,
)
replace_command = [
replace,
'@INPUT@',
'@OUTPUT@',
'PROTOCOL_CLIENT_INCLUDE_FILE',
client_header.full_path(),
'PROTOCOL_SERVER_INCLUDE_FILE',
server_header.full_path(),
]
# Check that header can be included by a pedantic C99 compiler
test_name = 'test-build-pedantic-@0@'.format(protocol_file.underscorify())
test_name_source = '@0@.c'.format(test_name)
test_source = custom_target(
test_name_source,
input: 'build-pedantic.c.in',
output: test_name_source,
command: replace_command,
)
pedantic_test_executable = executable(
test_name,
[
test_source,
client_header,
server_header,
code
],
link_args: [
'-Wl,--unresolved-symbols=ignore-all',
],
dependencies: libwayland,
c_args: [
'-std=c99',
'-pedantic',
'-Wall',
'-Werror' ],
install: false,
)
test(test_name, pedantic_test_executable)
# Check that the header
if not protocol_file.contains('xdg-foreign-unstable-v1')
test_name = 'test-build-cxx-@0@'.format(protocol_file.underscorify())
test_name_source = '@0@.cc'.format(test_name)
test_source = custom_target(
test_name_source,
input: 'build-cxx.cc.in',
output: test_name_source,
command: replace_command,
)
cxx_test_executable = executable(
test_name,
[
test_source,
client_header,
server_header,
],
link_args: [ '-Wl,--unresolved-symbols=ignore-all' ],
cpp_args: [
'-Wall',
'-Werror',
],
install: false,
)
test(test_name, cxx_test_executable)
endif
endforeach

23
third-party/vendor/wayland-protocols/protocols/tests/replace.py vendored Executable file
View file

@ -0,0 +1,23 @@
#!/usr/bin/python3
import sys
execpath, inpath, outpath, *dict_list = sys.argv
dictonary = {}
while dict_list:
key, value, *rest = dict_list
dictonary[key] = value
dict_list = rest
infile = open(inpath, 'r')
outfile = open(outpath, 'w')
buf = infile.read()
infile.close()
for key, value in dictonary.items():
buf = buf.replace('@{}@'.format(key), value)
outfile.write(buf)
outfile.close()

11
third-party/vendor/wayland-protocols/protocols/tests/scan.sh vendored Executable file
View file

@ -0,0 +1,11 @@
#!/bin/sh -e
if [ "x$SCANNER" = "x" ] ; then
echo "No scanner present, test skipped." 1>&2
exit 77
fi
$SCANNER client-header --strict $1 /dev/null
$SCANNER server-header --strict $1 /dev/null
$SCANNER private-code --strict $1 /dev/null
$SCANNER public-code --strict $1 /dev/null

4
third-party/vendor/wayland-protocols/protocols/unstable/fullscreen-shell/README vendored Normal file
View file

@ -0,0 +1,4 @@
Fullscreen shell protocol
Maintainers:
Jason Ekstrand <jason@jlekstrand.net>

254
third-party/vendor/wayland-protocols/protocols/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,254 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="fullscreen_shell_unstable_v1">
<copyright>
Copyright © 2016 Yong Bakos
Copyright © 2015 Jason Ekstrand
Copyright © 2015 Jonas Ådahl
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_fullscreen_shell_v1" version="1">
<description summary="displays a single surface per output">
Displays a single surface per output.
This interface provides a mechanism for a single client to display
simple full-screen surfaces. While there technically may be multiple
clients bound to this interface, only one of those clients should be
shown at a time.
To present a surface, the client uses either the present_surface or
present_surface_for_mode requests. Presenting a surface takes effect
on the next wl_surface.commit. See the individual requests for
details about scaling and mode switches.
The client can have at most one surface per output at any time.
Requesting a surface to be presented on an output that already has a
surface replaces the previously presented surface. Presenting a null
surface removes its content and effectively disables the output.
Exactly what happens when an output is "disabled" is
compositor-specific. The same surface may be presented on multiple
outputs simultaneously.
Once a surface is presented on an output, it stays on that output
until either the client removes it or the compositor destroys the
output. This way, the client can update the output's contents by
simply attaching a new buffer.
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="release" type="destructor">
<description summary="release the wl_fullscreen_shell interface">
Release the binding from the wl_fullscreen_shell interface.
This destroys the server-side object and frees this binding. If
the client binds to wl_fullscreen_shell multiple times, it may wish
to free some of those bindings.
</description>
</request>
<enum name="capability">
<description summary="capabilities advertised by the compositor">
Various capabilities that can be advertised by the compositor. They
are advertised one-at-a-time when the wl_fullscreen_shell interface is
bound. See the wl_fullscreen_shell.capability event for more details.
ARBITRARY_MODES:
This is a hint to the client that indicates that the compositor is
capable of setting practically any mode on its outputs. If this
capability is provided, wl_fullscreen_shell.present_surface_for_mode
will almost never fail and clients should feel free to set whatever
mode they like. If the compositor does not advertise this, it may
still support some modes that are not advertised through wl_global.mode
but it is less likely.
CURSOR_PLANE:
This is a hint to the client that indicates that the compositor can
handle a cursor surface from the client without actually compositing.
This may be because of a hardware cursor plane or some other mechanism.
If the compositor does not advertise this capability then setting
wl_pointer.cursor may degrade performance or be ignored entirely. If
CURSOR_PLANE is not advertised, it is recommended that the client draw
its own cursor and set wl_pointer.cursor(NULL).
</description>
<entry name="arbitrary_modes" value="1" summary="compositor is capable of almost any output mode"/>
<entry name="cursor_plane" value="2" summary="compositor has a separate cursor plane"/>
</enum>
<event name="capability">
<description summary="advertises a capability of the compositor">
Advertises a single capability of the compositor.
When the wl_fullscreen_shell interface is bound, this event is emitted
once for each capability advertised. Valid capabilities are given by
the wl_fullscreen_shell.capability enum. If clients want to take
advantage of any of these capabilities, they should use a
wl_display.sync request immediately after binding to ensure that they
receive all the capability events.
</description>
<arg name="capability" type="uint" enum="capability" />
</event>
<enum name="present_method">
<description summary="different method to set the surface fullscreen">
Hints to indicate to the compositor how to deal with a conflict
between the dimensions of the surface and the dimensions of the
output. The compositor is free to ignore this parameter.
</description>
<entry name="default" value="0" summary="no preference, apply default policy"/>
<entry name="center" value="1" summary="center the surface on the output"/>
<entry name="zoom" value="2" summary="scale the surface, preserving aspect ratio, to the largest size that will fit on the output" />
<entry name="zoom_crop" value="3" summary="scale the surface, preserving aspect ratio, to fully fill the output cropping if needed" />
<entry name="stretch" value="4" summary="scale the surface to the size of the output ignoring aspect ratio" />
</enum>
<request name="present_surface">
<description summary="present surface for display">
Present a surface on the given output.
If the output is null, the compositor will present the surface on
whatever display (or displays) it thinks best. In particular, this
may replace any or all surfaces currently presented so it should
not be used in combination with placing surfaces on specific
outputs.
The method parameter is a hint to the compositor for how the surface
is to be presented. In particular, it tells the compositor how to
handle a size mismatch between the presented surface and the
output. The compositor is free to ignore this parameter.
The "zoom", "zoom_crop", and "stretch" methods imply a scaling
operation on the surface. This will override any kind of output
scaling, so the buffer_scale property of the surface is effectively
ignored.
This request gives the surface the role of a fullscreen shell surface.
If the surface already has another role, it raises a role protocol
error.
</description>
<arg name="surface" type="object" interface="wl_surface" allow-null="true"/>
<arg name="method" type="uint" enum="present_method" />
<arg name="output" type="object" interface="wl_output" allow-null="true"/>
</request>
<request name="present_surface_for_mode">
<description summary="present surface for display at a particular mode">
Presents a surface on the given output for a particular mode.
If the current size of the output differs from that of the surface,
the compositor will attempt to change the size of the output to
match the surface. The result of the mode-switch operation will be
returned via the provided wl_fullscreen_shell_mode_feedback object.
If the current output mode matches the one requested or if the
compositor successfully switches the mode to match the surface,
then the mode_successful event will be sent and the output will
contain the contents of the given surface. If the compositor
cannot match the output size to the surface size, the mode_failed
will be sent and the output will contain the contents of the
previously presented surface (if any). If another surface is
presented on the given output before either of these has a chance
to happen, the present_cancelled event will be sent.
Due to race conditions and other issues unknown to the client, no
mode-switch operation is guaranteed to succeed. However, if the
mode is one advertised by wl_output.mode or if the compositor
advertises the ARBITRARY_MODES capability, then the client should
expect that the mode-switch operation will usually succeed.
If the size of the presented surface changes, the resulting output
is undefined. The compositor may attempt to change the output mode
to compensate. However, there is no guarantee that a suitable mode
will be found and the client has no way to be notified of success
or failure.
The framerate parameter specifies the desired framerate for the
output in mHz. The compositor is free to ignore this parameter. A
value of 0 indicates that the client has no preference.
If the value of wl_output.scale differs from wl_surface.buffer_scale,
then the compositor may choose a mode that matches either the buffer
size or the surface size. In either case, the surface will fill the
output.
This request gives the surface the role of a fullscreen shell surface.
If the surface already has another role, it raises a role protocol
error.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="output" type="object" interface="wl_output"/>
<arg name="framerate" type="int"/>
<arg name="feedback" type="new_id" interface="zwp_fullscreen_shell_mode_feedback_v1"/>
</request>
<enum name="error">
<description summary="wl_fullscreen_shell error values">
These errors can be emitted in response to wl_fullscreen_shell requests.
</description>
<entry name="invalid_method" value="0" summary="present_method is not known"/>
<entry name="role" value="1" summary="given wl_surface has another role"/>
</enum>
</interface>
<interface name="zwp_fullscreen_shell_mode_feedback_v1" version="1">
<event name="mode_successful">
<description summary="mode switch succeeded">
This event indicates that the attempted mode switch operation was
successful. A surface of the size requested in the mode switch
will fill the output without scaling.
Upon receiving this event, the client should destroy the
wl_fullscreen_shell_mode_feedback object.
</description>
</event>
<event name="mode_failed">
<description summary="mode switch failed">
This event indicates that the attempted mode switch operation
failed. This may be because the requested output mode is not
possible or it may mean that the compositor does not want to allow it.
Upon receiving this event, the client should destroy the
wl_fullscreen_shell_mode_feedback object.
</description>
</event>
<event name="present_cancelled">
<description summary="mode switch cancelled">
This event indicates that the attempted mode switch operation was
cancelled. Most likely this is because the client requested a
second mode switch before the first one completed.
Upon receiving this event, the client should destroy the
wl_fullscreen_shell_mode_feedback object.
</description>
</event>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/idle-inhibit/README vendored Normal file
View file

@ -0,0 +1,4 @@
Screensaver inhibition protocol
Maintainers:
Bryce Harrington <bryce@osg.samsung.com>

83
third-party/vendor/wayland-protocols/protocols/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml vendored Normal file
View file

@ -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>

4
third-party/vendor/wayland-protocols/protocols/unstable/input-method/README vendored Normal file
View file

@ -0,0 +1,4 @@
Input method protocol
Maintainers:
Jan Arne Petersen <janarne@gmail.com>

305
third-party/vendor/wayland-protocols/protocols/unstable/input-method/input-method-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,305 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="input_method_unstable_v1">
<copyright>
Copyright © 2012, 2013 Intel Corporation
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
</copyright>
<interface name="zwp_input_method_context_v1" version="1">
<description summary="input method context">
Corresponds to a text input on the input method side. An input method context
is created on text input activation on the input method side. It allows
receiving information about the text input from the application via events.
Input method contexts do not keep state after deactivation and should be
destroyed after deactivation is handled.
Text is generally UTF-8 encoded, indices and lengths are in bytes.
Serials are used to synchronize the state between the text input and
an input method. New serials are sent by the text input in the
commit_state request and are used by the input method to indicate
the known text input state in events like preedit_string, commit_string,
and keysym. The text input can then ignore events from the input method
which are based on an outdated state (for example after a reset).
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"/>
<request name="commit_string">
<description summary="commit string">
Send the commit string text for insertion to the application.
The text to commit could be either just a single character after a key
press or the result of some composing (pre-edit). It could be also an
empty text when some text should be removed (see
delete_surrounding_text) or when the input cursor should be moved (see
cursor_position).
Any previously set composing text will be removed.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="text" type="string"/>
</request>
<request name="preedit_string">
<description summary="pre-edit string">
Send the pre-edit string text to the application text input.
The commit text can be used to replace the pre-edit text on reset (for
example on unfocus).
Previously sent preedit_style and preedit_cursor requests are also
processed by the text_input.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="text" type="string"/>
<arg name="commit" type="string"/>
</request>
<request name="preedit_styling">
<description summary="pre-edit styling">
Set the styling information on composing text. The style is applied for
length in bytes from index relative to the beginning of
the composing text (as byte offset). Multiple styles can
be applied to a composing text.
This request should be sent before sending a preedit_string request.
</description>
<arg name="index" type="uint"/>
<arg name="length" type="uint"/>
<arg name="style" type="uint"/>
</request>
<request name="preedit_cursor">
<description summary="pre-edit cursor">
Set the cursor position inside the composing text (as byte offset)
relative to the start of the composing text.
When index is negative no cursor should be displayed.
This request should be sent before sending a preedit_string request.
</description>
<arg name="index" type="int"/>
</request>
<request name="delete_surrounding_text">
<description summary="delete text">
Remove the surrounding text.
This request will be handled on the text_input side directly following
a commit_string request.
</description>
<arg name="index" type="int"/>
<arg name="length" type="uint"/>
</request>
<request name="cursor_position">
<description summary="set cursor to a new position">
Set the cursor and anchor to a new position. Index is the new cursor
position in bytes (when >= 0 this is relative to the end of the inserted text,
otherwise it is relative to the beginning of the inserted text). Anchor is
the new anchor position in bytes (when >= 0 this is relative to the end of the
inserted text, otherwise it is relative to the beginning of the inserted
text). When there should be no selected text, anchor should be the same
as index.
This request will be handled on the text_input side directly following
a commit_string request.
</description>
<arg name="index" type="int"/>
<arg name="anchor" type="int"/>
</request>
<request name="modifiers_map">
<arg name="map" type="array"/>
</request>
<request name="keysym">
<description summary="keysym">
Notify when a key event was sent. Key events should not be used for
normal text input operations, which should be done with commit_string,
delete_surrounding_text, etc. The key event follows the wl_keyboard key
event convention. Sym is an XKB keysym, state is a wl_keyboard key_state.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="time" type="uint"/>
<arg name="sym" type="uint"/>
<arg name="state" type="uint"/>
<arg name="modifiers" type="uint"/>
</request>
<request name="grab_keyboard">
<description summary="grab hardware keyboard">
Allow an input method to receive hardware keyboard input and process
key events to generate text events (with pre-edit) over the wire. This
allows input methods which compose multiple key events for inputting
text like it is done for CJK languages.
</description>
<arg name="keyboard" type="new_id" interface="wl_keyboard"/>
</request>
<request name="key">
<description summary="forward key event">
Forward a wl_keyboard::key event to the client that was not processed
by the input method itself. Should be used when filtering key events
with grab_keyboard. The arguments should be the ones from the
wl_keyboard::key event.
For generating custom key events use the keysym request instead.
</description>
<arg name="serial" type="uint" summary="serial from wl_keyboard::key"/>
<arg name="time" type="uint" summary="time from wl_keyboard::key"/>
<arg name="key" type="uint" summary="key from wl_keyboard::key"/>
<arg name="state" type="uint" summary="state from wl_keyboard::key"/>
</request>
<request name="modifiers">
<description summary="forward modifiers event">
Forward a wl_keyboard::modifiers event to the client that was not
processed by the input method itself. Should be used when filtering
key events with grab_keyboard. The arguments should be the ones
from the wl_keyboard::modifiers event.
</description>
<arg name="serial" type="uint" summary="serial from wl_keyboard::modifiers"/>
<arg name="mods_depressed" type="uint" summary="mods_depressed from wl_keyboard::modifiers"/>
<arg name="mods_latched" type="uint" summary="mods_latched from wl_keyboard::modifiers"/>
<arg name="mods_locked" type="uint" summary="mods_locked from wl_keyboard::modifiers"/>
<arg name="group" type="uint" summary="group from wl_keyboard::modifiers"/>
</request>
<request name="language">
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="language" type="string"/>
</request>
<request name="text_direction">
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="direction" type="uint"/>
</request>
<event name="surrounding_text">
<description summary="surrounding text event">
The plain surrounding text around the input position. Cursor is the
position in bytes within the surrounding text relative to the beginning
of the text. Anchor is the position in bytes of the selection anchor
within the surrounding text relative to the beginning of the text. If
there is no selected text then anchor is the same as cursor.
</description>
<arg name="text" type="string"/>
<arg name="cursor" type="uint"/>
<arg name="anchor" type="uint"/>
</event>
<event name="reset">
</event>
<event name="content_type">
<arg name="hint" type="uint"/>
<arg name="purpose" type="uint"/>
</event>
<event name="invoke_action">
<arg name="button" type="uint"/>
<arg name="index" type="uint"/>
</event>
<event name="commit_state">
<arg name="serial" type="uint" summary="serial of text input state"/>
</event>
<event name="preferred_language">
<arg name="language" type="string"/>
</event>
</interface>
<interface name="zwp_input_method_v1" version="1">
<description summary="input method">
An input method object is responsible for composing text in response to
input from hardware or virtual keyboards. There is one input method
object per seat. On activate there is a new input method context object
created which allows the input method to communicate with the text input.
</description>
<event name="activate">
<description summary="activate event">
A text input was activated. Creates an input method context object
which allows communication with the text input.
</description>
<arg name="id" type="new_id" interface="zwp_input_method_context_v1"/>
</event>
<event name="deactivate">
<description summary="deactivate event">
The text input corresponding to the context argument was deactivated.
The input method context should be destroyed after deactivation is
handled.
</description>
<arg name="context" type="object" interface="zwp_input_method_context_v1"/>
</event>
</interface>
<interface name="zwp_input_panel_v1" version="1">
<description summary="interface for implementing keyboards">
Only one client can bind this interface at a time.
</description>
<request name="get_input_panel_surface">
<arg name="id" type="new_id" interface="zwp_input_panel_surface_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
</interface>
<interface name="zwp_input_panel_surface_v1" version="1">
<enum name="position">
<entry name="center_bottom" value="0"/>
</enum>
<request name="set_toplevel">
<description summary="set the surface type as a keyboard">
Set the input_panel_surface type to keyboard.
A keyboard surface is only shown when a text input is active.
</description>
<arg name="output" type="object" interface="wl_output"/>
<arg name="position" type="uint"/>
</request>
<request name="set_overlay_panel">
<description summary="set the surface type as an overlay panel">
Set the input_panel_surface to be an overlay panel.
This is shown near the input cursor above the application window when
a text input is active.
</description>
</request>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/input-timestamps/README vendored Normal file
View file

@ -0,0 +1,4 @@
High-resolution timestamps for input events.
Maintainers:
Alexandros Frantzis <alexandros.frantzis@collabora.com>

145
third-party/vendor/wayland-protocols/protocols/unstable/input-timestamps/input-timestamps-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,145 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="input_timestamps_unstable_v1">
<copyright>
Copyright © 2017 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>
<description summary="High-resolution timestamps for input events">
This protocol specifies a way for a client to request and receive
high-resolution timestamps for input events.
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_input_timestamps_manager_v1" version="1">
<description summary="context object for high-resolution input timestamps">
A global interface used for requesting high-resolution timestamps
for input events.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the input timestamps manager object">
Informs the server that the client will no longer be using this
protocol object. Existing objects created by this object are not
affected.
</description>
</request>
<request name="get_keyboard_timestamps">
<description summary="subscribe to high-resolution keyboard timestamp events">
Creates a new input timestamps object that represents a subscription
to high-resolution timestamp events for all wl_keyboard events that
carry a timestamp.
If the associated wl_keyboard object is invalidated, either through
client action (e.g. release) or server-side changes, the input
timestamps object becomes inert and the client should destroy it
by calling zwp_input_timestamps_v1.destroy.
</description>
<arg name="id" type="new_id" interface="zwp_input_timestamps_v1"/>
<arg name="keyboard" type="object" interface="wl_keyboard"
summary="the wl_keyboard object for which to get timestamp events"/>
</request>
<request name="get_pointer_timestamps">
<description summary="subscribe to high-resolution pointer timestamp events">
Creates a new input timestamps object that represents a subscription
to high-resolution timestamp events for all wl_pointer events that
carry a timestamp.
If the associated wl_pointer object is invalidated, either through
client action (e.g. release) or server-side changes, the input
timestamps object becomes inert and the client should destroy it
by calling zwp_input_timestamps_v1.destroy.
</description>
<arg name="id" type="new_id" interface="zwp_input_timestamps_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"
summary="the wl_pointer object for which to get timestamp events"/>
</request>
<request name="get_touch_timestamps">
<description summary="subscribe to high-resolution touch timestamp events">
Creates a new input timestamps object that represents a subscription
to high-resolution timestamp events for all wl_touch events that
carry a timestamp.
If the associated wl_touch object becomes invalid, either through
client action (e.g. release) or server-side changes, the input
timestamps object becomes inert and the client should destroy it
by calling zwp_input_timestamps_v1.destroy.
</description>
<arg name="id" type="new_id" interface="zwp_input_timestamps_v1"/>
<arg name="touch" type="object" interface="wl_touch"
summary="the wl_touch object for which to get timestamp events"/>
</request>
</interface>
<interface name="zwp_input_timestamps_v1" version="1">
<description summary="context object for input timestamps">
Provides high-resolution timestamp events for a set of subscribed input
events. The set of subscribed input events is determined by the
zwp_input_timestamps_manager_v1 request used to create this object.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the input timestamps object">
Informs the server that the client will no longer be using this
protocol object. After the server processes the request, no more
timestamp events will be emitted.
</description>
</request>
<event name="timestamp">
<description summary="high-resolution timestamp event">
The timestamp event is associated with the first subsequent input event
carrying a timestamp which belongs to the set of input events this
object is subscribed to.
The timestamp provided by this event is a high-resolution version of
the timestamp argument of the associated input event. The provided
timestamp is in the same clock domain and is at least as accurate as
the associated input event timestamp.
The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples,
each component being an unsigned 32-bit value. Whole seconds are in
tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo,
and the additional fractional part in tv_nsec as nanoseconds. Hence,
for valid timestamps tv_nsec must be in [0, 999999999].
</description>
<arg name="tv_sec_hi" type="uint"
summary="high 32 bits of the seconds part of the timestamp"/>
<arg name="tv_sec_lo" type="uint"
summary="low 32 bits of the seconds part of the timestamp"/>
<arg name="tv_nsec" type="uint"
summary="nanoseconds part of the timestamp"/>
</event>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/keyboard-shortcuts-inhibit/README vendored Normal file
View file

@ -0,0 +1,4 @@
Compositor shortcuts inhibit protocol
Maintainers:
Olivier Fourdan <ofourdan@redhat.com>

143
third-party/vendor/wayland-protocols/protocols/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,143 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="keyboard_shortcuts_inhibit_unstable_v1">
<copyright>
Copyright © 2017 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 inhibiting the compositor keyboard shortcuts">
This protocol specifies a way for a client to request the compositor
to ignore its own keyboard shortcuts for a given seat, so that all
key events from that seat get forwarded to a 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>
<interface name="zwp_keyboard_shortcuts_inhibit_manager_v1" version="1">
<description summary="context object for keyboard grab_manager">
A global interface used for inhibiting the compositor keyboard shortcuts.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the keyboard shortcuts inhibitor object">
Destroy the keyboard shortcuts inhibitor manager.
</description>
</request>
<request name="inhibit_shortcuts">
<description summary="create a new keyboard shortcuts inhibitor object">
Create a new keyboard shortcuts inhibitor object associated with
the given surface for the given seat.
If shortcuts are already inhibited for the specified seat and surface,
a protocol error "already_inhibited" is raised by the compositor.
</description>
<arg name="id" type="new_id" interface="zwp_keyboard_shortcuts_inhibitor_v1"/>
<arg name="surface" type="object" interface="wl_surface"
summary="the surface that inhibits the keyboard shortcuts behavior"/>
<arg name="seat" type="object" interface="wl_seat"
summary="the wl_seat for which keyboard shortcuts should be disabled"/>
</request>
<enum name="error">
<entry name="already_inhibited"
value="0"
summary="the shortcuts are already inhibited for this surface"/>
</enum>
</interface>
<interface name="zwp_keyboard_shortcuts_inhibitor_v1" version="1">
<description summary="context object for keyboard shortcuts inhibitor">
A keyboard shortcuts inhibitor instructs the compositor to ignore
its own keyboard shortcuts when the associated surface has keyboard
focus. As a result, when the surface has keyboard focus on the given
seat, it will receive all key events originating from the specified
seat, even those which would normally be caught by the compositor for
its own shortcuts.
The Wayland compositor is however under no obligation to disable
all of its shortcuts, and may keep some special key combo for its own
use, including but not limited to one allowing the user to forcibly
restore normal keyboard events routing in the case of an unwilling
client. The compositor may also use the same key combo to reactivate
an existing shortcut inhibitor that was previously deactivated on
user request.
When the compositor restores its own keyboard shortcuts, an
"inactive" event is emitted to notify the client that the keyboard
shortcuts inhibitor is not effectively active for the surface and
seat any more, and the client should not expect to receive all
keyboard events.
When the keyboard shortcuts inhibitor is inactive, the client has
no way to forcibly reactivate the keyboard shortcuts inhibitor.
The user can chose to re-enable a previously deactivated keyboard
shortcuts inhibitor using any mechanism the compositor may offer,
in which case the compositor will send an "active" event to notify
the client.
If the surface is destroyed, unmapped, or loses the seat's keyboard
focus, the keyboard shortcuts inhibitor becomes irrelevant and the
compositor will restore its own keyboard shortcuts but no "inactive"
event is emitted in this case.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the keyboard shortcuts inhibitor object">
Remove the keyboard shortcuts inhibitor from the associated wl_surface.
</description>
</request>
<event name="active">
<description summary="shortcuts are inhibited">
This event indicates that the shortcut inhibitor is active.
The compositor sends this event every time compositor shortcuts
are inhibited on behalf of the surface. When active, the client
may receive input events normally reserved by the compositor
(see zwp_keyboard_shortcuts_inhibitor_v1).
This occurs typically when the initial request "inhibit_shortcuts"
first becomes active or when the user instructs the compositor to
re-enable and existing shortcuts inhibitor using any mechanism
offered by the compositor.
</description>
</event>
<event name="inactive">
<description summary="shortcuts are restored">
This event indicates that the shortcuts inhibitor is inactive,
normal shortcuts processing is restored by the compositor.
</description>
</event>
</interface>
</protocol>

5
third-party/vendor/wayland-protocols/protocols/unstable/linux-dmabuf/README vendored Normal file
View file

@ -0,0 +1,5 @@
Linux DMA-BUF protocol
Maintainers:
Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Daniel Stone <daniels@collabora.com>

371
third-party/vendor/wayland-protocols/protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,371 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="linux_dmabuf_unstable_v1">
<copyright>
Copyright © 2014, 2015 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="zwp_linux_dmabuf_v1" version="3">
<description summary="factory for creating dmabuf-based wl_buffers">
Following the interfaces from:
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
and the Linux DRM sub-system's AddFb2 ioctl.
This interface offers ways to create generic dmabuf-based
wl_buffers. Immediately after a client binds to this interface,
the set of supported formats and format modifiers is sent with
'format' and 'modifier' events.
The following are required from clients:
- Clients must ensure that either all data in the dma-buf is
coherent for all subsequent read access or that coherency is
correctly handled by the underlying kernel-side dma-buf
implementation.
- Don't make any more attachments after sending the buffer to the
compositor. Making more attachments later increases the risk of
the compositor not being able to use (re-import) an existing
dmabuf-based wl_buffer.
The underlying graphics stack must ensure the following:
- The dmabuf file descriptors relayed to the server will stay valid
for the whole lifetime of the wl_buffer. This means the server may
at any time use those fds to import the dmabuf into any kernel
sub-system that might accept it.
However, when the underlying graphics stack fails to deliver the
promise, because of e.g. a device hot-unplug which raises internal
errors, after the wl_buffer has been successfully created the
compositor must not raise protocol errors to the client when dmabuf
import later fails.
To create a wl_buffer from one or more dmabufs, a client creates a
zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params
request. All planes required by the intended format are added with
the 'add' request. Finally, a 'create' or 'create_immed' request is
issued, which has the following outcome depending on the import success.
The 'create' request,
- on success, triggers a 'created' event which provides the final
wl_buffer to the client.
- on failure, triggers a 'failed' event to convey that the server
cannot use the dmabufs received from the client.
For the 'create_immed' request,
- on success, the server immediately imports the added dmabufs to
create a wl_buffer. No event is sent from the server in this case.
- on failure, the server can choose to either:
- terminate the client by raising a fatal error.
- mark the wl_buffer as failed, and send a 'failed' event to the
client. If the client uses a failed wl_buffer as an argument to any
request, the behaviour is compositor implementation-defined.
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="unbind the factory">
Objects created through this interface, especially wl_buffers, will
remain valid.
</description>
</request>
<request name="create_params">
<description summary="create a temporary object for buffer parameters">
This temporary object is used to collect multiple dmabuf handles into
a single batch to create a wl_buffer. It can only be used once and
should be destroyed after a 'created' or 'failed' event has been
received.
</description>
<arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1"
summary="the new temporary"/>
</request>
<event name="format">
<description summary="supported buffer format">
This event advertises one buffer format that the server supports.
All the supported formats are advertised once when the client
binds to this interface. A roundtrip after binding guarantees
that the client has received all supported formats.
For the definition of the format codes, see the
zwp_linux_buffer_params_v1::create request.
Warning: the 'format' event is likely to be deprecated and replaced
with the 'modifier' event introduced in zwp_linux_dmabuf_v1
version 3, described below. Please refrain from using the information
received from this event.
</description>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
</event>
<event name="modifier" since="3">
<description summary="supported buffer format modifier">
This event advertises the formats that the server supports, along with
the modifiers supported for each format. All the supported modifiers
for all the supported formats are advertised once when the client
binds to this interface. A roundtrip after binding guarantees that
the client has received all supported format-modifier pairs.
For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
It indicates that the server can support the format with an implicit
modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
is as if no explicit modifier is specified. The effective modifier
will be derived from the dmabuf.
A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for
a given format supports both explicit modifiers and implicit modifiers.
For the definition of the format and modifier codes, see the
zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add
requests.
</description>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
<arg name="modifier_hi" type="uint"
summary="high 32 bits of layout modifier"/>
<arg name="modifier_lo" type="uint"
summary="low 32 bits of layout modifier"/>
</event>
</interface>
<interface name="zwp_linux_buffer_params_v1" version="3">
<description summary="parameters for creating a dmabuf-based wl_buffer">
This temporary object is a collection of dmabufs and other
parameters that together form a single logical buffer. The temporary
object may eventually create one wl_buffer unless cancelled by
destroying it before requesting 'create'.
Single-planar formats only require one dmabuf, however
multi-planar formats may require more than one dmabuf. For all
formats, an 'add' request must be called once per plane (even if the
underlying dmabuf fd is identical).
You must use consecutive plane indices ('plane_idx' argument for 'add')
from zero to the number of planes used by the drm_fourcc format code.
All planes required by the format must be given exactly once, but can
be given in any order. Each plane index can be set only once.
</description>
<enum name="error">
<entry name="already_used" value="0"
summary="the dmabuf_batch object has already been used to create a wl_buffer"/>
<entry name="plane_idx" value="1"
summary="plane index out of bounds"/>
<entry name="plane_set" value="2"
summary="the plane index was already set"/>
<entry name="incomplete" value="3"
summary="missing or too many planes to create a buffer"/>
<entry name="invalid_format" value="4"
summary="format not supported"/>
<entry name="invalid_dimensions" value="5"
summary="invalid width or height"/>
<entry name="out_of_bounds" value="6"
summary="offset + stride * height goes out of dmabuf bounds"/>
<entry name="invalid_wl_buffer" value="7"
summary="invalid wl_buffer resulted from importing dmabufs via
the create_immed request on given buffer_params"/>
</enum>
<request name="destroy" type="destructor">
<description summary="delete this object, used or not">
Cleans up the temporary data sent to the server for dmabuf-based
wl_buffer creation.
</description>
</request>
<request name="add">
<description summary="add a dmabuf to the temporary set">
This request adds one dmabuf to the set in this
zwp_linux_buffer_params_v1.
The 64-bit unsigned value combined from modifier_hi and modifier_lo
is the dmabuf layout modifier. DRM AddFB2 ioctl calls this the
fb modifier, which is defined in drm_mode.h of Linux UAPI.
This is an opaque token. Drivers use this token to express tiling,
compression, etc. driver-specific modifications to the base format
defined by the DRM fourcc code.
Warning: It should be an error if the format/modifier pair was not
advertised with the modifier event. This is not enforced yet because
some implementations always accept DRM_FORMAT_MOD_INVALID. Also
version 2 of this protocol does not have the modifier event.
This request raises the PLANE_IDX error if plane_idx is too large.
The error PLANE_SET is raised if attempting to set a plane that
was already set.
</description>
<arg name="fd" type="fd" summary="dmabuf fd"/>
<arg name="plane_idx" type="uint" summary="plane index"/>
<arg name="offset" type="uint" summary="offset in bytes"/>
<arg name="stride" type="uint" summary="stride in bytes"/>
<arg name="modifier_hi" type="uint"
summary="high 32 bits of layout modifier"/>
<arg name="modifier_lo" type="uint"
summary="low 32 bits of layout modifier"/>
</request>
<enum name="flags" bitfield="true">
<entry name="y_invert" value="1" summary="contents are y-inverted"/>
<entry name="interlaced" value="2" summary="content is interlaced"/>
<entry name="bottom_first" value="4" summary="bottom field first"/>
</enum>
<request name="create">
<description summary="create a wl_buffer from the given dmabufs">
This asks for creation of a wl_buffer from the added dmabuf
buffers. The wl_buffer is not created immediately but returned via
the 'created' event if the dmabuf sharing succeeds. The sharing
may fail at runtime for reasons a client cannot predict, in
which case the 'failed' event is triggered.
The 'format' argument is a DRM_FORMAT code, as defined by the
libdrm's drm_fourcc.h. The Linux kernel's DRM sub-system is the
authoritative source on how the format codes should work.
The 'flags' is a bitfield of the flags defined in enum "flags".
'y_invert' means the that the image needs to be y-flipped.
Flag 'interlaced' means that the frame in the buffer is not
progressive as usual, but interlaced. An interlaced buffer as
supported here must always contain both top and bottom fields.
The top field always begins on the first pixel row. The temporal
ordering between the two fields is top field first, unless
'bottom_first' is specified. It is undefined whether 'bottom_first'
is ignored if 'interlaced' is not set.
This protocol does not convey any information about field rate,
duration, or timing, other than the relative ordering between the
two fields in one buffer. A compositor may have to estimate the
intended field rate from the incoming buffer rate. It is undefined
whether the time of receiving wl_surface.commit with a new buffer
attached, applying the wl_surface state, wl_surface.frame callback
trigger, presentation, or any other point in the compositor cycle
is used to measure the frame or field times. There is no support
for detecting missed or late frames/fields/buffers either, and
there is no support whatsoever for cooperating with interlaced
compositor output.
The composited image quality resulting from the use of interlaced
buffers is explicitly undefined. A compositor may use elaborate
hardware features or software to deinterlace and create progressive
output frames from a sequence of interlaced input buffers, or it
may produce substandard image quality. However, compositors that
cannot guarantee reasonable image quality in all cases are recommended
to just reject all interlaced buffers.
Any argument errors, including non-positive width or height,
mismatch between the number of planes and the format, bad
format, bad offset or stride, may be indicated by fatal protocol
errors: INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS,
OUT_OF_BOUNDS.
Dmabuf import errors in the server that are not obvious client
bugs are returned via the 'failed' event as non-fatal. This
allows attempting dmabuf sharing and falling back in the client
if it fails.
This request can be sent only once in the object's lifetime, after
which the only legal request is destroy. This object should be
destroyed after issuing a 'create' request. Attempting to use this
object after issuing 'create' raises ALREADY_USED protocol error.
It is not mandatory to issue 'create'. If a client wants to
cancel the buffer creation, it can just destroy this object.
</description>
<arg name="width" type="int" summary="base plane width in pixels"/>
<arg name="height" type="int" summary="base plane height in pixels"/>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
<arg name="flags" type="uint" enum="flags" summary="see enum flags"/>
</request>
<event name="created">
<description summary="buffer creation succeeded">
This event indicates that the attempted buffer creation was
successful. It provides the new wl_buffer referencing the dmabuf(s).
Upon receiving this event, the client should destroy the
zlinux_dmabuf_params object.
</description>
<arg name="buffer" type="new_id" interface="wl_buffer"
summary="the newly created wl_buffer"/>
</event>
<event name="failed">
<description summary="buffer creation failed">
This event indicates that the attempted buffer creation has
failed. It usually means that one of the dmabuf constraints
has not been fulfilled.
Upon receiving this event, the client should destroy the
zlinux_buffer_params object.
</description>
</event>
<request name="create_immed" since="2">
<description summary="immediately create a wl_buffer from the given
dmabufs">
This asks for immediate creation of a wl_buffer by importing the
added dmabufs.
In case of import success, no event is sent from the server, and the
wl_buffer is ready to be used by the client.
Upon import failure, either of the following may happen, as seen fit
by the implementation:
- the client is terminated with one of the following fatal protocol
errors:
- INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS,
in case of argument errors such as mismatch between the number
of planes and the format, bad format, non-positive width or
height, or bad offset or stride.
- INVALID_WL_BUFFER, in case the cause for failure is unknown or
plaform specific.
- the server creates an invalid wl_buffer, marks it as failed and
sends a 'failed' event to the client. The result of using this
invalid wl_buffer as an argument in any request by the client is
defined by the compositor implementation.
This takes the same arguments as a 'create' request, and obeys the
same restrictions.
</description>
<arg name="buffer_id" type="new_id" interface="wl_buffer"
summary="id for the newly created wl_buffer"/>
<arg name="width" type="int" summary="base plane width in pixels"/>
<arg name="height" type="int" summary="base plane height in pixels"/>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
<arg name="flags" type="uint" enum="flags" summary="see enum flags"/>
</request>
</interface>
</protocol>

5
third-party/vendor/wayland-protocols/protocols/unstable/linux-explicit-synchronization/README vendored Normal file
View file

@ -0,0 +1,5 @@
Linux explicit synchronization (dma-fence) protocol
Maintainers:
Daniel Stone <daniels@collabora.com>
Alexandros Frantzis <alexandros.frantzis@collabora.com>

256
third-party/vendor/wayland-protocols/protocols/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,256 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="zwp_linux_explicit_synchronization_unstable_v1">
<copyright>
Copyright 2016 The Chromium Authors.
Copyright 2017 Intel Corporation
Copyright 2018 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="zwp_linux_explicit_synchronization_v1" version="2">
<description summary="protocol for providing explicit synchronization">
This global is a factory interface, allowing clients to request
explicit synchronization for buffers on a per-surface basis.
See zwp_linux_surface_synchronization_v1 for more information.
This interface is derived from Chromium's
zcr_linux_explicit_synchronization_v1.
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 explicit synchronization factory object">
Destroy this explicit synchronization factory object. Other objects,
including zwp_linux_surface_synchronization_v1 objects created by this
factory, shall not be affected by this request.
</description>
</request>
<enum name="error">
<entry name="synchronization_exists" value="0"
summary="the surface already has a synchronization object associated"/>
</enum>
<request name="get_synchronization">
<description summary="extend surface interface for explicit synchronization">
Instantiate an interface extension for the given wl_surface to provide
explicit synchronization.
If the given wl_surface already has an explicit synchronization object
associated, the synchronization_exists protocol error is raised.
Graphics APIs, like EGL or Vulkan, that manage the buffer queue and
commits of a wl_surface themselves, are likely to be using this
extension internally. If a client is using such an API for a
wl_surface, it should not directly use this extension on that surface,
to avoid raising a synchronization_exists protocol error.
</description>
<arg name="id" type="new_id"
interface="zwp_linux_surface_synchronization_v1"
summary="the new synchronization interface id"/>
<arg name="surface" type="object" interface="wl_surface"
summary="the surface"/>
</request>
</interface>
<interface name="zwp_linux_surface_synchronization_v1" version="2">
<description summary="per-surface explicit synchronization support">
This object implements per-surface explicit synchronization.
Synchronization refers to co-ordination of pipelined operations performed
on buffers. Most GPU clients will schedule an asynchronous operation to
render to the buffer, then immediately send the buffer to the compositor
to be attached to a surface.
In implicit synchronization, ensuring that the rendering operation is
complete before the compositor displays the buffer is an implementation
detail handled by either the kernel or userspace graphics driver.
By contrast, in explicit synchronization, dma_fence objects mark when the
asynchronous operations are complete. When submitting a buffer, the
client provides an acquire fence which will be waited on before the
compositor accesses the buffer. The Wayland server, through a
zwp_linux_buffer_release_v1 object, will inform the client with an event
which may be accompanied by a release fence, when the compositor will no
longer access the buffer contents due to the specific commit that
requested the release event.
Each surface can be associated with only one object of this interface at
any time.
In version 1 of this interface, explicit synchronization is only
guaranteed to be supported for buffers created with any version of the
wp_linux_dmabuf buffer factory. Version 2 additionally guarantees
explicit synchronization support for opaque EGL buffers, which is a type
of platform specific buffers described in the EGL_WL_bind_wayland_display
extension. Compositors are free to support explicit synchronization for
additional buffer types.
</description>
<request name="destroy" type="destructor">
<description summary="destroy synchronization object">
Destroy this explicit synchronization object.
Any fence set by this object with set_acquire_fence since the last
commit will be discarded by the server. Any fences set by this object
before the last commit are not affected.
zwp_linux_buffer_release_v1 objects created by this object are not
affected by this request.
</description>
</request>
<enum name="error">
<entry name="invalid_fence" value="0"
summary="the fence specified by the client could not be imported"/>
<entry name="duplicate_fence" value="1"
summary="multiple fences added for a single surface commit"/>
<entry name="duplicate_release" value="2"
summary="multiple releases added for a single surface commit"/>
<entry name="no_surface" value="3"
summary="the associated wl_surface was destroyed"/>
<entry name="unsupported_buffer" value="4"
summary="the buffer does not support explicit synchronization"/>
<entry name="no_buffer" value="5"
summary="no buffer was attached"/>
</enum>
<request name="set_acquire_fence">
<description summary="set the acquire fence">
Set the acquire fence that must be signaled before the compositor
may sample from the buffer attached with wl_surface.attach. The fence
is a dma_fence kernel object.
The acquire fence is double-buffered state, and will be applied on the
next wl_surface.commit request for the associated surface. Thus, it
applies only to the buffer that is attached to the surface at commit
time.
If the provided fd is not a valid dma_fence fd, then an INVALID_FENCE
error is raised.
If a fence has already been attached during the same commit cycle, a
DUPLICATE_FENCE error is raised.
If the associated wl_surface was destroyed, a NO_SURFACE error is
raised.
If at surface commit time the attached buffer does not support explicit
synchronization, an UNSUPPORTED_BUFFER error is raised.
If at surface commit time there is no buffer attached, a NO_BUFFER
error is raised.
</description>
<arg name="fd" type="fd" summary="acquire fence fd"/>
</request>
<request name="get_release">
<description summary="release fence for last-attached buffer">
Create a listener for the release of the buffer attached by the
client with wl_surface.attach. See zwp_linux_buffer_release_v1
documentation for more information.
The release object is double-buffered state, and will be associated
with the buffer that is attached to the surface at wl_surface.commit
time.
If a zwp_linux_buffer_release_v1 object has already been requested for
the surface in the same commit cycle, a DUPLICATE_RELEASE error is
raised.
If the associated wl_surface was destroyed, a NO_SURFACE error
is raised.
If at surface commit time there is no buffer attached, a NO_BUFFER
error is raised.
</description>
<arg name="release" type="new_id" interface="zwp_linux_buffer_release_v1"
summary="new zwp_linux_buffer_release_v1 object"/>
</request>
</interface>
<interface name="zwp_linux_buffer_release_v1" version="1">
<description summary="buffer release explicit synchronization">
This object is instantiated in response to a
zwp_linux_surface_synchronization_v1.get_release request.
It provides an alternative to wl_buffer.release events, providing a
unique release from a single wl_surface.commit request. The release event
also supports explicit synchronization, providing a fence FD for the
client to synchronize against.
Exactly one event, either a fenced_release or an immediate_release, will
be emitted for the wl_surface.commit request. The compositor can choose
release by release which event it uses.
This event does not replace wl_buffer.release events; servers are still
required to send those events.
Once a buffer release object has delivered a 'fenced_release' or an
'immediate_release' event it is automatically destroyed.
</description>
<event name="fenced_release">
<description summary="release buffer with fence">
Sent when the compositor has finalised its usage of the associated
buffer for the relevant commit, providing a dma_fence which will be
signaled when all operations by the compositor on that buffer for that
commit have finished.
Once the fence has signaled, and assuming the associated buffer is not
pending release from other wl_surface.commit requests, no additional
explicit or implicit synchronization is required to safely reuse or
destroy the buffer.
This event destroys the zwp_linux_buffer_release_v1 object.
</description>
<arg name="fence" type="fd" summary="fence for last operation on buffer"/>
</event>
<event name="immediate_release">
<description summary="release buffer immediately">
Sent when the compositor has finalised its usage of the associated
buffer for the relevant commit, and either performed no operations
using it, or has a guarantee that all its operations on that buffer for
that commit have finished.
Once this event is received, and assuming the associated buffer is not
pending release from other wl_surface.commit requests, no additional
explicit or implicit synchronization is required to safely reuse or
destroy the buffer.
This event destroys the zwp_linux_buffer_release_v1 object.
</description>
</event>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/pointer-constraints/README vendored Normal file
View file

@ -0,0 +1,4 @@
Pointer constraints protocol
Maintainers:
Jonas Ådahl <jadahl@gmail.com>

339
third-party/vendor/wayland-protocols/protocols/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml vendored Normal file
View file

@ -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>

4
third-party/vendor/wayland-protocols/protocols/unstable/pointer-gestures/README vendored Normal file
View file

@ -0,0 +1,4 @@
Pointer gestures protocol
Maintainers:
Carlos Garnacho <carlosg@gnome.org>

186
third-party/vendor/wayland-protocols/protocols/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,186 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="pointer_gestures_unstable_v1">
<interface name="zwp_pointer_gestures_v1" version="2">
<description summary="touchpad gestures">
A global interface to provide semantic touchpad gestures for a given
pointer.
Two gestures are currently supported: swipe and pinch.
All gestures follow a three-stage cycle: begin, update, end and
are identified by a unique id.
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="get_swipe_gesture">
<description summary="get swipe gesture">
Create a swipe gesture object. See the
wl_pointer_gesture_swipe interface for details.
</description>
<arg name="id" type="new_id" interface="zwp_pointer_gesture_swipe_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"/>
</request>
<request name="get_pinch_gesture">
<description summary="get pinch gesture">
Create a pinch gesture object. See the
wl_pointer_gesture_pinch interface for details.
</description>
<arg name="id" type="new_id" interface="zwp_pointer_gesture_pinch_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"/>
</request>
<!-- Version 2 additions -->
<request name="release" type="destructor" since="2">
<description summary="destroy the pointer gesture object">
Destroy the pointer gesture object. Swipe and pinch objects created via this
gesture object remain valid.
</description>
</request>
</interface>
<interface name="zwp_pointer_gesture_swipe_v1" version="2">
<description summary="a swipe gesture object">
A swipe gesture object notifies a client about a multi-finger swipe
gesture detected on an indirect input device such as a touchpad.
The gesture is usually initiated by multiple fingers moving in the
same direction but once initiated the direction may change.
The precise conditions of when such a gesture is detected are
implementation-dependent.
A gesture consists of three stages: begin, update (optional) and end.
There cannot be multiple simultaneous pinch or swipe gestures on a
same pointer/seat, how compositors prevent these situations is
implementation-dependent.
A gesture may be cancelled by the compositor or the hardware.
Clients should not consider performing permanent or irreversible
actions until the end of a gesture has been received.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the pointer swipe gesture object"/>
</request>
<event name="begin">
<description summary="multi-finger swipe begin">
This event is sent when a multi-finger swipe gesture is detected
on the device.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="fingers" type="uint" summary="number of fingers"/>
</event>
<event name="update">
<description summary="multi-finger swipe motion">
This event is sent when a multi-finger swipe gesture changes the
position of the logical center.
The dx and dy coordinates are relative coordinates of the logical
center of the gesture compared to the previous event.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="dx" type="fixed" summary="delta x coordinate in surface coordinate space"/>
<arg name="dy" type="fixed" summary="delta y coordinate in surface coordinate space"/>
</event>
<event name="end">
<description summary="multi-finger swipe end">
This event is sent when a multi-finger swipe gesture ceases to
be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.
When a gesture is cancelled, the client should undo state changes
caused by this gesture. What causes a gesture to be cancelled is
implementation-dependent.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="cancelled" type="int" summary="1 if the gesture was cancelled, 0 otherwise"/>
</event>
</interface>
<interface name="zwp_pointer_gesture_pinch_v1" version="2">
<description summary="a pinch gesture object">
A pinch gesture object notifies a client about a multi-finger pinch
gesture detected on an indirect input device such as a touchpad.
The gesture is usually initiated by multiple fingers moving towards
each other or away from each other, or by two or more fingers rotating
around a logical center of gravity. The precise conditions of when
such a gesture is detected are implementation-dependent.
A gesture consists of three stages: begin, update (optional) and end.
There cannot be multiple simultaneous pinch or swipe gestures on a
same pointer/seat, how compositors prevent these situations is
implementation-dependent.
A gesture may be cancelled by the compositor or the hardware.
Clients should not consider performing permanent or irreversible
actions until the end of a gesture has been received.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the pinch gesture object"/>
</request>
<event name="begin">
<description summary="multi-finger pinch begin">
This event is sent when a multi-finger pinch gesture is detected
on the device.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="fingers" type="uint" summary="number of fingers"/>
</event>
<event name="update">
<description summary="multi-finger pinch motion">
This event is sent when a multi-finger pinch gesture changes the
position of the logical center, the rotation or the relative scale.
The dx and dy coordinates are relative coordinates in the
surface coordinate space of the logical center of the gesture.
The scale factor is an absolute scale compared to the
pointer_gesture_pinch.begin event, e.g. a scale of 2 means the fingers
are now twice as far apart as on pointer_gesture_pinch.begin.
The rotation is the relative angle in degrees clockwise compared to the previous
pointer_gesture_pinch.begin or pointer_gesture_pinch.update event.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="dx" type="fixed" summary="delta x coordinate in surface coordinate space"/>
<arg name="dy" type="fixed" summary="delta y coordinate in surface coordinate space"/>
<arg name="scale" type="fixed" summary="scale relative to the initial finger position"/>
<arg name="rotation" type="fixed" summary="angle in degrees cw relative to the previous event"/>
</event>
<event name="end">
<description summary="multi-finger pinch end">
This event is sent when a multi-finger pinch gesture ceases to
be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.
When a gesture is cancelled, the client should undo state changes
caused by this gesture. What causes a gesture to be cancelled is
implementation-dependent.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="cancelled" type="int" summary="1 if the gesture was cancelled, 0 otherwise"/>
</event>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/primary-selection/README vendored Normal file
View file

@ -0,0 +1,4 @@
Primary selection protocol
Maintainers:
Simon Ser <contact@emersion.fr>

225
third-party/vendor/wayland-protocols/protocols/unstable/primary-selection/primary-selection-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,225 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wp_primary_selection_unstable_v1">
<copyright>
Copyright © 2015, 2016 Red Hat
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="Primary selection protocol">
This protocol provides the ability to have a primary selection device to
match that of the X server. This primary selection is a shortcut to the
common clipboard selection, where text just needs to be selected in order
to allow copying it elsewhere. The de facto way to perform this action
is the middle mouse button, although it is not limited to this one.
Clients wishing to honor primary selection should create a primary
selection source and set it as the selection through
wp_primary_selection_device.set_selection whenever the text selection
changes. In order to minimize calls in pointer-driven text selection,
it should happen only once after the operation finished. Similarly,
a NULL source should be set when text is unselected.
wp_primary_selection_offer objects are first announced through the
wp_primary_selection_device.data_offer event. Immediately after this event,
the primary data offer will emit wp_primary_selection_offer.offer events
to let know of the mime types being offered.
When the primary selection changes, the client with the keyboard focus
will receive wp_primary_selection_device.selection events. Only the client
with the keyboard focus will receive such events with a non-NULL
wp_primary_selection_offer. Across keyboard focus changes, previously
focused clients will receive wp_primary_selection_device.events with a
NULL wp_primary_selection_offer.
In order to request the primary selection data, the client must pass
a recent serial pertaining to the press event that is triggering the
operation, if the compositor deems the serial valid and recent, the
wp_primary_selection_source.send event will happen in the other end
to let the transfer begin. The client owning the primary selection
should write the requested data, and close the file descriptor
immediately.
If the primary selection owner client disappeared during the transfer,
the client reading the data will receive a
wp_primary_selection_device.selection event with a NULL
wp_primary_selection_offer, the client should take this as a hint
to finish the reads related to the no longer existing offer.
The primary selection owner should be checking for errors during
writes, merely cancelling the ongoing transfer if any happened.
</description>
<interface name="zwp_primary_selection_device_manager_v1" version="1">
<description summary="X primary selection emulation">
The primary selection device manager is a singleton global object that
provides access to the primary selection. It allows to create
wp_primary_selection_source objects, as well as retrieving the per-seat
wp_primary_selection_device objects.
</description>
<request name="create_source">
<description summary="create a new primary selection source">
Create a new primary selection source.
</description>
<arg name="id" type="new_id" interface="zwp_primary_selection_source_v1"/>
</request>
<request name="get_device">
<description summary="create a new primary selection device">
Create a new data device for a given seat.
</description>
<arg name="id" type="new_id" interface="zwp_primary_selection_device_v1"/>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection device manager">
Destroy the primary selection device manager.
</description>
</request>
</interface>
<interface name="zwp_primary_selection_device_v1" version="1">
<request name="set_selection">
<description summary="set the primary selection">
Replaces the current selection. The previous owner of the primary
selection will receive a wp_primary_selection_source.cancelled event.
To unset the selection, set the source to NULL.
</description>
<arg name="source" type="object" interface="zwp_primary_selection_source_v1" allow-null="true"/>
<arg name="serial" type="uint" summary="serial of the event that triggered this request"/>
</request>
<event name="data_offer">
<description summary="introduce a new wp_primary_selection_offer">
Introduces a new wp_primary_selection_offer object that may be used
to receive the current primary selection. Immediately following this
event, the new wp_primary_selection_offer object will send
wp_primary_selection_offer.offer events to describe the offered mime
types.
</description>
<arg name="offer" type="new_id" interface="zwp_primary_selection_offer_v1"/>
</event>
<event name="selection">
<description summary="advertise a new primary selection">
The wp_primary_selection_device.selection event is sent to notify the
client of a new primary selection. This event is sent after the
wp_primary_selection.data_offer event introducing this object, and after
the offer has announced its mimetypes through
wp_primary_selection_offer.offer.
The data_offer is valid until a new offer or NULL is received
or until the client loses keyboard focus. The client must destroy the
previous selection data_offer, if any, upon receiving this event.
</description>
<arg name="id" type="object" interface="zwp_primary_selection_offer_v1" allow-null="true"/>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection device">
Destroy the primary selection device.
</description>
</request>
</interface>
<interface name="zwp_primary_selection_offer_v1" version="1">
<description summary="offer to transfer primary selection contents">
A wp_primary_selection_offer represents an offer to transfer the contents
of the primary selection clipboard to the client. Similar to
wl_data_offer, the offer also describes the mime types that the data can
be converted to and provides the mechanisms for transferring the data
directly to the client.
</description>
<request name="receive">
<description summary="request that the data is transferred">
To transfer the contents of the primary selection clipboard, the client
issues this request and indicates the mime type that it wants to
receive. The transfer happens through the passed file descriptor
(typically created with the pipe system call). The source client writes
the data in the mime type representation requested and then closes the
file descriptor.
The receiving client reads from the read end of the pipe until EOF and
closes its end, at which point the transfer is complete.
</description>
<arg name="mime_type" type="string"/>
<arg name="fd" type="fd"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection offer">
Destroy the primary selection offer.
</description>
</request>
<event name="offer">
<description summary="advertise offered mime type">
Sent immediately after creating announcing the
wp_primary_selection_offer through
wp_primary_selection_device.data_offer. One event is sent per offered
mime type.
</description>
<arg name="mime_type" type="string"/>
</event>
</interface>
<interface name="zwp_primary_selection_source_v1" version="1">
<description summary="offer to replace the contents of the primary selection">
The source side of a wp_primary_selection_offer, it provides a way to
describe the offered data and respond to requests to transfer the
requested contents of the primary selection clipboard.
</description>
<request name="offer">
<description summary="add an offered mime type">
This request adds a mime type to the set of mime types advertised to
targets. Can be called several times to offer multiple types.
</description>
<arg name="mime_type" type="string"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the primary selection source">
Destroy the primary selection source.
</description>
</request>
<event name="send">
<description summary="send the primary selection contents">
Request for the current primary selection contents from the client.
Send the specified mime type over the passed file descriptor, then
close it.
</description>
<arg name="mime_type" type="string"/>
<arg name="fd" type="fd"/>
</event>
<event name="cancelled">
<description summary="request for primary selection contents was canceled">
This primary selection source is no longer valid. The client should
clean up and destroy this primary selection source.
</description>
</event>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/relative-pointer/README vendored Normal file
View file

@ -0,0 +1,4 @@
Relative pointer protocol
Maintainers:
Jonas Ådahl <jadahl@gmail.com>

136
third-party/vendor/wayland-protocols/protocols/unstable/relative-pointer/relative-pointer-unstable-v1.xml vendored Normal file
View file

@ -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>

4
third-party/vendor/wayland-protocols/protocols/unstable/tablet/README vendored Normal file
View file

@ -0,0 +1,4 @@
Tablet protocol
Maintainers:
Peter Hutterer <peter.hutterer@who-t.net>

640
third-party/vendor/wayland-protocols/protocols/unstable/tablet/tablet-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,640 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="tablet_unstable_v1">
<copyright>
Copyright 2014 © Stephen "Lyude" Chandler Paul
Copyright 2015-2016 © 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="Wayland protocol for graphics tablets">
This description provides a high-level overview of the interplay between
the interfaces defined this protocol. For details, see the protocol
specification.
More than one tablet may exist, and device-specifics matter. Tablets are
not represented by a single virtual device like wl_pointer. A client
binds to the tablet manager object which is just a proxy object. From
that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
and that returns the actual interface that has all the tablets. With
this indirection, we can avoid merging wp_tablet into the actual Wayland
protocol, a long-term benefit.
The wp_tablet_seat sends a "tablet added" event for each tablet
connected. That event is followed by descriptive events about the
hardware; currently that includes events for name, vid/pid and
a wp_tablet.path event that describes a local path. This path can be
used to uniquely identify a tablet or get more information through
libwacom. Emulated or nested tablets can skip any of those, e.g. a
virtual tablet may not have a vid/pid. The sequence of descriptive
events is terminated by a wp_tablet.done event to signal that a client
may now finalize any initialization for that tablet.
Events from tablets require a tool in proximity. Tools are also managed
by the tablet seat; a "tool added" event is sent whenever a tool is new
to the compositor. That event is followed by a number of descriptive
events about the hardware; currently that includes capabilities,
hardware id and serial number, and tool type. Similar to the tablet
interface, a wp_tablet_tool.done event is sent to terminate that initial
sequence.
Any event from a tool happens on the wp_tablet_tool interface. When the
tool gets into proximity of the tablet, a proximity_in event is sent on
the wp_tablet_tool interface, listing the tablet and the surface. That
event is followed by a motion event with the coordinates. After that,
it's the usual motion, axis, button, etc. events. The protocol's
serialisation means events are grouped by wp_tablet_tool.frame events.
Two special events (that don't exist in X) are down and up. They signal
"tip touching the surface". For tablets without real proximity
detection, the sequence is: proximity_in, motion, down, frame.
When the tool leaves proximity, a proximity_out event is sent. If any
button is still down, a button release event is sent before this
proximity event. These button events are sent in the same frame as the
proximity event to signal to the client that the buttons were held when
the tool left proximity.
If the tool moves out of the surface but stays in proximity (i.e.
between windows), compositor-specific grab policies apply. This usually
means that the proximity-out is delayed until all buttons are released.
Moving a tool physically from one tablet to the other has no real effect
on the protocol, since we already have the tool object from the "tool
added" event. All the information is already there and the proximity
events on both tablets are all a client needs to reconstruct what
happened.
Some extra axes are normalized, i.e. the client knows the range as
specified in the protocol (e.g. [0, 65535]), the granularity however is
unknown. The current normalized axes are pressure, distance, and slider.
Other extra axes are in physical units as specified in the protocol.
The current extra axes with physical units are tilt, rotation and
wheel rotation.
Since tablets work independently of the pointer controlled by the mouse,
the focus handling is independent too and controlled by proximity.
The wp_tablet_tool.set_cursor request sets a tool-specific cursor.
This cursor surface may be the same as the mouse cursor, and it may be
the same across tools but it is possible to be more fine-grained. For
example, a client may set different cursors for the pen and eraser.
Tools are generally independent of tablets and it is
compositor-specific policy when a tool can be removed. Common approaches
will likely include some form of removing a tool when all tablets the
tool was used on are removed.
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_tablet_manager_v1" version="1">
<description summary="controller object for graphic tablet devices">
An object that provides access to the graphics tablets available on this
system. All tablets are associated with a seat, to get access to the
actual tablets, use wp_tablet_manager.get_tablet_seat.
</description>
<request name="get_tablet_seat">
<description summary="get the tablet seat">
Get the wp_tablet_seat object for the given seat. This object
provides access to all graphics tablets in this seat.
</description>
<arg name="tablet_seat" type="new_id" interface="zwp_tablet_seat_v1"/>
<arg name="seat" type="object" interface="wl_seat" summary="The wl_seat object to retrieve the tablets for" />
</request>
<request name="destroy" type="destructor">
<description summary="release the memory for the tablet manager object">
Destroy the wp_tablet_manager object. Objects created from this
object are unaffected and should be destroyed separately.
</description>
</request>
</interface>
<interface name="zwp_tablet_seat_v1" version="1">
<description summary="controller object for graphic tablet devices of a seat">
An object that provides access to the graphics tablets available on this
seat. After binding to this interface, the compositor sends a set of
wp_tablet_seat.tablet_added and wp_tablet_seat.tool_added events.
</description>
<request name="destroy" type="destructor">
<description summary="release the memory for the tablet seat object">
Destroy the wp_tablet_seat object. Objects created from this
object are unaffected and should be destroyed separately.
</description>
</request>
<event name="tablet_added">
<description summary="new device notification">
This event is sent whenever a new tablet becomes available on this
seat. This event only provides the object id of the tablet, any
static information about the tablet (device name, vid/pid, etc.) is
sent through the wp_tablet interface.
</description>
<arg name="id" type="new_id" interface="zwp_tablet_v1" summary="the newly added graphics tablet"/>
</event>
<event name="tool_added">
<description summary="a new tool has been used with a tablet">
This event is sent whenever a tool that has not previously been used
with a tablet comes into use. This event only provides the object id
of the tool; any static information about the tool (capabilities,
type, etc.) is sent through the wp_tablet_tool interface.
</description>
<arg name="id" type="new_id" interface="zwp_tablet_tool_v1" summary="the newly added tablet tool"/>
</event>
</interface>
<interface name="zwp_tablet_tool_v1" version="1">
<description summary="a physical tablet tool">
An object that represents a physical tool that has been, or is
currently in use with a tablet in this seat. Each wp_tablet_tool
object stays valid until the client destroys it; the compositor
reuses the wp_tablet_tool object to indicate that the object's
respective physical tool has come into proximity of a tablet again.
A wp_tablet_tool object's relation to a physical tool depends on the
tablet's ability to report serial numbers. If the tablet supports
this capability, then the object represents a specific physical tool
and can be identified even when used on multiple tablets.
A tablet tool has a number of static characteristics, e.g. tool type,
hardware_serial and capabilities. These capabilities are sent in an
event sequence after the wp_tablet_seat.tool_added event before any
actual events from this tool. This initial event sequence is
terminated by a wp_tablet_tool.done event.
Tablet tool events are grouped by wp_tablet_tool.frame events.
Any events received before a wp_tablet_tool.frame event should be
considered part of the same hardware state change.
</description>
<request name="set_cursor">
<description summary="set the tablet tool's surface">
Sets the surface of the cursor used for this tool on the given
tablet. This request only takes effect if the tool is in proximity
of one of the requesting client's surfaces or the surface parameter
is the current pointer surface. If there was a previous surface set
with this request it is replaced. If surface is NULL, the cursor
image is hidden.
The parameters hotspot_x and hotspot_y define the position of the
pointer surface relative to the pointer location. Its top-left corner
is always at (x, y) - (hotspot_x, hotspot_y), where (x, y) are the
coordinates of the pointer location, in surface-local coordinates.
On surface.attach requests to the pointer surface, hotspot_x and
hotspot_y are decremented by the x and y parameters passed to the
request. Attach must be confirmed by wl_surface.commit as usual.
The hotspot can also be updated by passing the currently set pointer
surface to this request with new values for hotspot_x and hotspot_y.
The current and pending input regions of the wl_surface are cleared,
and wl_surface.set_input_region is ignored until the wl_surface is no
longer used as the cursor. When the use as a cursor ends, the current
and pending input regions become undefined, and the wl_surface is
unmapped.
This request gives the surface the role of a cursor. The role
assigned by this request is the same as assigned by
wl_pointer.set_cursor meaning the same surface can be
used both as a wl_pointer cursor and a wp_tablet cursor. If the
surface already has another role, it raises a protocol error.
The surface may be used on multiple tablets and across multiple
seats.
</description>
<arg name="serial" type="uint" summary="serial of the enter event"/>
<arg name="surface" type="object" interface="wl_surface" allow-null="true"/>
<arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>
<arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the tool object">
This destroys the client's resource for this tool object.
</description>
</request>
<enum name="type">
<description summary="a physical tool type">
Describes the physical type of a tool. The physical type of a tool
generally defines its base usage.
The mouse tool represents a mouse-shaped tool that is not a relative
device but bound to the tablet's surface, providing absolute
coordinates.
The lens tool is a mouse-shaped tool with an attached lens to
provide precision focus.
</description>
<entry name="pen" value="0x140" summary="Pen"/>
<entry name="eraser" value="0x141" summary="Eraser"/>
<entry name="brush" value="0x142" summary="Brush"/>
<entry name="pencil" value="0x143" summary="Pencil"/>
<entry name="airbrush" value="0x144" summary="Airbrush"/>
<entry name="finger" value="0x145" summary="Finger"/>
<entry name="mouse" value="0x146" summary="Mouse"/>
<entry name="lens" value="0x147" summary="Lens"/>
</enum>
<event name="type">
<description summary="tool type">
The tool type is the high-level type of the tool and usually decides
the interaction expected from this tool.
This event is sent in the initial burst of events before the
wp_tablet_tool.done event.
</description>
<arg name="tool_type" type="uint" enum="type" summary="the physical tool type"/>
</event>
<event name="hardware_serial">
<description summary="unique hardware serial number of the tool">
If the physical tool can be identified by a unique 64-bit serial
number, this event notifies the client of this serial number.
If multiple tablets are available in the same seat and the tool is
uniquely identifiable by the serial number, that tool may move
between tablets.
Otherwise, if the tool has no serial number and this event is
missing, the tool is tied to the tablet it first comes into
proximity with. Even if the physical tool is used on multiple
tablets, separate wp_tablet_tool objects will be created, one per
tablet.
This event is sent in the initial burst of events before the
wp_tablet_tool.done event.
</description>
<arg name="hardware_serial_hi" type="uint" summary="the unique serial number of the tool, most significant bits"/>
<arg name="hardware_serial_lo" type="uint" summary="the unique serial number of the tool, least significant bits"/>
</event>
<event name="hardware_id_wacom">
<description summary="hardware id notification in Wacom's format">
This event notifies the client of a hardware id available on this tool.
The hardware id is a device-specific 64-bit id that provides extra
information about the tool in use, beyond the wl_tool.type
enumeration. The format of the id is specific to tablets made by
Wacom Inc. For example, the hardware id of a Wacom Grip
Pen (a stylus) is 0x802.
This event is sent in the initial burst of events before the
wp_tablet_tool.done event.
</description>
<arg name="hardware_id_hi" type="uint" summary="the hardware id, most significant bits"/>
<arg name="hardware_id_lo" type="uint" summary="the hardware id, least significant bits"/>
</event>
<enum name="capability">
<description summary="capability flags for a tool">
Describes extra capabilities on a tablet.
Any tool must provide x and y values, extra axes are
device-specific.
</description>
<entry name="tilt" value="1" summary="Tilt axes"/>
<entry name="pressure" value="2" summary="Pressure axis"/>
<entry name="distance" value="3" summary="Distance axis"/>
<entry name="rotation" value="4" summary="Z-rotation axis"/>
<entry name="slider" value="5" summary="Slider axis"/>
<entry name="wheel" value="6" summary="Wheel axis"/>
</enum>
<event name="capability">
<description summary="tool capability notification">
This event notifies the client of any capabilities of this tool,
beyond the main set of x/y axes and tip up/down detection.
One event is sent for each extra capability available on this tool.
This event is sent in the initial burst of events before the
wp_tablet_tool.done event.
</description>
<arg name="capability" type="uint" enum="capability" summary="the capability"/>
</event>
<event name="done">
<description summary="tool description events sequence complete">
This event signals the end of the initial burst of descriptive
events. A client may consider the static description of the tool to
be complete and finalize initialization of the tool.
</description>
</event>
<event name="removed">
<description summary="tool removed">
This event is sent when the tool is removed from the system and will
send no further events. Should the physical tool come back into
proximity later, a new wp_tablet_tool object will be created.
It is compositor-dependent when a tool is removed. A compositor may
remove a tool on proximity out, tablet removal or any other reason.
A compositor may also keep a tool alive until shutdown.
If the tool is currently in proximity, a proximity_out event will be
sent before the removed event. See wp_tablet_tool.proximity_out for
the handling of any buttons logically down.
When this event is received, the client must wp_tablet_tool.destroy
the object.
</description>
</event>
<event name="proximity_in">
<description summary="proximity in event">
Notification that this tool is focused on a certain surface.
This event can be received when the tool has moved from one surface to
another, or when the tool has come back into proximity above the
surface.
If any button is logically down when the tool comes into proximity,
the respective button event is sent after the proximity_in event but
within the same frame as the proximity_in event.
</description>
<arg name="serial" type="uint"/>
<arg name="tablet" type="object" interface="zwp_tablet_v1" summary="The tablet the tool is in proximity of"/>
<arg name="surface" type="object" interface="wl_surface" summary="The current surface the tablet tool is over"/>
</event>
<event name="proximity_out">
<description summary="proximity out event">
Notification that this tool has either left proximity, or is no
longer focused on a certain surface.
When the tablet tool leaves proximity of the tablet, button release
events are sent for each button that was held down at the time of
leaving proximity. These events are sent before the proximity_out
event but within the same wp_tablet.frame.
If the tool stays within proximity of the tablet, but the focus
changes from one surface to another, a button release event may not
be sent until the button is actually released or the tool leaves the
proximity of the tablet.
</description>
</event>
<event name="down">
<description summary="tablet tool is making contact">
Sent whenever the tablet tool comes in contact with the surface of the
tablet.
If the tool is already in contact with the tablet when entering the
input region, the client owning said region will receive a
wp_tablet.proximity_in event, followed by a wp_tablet.down
event and a wp_tablet.frame event.
Note that this event describes logical contact, not physical
contact. On some devices, a compositor may not consider a tool in
logical contact until a minimum physical pressure threshold is
exceeded.
</description>
<arg name="serial" type="uint"/>
</event>
<event name="up">
<description summary="tablet tool is no longer making contact">
Sent whenever the tablet tool stops making contact with the surface of
the tablet, or when the tablet tool moves out of the input region
and the compositor grab (if any) is dismissed.
If the tablet tool moves out of the input region while in contact
with the surface of the tablet and the compositor does not have an
ongoing grab on the surface, the client owning said region will
receive a wp_tablet.up event, followed by a wp_tablet.proximity_out
event and a wp_tablet.frame event. If the compositor has an ongoing
grab on this device, this event sequence is sent whenever the grab
is dismissed in the future.
Note that this event describes logical contact, not physical
contact. On some devices, a compositor may not consider a tool out
of logical contact until physical pressure falls below a specific
threshold.
</description>
</event>
<event name="motion">
<description summary="motion event">
Sent whenever a tablet tool moves.
</description>
<arg name="x" type="fixed" summary="surface-local x coordinate"/>
<arg name="y" type="fixed" summary="surface-local y coordinate"/>
</event>
<event name="pressure">
<description summary="pressure change event">
Sent whenever the pressure axis on a tool changes. The value of this
event is normalized to a value between 0 and 65535.
Note that pressure may be nonzero even when a tool is not in logical
contact. See the down and up events for more details.
</description>
<arg name="pressure" type="uint" summary="The current pressure value"/>
</event>
<event name="distance">
<description summary="distance change event">
Sent whenever the distance axis on a tool changes. The value of this
event is normalized to a value between 0 and 65535.
Note that distance may be nonzero even when a tool is not in logical
contact. See the down and up events for more details.
</description>
<arg name="distance" type="uint" summary="The current distance value"/>
</event>
<event name="tilt">
<description summary="tilt change event">
Sent whenever one or both of the tilt axes on a tool change. Each tilt
value is in 0.01 of a degree, relative to the z-axis of the tablet.
The angle is positive when the top of a tool tilts along the
positive x or y axis.
</description>
<arg name="tilt_x" type="int" summary="The current value of the X tilt axis"/>
<arg name="tilt_y" type="int" summary="The current value of the Y tilt axis"/>
</event>
<event name="rotation">
<description summary="z-rotation change event">
Sent whenever the z-rotation axis on the tool changes. The
rotation value is in 0.01 of a degree clockwise from the tool's
logical neutral position.
</description>
<arg name="degrees" type="int" summary="The current rotation of the Z axis"/>
</event>
<event name="slider">
<description summary="Slider position change event">
Sent whenever the slider position on the tool changes. The
value is normalized between -65535 and 65535, with 0 as the logical
neutral position of the slider.
The slider is available on e.g. the Wacom Airbrush tool.
</description>
<arg name="position" type="int" summary="The current position of slider"/>
</event>
<event name="wheel">
<description summary="Wheel delta event">
Sent whenever the wheel on the tool emits an event. This event
contains two values for the same axis change. The degrees value is
in 0.01 of a degree in the same orientation as the
wl_pointer.vertical_scroll axis. The clicks value is in discrete
logical clicks of the mouse wheel. This value may be zero if the
movement of the wheel was less than one logical click.
Clients should choose either value and avoid mixing degrees and
clicks. The compositor may accumulate values smaller than a logical
click and emulate click events when a certain threshold is met.
Thus, wl_tablet_tool.wheel events with non-zero clicks values may
have different degrees values.
</description>
<arg name="degrees" type="int" summary="The wheel delta in 0.01 of a degree"/>
<arg name="clicks" type="int" summary="The wheel delta in discrete clicks"/>
</event>
<enum name="button_state">
<description summary="physical button state">
Describes the physical state of a button that produced the button event.
</description>
<entry name="released" value="0" summary="button is not pressed"/>
<entry name="pressed" value="1" summary="button is pressed"/>
</enum>
<event name="button">
<description summary="button event">
Sent whenever a button on the tool is pressed or released.
If a button is held down when the tool moves in or out of proximity,
button events are generated by the compositor. See
wp_tablet_tool.proximity_in and wp_tablet_tool.proximity_out for
details.
</description>
<arg name="serial" type="uint"/>
<arg name="button" type="uint" summary="The button whose state has changed"/>
<arg name="state" type="uint" enum="button_state" summary="Whether the button was pressed or released"/>
</event>
<event name="frame">
<description summary="frame event">
Marks the end of a series of axis and/or button updates from the
tablet. The Wayland protocol requires axis updates to be sent
sequentially, however all events within a frame should be considered
one hardware event.
</description>
<arg name="time" type="uint" summary="The time of the event with millisecond granularity"/>
</event>
<enum name="error">
<entry name="role" value="0" summary="given wl_surface has another role"/>
</enum>
</interface>
<interface name="zwp_tablet_v1" version="1">
<description summary="graphics tablet device">
The wp_tablet interface represents one graphics tablet device. The
tablet interface itself does not generate events; all events are
generated by wp_tablet_tool objects when in proximity above a tablet.
A tablet has a number of static characteristics, e.g. device name and
pid/vid. These capabilities are sent in an event sequence after the
wp_tablet_seat.tablet_added event. This initial event sequence is
terminated by a wp_tablet.done event.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the tablet object">
This destroys the client's resource for this tablet object.
</description>
</request>
<event name="name">
<description summary="tablet device name">
This event is sent in the initial burst of events before the
wp_tablet.done event.
</description>
<arg name="name" type="string" summary="the device name"/>
</event>
<event name="id">
<description summary="tablet device USB vendor/product id">
This event is sent in the initial burst of events before the
wp_tablet.done event.
</description>
<arg name="vid" type="uint" summary="USB vendor id"/>
<arg name="pid" type="uint" summary="USB product id"/>
</event>
<event name="path">
<description summary="path to the device">
A system-specific device path that indicates which device is behind
this wp_tablet. This information may be used to gather additional
information about the device, e.g. through libwacom.
A device may have more than one device path. If so, multiple
wp_tablet.path events are sent. A device may be emulated and not
have a device path, and in that case this event will not be sent.
The format of the path is unspecified, it may be a device node, a
sysfs path, or some other identifier. It is up to the client to
identify the string provided.
This event is sent in the initial burst of events before the
wp_tablet.done event.
</description>
<arg name="path" type="string" summary="path to local device"/>
</event>
<event name="done">
<description summary="tablet description events sequence complete">
This event is sent immediately to signal the end of the initial
burst of descriptive events. A client may consider the static
description of the tablet to be complete and finalize initialization
of the tablet.
</description>
</event>
<event name="removed">
<description summary="tablet removed event">
Sent when the tablet has been removed from the system. When a tablet
is removed, some tools may be removed.
When this event is received, the client must wp_tablet.destroy
the object.
</description>
</event>
</interface>
</protocol>

1178
third-party/vendor/wayland-protocols/protocols/unstable/tablet/tablet-unstable-v2.xml vendored Normal file
View file

File diff suppressed because it is too large Load diff

4
third-party/vendor/wayland-protocols/protocols/unstable/text-input/README vendored Normal file
View file

@ -0,0 +1,4 @@
Text input protocol
Maintainers:
Jan Arne Petersen <janarne@gmail.com>

385
third-party/vendor/wayland-protocols/protocols/unstable/text-input/text-input-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,385 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="text_input_unstable_v1">
<copyright>
Copyright © 2012, 2013 Intel Corporation
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
</copyright>
<interface name="zwp_text_input_v1" version="1">
<description summary="text input">
An object used for text input. Adds support for text input and input
methods to applications. A text_input object is created from a
wl_text_input_manager and corresponds typically to a text entry in an
application.
Requests are used to activate/deactivate the text_input object and set
state information like surrounding and selected text or the content type.
The information about entered text is sent to the text_input object via
the pre-edit and commit events. Using this interface removes the need
for applications to directly process hardware key events and compose text
out of them.
Text is generally UTF-8 encoded, indices and lengths are in bytes.
Serials are used to synchronize the state between the text input and
an input method. New serials are sent by the text input in the
commit_state request and are used by the input method to indicate
the known text input state in events like preedit_string, commit_string,
and keysym. The text input can then ignore events from the input method
which are based on an outdated state (for example after a reset).
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="activate">
<description summary="request activation">
Requests the text_input object to be activated (typically when the
text entry gets focus).
The seat argument is a wl_seat which maintains the focus for this
activation. The surface argument is a wl_surface assigned to the
text_input object and tracked for focus lost. The enter event
is emitted on successful activation.
</description>
<arg name="seat" type="object" interface="wl_seat"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="deactivate">
<description summary="request deactivation">
Requests the text_input object to be deactivated (typically when the
text entry lost focus). The seat argument is a wl_seat which was used
for activation.
</description>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
<request name="show_input_panel">
<description summary="show input panels">
Requests input panels (virtual keyboard) to show.
</description>
</request>
<request name="hide_input_panel">
<description summary="hide input panels">
Requests input panels (virtual keyboard) to hide.
</description>
</request>
<request name="reset">
<description summary="reset">
Should be called by an editor widget when the input state should be
reset, for example after the text was changed outside of the normal
input method flow.
</description>
</request>
<request name="set_surrounding_text">
<description summary="sets the surrounding text">
Sets the plain surrounding text around the input position. Text is
UTF-8 encoded. Cursor is the byte offset within the
surrounding text. Anchor is the byte offset of the
selection anchor within the surrounding text. If there is no selected
text anchor, then it is the same as cursor.
</description>
<arg name="text" type="string"/>
<arg name="cursor" type="uint"/>
<arg name="anchor" type="uint"/>
</request>
<enum name="content_hint" bitfield="true">
<description summary="content hint">
Content hint is a bitmask to allow to modify the behavior of the text
input.
</description>
<entry name="none" value="0x0" summary="no special behaviour"/>
<entry name="default" value="0x7" summary="auto completion, correction and capitalization"/>
<entry name="password" value="0xc0" summary="hidden and sensitive text"/>
<entry name="auto_completion" value="0x1" summary="suggest word completions"/>
<entry name="auto_correction" value="0x2" summary="suggest word corrections"/>
<entry name="auto_capitalization" value="0x4" summary="switch to uppercase letters at the start of a sentence"/>
<entry name="lowercase" value="0x8" summary="prefer lowercase letters"/>
<entry name="uppercase" value="0x10" summary="prefer uppercase letters"/>
<entry name="titlecase" value="0x20" summary="prefer casing for titles and headings (can be language dependent)"/>
<entry name="hidden_text" value="0x40" summary="characters should be hidden"/>
<entry name="sensitive_data" value="0x80" summary="typed text should not be stored"/>
<entry name="latin" value="0x100" summary="just latin characters should be entered"/>
<entry name="multiline" value="0x200" summary="the text input is multiline"/>
</enum>
<enum name="content_purpose">
<description summary="content purpose">
The content purpose allows to specify the primary purpose of a text
input.
This allows an input method to show special purpose input panels with
extra characters or to disallow some characters.
</description>
<entry name="normal" value="0" summary="default input, allowing all characters"/>
<entry name="alpha" value="1" summary="allow only alphabetic characters"/>
<entry name="digits" value="2" summary="allow only digits"/>
<entry name="number" value="3" summary="input a number (including decimal separator and sign)"/>
<entry name="phone" value="4" summary="input a phone number"/>
<entry name="url" value="5" summary="input an URL"/>
<entry name="email" value="6" summary="input an email address"/>
<entry name="name" value="7" summary="input a name of a person"/>
<entry name="password" value="8" summary="input a password (combine with password or sensitive_data hint)"/>
<entry name="date" value="9" summary="input a date"/>
<entry name="time" value="10" summary="input a time"/>
<entry name="datetime" value="11" summary="input a date and time"/>
<entry name="terminal" value="12" summary="input for a terminal"/>
</enum>
<request name="set_content_type">
<description summary="set content purpose and hint">
Sets the content purpose and content hint. While the purpose is the
basic purpose of an input field, the hint flags allow to modify some
of the behavior.
When no content type is explicitly set, a normal content purpose with
default hints (auto completion, auto correction, auto capitalization)
should be assumed.
</description>
<arg name="hint" type="uint" enum="content_hint" />
<arg name="purpose" type="uint" enum="content_purpose" />
</request>
<request name="set_cursor_rectangle">
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</request>
<request name="set_preferred_language">
<description summary="sets preferred language">
Sets a specific language. This allows for example a virtual keyboard to
show a language specific layout. The "language" argument is an RFC-3066
format language tag.
It could be used for example in a word processor to indicate the
language of the currently edited document or in an instant message
application which tracks languages of contacts.
</description>
<arg name="language" type="string"/>
</request>
<request name="commit_state">
<arg name="serial" type="uint" summary="used to identify the known state"/>
</request>
<request name="invoke_action">
<arg name="button" type="uint"/>
<arg name="index" type="uint"/>
</request>
<event name="enter">
<description summary="enter event">
Notify the text_input object when it received focus. Typically in
response to an activate request.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
</event>
<event name="leave">
<description summary="leave event">
Notify the text_input object when it lost focus. Either in response
to a deactivate request or when the assigned surface lost focus or was
destroyed.
</description>
</event>
<event name="modifiers_map">
<description summary="modifiers map">
Transfer an array of 0-terminated modifier names. The position in
the array is the index of the modifier as used in the modifiers
bitmask in the keysym event.
</description>
<arg name="map" type="array"/>
</event>
<event name="input_panel_state">
<description summary="state of the input panel">
Notify when the visibility state of the input panel changed.
</description>
<arg name="state" type="uint"/>
</event>
<event name="preedit_string">
<description summary="pre-edit">
Notify when a new composing text (pre-edit) should be set around the
current cursor position. Any previously set composing text should
be removed.
The commit text can be used to replace the preedit text on reset
(for example on unfocus).
The text input should also handle all preedit_style and preedit_cursor
events occurring directly before preedit_string.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="text" type="string"/>
<arg name="commit" type="string"/>
</event>
<enum name="preedit_style">
<entry name="default" value="0" summary="default style for composing text"/>
<entry name="none" value="1" summary="style should be the same as in non-composing text"/>
<entry name="active" value="2"/>
<entry name="inactive" value="3"/>
<entry name="highlight" value="4"/>
<entry name="underline" value="5"/>
<entry name="selection" value="6"/>
<entry name="incorrect" value="7"/>
</enum>
<event name="preedit_styling">
<description summary="pre-edit styling">
Sets styling information on composing text. The style is applied for
length bytes from index relative to the beginning of the composing
text (as byte offset). Multiple styles can
be applied to a composing text by sending multiple preedit_styling
events.
This event is handled as part of a following preedit_string event.
</description>
<arg name="index" type="uint"/>
<arg name="length" type="uint"/>
<arg name="style" type="uint" enum="preedit_style" />
</event>
<event name="preedit_cursor">
<description summary="pre-edit cursor">
Sets the cursor position inside the composing text (as byte
offset) relative to the start of the composing text. When index is a
negative number no cursor is shown.
This event is handled as part of a following preedit_string event.
</description>
<arg name="index" type="int"/>
</event>
<event name="commit_string">
<description summary="commit">
Notify when text should be inserted into the editor widget. The text to
commit could be either just a single character after a key press or the
result of some composing (pre-edit). It could also be an empty text
when some text should be removed (see delete_surrounding_text) or when
the input cursor should be moved (see cursor_position).
Any previously set composing text should be removed.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="text" type="string"/>
</event>
<event name="cursor_position">
<description summary="set cursor to new position">
Notify when the cursor or anchor position should be modified.
This event should be handled as part of a following commit_string
event.
</description>
<arg name="index" type="int"/>
<arg name="anchor" type="int"/>
</event>
<event name="delete_surrounding_text">
<description summary="delete surrounding text">
Notify when the text around the current cursor position should be
deleted.
Index is relative to the current cursor (in bytes).
Length is the length of deleted text (in bytes).
This event should be handled as part of a following commit_string
event.
</description>
<arg name="index" type="int"/>
<arg name="length" type="uint"/>
</event>
<event name="keysym">
<description summary="keysym">
Notify when a key event was sent. Key events should not be used
for normal text input operations, which should be done with
commit_string, delete_surrounding_text, etc. The key event follows
the wl_keyboard key event convention. Sym is an XKB keysym, state a
wl_keyboard key_state. Modifiers are a mask for effective modifiers
(where the modifier indices are set by the modifiers_map event)
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="time" type="uint"/>
<arg name="sym" type="uint"/>
<arg name="state" type="uint"/>
<arg name="modifiers" type="uint"/>
</event>
<event name="language">
<description summary="language">
Sets the language of the input text. The "language" argument is an
RFC-3066 format language tag.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="language" type="string"/>
</event>
<enum name="text_direction">
<entry name="auto" value="0" summary="automatic text direction based on text and language"/>
<entry name="ltr" value="1" summary="left-to-right"/>
<entry name="rtl" value="2" summary="right-to-left"/>
</enum>
<event name="text_direction">
<description summary="text direction">
Sets the text direction of input text.
It is mainly needed for showing an input cursor on the correct side of
the editor when there is no input done yet and making sure neutral
direction text is laid out properly.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="direction" type="uint" enum="text_direction" />
</event>
</interface>
<interface name="zwp_text_input_manager_v1" version="1">
<description summary="text input manager">
A factory for text_input objects. This object is a global singleton.
</description>
<request name="create_text_input">
<description summary="create text input">
Creates a new text_input object.
</description>
<arg name="id" type="new_id" interface="zwp_text_input_v1"/>
</request>
</interface>
</protocol>

452
third-party/vendor/wayland-protocols/protocols/unstable/text-input/text-input-unstable-v3.xml vendored Normal file
View file

@ -0,0 +1,452 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="text_input_unstable_v3">
<copyright>
Copyright © 2012, 2013 Intel Corporation
Copyright © 2015, 2016 Jan Arne Petersen
Copyright © 2017, 2018 Red Hat, Inc.
Copyright © 2018 Purism SPC
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.
</copyright>
<description summary="Protocol for composing text">
This protocol allows compositors to act as input methods and to send text
to applications. A text input object is used to manage state of what are
typically text entry fields in the application.
This document adheres to the RFC 2119 when using words like "must",
"should", "may", etc.
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_text_input_v3" version="1">
<description summary="text input">
The zwp_text_input_v3 interface represents text input and input methods
associated with a seat. It provides enter/leave events to follow the
text input focus for a seat.
Requests are used to enable/disable the text-input object and set
state information like surrounding and selected text or the content type.
The information about the entered text is sent to the text-input object
via the preedit_string and commit_string events.
Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
must not point to middle bytes inside a code point: they must either
point to the first byte of a code point or to the end of the buffer.
Lengths must be measured between two valid indices.
Focus moving throughout surfaces will result in the emission of
zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
surface must commit zwp_text_input_v3.enable and
zwp_text_input_v3.disable requests as the keyboard focus moves across
editable and non-editable elements of the UI. Those two requests are not
expected to be paired with each other, the compositor must be able to
handle consecutive series of the same request.
State is sent by the state requests (set_surrounding_text,
set_content_type and set_cursor_rectangle) and a commit request. After an
enter event or disable request all state information is invalidated and
needs to be resent by the client.
</description>
<request name="destroy" type="destructor">
<description summary="Destroy the wp_text_input">
Destroy the wp_text_input object. Also disables all surfaces enabled
through this wp_text_input object.
</description>
</request>
<request name="enable">
<description summary="Request text input to be enabled">
Requests text input on the surface previously obtained from the enter
event.
This request must be issued every time the active text input changes
to a new one, including within the current surface. Use
zwp_text_input_v3.disable when there is no longer any input focus on
the current surface.
Clients must not enable more than one text input on the single seat
and should disable the current text input before enabling the new one.
At most one instance of text input may be in enabled state per instance,
Requests to enable the another text input when some text input is active
must be ignored by compositor.
This request resets all state associated with previous enable, disable,
set_surrounding_text, set_text_change_cause, set_content_type, and
set_cursor_rectangle requests, as well as the state associated with
preedit_string, commit_string, and delete_surrounding_text events.
The set_surrounding_text, set_content_type and set_cursor_rectangle
requests must follow if the text input supports the necessary
functionality.
State set with this request is double-buffered. It will get applied on
the next zwp_text_input_v3.commit request, and stay valid until the
next committed enable or disable request.
The changes must be applied by the compositor after issuing a
zwp_text_input_v3.commit request.
</description>
</request>
<request name="disable">
<description summary="Disable text input on a surface">
Explicitly disable text input on the current surface (typically when
there is no focus on any text entry inside the surface).
State set with this request is double-buffered. It will get applied on
the next zwp_text_input_v3.commit request.
</description>
</request>
<request name="set_surrounding_text">
<description summary="sets the surrounding text">
Sets the surrounding plain text around the input, excluding the preedit
text.
The client should notify the compositor of any changes in any of the
values carried with this request, including changes caused by handling
incoming text-input events as well as changes caused by other
mechanisms like keyboard typing.
If the client is unaware of the text around the cursor, it should not
issue this request, to signify lack of support to the compositor.
Text is UTF-8 encoded, and should include the cursor position, the
complete selection and additional characters before and after them.
There is a maximum length of wayland messages, so text can not be
longer than 4000 bytes.
Cursor is the byte offset of the cursor within text buffer.
Anchor is the byte offset of the selection anchor within text buffer.
If there is no selected text, anchor is the same as cursor.
If any preedit text is present, it is replaced with a cursor for the
purpose of this event.
Values set with this request are double-buffered. They will get applied
on the next zwp_text_input_v3.commit request, and stay valid until the
next committed enable or disable request.
The initial state for affected fields is empty, meaning that the text
input does not support sending surrounding text. If the empty values
get applied, subsequent attempts to change them may have no effect.
</description>
<arg name="text" type="string"/>
<arg name="cursor" type="int"/>
<arg name="anchor" type="int"/>
</request>
<enum name="change_cause">
<description summary="text change reason">
Reason for the change of surrounding text or cursor posision.
</description>
<entry name="input_method" value="0" summary="input method caused the change"/>
<entry name="other" value="1" summary="something else than the input method caused the change"/>
</enum>
<request name="set_text_change_cause">
<description summary="indicates the cause of surrounding text change">
Tells the compositor why the text surrounding the cursor changed.
Whenever the client detects an external change in text, cursor, or
anchor posision, it must issue this request to the compositor. This
request is intended to give the input method a chance to update the
preedit text in an appropriate way, e.g. by removing it when the user
starts typing with a keyboard.
cause describes the source of the change.
The value set with this request is double-buffered. It must be applied
and reset to initial at the next zwp_text_input_v3.commit request.
The initial value of cause is input_method.
</description>
<arg name="cause" type="uint" enum="change_cause"/>
</request>
<enum name="content_hint" bitfield="true">
<description summary="content hint">
Content hint is a bitmask to allow to modify the behavior of the text
input.
</description>
<entry name="none" value="0x0" summary="no special behavior"/>
<entry name="completion" value="0x1" summary="suggest word completions"/>
<entry name="spellcheck" value="0x2" summary="suggest word corrections"/>
<entry name="auto_capitalization" value="0x4" summary="switch to uppercase letters at the start of a sentence"/>
<entry name="lowercase" value="0x8" summary="prefer lowercase letters"/>
<entry name="uppercase" value="0x10" summary="prefer uppercase letters"/>
<entry name="titlecase" value="0x20" summary="prefer casing for titles and headings (can be language dependent)"/>
<entry name="hidden_text" value="0x40" summary="characters should be hidden"/>
<entry name="sensitive_data" value="0x80" summary="typed text should not be stored"/>
<entry name="latin" value="0x100" summary="just Latin characters should be entered"/>
<entry name="multiline" value="0x200" summary="the text input is multiline"/>
</enum>
<enum name="content_purpose">
<description summary="content purpose">
The content purpose allows to specify the primary purpose of a text
input.
This allows an input method to show special purpose input panels with
extra characters or to disallow some characters.
</description>
<entry name="normal" value="0" summary="default input, allowing all characters"/>
<entry name="alpha" value="1" summary="allow only alphabetic characters"/>
<entry name="digits" value="2" summary="allow only digits"/>
<entry name="number" value="3" summary="input a number (including decimal separator and sign)"/>
<entry name="phone" value="4" summary="input a phone number"/>
<entry name="url" value="5" summary="input an URL"/>
<entry name="email" value="6" summary="input an email address"/>
<entry name="name" value="7" summary="input a name of a person"/>
<entry name="password" value="8" summary="input a password (combine with sensitive_data hint)"/>
<entry name="pin" value="9" summary="input is a numeric password (combine with sensitive_data hint)"/>
<entry name="date" value="10" summary="input a date"/>
<entry name="time" value="11" summary="input a time"/>
<entry name="datetime" value="12" summary="input a date and time"/>
<entry name="terminal" value="13" summary="input for a terminal"/>
</enum>
<request name="set_content_type">
<description summary="set content purpose and hint">
Sets the content purpose and content hint. While the purpose is the
basic purpose of an input field, the hint flags allow to modify some of
the behavior.
Values set with this request are double-buffered. They will get applied
on the next zwp_text_input_v3.commit request.
Subsequent attempts to update them may have no effect. The values
remain valid until the next committed enable or disable request.
The initial value for hint is none, and the initial value for purpose
is normal.
</description>
<arg name="hint" type="uint" enum="content_hint"/>
<arg name="purpose" type="uint" enum="content_purpose"/>
</request>
<request name="set_cursor_rectangle">
<description summary="set cursor position">
Marks an area around the cursor as a x, y, width, height rectangle in
surface local coordinates.
Allows the compositor to put a window with word suggestions near the
cursor, without obstructing the text being input.
If the client is unaware of the position of edited text, it should not
issue this request, to signify lack of support to the compositor.
Values set with this request are double-buffered. They will get applied
on the next zwp_text_input_v3.commit request, and stay valid until the
next committed enable or disable request.
The initial values describing a cursor rectangle are empty. That means
the text input does not support describing the cursor area. If the
empty values get applied, subsequent attempts to change them may have
no effect.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</request>
<request name="commit">
<description summary="commit state">
Atomically applies state changes recently sent to the compositor.
The commit request establishes and updates the state of the client, and
must be issued after any changes to apply them.
Text input state (enabled status, content purpose, content hint,
surrounding text and change cause, cursor rectangle) is conceptually
double-buffered within the context of a text input, i.e. between a
committed enable request and the following committed enable or disable
request.
Protocol requests modify the pending state, as opposed to the current
state in use by the input method. A commit request atomically applies
all pending state, replacing the current state. After commit, the new
pending state is as documented for each related request.
Requests are applied in the order of arrival.
Neither current nor pending state are modified unless noted otherwise.
The compositor must count the number of commit requests coming from
each zwp_text_input_v3 object and use the count as the serial in done
events.
</description>
</request>
<event name="enter">
<description summary="enter event">
Notification that this seat's text-input focus is on a certain surface.
If client has created multiple text input objects, compositor must send
this event to all of them.
When the seat has the keyboard capability the text-input focus follows
the keyboard focus. This event sets the current surface for the
text-input object.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
</event>
<event name="leave">
<description summary="leave event">
Notification that this seat's text-input focus is no longer on a
certain surface. The client should reset any preedit string previously
set.
The leave notification clears the current surface. It is sent before
the enter notification for the new focus. After leave event, compositor
must ignore requests from any text input instances until next enter
event.
When the seat has the keyboard capability the text-input focus follows
the keyboard focus.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
</event>
<event name="preedit_string">
<description summary="pre-edit">
Notify when a new composing text (pre-edit) should be set at the
current cursor position. Any previously set composing text must be
removed. Any previously existing selected text must be removed.
The argument text contains the pre-edit string buffer.
The parameters cursor_begin and cursor_end are counted in bytes
relative to the beginning of the submitted text buffer. Cursor should
be hidden when both are equal to -1.
They could be represented by the client as a line if both values are
the same, or as a text highlight otherwise.
Values set with this event are double-buffered. They must be applied
and reset to initial on the next zwp_text_input_v3.done event.
The initial value of text is an empty string, and cursor_begin,
cursor_end and cursor_hidden are all 0.
</description>
<arg name="text" type="string" allow-null="true"/>
<arg name="cursor_begin" type="int"/>
<arg name="cursor_end" type="int"/>
</event>
<event name="commit_string">
<description summary="text commit">
Notify when text should be inserted into the editor widget. The text to
commit could be either just a single character after a key press or the
result of some composing (pre-edit).
Values set with this event are double-buffered. They must be applied
and reset to initial on the next zwp_text_input_v3.done event.
The initial value of text is an empty string.
</description>
<arg name="text" type="string" allow-null="true"/>
</event>
<event name="delete_surrounding_text">
<description summary="delete surrounding text">
Notify when the text around the current cursor position should be
deleted.
Before_length and after_length are the number of bytes before and after
the current cursor index (excluding the selection) to delete.
If a preedit text is present, in effect before_length is counted from
the beginning of it, and after_length from its end (see done event
sequence).
Values set with this event are double-buffered. They must be applied
and reset to initial on the next zwp_text_input_v3.done event.
The initial values of both before_length and after_length are 0.
</description>
<arg name="before_length" type="uint" summary="length of text before current cursor position"/>
<arg name="after_length" type="uint" summary="length of text after current cursor position"/>
</event>
<event name="done">
<description summary="apply changes">
Instruct the application to apply changes to state requested by the
preedit_string, commit_string and delete_surrounding_text events. The
state relating to these events is double-buffered, and each one
modifies the pending state. This event replaces the current state with
the pending state.
The application must proceed by evaluating the changes in the following
order:
1. Replace existing preedit string with the cursor.
2. Delete requested surrounding text.
3. Insert commit string with the cursor at its end.
4. Calculate surrounding text to send.
5. Insert new preedit text in cursor position.
6. Place cursor inside preedit text.
The serial number reflects the last state of the zwp_text_input_v3
object known to the compositor. The value of the serial argument must
be equal to the number of commit requests already issued on that object.
When the client receives a done event with a serial different than the
number of past commit requests, it must proceed as normal, except it
should not change the current state of the zwp_text_input_v3 object.
</description>
<arg name="serial" type="uint"/>
</event>
</interface>
<interface name="zwp_text_input_manager_v3" version="1">
<description summary="text input manager">
A factory for text-input objects. This object is a global singleton.
</description>
<request name="destroy" type="destructor">
<description summary="Destroy the wp_text_input_manager">
Destroy the wp_text_input_manager object.
</description>
</request>
<request name="get_text_input">
<description summary="create a new text input object">
Creates a new text-input object for a given seat.
</description>
<arg name="id" type="new_id" interface="zwp_text_input_v3"/>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/xdg-decoration/README vendored Normal file
View file

@ -0,0 +1,4 @@
xdg_decoration protocol
Maintainers:
Simon Ser <contact@emersion.fr>

156
third-party/vendor/wayland-protocols/protocols/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml vendored Normal file
View file

@ -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>

4
third-party/vendor/wayland-protocols/protocols/unstable/xdg-foreign/README vendored Normal file
View file

@ -0,0 +1,4 @@
xdg foreign protocol
Maintainers:
Jonas Ådahl <jadahl@gmail.com>

182
third-party/vendor/wayland-protocols/protocols/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,182 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="xdg_foreign_unstable_v1">
<copyright>
Copyright © 2015-2016 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 exporting xdg surface handles">
This protocol specifies a way for making it possible to reference a surface
of a different client. With such a reference, a client can, by using the
interfaces provided by this protocol, manipulate the relationship between
its own surfaces and the surface of some other client. For example, stack
some of its own surface above the other clients surface.
In order for a client A to get a reference of a surface of client B, client
B must first export its surface using xdg_exporter.export. Upon doing this,
client B will receive a handle (a unique string) that it may share with
client A in some way (for example D-Bus). After client A has received the
handle from client B, it may use xdg_importer.import to create a reference
to the surface client B just exported. See the corresponding requests for
details.
A possible use case for this is out-of-process dialogs. For example when a
sandboxed client without file system access needs the user to select a file
on the file system, given sandbox environment support, it can export its
surface, passing the exported surface handle to an unsandboxed process that
can show a file browser dialog and stack it above the sandboxed client's
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>
<interface name="zxdg_exporter_v1" version="1">
<description summary="interface for exporting surfaces">
A global interface used for exporting surfaces that can later be imported
using xdg_importer.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_exporter object">
Notify the compositor that the xdg_exporter object will no longer be
used.
</description>
</request>
<request name="export">
<description summary="export a surface">
The export request exports the passed surface so that it can later be
imported via xdg_importer. When called, a new xdg_exported object will
be created and xdg_exported.handle will be sent immediately. See the
corresponding interface and event for details.
A surface may be exported multiple times, and each exported handle may
be used to create an xdg_imported multiple times. Only xdg_surface
surfaces may be exported.
</description>
<arg name="id" type="new_id" interface="zxdg_exported_v1"
summary="the new xdg_exported object"/>
<arg name="surface" type="object" interface="wl_surface"
summary="the surface to export"/>
</request>
</interface>
<interface name="zxdg_importer_v1" version="1">
<description summary="interface for importing surfaces">
A global interface used for importing surfaces exported by xdg_exporter.
With this interface, a client can create a reference to a surface of
another client.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_importer object">
Notify the compositor that the xdg_importer object will no longer be
used.
</description>
</request>
<request name="import">
<description summary="import a surface">
The import request imports a surface from any client given a handle
retrieved by exporting said surface using xdg_exporter.export. When
called, a new xdg_imported object will be created. This new object
represents the imported surface, and the importing client can
manipulate its relationship using it. See xdg_imported for details.
</description>
<arg name="id" type="new_id" interface="zxdg_imported_v1"
summary="the new xdg_imported object"/>
<arg name="handle" type="string"
summary="the exported surface handle"/>
</request>
</interface>
<interface name="zxdg_exported_v1" version="1">
<description summary="an exported surface handle">
An xdg_exported object represents an exported reference to a surface. The
exported surface may be referenced as long as the xdg_exported object not
destroyed. Destroying the xdg_exported invalidates any relationship the
importer may have established using xdg_imported.
</description>
<request name="destroy" type="destructor">
<description summary="unexport the exported surface">
Revoke the previously exported surface. This invalidates any
relationship the importer may have set up using the xdg_imported created
given the handle sent via xdg_exported.handle.
</description>
</request>
<event name="handle">
<description summary="the exported surface handle">
The handle event contains the unique handle of this exported surface
reference. It may be shared with any client, which then can use it to
import the surface by calling xdg_importer.import. A handle may be
used to import the surface multiple times.
</description>
<arg name="handle" type="string" summary="the exported surface handle"/>
</event>
</interface>
<interface name="zxdg_imported_v1" version="1">
<description summary="an imported surface handle">
An xdg_imported object represents an imported reference to surface exported
by some client. A client can use this interface to manipulate
relationships between its own surfaces and the imported surface.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_imported object">
Notify the compositor that it will no longer use the xdg_imported
object. Any relationship that may have been set up will at this point
be invalidated.
</description>
</request>
<request name="set_parent_of">
<description summary="set as the parent of some surface">
Set the imported surface as the parent of some surface of the client.
The passed surface must be a toplevel xdg_surface. Calling this function
sets up a surface to surface relation with the same stacking and positioning
semantics as xdg_surface.set_parent.
</description>
<arg name="surface" type="object" interface="wl_surface"
summary="the child surface"/>
</request>
<event name="destroyed">
<description summary="the imported surface handle has been destroyed">
The imported surface handle has been destroyed and any relationship set
up has been invalidated. This may happen for various reasons, for
example if the exported surface or the exported surface handle has been
destroyed, if the handle used for importing was invalid.
</description>
</event>
</interface>
</protocol>

200
third-party/vendor/wayland-protocols/protocols/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml vendored Normal file
View file

@ -0,0 +1,200 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="xdg_foreign_unstable_v2">
<copyright>
Copyright © 2015-2016 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 exporting xdg surface handles">
This protocol specifies a way for making it possible to reference a surface
of a different client. With such a reference, a client can, by using the
interfaces provided by this protocol, manipulate the relationship between
its own surfaces and the surface of some other client. For example, stack
some of its own surface above the other clients surface.
In order for a client A to get a reference of a surface of client B, client
B must first export its surface using xdg_exporter.export_toplevel. Upon
doing this, client B will receive a handle (a unique string) that it may
share with client A in some way (for example D-Bus). After client A has
received the handle from client B, it may use xdg_importer.import_toplevel
to create a reference to the surface client B just exported. See the
corresponding requests for details.
A possible use case for this is out-of-process dialogs. For example when a
sandboxed client without file system access needs the user to select a file
on the file system, given sandbox environment support, it can export its
surface, passing the exported surface handle to an unsandboxed process that
can show a file browser dialog and stack it above the sandboxed client's
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>
<interface name="zxdg_exporter_v2" version="1">
<description summary="interface for exporting surfaces">
A global interface used for exporting surfaces that can later be imported
using xdg_importer.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_exporter object">
Notify the compositor that the xdg_exporter object will no longer be
used.
</description>
</request>
<enum name="error">
<description summary="error values">
These errors can be emitted in response to invalid xdg_exporter
requests.
</description>
<entry name="invalid_surface" value="0" summary="surface is not an xdg_toplevel"/>
</enum>
<request name="export_toplevel">
<description summary="export a toplevel surface">
The export_toplevel request exports the passed surface so that it can later be
imported via xdg_importer. When called, a new xdg_exported object will
be created and xdg_exported.handle will be sent immediately. See the
corresponding interface and event for details.
A surface may be exported multiple times, and each exported handle may
be used to create an xdg_imported multiple times. Only xdg_toplevel
equivalent surfaces may be exported, otherwise an invalid_surface
protocol error is sent.
</description>
<arg name="id" type="new_id" interface="zxdg_exported_v2"
summary="the new xdg_exported object"/>
<arg name="surface" type="object" interface="wl_surface"
summary="the surface to export"/>
</request>
</interface>
<interface name="zxdg_importer_v2" version="1">
<description summary="interface for importing surfaces">
A global interface used for importing surfaces exported by xdg_exporter.
With this interface, a client can create a reference to a surface of
another client.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_importer object">
Notify the compositor that the xdg_importer object will no longer be
used.
</description>
</request>
<request name="import_toplevel">
<description summary="import a toplevel surface">
The import_toplevel request imports a surface from any client given a handle
retrieved by exporting said surface using xdg_exporter.export_toplevel.
When called, a new xdg_imported object will be created. This new object
represents the imported surface, and the importing client can
manipulate its relationship using it. See xdg_imported for details.
</description>
<arg name="id" type="new_id" interface="zxdg_imported_v2"
summary="the new xdg_imported object"/>
<arg name="handle" type="string"
summary="the exported surface handle"/>
</request>
</interface>
<interface name="zxdg_exported_v2" version="1">
<description summary="an exported surface handle">
An xdg_exported object represents an exported reference to a surface. The
exported surface may be referenced as long as the xdg_exported object not
destroyed. Destroying the xdg_exported invalidates any relationship the
importer may have established using xdg_imported.
</description>
<request name="destroy" type="destructor">
<description summary="unexport the exported surface">
Revoke the previously exported surface. This invalidates any
relationship the importer may have set up using the xdg_imported created
given the handle sent via xdg_exported.handle.
</description>
</request>
<event name="handle">
<description summary="the exported surface handle">
The handle event contains the unique handle of this exported surface
reference. It may be shared with any client, which then can use it to
import the surface by calling xdg_importer.import_toplevel. A handle
may be used to import the surface multiple times.
</description>
<arg name="handle" type="string" summary="the exported surface handle"/>
</event>
</interface>
<interface name="zxdg_imported_v2" version="1">
<description summary="an imported surface handle">
An xdg_imported object represents an imported reference to surface exported
by some client. A client can use this interface to manipulate
relationships between its own surfaces and the imported surface.
</description>
<enum name="error">
<description summary="error values">
These errors can be emitted in response to invalid xdg_imported
requests.
</description>
<entry name="invalid_surface" value="0" summary="surface is not an xdg_toplevel"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_imported object">
Notify the compositor that it will no longer use the xdg_imported
object. Any relationship that may have been set up will at this point
be invalidated.
</description>
</request>
<request name="set_parent_of">
<description summary="set as the parent of some surface">
Set the imported surface as the parent of some surface of the client.
The passed surface must be an xdg_toplevel equivalent, otherwise an
invalid_surface protocol error is sent. Calling this function sets up
a surface to surface relation with the same stacking and positioning
semantics as xdg_toplevel.set_parent.
</description>
<arg name="surface" type="object" interface="wl_surface"
summary="the child surface"/>
</request>
<event name="destroyed">
<description summary="the imported surface handle has been destroyed">
The imported surface handle has been destroyed and any relationship set
up has been invalidated. This may happen for various reasons, for
example if the exported surface or the exported surface handle has been
destroyed, if the handle used for importing was invalid.
</description>
</event>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/xdg-output/README vendored Normal file
View file

@ -0,0 +1,4 @@
xdg_output protocol
Maintainers:
Olivier Fourdan <ofourdan@redhat.com>

220
third-party/vendor/wayland-protocols/protocols/unstable/xdg-output/xdg-output-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,220 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="xdg_output_unstable_v1">
<copyright>
Copyright © 2017 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 to describe output regions">
This protocol aims at describing outputs in a way which is more in line
with the concept of an output on desktop oriented systems.
Some information are more specific to the concept of an output for
a desktop oriented system and may not make sense in other applications,
such as IVI systems for example.
Typically, the global compositor space on a desktop system is made of
a contiguous or overlapping set of rectangular regions.
Some of the information provided in this protocol might be identical
to their counterparts already available from wl_output, in which case
the information provided by this protocol should be preferred to their
equivalent in wl_output. The goal is to move the desktop specific
concepts (such as output location within the global compositor space,
the connector name and types, etc.) out of the core wl_output protocol.
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="zxdg_output_manager_v1" version="3">
<description summary="manage xdg_output objects">
A global factory interface for xdg_output objects.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_output_manager object">
Using this request a client can tell the server that it is not
going to use the xdg_output_manager object anymore.
Any objects already created through this instance are not affected.
</description>
</request>
<request name="get_xdg_output">
<description summary="create an xdg output from a wl_output">
This creates a new xdg_output object for the given wl_output.
</description>
<arg name="id" type="new_id" interface="zxdg_output_v1"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
</interface>
<interface name="zxdg_output_v1" version="3">
<description summary="compositor logical output region">
An xdg_output describes part of the compositor geometry.
This typically corresponds to a monitor that displays part of the
compositor space.
For objects version 3 onwards, after all xdg_output properties have been
sent (when the object is created and when properties are updated), a
wl_output.done event is sent. This allows changes to the output
properties to be seen as atomic, even if they happen via multiple events.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the xdg_output object">
Using this request a client can tell the server that it is not
going to use the xdg_output object anymore.
</description>
</request>
<event name="logical_position">
<description summary="position of the output within the global compositor space">
The position event describes the location of the wl_output within
the global compositor space.
The logical_position event is sent after creating an xdg_output
(see xdg_output_manager.get_xdg_output) and whenever the location
of the output changes within the global compositor space.
</description>
<arg name="x" type="int"
summary="x position within the global compositor space"/>
<arg name="y" type="int"
summary="y position within the global compositor space"/>
</event>
<event name="logical_size">
<description summary="size of the output in the global compositor space">
The logical_size event describes the size of the output in the
global compositor space.
For example, a surface without any buffer scale, transformation
nor rotation set, with the size matching the logical_size will
have the same size as the corresponding output when displayed.
Most regular Wayland clients should not pay attention to the
logical size and would rather rely on xdg_shell interfaces.
Some clients such as Xwayland, however, need this to configure
their surfaces in the global compositor space as the compositor
may apply a different scale from what is advertised by the output
scaling property (to achieve fractional scaling, for example).
For example, for a wl_output mode 3840×2160 and a scale factor 2:
- A compositor not scaling the surface buffers will advertise a
logical size of 3840×2160,
- A compositor automatically scaling the surface buffers will
advertise a logical size of 1920×1080,
- A compositor using a fractional scale of 1.5 will advertise a
logical size to 2560×1620.
For example, for a wl_output mode 1920×1080 and a 90 degree rotation,
the compositor will advertise a logical size of 1080x1920.
The logical_size event is sent after creating an xdg_output
(see xdg_output_manager.get_xdg_output) and whenever the logical
size of the output changes, either as a result of a change in the
applied scale or because of a change in the corresponding output
mode(see wl_output.mode) or transform (see wl_output.transform).
</description>
<arg name="width" type="int"
summary="width in global compositor space"/>
<arg name="height" type="int"
summary="height in global compositor space"/>
</event>
<event name="done">
<description summary="all information about the output have been sent">
This event is sent after all other properties of an xdg_output
have been sent.
This allows changes to the xdg_output properties to be seen as
atomic, even if they happen via multiple events.
For objects version 3 onwards, this event is deprecated. Compositors
are not required to send it anymore and must send wl_output.done
instead.
</description>
</event>
<!-- Version 2 additions -->
<event name="name" since="2">
<description summary="name of this output">
Many compositors will assign names to their outputs, show them to the
user, allow them to be configured by name, etc. The client may wish to
know this name as well to offer the user similar behaviors.
The naming convention is compositor defined, but limited to
alphanumeric characters and dashes (-). Each name is unique among all
wl_output globals, but if a wl_output global is destroyed the same name
may be reused later. The names will also remain consistent across
sessions with the same hardware and software configuration.
Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do
not assume that the name is a reflection of an underlying DRM
connector, X11 connection, etc.
The name event is sent after creating an xdg_output (see
xdg_output_manager.get_xdg_output). This event is only sent once per
xdg_output, and the name does not change over the lifetime of the
wl_output global.
</description>
<arg name="name" type="string" summary="output name"/>
</event>
<event name="description" since="2">
<description summary="human-readable description of this output">
Many compositors can produce human-readable descriptions of their
outputs. The client may wish to know this description as well, to
communicate the user for various purposes.
The description is a UTF-8 string with no convention defined for its
contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11
output via :1'.
The description event is sent after creating an xdg_output (see
xdg_output_manager.get_xdg_output) and whenever the description
changes. The description is optional, and may not be sent at all.
For objects of version 2 and lower, this event is only sent once per
xdg_output, and the description does not change over the lifetime of
the wl_output global.
</description>
<arg name="description" type="string" summary="output description"/>
</event>
</interface>
</protocol>

4
third-party/vendor/wayland-protocols/protocols/unstable/xdg-shell/README vendored Normal file
View file

@ -0,0 +1,4 @@
xdg shell protocol
Maintainers:
Jasper St. Pierre <jstpierre@mecheye.net>

623
third-party/vendor/wayland-protocols/protocols/unstable/xdg-shell/xdg-shell-unstable-v5.xml vendored Normal file
View file

@ -0,0 +1,623 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="xdg_shell_unstable_v5">
<copyright>
Copyright © 2008-2013 Kristian Høgsberg
Copyright © 2013 Rafael Antognolli
Copyright © 2013 Jasper St. Pierre
Copyright © 2010-2013 Intel Corporation
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
</copyright>
<interface name="xdg_shell" version="1">
<description summary="create desktop-style surfaces">
xdg_shell allows clients to turn a wl_surface into a "real window"
which can be dragged, resized, stacked, and moved around by the
user. Everything about this interface is suited towards traditional
desktop environments.
</description>
<enum name="version">
<description summary="latest protocol version">
The 'current' member of this enum gives the version of the
protocol. Implementations can compare this to the version
they implement using static_assert to ensure the protocol and
implementation versions match.
</description>
<entry name="current" value="5" summary="Always the latest version"/>
</enum>
<enum name="error">
<entry name="role" value="0" summary="given wl_surface has another role"/>
<entry name="defunct_surfaces" value="1" summary="xdg_shell was destroyed before children"/>
<entry name="not_the_topmost_popup" value="2" summary="the client tried to map or destroy a non-topmost popup"/>
<entry name="invalid_popup_parent" value="3" summary="the client specified an invalid popup parent surface"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroy xdg_shell">
Destroy this xdg_shell object.
Destroying a bound xdg_shell object while there are surfaces
still alive created by this xdg_shell object instance is illegal
and will result in a protocol error.
</description>
</request>
<request name="use_unstable_version">
<description summary="enable use of this unstable version">
Negotiate the unstable version of the interface. This
mechanism is in place to ensure client and server agree on the
unstable versions of the protocol that they speak or exit
cleanly if they don't agree. This request will go away once
the xdg-shell protocol is stable.
</description>
<arg name="version" type="int"/>
</request>
<request name="get_xdg_surface">
<description summary="create a shell surface from a surface">
This creates an xdg_surface for the given surface and gives it the
xdg_surface role. A wl_surface can only be given an xdg_surface role
once. If get_xdg_surface is called with a wl_surface that already has
an active xdg_surface associated with it, or if it had any other role,
an error is raised.
See the documentation of xdg_surface for more details about what an
xdg_surface is and how it is used.
</description>
<arg name="id" type="new_id" interface="xdg_surface"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="get_xdg_popup">
<description summary="create a popup for a surface">
This creates an xdg_popup for the given surface and gives it the
xdg_popup role. A wl_surface can only be given an xdg_popup role
once. If get_xdg_popup is called with a wl_surface that already has
an active xdg_popup associated with it, or if it had any other role,
an error is raised.
This request must be used in response to some sort of user action
like a button press, key press, or touch down event.
See the documentation of xdg_popup for more details about what an
xdg_popup is and how it is used.
</description>
<arg name="id" type="new_id" interface="xdg_popup"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="parent" type="object" interface="wl_surface"/>
<arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
<arg name="serial" type="uint" summary="the serial of the user event"/>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
</request>
<event name="ping">
<description summary="check if the client is alive">
The ping event asks the client if it's still alive. Pass the
serial specified in the event back to the compositor by sending
a "pong" request back with the specified serial.
Compositors can use this to determine if the client is still
alive. It's unspecified what will happen if the client doesn't
respond to the ping request, or in what timeframe. Clients should
try to respond in a reasonable amount of time.
A compositor is free to ping in any way it wants, but a client must
always respond to any xdg_shell object it created.
</description>
<arg name="serial" type="uint" summary="pass this to the pong request"/>
</event>
<request name="pong">
<description summary="respond to a ping event">
A client must respond to a ping event with a pong request or
the client may be deemed unresponsive.
</description>
<arg name="serial" type="uint" summary="serial of the ping event"/>
</request>
</interface>
<interface name="xdg_surface" version="1">
<description summary="A desktop window">
An interface that may be implemented by a wl_surface, for
implementations that provide a desktop-style user interface.
It provides requests to treat surfaces like windows, allowing to set
properties like maximized, fullscreen, minimized, and to move and resize
them, and associate metadata like title and app id.
The client must call wl_surface.commit on the corresponding wl_surface
for the xdg_surface state to take effect. Prior to committing the new
state, it can set up initial configuration, such as maximizing or setting
a window geometry.
Even without attaching a buffer the compositor must respond to initial
committed configuration, for instance sending a configure event with
expected window geometry if the client maximized its surface during
initialization.
For a surface to be mapped by the compositor the client must have
committed both an xdg_surface state and a buffer.
</description>
<request name="destroy" type="destructor">
<description summary="Destroy the xdg_surface">
Unmap and destroy the window. The window will be effectively
hidden from the user's point of view, and all state like
maximization, fullscreen, and so on, will be lost.
</description>
</request>
<request name="set_parent">
<description summary="set the parent of this surface">
Set the "parent" of this surface. This window should be stacked
above a parent. The parent surface must be mapped as long as this
surface is mapped.
Parent windows should be set on dialogs, toolboxes, or other
"auxiliary" surfaces, so that the parent is raised when the dialog
is raised.
</description>
<arg name="parent" type="object" interface="xdg_surface" allow-null="true"/>
</request>
<request name="set_title">
<description summary="set surface title">
Set a short title for the surface.
This string may be used to identify the surface in a task bar,
window list, or other user interface elements provided by the
compositor.
The string must be encoded in UTF-8.
</description>
<arg name="title" type="string"/>
</request>
<request name="set_app_id">
<description summary="set application ID">
Set an application identifier for the surface.
The app ID identifies the general class of applications to which
the surface belongs. The compositor can use this to group multiple
surfaces together, or to determine how to launch a new application.
For D-Bus activatable applications, the app ID is used as the D-Bus
service name.
The compositor shell will try to group application surfaces together
by their app ID. As a best practice, it is suggested to select app
ID's that match the basename of the application's .desktop file.
For example, "org.freedesktop.FooViewer" where the .desktop file is
"org.freedesktop.FooViewer.desktop".
See the desktop-entry specification [0] for more details on
application identifiers and how they relate to well-known D-Bus
names and .desktop files.
[0] http://standards.freedesktop.org/desktop-entry-spec/
</description>
<arg name="app_id" type="string"/>
</request>
<request name="show_window_menu">
<description summary="show the window menu">
Clients implementing client-side decorations might want to show
a context menu when right-clicking on the decorations, giving the
user a menu that they can use to maximize or minimize the window.
This request asks the compositor to pop up such a window menu at
the given position, relative to the local surface coordinates of
the parent surface. There are no guarantees as to what menu items
the window menu contains.
This request must be used in response to some sort of user action
like a button press, key press, or touch down event.
</description>
<arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
<arg name="serial" type="uint" summary="the serial of the user event"/>
<arg name="x" type="int" summary="the x position to pop up the window menu at"/>
<arg name="y" type="int" summary="the y position to pop up the window menu at"/>
</request>
<request name="move">
<description summary="start an interactive move">
Start an interactive, user-driven move of the surface.
This request must be used in response to some sort of user action
like a button press, key press, or touch down event. The passed
serial is used to determine the type of interactive move (touch,
pointer, etc).
The server may ignore move requests depending on the state of
the surface (e.g. fullscreen or maximized), or if the passed serial
is no longer valid.
If triggered, the surface will lose the focus of the device
(wl_pointer, wl_touch, etc) used for the move. It is up to the
compositor to visually indicate that the move is taking place, such as
updating a pointer cursor, during the move. There is no guarantee
that the device focus will return when the move is completed.
</description>
<arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
<arg name="serial" type="uint" summary="the serial of the user event"/>
</request>
<enum name="resize_edge">
<description summary="edge values for resizing">
These values are used to indicate which edge of a surface
is being dragged in a resize operation.
</description>
<entry name="none" value="0"/>
<entry name="top" value="1"/>
<entry name="bottom" value="2"/>
<entry name="left" value="4"/>
<entry name="top_left" value="5"/>
<entry name="bottom_left" value="6"/>
<entry name="right" value="8"/>
<entry name="top_right" value="9"/>
<entry name="bottom_right" value="10"/>
</enum>
<request name="resize">
<description summary="start an interactive resize">
Start a user-driven, interactive resize of the surface.
This request must be used in response to some sort of user action
like a button press, key press, or touch down event. The passed
serial is used to determine the type of interactive resize (touch,
pointer, etc).
The server may ignore resize requests depending on the state of
the surface (e.g. fullscreen or maximized).
If triggered, the client will receive configure events with the
"resize" state enum value and the expected sizes. See the "resize"
enum value for more details about what is required. The client
must also acknowledge configure events using "ack_configure". After
the resize is completed, the client will receive another "configure"
event without the resize state.
If triggered, the surface also will lose the focus of the device
(wl_pointer, wl_touch, etc) used for the resize. It is up to the
compositor to visually indicate that the resize is taking place,
such as updating a pointer cursor, during the resize. There is no
guarantee that the device focus will return when the resize is
completed.
The edges parameter specifies how the surface should be resized,
and is one of the values of the resize_edge enum. The compositor
may use this information to update the surface position for
example when dragging the top left corner. The compositor may also
use this information to adapt its behavior, e.g. choose an
appropriate cursor image.
</description>
<arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
<arg name="serial" type="uint" summary="the serial of the user event"/>
<arg name="edges" type="uint" summary="which edge or corner is being dragged"/>
</request>
<enum name="state">
<description summary="types of state on the surface">
The different state values used on the surface. This is designed for
state values like maximized, fullscreen. It is paired with the
configure event to ensure that both the client and the compositor
setting the state can be synchronized.
States set in this way are double-buffered. They will get applied on
the next commit.
Desktop environments may extend this enum by taking up a range of
values and documenting the range they chose in this description.
They are not required to document the values for the range that they
chose. Ideally, any good extensions from a desktop environment should
make its way into standardization into this enum.
The current reserved ranges are:
0x0000 - 0x0FFF: xdg-shell core values, documented below.
0x1000 - 0x1FFF: GNOME
0x2000 - 0x2FFF: EFL
</description>
<entry name="maximized" value="1" summary="the surface is maximized">
<description summary="the surface is maximized">
The surface is maximized. The window geometry specified in the configure
event must be obeyed by the client.
</description>
</entry>
<entry name="fullscreen" value="2" summary="the surface is fullscreen">
<description summary="the surface is fullscreen">
The surface is fullscreen. The window geometry specified in the configure
event must be obeyed by the client.
</description>
</entry>
<entry name="resizing" value="3" summary="the surface is being resized">
<description summary="the surface is being resized">
The surface is being resized. The window geometry specified in the
configure event is a maximum; the client cannot resize beyond it.
Clients that have aspect ratio or cell sizing configuration can use
a smaller size, however.
</description>
</entry>
<entry name="activated" value="4" summary="the surface is now activated">
<description summary="the surface is now activated">
Client window decorations should be painted as if the window is
active. Do not assume this means that the window actually has
keyboard or pointer focus.
</description>
</entry>
</enum>
<event name="configure">
<description summary="suggest a surface change">
The configure event asks the client to resize its surface or to
change its state.
The width and height arguments specify a hint to the window
about how its surface should be resized in window geometry
coordinates. See set_window_geometry.
If the width or height arguments are zero, it means the client
should decide its own window dimension. This may happen when the
compositor need to configure the state of the surface but doesn't
have any information about any previous or expected dimension.
The states listed in the event specify how the width/height
arguments should be interpreted, and possibly how it should be
drawn.
Clients should arrange their surface for the new size and
states, and then send a ack_configure request with the serial
sent in this configure event at some point before committing
the new surface.
If the client receives multiple configure events before it
can respond to one, it is free to discard all but the last
event it received.
</description>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
<arg name="states" type="array"/>
<arg name="serial" type="uint"/>
</event>
<request name="ack_configure">
<description summary="ack a configure event">
When a configure event is received, if a client commits the
surface in response to the configure event, then the client
must make an ack_configure request sometime before the commit
request, passing along the serial of the configure event.
For instance, the compositor might use this information to move
a surface to the top left only when the client has drawn itself
for the maximized or fullscreen state.
If the client receives multiple configure events before it
can respond to one, it only has to ack the last configure event.
A client is not required to commit immediately after sending
an ack_configure request - it may even ack_configure several times
before its next surface commit.
The compositor expects that the most recently received
ack_configure request at the time of a commit indicates which
configure event the client is responding to.
</description>
<arg name="serial" type="uint" summary="the serial from the configure event"/>
</request>
<request name="set_window_geometry">
<description summary="set the new window geometry">
The window geometry of a window is its "visible bounds" from the
user's perspective. Client-side decorations often have invisible
portions like drop-shadows which should be ignored for the
purposes of aligning, placing and constraining windows.
The window geometry is double buffered, and will be applied at the
time wl_surface.commit of the corresponding wl_surface is called.
Once the window geometry of the surface is set once, it is not
possible to unset it, and it will remain the same until
set_window_geometry is called again, even if a new subsurface or
buffer is attached.
If never set, the value is the full bounds of the surface,
including any subsurfaces. This updates dynamically on every
commit. This unset mode is meant for extremely simple clients.
If responding to a configure event, the window geometry in here
must respect the sizing negotiations specified by the states in
the configure event.
The arguments are given in the surface local coordinate space of
the wl_surface associated with this xdg_surface.
The width and height must be greater than zero.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</request>
<request name="set_maximized">
<description summary="maximize the window">
Maximize the surface.
After requesting that the surface should be maximized, the compositor
will respond by emitting a configure event with the "maximized" state
and the required window geometry. The client should then update its
content, drawing it in a maximized state, i.e. without shadow or other
decoration outside of the window geometry. The client must also
acknowledge the configure when committing the new content (see
ack_configure).
It is up to the compositor to decide how and where to maximize the
surface, for example which output and what region of the screen should
be used.
If the surface was already maximized, the compositor will still emit
a configure event with the "maximized" state.
</description>
</request>
<request name="unset_maximized">
<description summary="unmaximize the window">
Unmaximize the surface.
After requesting that the surface should be unmaximized, the compositor
will respond by emitting a configure event without the "maximized"
state. If available, the compositor will include the window geometry
dimensions the window had prior to being maximized in the configure
request. The client must then update its content, drawing it in a
regular state, i.e. potentially with shadow, etc. The client must also
acknowledge the configure when committing the new content (see
ack_configure).
It is up to the compositor to position the surface after it was
unmaximized; usually the position the surface had before maximizing, if
applicable.
If the surface was already not maximized, the compositor will still
emit a configure event without the "maximized" state.
</description>
</request>
<request name="set_fullscreen">
<description summary="set the window as fullscreen on a monitor">
Make the surface fullscreen.
You can specify an output that you would prefer to be fullscreen.
If this value is NULL, it's up to the compositor to choose which
display will be used to map this surface.
If the surface doesn't cover the whole output, the compositor will
position the surface in the center of the output and compensate with
black borders filling the rest of the output.
</description>
<arg name="output" type="object" interface="wl_output" allow-null="true"/>
</request>
<request name="unset_fullscreen" />
<request name="set_minimized">
<description summary="set the window as minimized">
Request that the compositor minimize your surface. There is no
way to know if the surface is currently minimized, nor is there
any way to unset minimization on this surface.
If you are looking to throttle redrawing when minimized, please
instead use the wl_surface.frame event for this, as this will
also work with live previews on windows in Alt-Tab, Expose or
similar compositor features.
</description>
</request>
<event name="close">
<description summary="surface wants to be closed">
The close event is sent by the compositor when the user
wants the surface to be closed. This should be equivalent to
the user clicking the close button in client-side decorations,
if your application has any...
This is only a request that the user intends to close your
window. The client may choose to ignore this request, or show
a dialog to ask the user to save their data...
</description>
</event>
</interface>
<interface name="xdg_popup" version="1">
<description summary="short-lived, popup surfaces for menus">
A popup surface is a short-lived, temporary surface that can be
used to implement menus. It takes an explicit grab on the surface
that will be dismissed when the user dismisses the popup. This can
be done by the user clicking outside the surface, using the keyboard,
or even locking the screen through closing the lid or a timeout.
When the popup is dismissed, a popup_done event will be sent out,
and at the same time the surface will be unmapped. The xdg_popup
object is now inert and cannot be reactivated, so clients should
destroy it. Explicitly destroying the xdg_popup object will also
dismiss the popup and unmap the surface.
Clients will receive events for all their surfaces during this
grab (which is an "owner-events" grab in X11 parlance). This is
done so that users can navigate through submenus and other
"nested" popup windows without having to dismiss the topmost
popup.
Clients that want to dismiss the popup when another surface of
their own is clicked should dismiss the popup using the destroy
request.
The parent surface must have either an xdg_surface or xdg_popup
role.
Specifying an xdg_popup for the parent means that the popups are
nested, with this popup now being the topmost popup. Nested
popups must be destroyed in the reverse order they were created
in, e.g. the only popup you are allowed to destroy at all times
is the topmost one.
If there is an existing popup when creating a new popup, the
parent must be the current topmost popup.
A parent surface must be mapped before the new popup is mapped.
When compositors choose to dismiss a popup, they will likely
dismiss every nested popup as well. When a compositor dismisses
popups, it will follow the same dismissing order as required
from the client.
The x and y arguments passed when creating the popup object specify
where the top left of the popup should be placed, relative to the
local surface coordinates of the parent surface. See
xdg_shell.get_xdg_popup.
The client must call wl_surface.commit on the corresponding wl_surface
for the xdg_popup state to take effect.
For a surface to be mapped by the compositor the client must have
committed both the xdg_popup state and a buffer.
</description>
<request name="destroy" type="destructor">
<description summary="remove xdg_popup interface">
This destroys the popup. Explicitly destroying the xdg_popup
object will also dismiss the popup, and unmap the surface.
If this xdg_popup is not the "topmost" popup, a protocol error
will be sent.
</description>
</request>
<event name="popup_done">
<description summary="popup interaction is done">
The popup_done event is sent out when a popup is dismissed by the
compositor. The client should destroy the xdg_popup object at this
point.
</description>
</event>
</interface>
</protocol>

1044
third-party/vendor/wayland-protocols/protocols/unstable/xdg-shell/xdg-shell-unstable-v6.xml vendored Normal file
View file

File diff suppressed because it is too large Load diff

4
third-party/vendor/wayland-protocols/protocols/unstable/xwayland-keyboard-grab/README vendored Normal file
View file

@ -0,0 +1,4 @@
Xwayland keyboard grabbing protocol
Maintainers:
Olivier Fourdan <ofourdan@redhat.com>

121
third-party/vendor/wayland-protocols/protocols/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,121 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="xwayland_keyboard_grab_unstable_v1">
<copyright>
Copyright © 2017 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 grabbing the keyboard from Xwayland">
This protocol is application-specific to meet the needs of the X11
protocol through Xwayland. It provides a way for Xwayland to request
all keyboard events to be forwarded to a surface even when the
surface does not have keyboard focus.
In the X11 protocol, a client may request an "active grab" on the
keyboard. On success, all key events are reported only to the
grabbing X11 client. For details, see XGrabKeyboard(3).
The core Wayland protocol does not have a notion of an active
keyboard grab. When running in Xwayland, X11 applications may
acquire an active grab inside Xwayland but that cannot be translated
to the Wayland compositor who may set the input focus to some other
surface. In doing so, it breaks the X11 client assumption that all
key events are reported to the grabbing client.
This protocol specifies a way for Xwayland to request all keyboard
be directed to the given surface. The protocol does not guarantee
that the compositor will honor this request and it does not
prescribe user interfaces on how to handle the respond. For example,
a compositor may inform the user that all key events are now
forwarded to the given client surface, or it may ask the user for
permission to do so.
Compositors are required to restrict access to this application
specific protocol to Xwayland alone.
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_xwayland_keyboard_grab_manager_v1" version="1">
<description summary="context object for keyboard grab manager">
A global interface used for grabbing the keyboard.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the keyboard grab manager">
Destroy the keyboard grab manager.
</description>
</request>
<request name="grab_keyboard">
<description summary="grab the keyboard to a surface">
The grab_keyboard request asks for a grab of the keyboard, forcing
the keyboard focus for the given seat upon the given surface.
The protocol provides no guarantee that the grab is ever satisfied,
and does not require the compositor to send an error if the grab
cannot ever be satisfied. It is thus possible to request a keyboard
grab that will never be effective.
The protocol:
* does not guarantee that the grab itself is applied for a surface,
the grab request may be silently ignored by the compositor,
* does not guarantee that any events are sent to this client even
if the grab is applied to a surface,
* does not guarantee that events sent to this client are exhaustive,
a compositor may filter some events for its own consumption,
* does not guarantee that events sent to this client are continuous,
a compositor may change and reroute keyboard events while the grab
is nominally active.
</description>
<arg name="id" type="new_id" interface="zwp_xwayland_keyboard_grab_v1"/>
<arg name="surface" type="object" interface="wl_surface"
summary="surface to report keyboard events to"/>
<arg name="seat" type="object" interface="wl_seat"
summary="the seat for which the keyboard should be grabbed"/>
</request>
</interface>
<interface name="zwp_xwayland_keyboard_grab_v1" version="1">
<description summary="interface for grabbing the keyboard">
A global interface used for grabbing the keyboard.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the grabbed keyboard object">
Destroy the grabbed keyboard object. If applicable, the compositor
will ungrab the keyboard.
</description>
</request>
</interface>
</protocol>

5
third-party/vendor/wayland-protocols/protocols/wayland-protocols-uninstalled.pc.in vendored Normal file
View file

@ -0,0 +1,5 @@
pkgdatadir=@abs_top_srcdir@
Name: Wayland Protocols
Description: Wayland protocol files (not installed)
Version: @WAYLAND_PROTOCOLS_VERSION@

7
third-party/vendor/wayland-protocols/protocols/wayland-protocols.pc.in vendored Normal file
View file

@ -0,0 +1,7 @@
prefix=@prefix@
datarootdir=@datarootdir@
pkgdatadir=${pc_sysrootdir}${datarootdir}/@PACKAGE@
Name: Wayland Protocols
Description: Wayland protocol files
Version: @WAYLAND_PROTOCOLS_VERSION@

35
third-party/vendor/wayland-protocols/src/lib.rs vendored Normal file
View file

@ -0,0 +1,35 @@
//! This crate provides bindings to the official wayland protocol extensions
//! provided in https://cgit.freedesktop.org/wayland/wayland-protocols
//!
//! These bindings are built on top of the crates wayland-client and wayland-server.
//!
//! Each protocol module contains a `client` and a `server` submodules, for each side of the
//! protocol. The creation of these modules (and the dependency on the associated crate) is
//! controlled by the two cargo features `client` and `server`.
//!
//! The cargo feature `unstable_protocols` adds an `unstable` module, containing bindings
//! to protocols that are not yet considered stable. As such, no stability guarantee is
//! given for these protocols.
//!
//! Some protocols require unstable rust features, the inclusion of them is controlled
//! by the cargo feature `nightly`.
#![warn(missing_docs)]
#[macro_use]
extern crate bitflags;
#[macro_use]
mod protocol_macro;
#[cfg(feature = "staging_protocols")]
pub mod staging;
#[cfg(feature = "unstable_protocols")]
pub mod unstable;
pub mod misc;
pub mod wlr;
mod stable;
pub use stable::*;

107
third-party/vendor/wayland-protocols/src/misc.rs vendored Normal file
View file

@ -0,0 +1,107 @@
//! Misc protocols
//!
//! This module contains protocols that are not clearly packaged by their maintainers,
//! often being implementation details of desktop environment, but can be used by external
//! tools for interoperability.
//!
//! Given they are not clearly packaged, the maintainers of this crate cannot guarantee
//! anything when it comes to them being up to date or the stability of their interface.
//! Pull requests for updating them will be welcomed, but we won't actively check if they
//! have received any updates.
#![cfg_attr(rustfmt, rustfmt_skip)]
pub mod gtk_primary_selection {
//! Gtk primary selection protocol
//!
//! This protocol provides the ability to have a primary selection device to
//! match that of the X server. This primary selection is a shortcut to the
//! common clipboard selection, where text just needs to be selected in order
//! to allow copying it elsewhere. The de facto way to perform this action
//! is the middle mouse button, although it is not limited to this one.
//!
//! Clients wishing to honor primary selection should create a primary
//! selection source and set it as the selection through
//! `wp_primary_selection_device.set_selection` whenever the text selection
//! changes. In order to minimize calls in pointer-driven text selection,
//! it should happen only once after the operation finished. Similarly,
//! a NULL source should be set when text is unselected.
//!
//! `wp_primary_selection_offer` objects are first announced through the
//! `wp_primary_selection_device.data_offer` event. Immediately after this event,
//! the primary data offer will emit `wp_primary_selection_offer.offer` events
//! to let know of the mime types being offered.
//!
//! When the primary selection changes, the client with the keyboard focus
//! will receive `wp_primary_selection_device.selection` events. Only the client
//! with the keyboard focus will receive such events with a non-NULL
//! `wp_primary_selection_offer`. Across keyboard focus changes, previously
//! focused clients will receive `wp_primary_selection_device.events` with a
//! NULL `wp_primary_selection_offer`.
//!
//! In order to request the primary selection data, the client must pass
//! a recent serial pertaining to the press event that is triggering the
//! operation, if the compositor deems the serial valid and recent, the
//! `wp_primary_selection_source.send` event will happen in the other end
//! to let the transfer begin. The client owning the primary selection
//! should write the requested data, and close the file descriptor
//! immediately.
//!
//! If the primary selection owner client disappeared during the transfer,
//! the client reading the data will receive a
//! `wp_primary_selection_device.selection` event with a NULL
//! `wp_primary_selection_offer`, the client should take this as a hint
//! to finish the reads related to the no longer existing offer.
//!
//! The primary selection owner should be checking for errors during
//! writes, merely cancelling the ongoing transfer if any happened.
wayland_protocol!("gtk-primary-selection", [(wl_seat, wl_seat_interface)], []);
}
#[cfg(feature = "unstable_protocols")]
pub mod zwp_input_method_v2 {
//! Input method v2 unstable
//!
//! This protocol allows applications to act as input methods for compositors.
//!
//! An input method context is used to manage the state of the input method.
//!
//! Text strings are UTF-8 encoded, their indices and lengths are in bytes.
//!
//! This document adheres to the RFC 2119 when using words like "must",
//! "should", "may", etc.
//!
//! 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.
wayland_protocol!(
"input-method-unstable-v2",
[
(wl_seat, wl_seat_interface),
(wl_surface, wl_surface_interface),
(wl_output, wl_output_interface),
(wl_keyboard, wl_keyboard_interface)
],
[(unstable::text_input::v3, zwp_text_input_v3, zwp_text_input_v3_interface)]
);
}
pub mod server_decoration{
//! KDE server decoration protocol
//!
//! This interface allows to coordinate whether the server should create
//! a server-side window decoration around a wl_surface representing a
//! shell surface (wl_shell_surface or similar). By announcing support
//! for this interface the server indicates that it supports server
//! side decorations.
//!
//! Use in conjunction with zxdg_decoration_manager_v1 is undefined.
wayland_protocol!("server-decoration", [(wl_surface, wl_seat_surface)], []);
}

64
third-party/vendor/wayland-protocols/src/protocol_macro.rs vendored Normal file
View file

@ -0,0 +1,64 @@
macro_rules! wayland_protocol(
(
$name: expr,
[$(($import: ident, $interface: ident)),*],
// Path declaration in prot_name is to allow importing from another class of protocols, such as unstable
[$(($($prot_name:ident)::+, $prot_import: ident, $prot_iface: ident)),*]
) => {
#[cfg(feature = "client")]
pub use self::generated::client;
#[cfg(feature = "server")]
pub use self::generated::server;
mod generated {
#![allow(dead_code,non_camel_case_types,unused_unsafe,unused_variables)]
#![allow(non_upper_case_globals,non_snake_case,unused_imports)]
#![allow(missing_docs, clippy::all)]
#[cfg(feature = "client")]
pub mod client {
//! Client-side API of this protocol
pub(crate) use wayland_client::{Main, Attached, Proxy, ProxyMap, AnonymousObject};
pub(crate) use wayland_commons::map::{Object, ObjectMetadata};
pub(crate) use wayland_commons::{Interface, MessageGroup};
pub(crate) use wayland_commons::wire::{Argument, MessageDesc, ArgumentType, Message};
pub(crate) use wayland_commons::smallvec;
pub(crate) use wayland_client::protocol::{$($import),*};
pub(crate) use wayland_client::sys;
$(
pub(crate) use crate::$($prot_name ::)*client::$prot_import;
)*
include!(concat!(env!("OUT_DIR"), "/", $name, "_client_api.rs"));
}
#[cfg(feature = "server")]
pub mod server {
//! Server-side API of this protocol
pub(crate) use wayland_server::{Main, AnonymousObject, Resource, ResourceMap};
pub(crate) use wayland_commons::map::{Object, ObjectMetadata};
pub(crate) use wayland_commons::{Interface, MessageGroup};
pub(crate) use wayland_commons::wire::{Argument, MessageDesc, ArgumentType, Message};
pub(crate) use wayland_commons::smallvec;
pub(crate) use wayland_server::protocol::{$($import),*};
pub(crate) use wayland_server::sys;
$(
pub(crate) use crate::$($prot_name ::)*server::$prot_import;
)*
include!(concat!(env!("OUT_DIR"), "/", $name, "_server_api.rs"));
}
}
}
);
#[cfg(any(feature = "staging_protocols", feature = "unstable_protocols"))]
macro_rules! wayland_protocol_versioned(
($name: expr, [$($version: ident),*], $std_imports:tt, $prot_imports:tt) => {
$(
#[allow(missing_docs)]
pub mod $version {
wayland_protocol!(concat!($name, "-", stringify!($version)), $std_imports, $prot_imports);
}
)*
}
);

38
third-party/vendor/wayland-protocols/src/stable.rs vendored Normal file
View file

@ -0,0 +1,38 @@
#![cfg_attr(rustfmt, rustfmt_skip)]
pub mod presentation_time {
//! Presentation time protocol
//!
//! Allows precise feedback on presentation timing, for example for smooth video playback.
wayland_protocol!(
"presentation-time",
[(wl_surface, wl_surface_interface), (wl_output, wl_output_interface)],
[]
);
}
pub mod xdg_shell {
//! XDG Shell protocol
//!
//! Exposes the `xdg_wm_base` global, which deprecates and replaces `wl_shell`.
wayland_protocol!(
"xdg-shell",
[
(wl_seat, wl_seat_interface),
(wl_surface, wl_surface_interface),
(wl_output, wl_output_interface)
],
[]
);
}
pub mod viewporter {
//! Viewporter protocol
//!
//! Provides the capability of scaling and cropping surfaces, decorrelating the surface
//! dimensions from the size of the buffer.
wayland_protocol!("viewporter", [(wl_surface, wl_surface_interface)], []);
}

41
third-party/vendor/wayland-protocols/src/staging.rs vendored Normal file
View file

@ -0,0 +1,41 @@
//! Staging protocols from wayland-protocols
//!
//! The protocols described this module are in the staging process and will soon be made part of a
//! release. Staging protocols are guaranteed to have no backwards incompatible changes introduced.
//!
//! These protocols are ready for wider adoption and clients and compositors are encouraged to
//! implement staging protocol extensions where a protocol's functionality is desired.
//!
//! Although these protocols should be stable, the protocols may be completely replaced in a new
//! major version or with a completely different protocol.
#![cfg_attr(rustfmt, rustfmt_skip)]
pub mod xdg_activation {
//! The way for a client to pass focus to another toplevel is as follows.
//!
//! The client that intends to activate another toplevel uses the
//! xdg_activation_v1.get_activation_token request to get an activation token.
//! This token is then passed to the client to be activated through a separate
//! band of communication. The client to be activated will then pass the token
//! it received to the xdg_activation_v1.activate request. The compositor can
//! then use this token to decide how to react to the activation request.
//!
//! The token the activating client gets may be ineffective either already at
//! the time it receives it, for example if it was not focused, for focus
//! stealing prevention. The activating client will have no way to discover
//! the validity of the token, and may still forward it to the to be activated
//! client.
//!
//! The created activation token may optionally get information attached to it
//! that can be used by the compositor to identify the application that we
//! intend to activate. This can for example be used to display a visual hint
//! about what application is being started.
wayland_protocol_versioned!(
"xdg-activation",
[v1],
[(wl_seat, wl_seat_interface), (wl_surface, wl_surface_interface)],
[]
);
}

388
third-party/vendor/wayland-protocols/src/unstable.rs vendored Normal file
View file

@ -0,0 +1,388 @@
//! Unstable protocols from wayland-protocols
//!
//! The protocols described in this module are experimental and
//! provide no guarantee of forward support. They may be abandoned
//! or never widely implemented.
//!
//! 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.
#![cfg_attr(rustfmt, rustfmt_skip)]
pub mod fullscreen_shell {
//! Fullscreen shell protocol
wayland_protocol_versioned!(
"fullscreen-shell",
[v1],
[(wl_surface, wl_surface_interface), (wl_output, wl_output_interface)],
[]
);
}
pub mod idle_inhibit {
//! Screensaver inhibition protocol
wayland_protocol_versioned!("idle-inhibit", [v1], [(wl_surface, wl_surface_interface)], []);
}
pub mod input_method {
//! Input method protocol
wayland_protocol_versioned!(
"input-method",
[v1],
[
(wl_surface, wl_surface_interface),
(wl_output, wl_output_interface),
(wl_keyboard, wl_keyboard_interface)
],
[]
);
}
pub mod input_timestamps {
//! Input timestamps protocol
wayland_protocol_versioned!(
"input-timestamps",
[v1],
[
(wl_keyboard, wl_keyboard_interface),
(wl_pointer, wl_pointer_interface),
(wl_touch, wl_touch_interface)
],
[]
);
}
pub mod keyboard_shortcuts_inhibit {
//! Protocol for inhibiting the compositor keyboard shortcuts
//!
//! This protocol specifies a way for a client to request the compositor
//! to ignore its own keyboard shortcuts for a given seat, so that all
//! key events from that seat get forwarded to a surface.
wayland_protocol_versioned!(
"keyboard-shortcuts-inhibit",
[v1],
[(wl_seat, wl_seat_interface), (wl_surface, wl_surface_interface)],
[]
);
}
pub mod linux_dmabuf {
//! Linux DMA-BUF protocol
wayland_protocol_versioned!("linux-dmabuf", [v1], [(wl_buffer, wl_buffer_interface)], []);
}
pub mod linux_explicit_synchronization {
//! Linux explicit synchronization protocol
wayland_protocol_versioned!(
"linux-explicit-synchronization",
[v1],
[(wl_surface, wl_surface_interface)],
[]
);
}
pub mod pointer_constraints {
//! 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.
wayland_protocol_versioned!(
"pointer-constraints",
[v1],
[
(wl_surface, wl_surface_interface),
(wl_pointer, wl_pointer_interface),
(wl_region, wl_region_interface)
],
[]
);
}
pub mod pointer_gestures {
//! Pointer gestures protocol
wayland_protocol_versioned!(
"pointer-gestures",
[v1],
[(wl_surface, wl_surface_interface), (wl_pointer, wl_pointer_interface)],
[]
);
}
pub mod primary_selection {
//! Primary selection protocol
wayland_protocol_versioned!("primary-selection", [v1], [(wl_seat, wl_seat_interface)], []);
}
pub mod relative_pointer {
//! 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.
wayland_protocol_versioned!("relative-pointer", [v1], [(wl_pointer, wl_pointer_interface)], []);
}
pub mod tablet {
//! Wayland protocol for graphics tablets
//!
//! This description provides a high-level overview of the interplay between
//! the interfaces defined this protocol. For details, see the protocol
//! specification.
//!
//! More than one tablet may exist, and device-specifics matter. Tablets are
//! not represented by a single virtual device like wl_pointer. A client
//! binds to the tablet manager object which is just a proxy object. From
//! that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
//! and that returns the actual interface that has all the tablets. With
//! this indirection, we can avoid merging wp_tablet into the actual Wayland
//! protocol, a long-term benefit.
//!
//! The wp_tablet_seat sends a "tablet added" event for each tablet
//! connected. That event is followed by descriptive events about the
//! hardware; currently that includes events for name, vid/pid and
//! a wp_tablet.path event that describes a local path. This path can be
//! used to uniquely identify a tablet or get more information through
//! libwacom. Emulated or nested tablets can skip any of those, e.g. a
//! virtual tablet may not have a vid/pid. The sequence of descriptive
//! events is terminated by a wp_tablet.done event to signal that a client
//! may now finalize any initialization for that tablet.
//!
//! Events from tablets require a tool in proximity. Tools are also managed
//! by the tablet seat; a "tool added" event is sent whenever a tool is new
//! to the compositor. That event is followed by a number of descriptive
//! events about the hardware; currently that includes capabilities,
//! hardware id and serial number, and tool type. Similar to the tablet
//! interface, a wp_tablet_tool.done event is sent to terminate that initial
//! sequence.
//!
//! Any event from a tool happens on the wp_tablet_tool interface. When the
//! tool gets into proximity of the tablet, a proximity_in event is sent on
//! the wp_tablet_tool interface, listing the tablet and the surface. That
//! event is followed by a motion event with the coordinates. After that,
//! it's the usual motion, axis, button, etc. events. The protocol's
//! serialisation means events are grouped by wp_tablet_tool.frame events.
//!
//! Two special events (that don't exist in X) are down and up. They signal
//! "tip touching the surface". For tablets without real proximity
//! detection, the sequence is: proximity_in, motion, down, frame.
//!
//! When the tool leaves proximity, a proximity_out event is sent. If any
//! button is still down, a button release event is sent before this
//! proximity event. These button events are sent in the same frame as the
//! proximity event to signal to the client that the buttons were held when
//! the tool left proximity.
//!
//! If the tool moves out of the surface but stays in proximity (i.e.
//! between windows), compositor-specific grab policies apply. This usually
//! means that the proximity-out is delayed until all buttons are released.
//!
//! Moving a tool physically from one tablet to the other has no real effect
//! on the protocol, since we already have the tool object from the "tool
//! added" event. All the information is already there and the proximity
//! events on both tablets are all a client needs to reconstruct what
//! happened.
//!
//! Some extra axes are normalized, i.e. the client knows the range as
//! specified in the protocol (e.g. [0, 65535]), the granularity however is
//! unknown. The current normalized axes are pressure, distance, and slider.
//!
//! Other extra axes are in physical units as specified in the protocol.
//! The current extra axes with physical units are tilt, rotation and
//! wheel rotation.
//!
//! Since tablets work independently of the pointer controlled by the mouse,
//! the focus handling is independent too and controlled by proximity.
//! The wp_tablet_tool.set_cursor request sets a tool-specific cursor.
//! This cursor surface may be the same as the mouse cursor, and it may be
//! the same across tools but it is possible to be more fine-grained. For
//! example, a client may set different cursors for the pen and eraser.
//!
//! Tools are generally independent of tablets and it is
//! compositor-specific policy when a tool can be removed. Common approaches
//! will likely include some form of removing a tool when all tablets the
//! tool was used on are removed.
wayland_protocol_versioned!(
"tablet",
[v1, v2],
[(wl_seat, wl_seat_interface), (wl_surface, wl_surface_interface)],
[]
);
}
pub mod text_input {
//! Text input protocol
wayland_protocol_versioned!(
"text-input",
[v1, v3],
[(wl_seat, wl_seat_interface), (wl_surface, wl_surface_interface)],
[]
);
}
pub mod xdg_decoration {
//! 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.
wayland_protocol_versioned!(
"xdg-decoration",
[v1],
[],
[(xdg_shell, xdg_toplevel, xdg_toplevel_interface)]
);
}
pub mod xdg_foreign {
//! Protocol for exporting xdg surface handles
//!
//! This protocol specifies a way for making it possible to reference a surface
//! of a different client. With such a reference, a client can, by using the
//! interfaces provided by this protocol, manipulate the relationship between
//! its own surfaces and the surface of some other client. For example, stack
//! some of its own surface above the other clients surface.
//!
//! In order for a client A to get a reference of a surface of client B, client
//! B must first export its surface using xdg_exporter.export. Upon doing this,
//! client B will receive a handle (a unique string) that it may share with
//! client A in some way (for example D-Bus). After client A has received the
//! handle from client B, it may use xdg_importer.import to create a reference
//! to the surface client B just exported. See the corresponding requests for
//! details.
//!
//! A possible use case for this is out-of-process dialogs. For example when a
//! sandboxed client without file system access needs the user to select a file
//! on the file system, given sandbox environment support, it can export its
//! surface, passing the exported surface handle to an unsandboxed process that
//! can show a file browser dialog and stack it above the sandboxed client's
//! surface.
wayland_protocol_versioned!("xdg-foreign", [v1, v2], [(wl_surface, wl_surface_interface)], []);
}
pub mod xdg_output {
//! Protocol to describe output regions
//!
//! This protocol aims at describing outputs in a way which is more in line
//! with the concept of an output on desktop oriented systems.
//!
//! Some information are more specific to the concept of an output for
//! a desktop oriented system and may not make sense in other applications,
//! such as IVI systems for example.
//!
//! Typically, the global compositor space on a desktop system is made of
//! a contiguous or overlapping set of rectangular regions.
//!
//! Some of the information provided in this protocol might be identical
//! to their counterparts already available from wl_output, in which case
//! the information provided by this protocol should be preferred to their
//! equivalent in wl_output. The goal is to move the desktop specific
//! concepts (such as output location within the global compositor space,
//! the connector name and types, etc.) out of the core wl_output protocol.
wayland_protocol_versioned!("xdg-output", [v1], [(wl_output, wl_output_interface)], []);
}
pub mod xdg_shell {
//! XDG Shell protocol
//!
//! These are the old, unstable versions of the now stable XDG Shell protocol.
//!
//! They remain here for compatibility reasons, allowing you to support older
//! clients/server not yet implementing the new protocol.
wayland_protocol_versioned!(
"xdg-shell",
[v5, v6],
[
(wl_surface, wl_surface_interface),
(wl_output, wl_output_interface),
(wl_seat, wl_seat_interface)
],
[]
);
}
pub mod xwayland_keyboard_grab {
//! Protocol for grabbing the keyboard from Xwayland
//!
//! This protocol is application-specific to meet the needs of the X11
//! protocol through Xwayland. It provides a way for Xwayland to request
//! all keyboard events to be forwarded to a surface even when the
//! surface does not have keyboard focus.
//!
//! In the X11 protocol, a client may request an "active grab" on the
//! keyboard. On success, all key events are reported only to the
//! grabbing X11 client. For details, see XGrabKeyboard(3).
//!
//! The core Wayland protocol does not have a notion of an active
//! keyboard grab. When running in Xwayland, X11 applications may
//! acquire an active grab inside Xwayland but that cannot be translated
//! to the Wayland compositor who may set the input focus to some other
//! surface. In doing so, it breaks the X11 client assumption that all
//! key events are reported to the grabbing client.
//!
//! This protocol specifies a way for Xwayland to request all keyboard
//! be directed to the given surface. The protocol does not guarantee
//! that the compositor will honor this request and it does not
//! prescribe user interfaces on how to handle the respond. For example,
//! a compositor may inform the user that all key events are now
//! forwarded to the given client surface, or it may ask the user for
//! permission to do so.
//!
//! Compositors are required to restrict access to this application
//! specific protocol to Xwayland alone.
wayland_protocol_versioned!(
"xwayland-keyboard-grab",
[v1],
[(wl_seat, wl_seat_interface), (wl_surface, wl_surface_interface)],
[]
);
}

151
third-party/vendor/wayland-protocols/src/wlr.rs vendored Normal file
View file

@ -0,0 +1,151 @@
//! wlr-procotols extension family
//!
//! This module regroup bindings to the protocol extensions from
//! [wlr-protocols](https://github.com/swaywm/wlr-protocols).
#![cfg_attr(rustfmt, rustfmt_skip)]
#[cfg(feature = "unstable_protocols")]
pub mod unstable {
//! Unstable protocols from wlr-protocols
//!
//! The protocols described in this module are 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.
pub mod data_control {
//! Control data devices, particularly the clipboard.
//!
//! An interface to control data devices, particularly to manage the current selection and
//! take the role of a clipboard manager.
wayland_protocol_versioned!("wlr-data-control", [v1], [(wl_seat, wl_seat_interface)], []);
}
pub mod export_dmabuf {
//! A protocol for low overhead screen content capturing
//!
//! An interface to capture surfaces in an efficient way by exporting DMA-BUFs.
wayland_protocol_versioned!(
"wlr-export-dmabuf",
[v1],
[(wl_output, wl_output_interface)],
[]
);
}
pub mod foreign_toplevel {
//! List and control opened apps
//!
//! Use for creating taskbars and docks.
wayland_protocol_versioned!(
"wlr-foreign-toplevel-management",
[v1],
[
(wl_seat, wl_seat_interface),
(wl_surface, wl_surface_interface),
(wl_output, wl_output_interface)
],
[]
);
}
pub mod gamma_control {
//! Manage gamma tables of outputs.
//!
//! This protocol allows a privileged client to set the gamma tables for outputs.
wayland_protocol_versioned!(
"wlr-gamma-control",
[v1],
[(wl_output, wl_output_interface)],
[]
);
}
pub mod input_inhibitor {
//! Inhibits input events to other clients
wayland_protocol_versioned!("wlr-input-inhibitor", [v1], [], []);
}
pub mod layer_shell {
//! Layered shell protocol
wayland_protocol_versioned!(
"wlr-layer-shell",
[v1],
[(wl_output, wl_output_interface), (wl_surface, wl_surface_interface)],
[(xdg_shell, xdg_popup, xdg_popup_interface)]
);
}
pub mod output_management {
//! Output management protocol
//!
//! This protocol exposes interfaces to obtain and modify output device configuration.
wayland_protocol_versioned!(
"wlr-output-management",
[v1],
[(wl_output, wl_output_interface)],
[]
);
}
pub mod output_power_management {
//! Output power management protocol
//!
//! This protocol allows clients to control power management modes
//! of outputs that are currently part of the compositor space. The
//! intent is to allow special clients like desktop shells to power
//! down outputs when the system is idle.
wayland_protocol_versioned!(
"wlr-output-power-management",
[v1],
[(wl_output, wl_output_interface)],
[]
);
}
pub mod screencopy {
//! Screen content capturing on client buffers
//!
//! This protocol allows clients to ask the compositor to copy part of the
//! screen content to a client buffer.
wayland_protocol_versioned!(
"wlr-screencopy",
[v1],
[(wl_buffer, wl_buffer_interface), (wl_output, wl_output_interface), (wl_shm, wl_shm_interface)],
[]
);
}
pub mod virtual_pointer {
//! Virtual pointer protocol
//!
//! This protocol allows clients to emulate a physical pointer device. The
//! requests are mostly mirror opposites of those specified in wl_pointer.
wayland_protocol_versioned!(
"wlr-virtual-pointer",
[v1],
[(wl_seat, wl_seat_interface), (wl_output, wl_output_interface), (wl_pointer, wl_pointer_interface)],
[]
);
}
}

39
third-party/vendor/wayland-protocols/wlr-protocols/Makefile vendored Normal file
View file

@ -0,0 +1,39 @@
PREFIX=/usr
DATADIR=$${datarootdir}
DATAROOTDIR=$${prefix}/share
unstable_protocols = \
unstable/wlr-export-dmabuf-unstable-v1.xml \
unstable/wlr-gamma-control-unstable-v1.xml \
unstable/wlr-input-inhibitor-unstable-v1.xml \
unstable/wlr-layer-shell-unstable-v1.xml \
unstable/wlr-output-power-management-v1.xml \
unstable/wlr-screencopy-unstable-v1.xml
check:
./check.sh
clean:
rm -f wlr-protocols.pc
wlr-protocols.pc: wlr-protocols.pc.in
sed \
-e 's:@prefix@:$(PREFIX):g' \
-e 's:@datadir@:$(DATADIR):g' \
-e 's:@datarootdir@:$(DATAROOTDIR):g' \
<$< >$@
install-unstable: $(unstable_protocols)
mkdir -p $(DESTDIR)$(PREFIX)/share/wlr-protocols/unstable
for protocol in $^ ; \
do \
install -Dm644 $$protocol \
$(DESTDIR)$(PREFIX)/share/wlr-protocols/$$protocol ; \
done
install-pc: wlr-protocols.pc
mkdir -p $(DESTDIR)$(PREFIX)/share/pkgconfig/
install -Dm644 wlr-protocols.pc \
$(DESTDIR)$(PREFIX)/share/pkgconfig/wlr-protocols.pc
install: install-unstable install-pc

14
third-party/vendor/wayland-protocols/wlr-protocols/README.md vendored Normal file
View file

@ -0,0 +1,14 @@
# wlr-protocols
Wayland protocols designed for use in wlroots (and other compositors).
## Submitting changes to existing protocols
Please submit a pull request on GitHub.
## Submitting new protocols
New protocols should not be submitted to wlr-protocols. Instead, submit them to
[wayland-protocols].
[wayland-protocols]: https://gitlab.freedesktop.org/wayland/wayland-protocols

9
third-party/vendor/wayland-protocols/wlr-protocols/check.sh vendored Executable file
View file

@ -0,0 +1,9 @@
#!/bin/sh -eux
for f in $(echo unstable/*.xml)
do
wayland-scanner -s client-header "$f" /dev/null
wayland-scanner -s server-header "$f" /dev/null
wayland-scanner -s public-code "$f" /dev/null
wayland-scanner -s private-code "$f" /dev/null
done

278
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-data-control-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,278 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_data_control_unstable_v1">
<copyright>
Copyright © 2018 Simon Ser
Copyright © 2019 Ivan Molodetskikh
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.
</copyright>
<description summary="control data devices">
This protocol allows a privileged client to control data devices. In
particular, the client will be able to manage the current selection and take
the role of a clipboard manager.
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="zwlr_data_control_manager_v1" version="2">
<description summary="manager to control data devices">
This interface is a manager that allows creating per-seat data device
controls.
</description>
<request name="create_data_source">
<description summary="create a new data source">
Create a new data source.
</description>
<arg name="id" type="new_id" interface="zwlr_data_control_source_v1"
summary="data source to create"/>
</request>
<request name="get_data_device">
<description summary="get a data device for a seat">
Create a data device that can be used to manage a seat's selection.
</description>
<arg name="id" type="new_id" interface="zwlr_data_control_device_v1"/>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
All objects created by the manager will still remain valid, until their
appropriate destroy request has been called.
</description>
</request>
</interface>
<interface name="zwlr_data_control_device_v1" version="2">
<description summary="manage a data device for a seat">
This interface allows a client to manage a seat's selection.
When the seat is destroyed, this object becomes inert.
</description>
<request name="set_selection">
<description summary="copy data to the selection">
This request asks the compositor to set the selection to the data from
the source on behalf of the client.
The given source may not be used in any further set_selection or
set_primary_selection requests. Attempting to use a previously used
source is a protocol error.
To unset the selection, set the source to NULL.
</description>
<arg name="source" type="object" interface="zwlr_data_control_source_v1"
allow-null="true"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy this data device">
Destroys the data device object.
</description>
</request>
<event name="data_offer">
<description summary="introduce a new wlr_data_control_offer">
The data_offer event introduces a new wlr_data_control_offer object,
which will subsequently be used in either the
wlr_data_control_device.selection event (for the regular clipboard
selections) or the wlr_data_control_device.primary_selection event (for
the primary clipboard selections). Immediately following the
wlr_data_control_device.data_offer event, the new data_offer object
will send out wlr_data_control_offer.offer events to describe the MIME
types it offers.
</description>
<arg name="id" type="new_id" interface="zwlr_data_control_offer_v1"/>
</event>
<event name="selection">
<description summary="advertise new selection">
The selection event is sent out to notify the client of a new
wlr_data_control_offer for the selection for this device. The
wlr_data_control_device.data_offer and the wlr_data_control_offer.offer
events are sent out immediately before this event to introduce the data
offer object. The selection event is sent to a client when a new
selection is set. The wlr_data_control_offer is valid until a new
wlr_data_control_offer or NULL is received. The client must destroy the
previous selection wlr_data_control_offer, if any, upon receiving this
event.
The first selection event is sent upon binding the
wlr_data_control_device object.
</description>
<arg name="id" type="object" interface="zwlr_data_control_offer_v1"
allow-null="true"/>
</event>
<event name="finished">
<description summary="this data control is no longer valid">
This data control object is no longer valid and should be destroyed by
the client.
</description>
</event>
<!-- Version 2 additions -->
<event name="primary_selection" since="2">
<description summary="advertise new primary selection">
The primary_selection event is sent out to notify the client of a new
wlr_data_control_offer for the primary selection for this device. The
wlr_data_control_device.data_offer and the wlr_data_control_offer.offer
events are sent out immediately before this event to introduce the data
offer object. The primary_selection event is sent to a client when a
new primary selection is set. The wlr_data_control_offer is valid until
a new wlr_data_control_offer or NULL is received. The client must
destroy the previous primary selection wlr_data_control_offer, if any,
upon receiving this event.
If the compositor supports primary selection, the first
primary_selection event is sent upon binding the
wlr_data_control_device object.
</description>
<arg name="id" type="object" interface="zwlr_data_control_offer_v1"
allow-null="true"/>
</event>
<request name="set_primary_selection" since="2">
<description summary="copy data to the primary selection">
This request asks the compositor to set the primary selection to the
data from the source on behalf of the client.
The given source may not be used in any further set_selection or
set_primary_selection requests. Attempting to use a previously used
source is a protocol error.
To unset the primary selection, set the source to NULL.
The compositor will ignore this request if it does not support primary
selection.
</description>
<arg name="source" type="object" interface="zwlr_data_control_source_v1"
allow-null="true"/>
</request>
<enum name="error" since="2">
<entry name="used_source" value="1"
summary="source given to set_selection or set_primary_selection was already used before"/>
</enum>
</interface>
<interface name="zwlr_data_control_source_v1" version="1">
<description summary="offer to transfer data">
The wlr_data_control_source object is the source side of a
wlr_data_control_offer. It is created by the source client in a data
transfer and provides a way to describe the offered data and a way to
respond to requests to transfer the data.
</description>
<enum name="error">
<entry name="invalid_offer" value="1"
summary="offer sent after wlr_data_control_device.set_selection"/>
</enum>
<request name="offer">
<description summary="add an offered MIME type">
This request adds a MIME type to the set of MIME types advertised to
targets. Can be called several times to offer multiple types.
Calling this after wlr_data_control_device.set_selection is a protocol
error.
</description>
<arg name="mime_type" type="string"
summary="MIME type offered by the data source"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy this source">
Destroys the data source object.
</description>
</request>
<event name="send">
<description summary="send the data">
Request for data from the client. Send the data as the specified MIME
type over the passed file descriptor, then close it.
</description>
<arg name="mime_type" type="string" summary="MIME type for the data"/>
<arg name="fd" type="fd" summary="file descriptor for the data"/>
</event>
<event name="cancelled">
<description summary="selection was cancelled">
This data source is no longer valid. The data source has been replaced
by another data source.
The client should clean up and destroy this data source.
</description>
</event>
</interface>
<interface name="zwlr_data_control_offer_v1" version="1">
<description summary="offer to transfer data">
A wlr_data_control_offer represents a piece of data offered for transfer
by another client (the source client). The offer describes the different
MIME types that the data can be converted to and provides the mechanism
for transferring the data directly from the source client.
</description>
<request name="receive">
<description summary="request that the data is transferred">
To transfer the offered data, the client issues this request and
indicates the MIME type it wants to receive. The transfer happens
through the passed file descriptor (typically created with the pipe
system call). The source client writes the data in the MIME type
representation requested and then closes the file descriptor.
The receiving client reads from the read end of the pipe until EOF and
then closes its end, at which point the transfer is complete.
This request may happen multiple times for different MIME types.
</description>
<arg name="mime_type" type="string"
summary="MIME type desired by receiver"/>
<arg name="fd" type="fd" summary="file descriptor for data transfer"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy this offer">
Destroys the data offer object.
</description>
</request>
<event name="offer">
<description summary="advertise offered MIME type">
Sent immediately after creating the wlr_data_control_offer object.
One event per offered MIME type.
</description>
<arg name="mime_type" type="string" summary="offered MIME type"/>
</event>
</interface>
</protocol>

203
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-export-dmabuf-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,203 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_export_dmabuf_unstable_v1">
<copyright>
Copyright © 2018 Rostislav Pehlivanov
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="a protocol for low overhead screen content capturing">
An interface to capture surfaces in an efficient way by exporting DMA-BUFs.
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="zwlr_export_dmabuf_manager_v1" version="1">
<description summary="manager to inform clients and begin capturing">
This object is a manager with which to start capturing from sources.
</description>
<request name="capture_output">
<description summary="capture a frame from an output">
Capture the next frame of an entire output.
</description>
<arg name="frame" type="new_id" interface="zwlr_export_dmabuf_frame_v1"/>
<arg name="overlay_cursor" type="int"
summary="include custom client hardware cursor on top of the frame"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
All objects created by the manager will still remain valid, until their
appropriate destroy request has been called.
</description>
</request>
</interface>
<interface name="zwlr_export_dmabuf_frame_v1" version="1">
<description summary="a DMA-BUF frame">
This object represents a single DMA-BUF frame.
If the capture is successful, the compositor will first send a "frame"
event, followed by one or several "object". When the frame is available
for readout, the "ready" event is sent.
If the capture failed, the "cancel" event is sent. This can happen anytime
before the "ready" event.
Once either a "ready" or a "cancel" event is received, the client should
destroy the frame. Once an "object" event is received, the client is
responsible for closing the associated file descriptor.
All frames are read-only and may not be written into or altered.
</description>
<enum name="flags">
<description summary="frame flags">
Special flags that should be respected by the client.
</description>
<entry name="transient" value="0x1"
summary="clients should copy frame before processing"/>
</enum>
<event name="frame">
<description summary="a frame description">
Main event supplying the client with information about the frame. If the
capture didn't fail, this event is always emitted first before any other
events.
This event is followed by a number of "object" as specified by the
"num_objects" argument.
</description>
<arg name="width" type="uint"
summary="frame width in pixels"/>
<arg name="height" type="uint"
summary="frame height in pixels"/>
<arg name="offset_x" type="uint"
summary="crop offset for the x axis"/>
<arg name="offset_y" type="uint"
summary="crop offset for the y axis"/>
<arg name="buffer_flags" type="uint"
summary="flags which indicate properties (invert, interlacing),
has the same values as zwp_linux_buffer_params_v1:flags"/>
<arg name="flags" type="uint" enum="flags"
summary="indicates special frame features"/>
<arg name="format" type="uint"
summary="format of the frame (DRM_FORMAT_*)"/>
<arg name="mod_high" type="uint"
summary="drm format modifier, high"/>
<arg name="mod_low" type="uint"
summary="drm format modifier, low"/>
<arg name="num_objects" type="uint"
summary="indicates how many objects (FDs) the frame has (max 4)"/>
</event>
<event name="object">
<description summary="an object description">
Event which serves to supply the client with the file descriptors
containing the data for each object.
After receiving this event, the client must always close the file
descriptor as soon as they're done with it and even if the frame fails.
</description>
<arg name="index" type="uint"
summary="index of the current object"/>
<arg name="fd" type="fd"
summary="fd of the current object"/>
<arg name="size" type="uint"
summary="size in bytes for the current object"/>
<arg name="offset" type="uint"
summary="starting point for the data in the object's fd"/>
<arg name="stride" type="uint"
summary="line size in bytes"/>
<arg name="plane_index" type="uint"
summary="index of the plane the data in the object applies to"/>
</event>
<event name="ready">
<description summary="indicates frame is available for reading">
This event is sent as soon as the frame is presented, indicating it is
available for reading. This event includes the time at which
presentation happened at.
The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples,
each component being an unsigned 32-bit value. Whole seconds are in
tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo,
and the additional fractional part in tv_nsec as nanoseconds. Hence,
for valid timestamps tv_nsec must be in [0, 999999999]. The seconds part
may have an arbitrary offset at start.
After receiving this event, the client should destroy this object.
</description>
<arg name="tv_sec_hi" type="uint"
summary="high 32 bits of the seconds part of the timestamp"/>
<arg name="tv_sec_lo" type="uint"
summary="low 32 bits of the seconds part of the timestamp"/>
<arg name="tv_nsec" type="uint"
summary="nanoseconds part of the timestamp"/>
</event>
<enum name="cancel_reason">
<description summary="cancel reason">
Indicates reason for cancelling the frame.
</description>
<entry name="temporary" value="0"
summary="temporary error, source will produce more frames"/>
<entry name="permanent" value="1"
summary="fatal error, source will not produce frames"/>
<entry name="resizing" value="2"
summary="temporary error, source will produce more frames"/>
</enum>
<event name="cancel">
<description summary="indicates the frame is no longer valid">
If the capture failed or if the frame is no longer valid after the
"frame" event has been emitted, this event will be used to inform the
client to scrap the frame.
If the failure is temporary, the client may capture again the same
source. If the failure is permanent, any further attempts to capture the
same source will fail again.
After receiving this event, the client should destroy this object.
</description>
<arg name="reason" type="uint" enum="cancel_reason"
summary="indicates a reason for cancelling this frame capture"/>
</event>
<request name="destroy" type="destructor">
<description summary="delete this object, used or not">
Unreferences the frame. This request must be called as soon as its no
longer used.
It can be called at any time by the client. The client will still have
to close any FDs it has been given.
</description>
</request>
</interface>
</protocol>

270
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-foreign-toplevel-management-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,270 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_foreign_toplevel_management_unstable_v1">
<copyright>
Copyright © 2018 Ilia Bozhinov
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.
</copyright>
<interface name="zwlr_foreign_toplevel_manager_v1" version="3">
<description summary="list and control opened apps">
The purpose of this protocol is to enable the creation of taskbars
and docks by providing them with a list of opened applications and
letting them request certain actions on them, like maximizing, etc.
After a client binds the zwlr_foreign_toplevel_manager_v1, each opened
toplevel window will be sent via the toplevel event
</description>
<event name="toplevel">
<description summary="a toplevel has been created">
This event is emitted whenever a new toplevel window is created. It
is emitted for all toplevels, regardless of the app that has created
them.
All initial details of the toplevel(title, app_id, states, etc.) will
be sent immediately after this event via the corresponding events in
zwlr_foreign_toplevel_handle_v1.
</description>
<arg name="toplevel" type="new_id" interface="zwlr_foreign_toplevel_handle_v1"/>
</event>
<request name="stop">
<description summary="stop sending events">
Indicates the client no longer wishes to receive events for new toplevels.
However the compositor may emit further toplevel_created events, until
the finished event is emitted.
The client must not send any more requests after this one.
</description>
</request>
<event name="finished">
<description summary="the compositor has finished with the toplevel manager">
This event indicates that the compositor is done sending events to the
zwlr_foreign_toplevel_manager_v1. The server will destroy the object
immediately after sending this request, so it will become invalid and
the client should free any resources associated with it.
</description>
</event>
</interface>
<interface name="zwlr_foreign_toplevel_handle_v1" version="3">
<description summary="an opened toplevel">
A zwlr_foreign_toplevel_handle_v1 object represents an opened toplevel
window. Each app may have multiple opened toplevels.
Each toplevel has a list of outputs it is visible on, conveyed to the
client with the output_enter and output_leave events.
</description>
<event name="title">
<description summary="title change">
This event is emitted whenever the title of the toplevel changes.
</description>
<arg name="title" type="string"/>
</event>
<event name="app_id">
<description summary="app-id change">
This event is emitted whenever the app-id of the toplevel changes.
</description>
<arg name="app_id" type="string"/>
</event>
<event name="output_enter">
<description summary="toplevel entered an output">
This event is emitted whenever the toplevel becomes visible on
the given output. A toplevel may be visible on multiple outputs.
</description>
<arg name="output" type="object" interface="wl_output"/>
</event>
<event name="output_leave">
<description summary="toplevel left an output">
This event is emitted whenever the toplevel stops being visible on
the given output. It is guaranteed that an entered-output event
with the same output has been emitted before this event.
</description>
<arg name="output" type="object" interface="wl_output"/>
</event>
<request name="set_maximized">
<description summary="requests that the toplevel be maximized">
Requests that the toplevel be maximized. If the maximized state actually
changes, this will be indicated by the state event.
</description>
</request>
<request name="unset_maximized">
<description summary="requests that the toplevel be unmaximized">
Requests that the toplevel be unmaximized. If the maximized state actually
changes, this will be indicated by the state event.
</description>
</request>
<request name="set_minimized">
<description summary="requests that the toplevel be minimized">
Requests that the toplevel be minimized. If the minimized state actually
changes, this will be indicated by the state event.
</description>
</request>
<request name="unset_minimized">
<description summary="requests that the toplevel be unminimized">
Requests that the toplevel be unminimized. If the minimized state actually
changes, this will be indicated by the state event.
</description>
</request>
<request name="activate">
<description summary="activate the toplevel">
Request that this toplevel be activated on the given seat.
There is no guarantee the toplevel will be actually activated.
</description>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
<enum name="state">
<description summary="types of states on the toplevel">
The different states that a toplevel can have. These have the same meaning
as the states with the same names defined in xdg-toplevel
</description>
<entry name="maximized" value="0" summary="the toplevel is maximized"/>
<entry name="minimized" value="1" summary="the toplevel is minimized"/>
<entry name="activated" value="2" summary="the toplevel is active"/>
<entry name="fullscreen" value="3" summary="the toplevel is fullscreen" since="2"/>
</enum>
<event name="state">
<description summary="the toplevel state changed">
This event is emitted immediately after the zlw_foreign_toplevel_handle_v1
is created and each time the toplevel state changes, either because of a
compositor action or because of a request in this protocol.
</description>
<arg name="state" type="array"/>
</event>
<event name="done">
<description summary="all information about the toplevel has been sent">
This event is sent after all changes in the toplevel state have been
sent.
This allows changes to the zwlr_foreign_toplevel_handle_v1 properties
to be seen as atomic, even if they happen via multiple events.
</description>
</event>
<request name="close">
<description summary="request that the toplevel be closed">
Send a request to the toplevel to close itself. The compositor would
typically use a shell-specific method to carry out this request, for
example by sending the xdg_toplevel.close event. However, this gives
no guarantees the toplevel will actually be destroyed. If and when
this happens, the zwlr_foreign_toplevel_handle_v1.closed event will
be emitted.
</description>
</request>
<request name="set_rectangle">
<description summary="the rectangle which represents the toplevel">
The rectangle of the surface specified in this request corresponds to
the place where the app using this protocol represents the given toplevel.
It can be used by the compositor as a hint for some operations, e.g
minimizing. The client is however not required to set this, in which
case the compositor is free to decide some default value.
If the client specifies more than one rectangle, only the last one is
considered.
The dimensions are given in surface-local coordinates.
Setting width=height=0 removes the already-set rectangle.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</request>
<enum name="error">
<entry name="invalid_rectangle" value="0"
summary="the provided rectangle is invalid"/>
</enum>
<event name="closed">
<description summary="this toplevel has been destroyed">
This event means the toplevel has been destroyed. It is guaranteed there
won't be any more events for this zwlr_foreign_toplevel_handle_v1. The
toplevel itself becomes inert so any requests will be ignored except the
destroy request.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the zwlr_foreign_toplevel_handle_v1 object">
Destroys the zwlr_foreign_toplevel_handle_v1 object.
This request should be called either when the client does not want to
use the toplevel anymore or after the closed event to finalize the
destruction of the object.
</description>
</request>
<!-- Version 2 additions -->
<request name="set_fullscreen" since="2">
<description summary="request that the toplevel be fullscreened">
Requests that the toplevel be fullscreened on the given output. If the
fullscreen state and/or the outputs the toplevel is visible on actually
change, this will be indicated by the state and output_enter/leave
events.
The output parameter is only a hint to the compositor. Also, if output
is NULL, the compositor should decide which output the toplevel will be
fullscreened on, if at all.
</description>
<arg name="output" type="object" interface="wl_output" allow-null="true"/>
</request>
<request name="unset_fullscreen" since="2">
<description summary="request that the toplevel be unfullscreened">
Requests that the toplevel be unfullscreened. If the fullscreen state
actually changes, this will be indicated by the state event.
</description>
</request>
<!-- Version 3 additions -->
<event name="parent" since="3">
<description summary="parent change">
This event is emitted whenever the parent of the toplevel changes.
No event is emitted when the parent handle is destroyed by the client.
</description>
<arg name="parent" type="object" interface="zwlr_foreign_toplevel_handle_v1" allow-null="true"/>
</event>
</interface>
</protocol>

126
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-gamma-control-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,126 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_gamma_control_unstable_v1">
<copyright>
Copyright © 2015 Giulio camuffo
Copyright © 2018 Simon Ser
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.
</copyright>
<description summary="manage gamma tables of outputs">
This protocol allows a privileged client to set the gamma tables for
outputs.
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="zwlr_gamma_control_manager_v1" version="1">
<description summary="manager to create per-output gamma controls">
This interface is a manager that allows creating per-output gamma
controls.
</description>
<request name="get_gamma_control">
<description summary="get a gamma control for an output">
Create a gamma control that can be used to adjust gamma tables for the
provided output.
</description>
<arg name="id" type="new_id" interface="zwlr_gamma_control_v1"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
All objects created by the manager will still remain valid, until their
appropriate destroy request has been called.
</description>
</request>
</interface>
<interface name="zwlr_gamma_control_v1" version="1">
<description summary="adjust gamma tables for an output">
This interface allows a client to adjust gamma tables for a particular
output.
The client will receive the gamma size, and will then be able to set gamma
tables. At any time the compositor can send a failed event indicating that
this object is no longer valid.
There can only be at most one gamma control object per output, which
has exclusive access to this particular output. When the gamma control
object is destroyed, the gamma table is restored to its original value.
</description>
<event name="gamma_size">
<description summary="size of gamma ramps">
Advertise the size of each gamma ramp.
This event is sent immediately when the gamma control object is created.
</description>
<arg name="size" type="uint" summary="number of elements in a ramp"/>
</event>
<enum name="error">
<entry name="invalid_gamma" value="1" summary="invalid gamma tables"/>
</enum>
<request name="set_gamma">
<description summary="set the gamma table">
Set the gamma table. The file descriptor can be memory-mapped to provide
the raw gamma table, which contains successive gamma ramps for the red,
green and blue channels. Each gamma ramp is an array of 16-byte unsigned
integers which has the same length as the gamma size.
The file descriptor data must have the same length as three times the
gamma size.
</description>
<arg name="fd" type="fd" summary="gamma table file descriptor"/>
</request>
<event name="failed">
<description summary="object no longer valid">
This event indicates that the gamma control is no longer valid. This
can happen for a number of reasons, including:
- The output doesn't support gamma tables
- Setting the gamma tables failed
- Another client already has exclusive gamma control for this output
- The compositor has transferred gamma control to another client
Upon receiving this event, the client should destroy this object.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy this control">
Destroys the gamma control object. If the object is still valid, this
restores the original gamma tables.
</description>
</request>
</interface>
</protocol>

68
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-input-inhibitor-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,68 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_input_inhibit_unstable_v1">
<copyright>
Copyright © 2018 Drew DeVault
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.
</copyright>
<interface name="zwlr_input_inhibit_manager_v1" version="1">
<description summary="inhibits input events to other clients">
Clients can use this interface to prevent input events from being sent to
any surfaces but its own, which is useful for example in lock screen
software. It is assumed that access to this interface will be locked down
to whitelisted clients by the compositor.
</description>
<request name="get_inhibitor">
<description summary="inhibit input to other clients">
Activates the input inhibitor. As long as the inhibitor is active, the
compositor will not send input events to other clients.
</description>
<arg name="id" type="new_id" interface="zwlr_input_inhibitor_v1"/>
</request>
<enum name="error">
<entry name="already_inhibited" value="0" summary="an input inhibitor is already in use on the compositor"/>
</enum>
</interface>
<interface name="zwlr_input_inhibitor_v1" version="1">
<description summary="inhibits input to other clients">
While this resource exists, input to clients other than the owner of the
inhibitor resource will not receive input events. Any client which
previously had focus will receive a leave event and will not be given
focus again. The client that owns this resource will receive all input
events normally. The compositor will also disable all of its own input
processing (such as keyboard shortcuts) while the inhibitor is active.
The compositor may continue to send input events to selected clients,
such as an on-screen keyboard (via the input-method protocol).
</description>
<request name="destroy" type="destructor">
<description summary="destroy the input inhibitor object">
Destroy the inhibitor and allow other clients to receive input.
</description>
</request>
</interface>
</protocol>

390
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-layer-shell-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,390 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_layer_shell_unstable_v1">
<copyright>
Copyright © 2017 Drew DeVault
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.
</copyright>
<interface name="zwlr_layer_shell_v1" version="4">
<description summary="create surfaces that are layers of the desktop">
Clients can use this interface to assign the surface_layer role to
wl_surfaces. Such surfaces are assigned to a "layer" of the output and
rendered with a defined z-depth respective to each other. They may also be
anchored to the edges and corners of a screen and specify input handling
semantics. This interface should be suitable for the implementation of
many desktop shell components, and a broad number of other applications
that interact with the desktop.
</description>
<request name="get_layer_surface">
<description summary="create a layer_surface from a surface">
Create a layer surface for an existing surface. This assigns the role of
layer_surface, or raises a protocol error if another role is already
assigned.
Creating a layer surface from a wl_surface which has a buffer attached
or committed is a client error, and any attempts by a client to attach
or manipulate a buffer prior to the first layer_surface.configure call
must also be treated as errors.
After creating a layer_surface object and setting it up, the client
must perform an initial commit without any buffer attached.
The compositor will reply with a layer_surface.configure event.
The client must acknowledge it and is then allowed to attach a buffer
to map the surface.
You may pass NULL for output to allow the compositor to decide which
output to use. Generally this will be the one that the user most
recently interacted with.
Clients can specify a namespace that defines the purpose of the layer
surface.
</description>
<arg name="id" type="new_id" interface="zwlr_layer_surface_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="output" type="object" interface="wl_output" allow-null="true"/>
<arg name="layer" type="uint" enum="layer" summary="layer to add this surface to"/>
<arg name="namespace" type="string" summary="namespace for the layer surface"/>
</request>
<enum name="error">
<entry name="role" value="0" summary="wl_surface has another role"/>
<entry name="invalid_layer" value="1" summary="layer value is invalid"/>
<entry name="already_constructed" value="2" summary="wl_surface has a buffer attached or committed"/>
</enum>
<enum name="layer">
<description summary="available layers for surfaces">
These values indicate which layers a surface can be rendered in. They
are ordered by z depth, bottom-most first. Traditional shell surfaces
will typically be rendered between the bottom and top layers.
Fullscreen shell surfaces are typically rendered at the top layer.
Multiple surfaces can share a single layer, and ordering within a
single layer is undefined.
</description>
<entry name="background" value="0"/>
<entry name="bottom" value="1"/>
<entry name="top" value="2"/>
<entry name="overlay" value="3"/>
</enum>
<!-- Version 3 additions -->
<request name="destroy" type="destructor" since="3">
<description summary="destroy the layer_shell object">
This request indicates that the client will not use the layer_shell
object any more. Objects that have been created through this instance
are not affected.
</description>
</request>
</interface>
<interface name="zwlr_layer_surface_v1" version="4">
<description summary="layer metadata interface">
An interface that may be implemented by a wl_surface, for surfaces that
are designed to be rendered as a layer of a stacked desktop-like
environment.
Layer surface state (layer, size, anchor, exclusive zone,
margin, interactivity) is double-buffered, and will be applied at the
time wl_surface.commit of the corresponding wl_surface is called.
Attaching a null buffer to a layer surface unmaps it.
Unmapping a layer_surface means that the surface cannot be shown by the
compositor until it is explicitly mapped again. The layer_surface
returns to the state it had right after layer_shell.get_layer_surface.
The client can re-map the surface by performing a commit without any
buffer attached, waiting for a configure event and handling it as usual.
</description>
<request name="set_size">
<description summary="sets the size of the surface">
Sets the size of the surface in surface-local coordinates. The
compositor will display the surface centered with respect to its
anchors.
If you pass 0 for either value, the compositor will assign it and
inform you of the assignment in the configure event. You must set your
anchor to opposite edges in the dimensions you omit; not doing so is a
protocol error. Both values are 0 by default.
Size is double-buffered, see wl_surface.commit.
</description>
<arg name="width" type="uint"/>
<arg name="height" type="uint"/>
</request>
<request name="set_anchor">
<description summary="configures the anchor point of the surface">
Requests that the compositor anchor the surface to the specified edges
and corners. If two orthogonal edges are specified (e.g. 'top' and
'left'), then the anchor point will be the intersection of the edges
(e.g. the top left corner of the output); otherwise the anchor point
will be centered on that edge, or in the center if none is specified.
Anchor is double-buffered, see wl_surface.commit.
</description>
<arg name="anchor" type="uint" enum="anchor"/>
</request>
<request name="set_exclusive_zone">
<description summary="configures the exclusive geometry of this surface">
Requests that the compositor avoids occluding an area with other
surfaces. The compositor's use of this information is
implementation-dependent - do not assume that this region will not
actually be occluded.
A positive value is only meaningful if the surface is anchored to one
edge or an edge and both perpendicular edges. If the surface is not
anchored, anchored to only two perpendicular edges (a corner), anchored
to only two parallel edges or anchored to all edges, a positive value
will be treated the same as zero.
A positive zone is the distance from the edge in surface-local
coordinates to consider exclusive.
Surfaces that do not wish to have an exclusive zone may instead specify
how they should interact with surfaces that do. If set to zero, the
surface indicates that it would like to be moved to avoid occluding
surfaces with a positive exclusive zone. If set to -1, the surface
indicates that it would not like to be moved to accommodate for other
surfaces, and the compositor should extend it all the way to the edges
it is anchored to.
For example, a panel might set its exclusive zone to 10, so that
maximized shell surfaces are not shown on top of it. A notification
might set its exclusive zone to 0, so that it is moved to avoid
occluding the panel, but shell surfaces are shown underneath it. A
wallpaper or lock screen might set their exclusive zone to -1, so that
they stretch below or over the panel.
The default value is 0.
Exclusive zone is double-buffered, see wl_surface.commit.
</description>
<arg name="zone" type="int"/>
</request>
<request name="set_margin">
<description summary="sets a margin from the anchor point">
Requests that the surface be placed some distance away from the anchor
point on the output, in surface-local coordinates. Setting this value
for edges you are not anchored to has no effect.
The exclusive zone includes the margin.
Margin is double-buffered, see wl_surface.commit.
</description>
<arg name="top" type="int"/>
<arg name="right" type="int"/>
<arg name="bottom" type="int"/>
<arg name="left" type="int"/>
</request>
<enum name="keyboard_interactivity">
<description summary="types of keyboard interaction possible for a layer shell surface">
Types of keyboard interaction possible for layer shell surfaces. The
rationale for this is twofold: (1) some applications are not interested
in keyboard events and not allowing them to be focused can improve the
desktop experience; (2) some applications will want to take exclusive
keyboard focus.
</description>
<entry name="none" value="0">
<description summary="no keyboard focus is possible">
This value indicates that this surface is not interested in keyboard
events and the compositor should never assign it the keyboard focus.
This is the default value, set for newly created layer shell surfaces.
This is useful for e.g. desktop widgets that display information or
only have interaction with non-keyboard input devices.
</description>
</entry>
<entry name="exclusive" value="1">
<description summary="request exclusive keyboard focus">
Request exclusive keyboard focus if this surface is above the shell surface layer.
For the top and overlay layers, the seat will always give
exclusive keyboard focus to the top-most layer which has keyboard
interactivity set to exclusive. If this layer contains multiple
surfaces with keyboard interactivity set to exclusive, the compositor
determines the one receiving keyboard events in an implementation-
defined manner. In this case, no guarantee is made when this surface
will receive keyboard focus (if ever).
For the bottom and background layers, the compositor is allowed to use
normal focus semantics.
This setting is mainly intended for applications that need to ensure
they receive all keyboard events, such as a lock screen or a password
prompt.
</description>
</entry>
<entry name="on_demand" value="2" since="4">
<description summary="request regular keyboard focus semantics">
This requests the compositor to allow this surface to be focused and
unfocused by the user in an implementation-defined manner. The user
should be able to unfocus this surface even regardless of the layer
it is on.
Typically, the compositor will want to use its normal mechanism to
manage keyboard focus between layer shell surfaces with this setting
and regular toplevels on the desktop layer (e.g. click to focus).
Nevertheless, it is possible for a compositor to require a special
interaction to focus or unfocus layer shell surfaces (e.g. requiring
a click even if focus follows the mouse normally, or providing a
keybinding to switch focus between layers).
This setting is mainly intended for desktop shell components (e.g.
panels) that allow keyboard interaction. Using this option can allow
implementing a desktop shell that can be fully usable without the
mouse.
</description>
</entry>
</enum>
<request name="set_keyboard_interactivity">
<description summary="requests keyboard events">
Set how keyboard events are delivered to this surface. By default,
layer shell surfaces do not receive keyboard events; this request can
be used to change this.
This setting is inherited by child surfaces set by the get_popup
request.
Layer surfaces receive pointer, touch, and tablet events normally. If
you do not want to receive them, set the input region on your surface
to an empty region.
Keyboard interactivity is double-buffered, see wl_surface.commit.
</description>
<arg name="keyboard_interactivity" type="uint" enum="keyboard_interactivity"/>
</request>
<request name="get_popup">
<description summary="assign this layer_surface as an xdg_popup parent">
This assigns an xdg_popup's parent to this layer_surface. This popup
should have been created via xdg_surface::get_popup with the parent set
to NULL, and this request must be invoked before committing the popup's
initial state.
See the documentation of xdg_popup for more details about what an
xdg_popup is and how it is used.
</description>
<arg name="popup" type="object" interface="xdg_popup"/>
</request>
<request name="ack_configure">
<description summary="ack a configure event">
When a configure event is received, if a client commits the
surface in response to the configure event, then the client
must make an ack_configure request sometime before the commit
request, passing along the serial of the configure event.
If the client receives multiple configure events before it
can respond to one, it only has to ack the last configure event.
A client is not required to commit immediately after sending
an ack_configure request - it may even ack_configure several times
before its next surface commit.
A client may send multiple ack_configure requests before committing, but
only the last request sent before a commit indicates which configure
event the client really is responding to.
</description>
<arg name="serial" type="uint" summary="the serial from the configure event"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the layer_surface">
This request destroys the layer surface.
</description>
</request>
<event name="configure">
<description summary="suggest a surface change">
The configure event asks the client to resize its surface.
Clients should arrange their surface for the new states, and then send
an ack_configure request with the serial sent in this configure event at
some point before committing the new surface.
The client is free to dismiss all but the last configure event it
received.
The width and height arguments specify the size of the window in
surface-local coordinates.
The size is a hint, in the sense that the client is free to ignore it if
it doesn't resize, pick a smaller size (to satisfy aspect ratio or
resize in steps of NxM pixels). If the client picks a smaller size and
is anchored to two opposite anchors (e.g. 'top' and 'bottom'), the
surface will be centered on this axis.
If the width or height arguments are zero, it means the client should
decide its own window dimension.
</description>
<arg name="serial" type="uint"/>
<arg name="width" type="uint"/>
<arg name="height" type="uint"/>
</event>
<event name="closed">
<description summary="surface should be closed">
The closed event is sent by the compositor when the surface will no
longer be shown. The output may have been destroyed or the user may
have asked for it to be removed. Further changes to the surface will be
ignored. The client should destroy the resource after receiving this
event, and create a new surface if they so choose.
</description>
</event>
<enum name="error">
<entry name="invalid_surface_state" value="0" summary="provided surface state is invalid"/>
<entry name="invalid_size" value="1" summary="size is invalid"/>
<entry name="invalid_anchor" value="2" summary="anchor bitfield is invalid"/>
<entry name="invalid_keyboard_interactivity" value="3" summary="keyboard interactivity is invalid"/>
</enum>
<enum name="anchor" bitfield="true">
<entry name="top" value="1" summary="the top edge of the anchor rectangle"/>
<entry name="bottom" value="2" summary="the bottom edge of the anchor rectangle"/>
<entry name="left" value="4" summary="the left edge of the anchor rectangle"/>
<entry name="right" value="8" summary="the right edge of the anchor rectangle"/>
</enum>
<!-- Version 2 additions -->
<request name="set_layer" since="2">
<description summary="change the layer of the surface">
Change the layer that the surface is rendered on.
Layer is double-buffered, see wl_surface.commit.
</description>
<arg name="layer" type="uint" enum="zwlr_layer_shell_v1.layer" summary="layer to move this surface to"/>
</request>
</interface>
</protocol>

554
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-output-management-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,554 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_output_management_unstable_v1">
<copyright>
Copyright © 2019 Purism SPC
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.
</copyright>
<description summary="protocol to configure output devices">
This protocol exposes interfaces to obtain and modify output device
configuration.
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="zwlr_output_manager_v1" version="2">
<description summary="output device configuration manager">
This interface is a manager that allows reading and writing the current
output device configuration.
Output devices that display pixels (e.g. a physical monitor or a virtual
output in a window) are represented as heads. Heads cannot be created nor
destroyed by the client, but they can be enabled or disabled and their
properties can be changed. Each head may have one or more available modes.
Whenever a head appears (e.g. a monitor is plugged in), it will be
advertised via the head event. Immediately after the output manager is
bound, all current heads are advertised.
Whenever a head's properties change, the relevant wlr_output_head events
will be sent. Not all head properties will be sent: only properties that
have changed need to.
Whenever a head disappears (e.g. a monitor is unplugged), a
wlr_output_head.finished event will be sent.
After one or more heads appear, change or disappear, the done event will
be sent. It carries a serial which can be used in a create_configuration
request to update heads properties.
The information obtained from this protocol should only be used for output
configuration purposes. This protocol is not designed to be a generic
output property advertisement protocol for regular clients. Instead,
protocols such as xdg-output should be used.
</description>
<event name="head">
<description summary="introduce a new head">
This event introduces a new head. This happens whenever a new head
appears (e.g. a monitor is plugged in) or after the output manager is
bound.
</description>
<arg name="head" type="new_id" interface="zwlr_output_head_v1"/>
</event>
<event name="done">
<description summary="sent all information about current configuration">
This event is sent after all information has been sent after binding to
the output manager object and after any subsequent changes. This applies
to child head and mode objects as well. In other words, this event is
sent whenever a head or mode is created or destroyed and whenever one of
their properties has been changed. Not all state is re-sent each time
the current configuration changes: only the actual changes are sent.
This allows changes to the output configuration to be seen as atomic,
even if they happen via multiple events.
A serial is sent to be used in a future create_configuration request.
</description>
<arg name="serial" type="uint" summary="current configuration serial"/>
</event>
<request name="create_configuration">
<description summary="create a new output configuration object">
Create a new output configuration object. This allows to update head
properties.
</description>
<arg name="id" type="new_id" interface="zwlr_output_configuration_v1"/>
<arg name="serial" type="uint"/>
</request>
<request name="stop">
<description summary="stop sending events">
Indicates the client no longer wishes to receive events for output
configuration changes. However the compositor may emit further events,
until the finished event is emitted.
The client must not send any more requests after this one.
</description>
</request>
<event name="finished">
<description summary="the compositor has finished with the manager">
This event indicates that the compositor is done sending manager events.
The compositor will destroy the object immediately after sending this
event, so it will become invalid and the client should release any
resources associated with it.
</description>
</event>
</interface>
<interface name="zwlr_output_head_v1" version="2">
<description summary="output device">
A head is an output device. The difference between a wl_output object and
a head is that heads are advertised even if they are turned off. A head
object only advertises properties and cannot be used directly to change
them.
A head has some read-only properties: modes, name, description and
physical_size. These cannot be changed by clients.
Other properties can be updated via a wlr_output_configuration object.
Properties sent via this interface are applied atomically via the
wlr_output_manager.done event. No guarantees are made regarding the order
in which properties are sent.
</description>
<event name="name">
<description summary="head name">
This event describes the head name.
The naming convention is compositor defined, but limited to alphanumeric
characters and dashes (-). Each name is unique among all wlr_output_head
objects, but if a wlr_output_head object is destroyed the same name may
be reused later. The names will also remain consistent across sessions
with the same hardware and software configuration.
Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do
not assume that the name is a reflection of an underlying DRM
connector, X11 connection, etc.
If the compositor implements the xdg-output protocol and this head is
enabled, the xdg_output.name event must report the same name.
The name event is sent after a wlr_output_head object is created. This
event is only sent once per object, and the name does not change over
the lifetime of the wlr_output_head object.
</description>
<arg name="name" type="string"/>
</event>
<event name="description">
<description summary="head description">
This event describes a human-readable description of the head.
The description is a UTF-8 string with no convention defined for its
contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11
output via :1'. However, do not assume that the name is a reflection of
the make, model, serial of the underlying DRM connector or the display
name of the underlying X11 connection, etc.
If the compositor implements xdg-output and this head is enabled,
the xdg_output.description must report the same description.
The description event is sent after a wlr_output_head object is created.
This event is only sent once per object, and the description does not
change over the lifetime of the wlr_output_head object.
</description>
<arg name="description" type="string"/>
</event>
<event name="physical_size">
<description summary="head physical size">
This event describes the physical size of the head. This event is only
sent if the head has a physical size (e.g. is not a projector or a
virtual device).
</description>
<arg name="width" type="int" summary="width in millimeters of the output"/>
<arg name="height" type="int" summary="height in millimeters of the output"/>
</event>
<event name="mode">
<description summary="introduce a mode">
This event introduces a mode for this head. It is sent once per
supported mode.
</description>
<arg name="mode" type="new_id" interface="zwlr_output_mode_v1"/>
</event>
<event name="enabled">
<description summary="head is enabled or disabled">
This event describes whether the head is enabled. A disabled head is not
mapped to a region of the global compositor space.
When a head is disabled, some properties (current_mode, position,
transform and scale) are irrelevant.
</description>
<arg name="enabled" type="int" summary="zero if disabled, non-zero if enabled"/>
</event>
<event name="current_mode">
<description summary="current mode">
This event describes the mode currently in use for this head. It is only
sent if the output is enabled.
</description>
<arg name="mode" type="object" interface="zwlr_output_mode_v1"/>
</event>
<event name="position">
<description summary="current position">
This events describes the position of the head in the global compositor
space. It is only sent if the output is enabled.
</description>
<arg name="x" type="int"
summary="x position within the global compositor space"/>
<arg name="y" type="int"
summary="y position within the global compositor space"/>
</event>
<event name="transform">
<description summary="current transformation">
This event describes the transformation currently applied to the head.
It is only sent if the output is enabled.
</description>
<arg name="transform" type="int" enum="wl_output.transform"/>
</event>
<event name="scale">
<description summary="current scale">
This events describes the scale of the head in the global compositor
space. It is only sent if the output is enabled.
</description>
<arg name="scale" type="fixed"/>
</event>
<event name="finished">
<description summary="the head has been destroyed">
The compositor will destroy the object immediately after sending this
event, so it will become invalid and the client should release any
resources associated with it.
</description>
</event>
<!-- Version 2 additions -->
<event name="make" since="2">
<description summary="head manufacturer">
This event describes the manufacturer of the head.
This must report the same make as the wl_output interface does in its
geometry event.
Together with the model and serial_number events the purpose is to
allow clients to recognize heads from previous sessions and for example
load head-specific configurations back.
It is not guaranteed this event will be ever sent. A reason for that
can be that the compositor does not have information about the make of
the head or the definition of a make is not sensible in the current
setup, for example in a virtual session. Clients can still try to
identify the head by available information from other events but should
be aware that there is an increased risk of false positives.
It is not recommended to display the make string in UI to users. For
that the string provided by the description event should be preferred.
</description>
<arg name="make" type="string"/>
</event>
<event name="model" since="2">
<description summary="head model">
This event describes the model of the head.
This must report the same model as the wl_output interface does in its
geometry event.
Together with the make and serial_number events the purpose is to
allow clients to recognize heads from previous sessions and for example
load head-specific configurations back.
It is not guaranteed this event will be ever sent. A reason for that
can be that the compositor does not have information about the model of
the head or the definition of a model is not sensible in the current
setup, for example in a virtual session. Clients can still try to
identify the head by available information from other events but should
be aware that there is an increased risk of false positives.
It is not recommended to display the model string in UI to users. For
that the string provided by the description event should be preferred.
</description>
<arg name="model" type="string"/>
</event>
<event name="serial_number" since="2">
<description summary="head serial number">
This event describes the serial number of the head.
Together with the make and model events the purpose is to allow clients
to recognize heads from previous sessions and for example load head-
specific configurations back.
It is not guaranteed this event will be ever sent. A reason for that
can be that the compositor does not have information about the serial
number of the head or the definition of a serial number is not sensible
in the current setup. Clients can still try to identify the head by
available information from other events but should be aware that there
is an increased risk of false positives.
It is not recommended to display the serial_number string in UI to
users. For that the string provided by the description event should be
preferred.
</description>
<arg name="serial_number" type="string"/>
</event>
</interface>
<interface name="zwlr_output_mode_v1" version="2">
<description summary="output mode">
This object describes an output mode.
Some heads don't support output modes, in which case modes won't be
advertised.
Properties sent via this interface are applied atomically via the
wlr_output_manager.done event. No guarantees are made regarding the order
in which properties are sent.
</description>
<event name="size">
<description summary="mode size">
This event describes the mode size. The size is given in physical
hardware units of the output device. This is not necessarily the same as
the output size in the global compositor space. For instance, the output
may be scaled or transformed.
</description>
<arg name="width" type="int" summary="width of the mode in hardware units"/>
<arg name="height" type="int" summary="height of the mode in hardware units"/>
</event>
<event name="refresh">
<description summary="mode refresh rate">
This event describes the mode's fixed vertical refresh rate. It is only
sent if the mode has a fixed refresh rate.
</description>
<arg name="refresh" type="int" summary="vertical refresh rate in mHz"/>
</event>
<event name="preferred">
<description summary="mode is preferred">
This event advertises this mode as preferred.
</description>
</event>
<event name="finished">
<description summary="the mode has been destroyed">
The compositor will destroy the object immediately after sending this
event, so it will become invalid and the client should release any
resources associated with it.
</description>
</event>
</interface>
<interface name="zwlr_output_configuration_v1" version="2">
<description summary="output configuration">
This object is used by the client to describe a full output configuration.
First, the client needs to setup the output configuration. Each head can
be either enabled (and configured) or disabled. It is a protocol error to
send two enable_head or disable_head requests with the same head. It is a
protocol error to omit a head in a configuration.
Then, the client can apply or test the configuration. The compositor will
then reply with a succeeded, failed or cancelled event. Finally the client
should destroy the configuration object.
</description>
<enum name="error">
<entry name="already_configured_head" value="1"
summary="head has been configured twice"/>
<entry name="unconfigured_head" value="2"
summary="head has not been configured"/>
<entry name="already_used" value="3"
summary="request sent after configuration has been applied or tested"/>
</enum>
<request name="enable_head">
<description summary="enable and configure a head">
Enable a head. This request creates a head configuration object that can
be used to change the head's properties.
</description>
<arg name="id" type="new_id" interface="zwlr_output_configuration_head_v1"
summary="a new object to configure the head"/>
<arg name="head" type="object" interface="zwlr_output_head_v1"
summary="the head to be enabled"/>
</request>
<request name="disable_head">
<description summary="disable a head">
Disable a head.
</description>
<arg name="head" type="object" interface="zwlr_output_head_v1"
summary="the head to be disabled"/>
</request>
<request name="apply">
<description summary="apply the configuration">
Apply the new output configuration.
In case the configuration is successfully applied, there is no guarantee
that the new output state matches completely the requested
configuration. For instance, a compositor might round the scale if it
doesn't support fractional scaling.
After this request has been sent, the compositor must respond with an
succeeded, failed or cancelled event. Sending a request that isn't the
destructor is a protocol error.
</description>
</request>
<request name="test">
<description summary="test the configuration">
Test the new output configuration. The configuration won't be applied,
but will only be validated.
Even if the compositor succeeds to test a configuration, applying it may
fail.
After this request has been sent, the compositor must respond with an
succeeded, failed or cancelled event. Sending a request that isn't the
destructor is a protocol error.
</description>
</request>
<event name="succeeded">
<description summary="configuration changes succeeded">
Sent after the compositor has successfully applied the changes or
tested them.
Upon receiving this event, the client should destroy this object.
If the current configuration has changed, events to describe the changes
will be sent followed by a wlr_output_manager.done event.
</description>
</event>
<event name="failed">
<description summary="configuration changes failed">
Sent if the compositor rejects the changes or failed to apply them. The
compositor should revert any changes made by the apply request that
triggered this event.
Upon receiving this event, the client should destroy this object.
</description>
</event>
<event name="cancelled">
<description summary="configuration has been cancelled">
Sent if the compositor cancels the configuration because the state of an
output changed and the client has outdated information (e.g. after an
output has been hotplugged).
The client can create a new configuration with a newer serial and try
again.
Upon receiving this event, the client should destroy this object.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the output configuration">
Using this request a client can tell the compositor that it is not going
to use the configuration object anymore. Any changes to the outputs
that have not been applied will be discarded.
This request also destroys wlr_output_configuration_head objects created
via this object.
</description>
</request>
</interface>
<interface name="zwlr_output_configuration_head_v1" version="2">
<description summary="head configuration">
This object is used by the client to update a single head's configuration.
It is a protocol error to set the same property twice.
</description>
<enum name="error">
<entry name="already_set" value="1" summary="property has already been set"/>
<entry name="invalid_mode" value="2" summary="mode doesn't belong to head"/>
<entry name="invalid_custom_mode" value="3" summary="mode is invalid"/>
<entry name="invalid_transform" value="4" summary="transform value outside enum"/>
<entry name="invalid_scale" value="5" summary="scale negative or zero"/>
</enum>
<request name="set_mode">
<description summary="set the mode">
This request sets the head's mode.
</description>
<arg name="mode" type="object" interface="zwlr_output_mode_v1"/>
</request>
<request name="set_custom_mode">
<description summary="set a custom mode">
This request assigns a custom mode to the head. The size is given in
physical hardware units of the output device. If set to zero, the
refresh rate is unspecified.
It is a protocol error to set both a mode and a custom mode.
</description>
<arg name="width" type="int" summary="width of the mode in hardware units"/>
<arg name="height" type="int" summary="height of the mode in hardware units"/>
<arg name="refresh" type="int" summary="vertical refresh rate in mHz or zero"/>
</request>
<request name="set_position">
<description summary="set the position">
This request sets the head's position in the global compositor space.
</description>
<arg name="x" type="int" summary="x position in the global compositor space"/>
<arg name="y" type="int" summary="y position in the global compositor space"/>
</request>
<request name="set_transform">
<description summary="set the transform">
This request sets the head's transform.
</description>
<arg name="transform" type="int" enum="wl_output.transform"/>
</request>
<request name="set_scale">
<description summary="set the scale">
This request sets the head's scale.
</description>
<arg name="scale" type="fixed"/>
</request>
</interface>
</protocol>

128
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-output-power-management-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,128 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_output_power_management_unstable_v1">
<copyright>
Copyright © 2019 Purism SPC
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="Control power management modes of outputs">
This protocol allows clients to control power management modes
of outputs that are currently part of the compositor space. The
intent is to allow special clients like desktop shells to power
down outputs when the system is idle.
To modify outputs not currently part of the compositor space see
wlr-output-management.
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="zwlr_output_power_manager_v1" version="1">
<description summary="manager to create per-output power management">
This interface is a manager that allows creating per-output power
management mode controls.
</description>
<request name="get_output_power">
<description summary="get a power management for an output">
Create an output power management mode control that can be used to
adjust the power management mode for a given output.
</description>
<arg name="id" type="new_id" interface="zwlr_output_power_v1"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
All objects created by the manager will still remain valid, until their
appropriate destroy request has been called.
</description>
</request>
</interface>
<interface name="zwlr_output_power_v1" version="1">
<description summary="adjust power management mode for an output">
This object offers requests to set the power management mode of
an output.
</description>
<enum name="mode">
<entry name="off" value="0"
summary="Output is turned off."/>
<entry name="on" value="1"
summary="Output is turned on, no power saving"/>
</enum>
<enum name="error">
<entry name="invalid_mode" value="1" summary="nonexistent power save mode"/>
</enum>
<request name="set_mode">
<description summary="Set an outputs power save mode">
Set an output's power save mode to the given mode. The mode change
is effective immediately. If the output does not support the given
mode a failed event is sent.
</description>
<arg name="mode" type="uint" enum="mode" summary="the power save mode to set"/>
</request>
<event name="mode">
<description summary="Report a power management mode change">
Report the power management mode change of an output.
The mode event is sent after an output changed its power
management mode. The reason can be a client using set_mode or the
compositor deciding to change an output's mode.
This event is also sent immediately when the object is created
so the client is informed about the current power management mode.
</description>
<arg name="mode" type="uint" enum="mode"
summary="the output's new power management mode"/>
</event>
<event name="failed">
<description summary="object no longer valid">
This event indicates that the output power management mode control
is no longer valid. This can happen for a number of reasons,
including:
- The output doesn't support power management
- Another client already has exclusive power management mode control
for this output
- The output disappeared
Upon receiving this event, the client should destroy this object.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy this power management">
Destroys the output power management mode control object.
</description>
</request>
</interface>
</protocol>

232
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-screencopy-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,232 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_screencopy_unstable_v1">
<copyright>
Copyright © 2018 Simon Ser
Copyright © 2019 Andri Yngvason
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="screen content capturing on client buffers">
This protocol allows clients to ask the compositor to copy part of the
screen content to a client buffer.
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="zwlr_screencopy_manager_v1" version="3">
<description summary="manager to inform clients and begin capturing">
This object is a manager which offers requests to start capturing from a
source.
</description>
<request name="capture_output">
<description summary="capture an output">
Capture the next frame of an entire output.
</description>
<arg name="frame" type="new_id" interface="zwlr_screencopy_frame_v1"/>
<arg name="overlay_cursor" type="int"
summary="composite cursor onto the frame"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="capture_output_region">
<description summary="capture an output's region">
Capture the next frame of an output's region.
The region is given in output logical coordinates, see
xdg_output.logical_size. The region will be clipped to the output's
extents.
</description>
<arg name="frame" type="new_id" interface="zwlr_screencopy_frame_v1"/>
<arg name="overlay_cursor" type="int"
summary="composite cursor onto the frame"/>
<arg name="output" type="object" interface="wl_output"/>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
All objects created by the manager will still remain valid, until their
appropriate destroy request has been called.
</description>
</request>
</interface>
<interface name="zwlr_screencopy_frame_v1" version="3">
<description summary="a frame ready for copy">
This object represents a single frame.
When created, a series of buffer events will be sent, each representing a
supported buffer type. The "buffer_done" event is sent afterwards to
indicate that all supported buffer types have been enumerated. The client
will then be able to send a "copy" request. If the capture is successful,
the compositor will send a "flags" followed by a "ready" event.
For objects version 2 or lower, wl_shm buffers are always supported, ie.
the "buffer" event is guaranteed to be sent.
If the capture failed, the "failed" event is sent. This can happen anytime
before the "ready" event.
Once either a "ready" or a "failed" event is received, the client should
destroy the frame.
</description>
<event name="buffer">
<description summary="wl_shm buffer information">
Provides information about wl_shm buffer parameters that need to be
used for this frame. This event is sent once after the frame is created
if wl_shm buffers are supported.
</description>
<arg name="format" type="uint" enum="wl_shm.format" summary="buffer format"/>
<arg name="width" type="uint" summary="buffer width"/>
<arg name="height" type="uint" summary="buffer height"/>
<arg name="stride" type="uint" summary="buffer stride"/>
</event>
<request name="copy">
<description summary="copy the frame">
Copy the frame to the supplied buffer. The buffer must have a the
correct size, see zwlr_screencopy_frame_v1.buffer and
zwlr_screencopy_frame_v1.linux_dmabuf. The buffer needs to have a
supported format.
If the frame is successfully copied, a "flags" and a "ready" events are
sent. Otherwise, a "failed" event is sent.
</description>
<arg name="buffer" type="object" interface="wl_buffer"/>
</request>
<enum name="error">
<entry name="already_used" value="0"
summary="the object has already been used to copy a wl_buffer"/>
<entry name="invalid_buffer" value="1"
summary="buffer attributes are invalid"/>
</enum>
<enum name="flags" bitfield="true">
<entry name="y_invert" value="1" summary="contents are y-inverted"/>
</enum>
<event name="flags">
<description summary="frame flags">
Provides flags about the frame. This event is sent once before the
"ready" event.
</description>
<arg name="flags" type="uint" enum="flags" summary="frame flags"/>
</event>
<event name="ready">
<description summary="indicates frame is available for reading">
Called as soon as the frame is copied, indicating it is available
for reading. This event includes the time at which presentation happened
at.
The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples,
each component being an unsigned 32-bit value. Whole seconds are in
tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo,
and the additional fractional part in tv_nsec as nanoseconds. Hence,
for valid timestamps tv_nsec must be in [0, 999999999]. The seconds part
may have an arbitrary offset at start.
After receiving this event, the client should destroy the object.
</description>
<arg name="tv_sec_hi" type="uint"
summary="high 32 bits of the seconds part of the timestamp"/>
<arg name="tv_sec_lo" type="uint"
summary="low 32 bits of the seconds part of the timestamp"/>
<arg name="tv_nsec" type="uint"
summary="nanoseconds part of the timestamp"/>
</event>
<event name="failed">
<description summary="frame copy failed">
This event indicates that the attempted frame copy has failed.
After receiving this event, the client should destroy the object.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="delete this object, used or not">
Destroys the frame. This request can be sent at any time by the client.
</description>
</request>
<!-- Version 2 additions -->
<request name="copy_with_damage" since="2">
<description summary="copy the frame when it's damaged">
Same as copy, except it waits until there is damage to copy.
</description>
<arg name="buffer" type="object" interface="wl_buffer"/>
</request>
<event name="damage" since="2">
<description summary="carries the coordinates of the damaged region">
This event is sent right before the ready event when copy_with_damage is
requested. It may be generated multiple times for each copy_with_damage
request.
The arguments describe a box around an area that has changed since the
last copy request that was derived from the current screencopy manager
instance.
The union of all regions received between the call to copy_with_damage
and a ready event is the total damage since the prior ready event.
</description>
<arg name="x" type="uint" summary="damaged x coordinates"/>
<arg name="y" type="uint" summary="damaged y coordinates"/>
<arg name="width" type="uint" summary="current width"/>
<arg name="height" type="uint" summary="current height"/>
</event>
<!-- Version 3 additions -->
<event name="linux_dmabuf" since="3">
<description summary="linux-dmabuf buffer information">
Provides information about linux-dmabuf buffer parameters that need to
be used for this frame. This event is sent once after the frame is
created if linux-dmabuf buffers are supported.
</description>
<arg name="format" type="uint" summary="fourcc pixel format"/>
<arg name="width" type="uint" summary="buffer width"/>
<arg name="height" type="uint" summary="buffer height"/>
</event>
<event name="buffer_done" since="3">
<description summary="all buffer types reported">
This event is sent once after all buffer events have been sent.
The client should proceed to create a buffer of one of the supported
types, and send a "copy" request.
</description>
</event>
</interface>
</protocol>

152
third-party/vendor/wayland-protocols/wlr-protocols/unstable/wlr-virtual-pointer-unstable-v1.xml vendored Normal file
View file

@ -0,0 +1,152 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wlr_virtual_pointer_unstable_v1">
<copyright>
Copyright © 2019 Josef Gajdusek
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="zwlr_virtual_pointer_v1" version="2">
<description summary="virtual pointer">
This protocol allows clients to emulate a physical pointer device. The
requests are mostly mirror opposites of those specified in wl_pointer.
</description>
<enum name="error">
<entry name="invalid_axis" value="0"
summary="client sent invalid axis enumeration value" />
<entry name="invalid_axis_source" value="1"
summary="client sent invalid axis source enumeration value" />
</enum>
<request name="motion">
<description summary="pointer relative motion event">
The pointer has moved by a relative amount to the previous request.
Values are in the global compositor space.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="dx" type="fixed" summary="displacement on the x-axis"/>
<arg name="dy" type="fixed" summary="displacement on the y-axis"/>
</request>
<request name="motion_absolute">
<description summary="pointer absolute motion event">
The pointer has moved in an absolute coordinate frame.
Value of x can range from 0 to x_extent, value of y can range from 0
to y_extent.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="x" type="uint" summary="position on the x-axis"/>
<arg name="y" type="uint" summary="position on the y-axis"/>
<arg name="x_extent" type="uint" summary="extent of the x-axis"/>
<arg name="y_extent" type="uint" summary="extent of the y-axis"/>
</request>
<request name="button">
<description summary="button event">
A button was pressed or released.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="button" type="uint" summary="button that produced the event"/>
<arg name="state" type="uint" enum="wl_pointer.button_state" summary="physical state of the button"/>
</request>
<request name="axis">
<description summary="axis event">
Scroll and other axis requests.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="axis" type="uint" enum="wl_pointer.axis" summary="axis type"/>
<arg name="value" type="fixed" summary="length of vector in touchpad coordinates"/>
</request>
<request name="frame">
<description summary="end of a pointer event sequence">
Indicates the set of events that logically belong together.
</description>
</request>
<request name="axis_source">
<description summary="axis source event">
Source information for scroll and other axis.
</description>
<arg name="axis_source" type="uint" enum="wl_pointer.axis_source" summary="source of the axis event"/>
</request>
<request name="axis_stop">
<description summary="axis stop event">
Stop notification for scroll and other axes.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="axis" type="uint" enum="wl_pointer.axis" summary="the axis stopped with this event"/>
</request>
<request name="axis_discrete">
<description summary="axis click event">
Discrete step information for scroll and other axes.
This event allows the client to extend data normally sent using the axis
event with discrete value.
</description>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
<arg name="axis" type="uint" enum="wl_pointer.axis" summary="axis type"/>
<arg name="value" type="fixed" summary="length of vector in touchpad coordinates"/>
<arg name="discrete" type="int" summary="number of steps"/>
</request>
<request name="destroy" type="destructor" since="1">
<description summary="destroy the virtual pointer object"/>
</request>
</interface>
<interface name="zwlr_virtual_pointer_manager_v1" version="2">
<description summary="virtual pointer manager">
This object allows clients to create individual virtual pointer objects.
</description>
<request name="create_virtual_pointer">
<description summary="Create a new virtual pointer">
Creates a new virtual pointer. The optional seat is a suggestion to the
compositor.
</description>
<arg name="seat" type="object" interface="wl_seat" allow-null="true"/>
<arg name="id" type="new_id" interface="zwlr_virtual_pointer_v1"/>
</request>
<request name="destroy" type="destructor" since="1">
<description summary="destroy the virtual pointer manager"/>
</request>
<!-- Version 2 additions -->
<request name="create_virtual_pointer_with_output" since="2">
<description summary="Create a new virtual pointer">
Creates a new virtual pointer. The seat and the output arguments are
optional. If the seat argument is set, the compositor should assign the
input device to the requested seat. If the output argument is set, the
compositor should map the input device to the requested output.
</description>
<arg name="seat" type="object" interface="wl_seat" allow-null="true"/>
<arg name="output" type="object" interface="wl_output" allow-null="true"/>
<arg name="id" type="new_id" interface="zwlr_virtual_pointer_v1"/>
</request>
</interface>
</protocol>

7
third-party/vendor/wayland-protocols/wlr-protocols/wlr-protocols.pc.in vendored Normal file
View file

@ -0,0 +1,7 @@
prefix=@prefix@
datarootdir=@datarootdir@
pkgdatadir=${pc_sysrootdir}@datadir@/wlr-protocols
Name: wlroots Wayland protocols
Description: Wayland protocol files
Version: 1.0