PeterCxy/wl-mitm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Include all known protocols from wayland-explorer

Browse source 
Also adjust the build scripts so that we don't just export one big Rust
file...
This commit is contained in:
Peter Cai 2025-03-02 18:19:23 -05:00
parent e0cc002148
commit 76f4ae4a73
124 changed files with 30269 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
.vscode/settings.json vendored Normal file
View file

@ -0,0 +1,3 @@
{
"rust-analyzer.cargo.targetDir": "target/rust-analyzer"
}

14
build.rs
View file

@ -1,17 +1,7 @@
use std::{env, path::Path};
fn main() {
let out_dir = env::var_os("OUT_DIR").unwrap();
let out_file = Path::new(&out_dir).join("proto_generated.rs");
let out_dir = std::env::var_os("OUT_DIR").unwrap();
std::fs::write(&out_file, protogen::generate_from_dir("proto"))
.expect("unable to write to file");
// If rustfmt is present, run rustfmt so that the generated file is somewhat human-readable
std::process::Command::new("rustfmt")
.arg(out_file.to_str().expect("utf8 error"))
.output()
.ok();
protogen::generate_from_dir(&out_dir, "proto");
println!("cargo::rerun-if-changed=build.rs");
println!("cargo::rerun-if-changed=proto");

84
proto/agl-screenshooter.xml Normal file
View file

@ -0,0 +1,84 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="agl_screenshooter">
<copyright>
Copyright © 2020 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="agl_screenshooter" version="1">
<description summary="agl screenshooter">
agl compositor extension that performs a screenshot of the output, which
is represented by a 'wl_output' object.
A client would call 'take_shot' request and wait until the compositor
finishes to write the data to a wayland buffer, moment in which signals
back the client with the help of the 'done' event. Clients should wait
until the 'done' event is received, if they want to take another
screenshot, or take another screnshot of a different output.
The client must provide a wl_shm-based wl_buffer of the correct size when
taking a shot. The compositor will write the shot into the wl_buffer and then
send the 'done' event that signals completion of writing the data.
Once the compositor has finished to transfer the data back into the supplied
wayland buffer, the client should be able to transfer it to a popular
file format on the disk.
</description>
<enum name="done_status">
<entry name="success" value="0"/>
<entry name="no_memory" value="1"/>
<entry name="bad_buffer" value="2"/>
</enum>
<request name="take_shot">
<description summary="performs a screenshot">
Takes a screenshot of the wayland output represented by a 'wl_output'
object. Clients should first retrieve it using global registry, as well
as the 'wl_shm' object in order to create a wayland buffer type of
object ('wl_buffer').
Clients can derive the stride and size from the 'wl_output' object, and
later on use those when creating shm-based 'wl_buffer', as well as supplying
the pixel format.
</description>
<arg name="output" type="object" interface="wl_output"/>
<arg name="buffer" type="object" interface="wl_buffer"/>
</request>
<event name="done">
<description summary="sent when 'take_shot' finished">
Even sent back to notify client 'take_shot' request has completed.
</description>
<arg name="status" type="uint" enum="done_status" />
</event>
<request name="destroy" type="destructor">
<description summary="destroy main object">
Destroys the 'weston_screenshooter' interface.
</description>
</request>
</interface>
</protocol>

163
proto/agl-shell-desktop.xml Normal file
View file

@ -0,0 +1,163 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="agl_shell_desktop">
<copyright>
Copyright © 2020 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="agl_shell_desktop" version="2">
<description summary="Private extension to allow applications activate other apps">
This extension can be used by regular application to instruct to compositor
to activate or switch to other running (regular) applications. The client
is responsible for filtering their own app_id when receiving application id.
The compositor will allow clients to bind to this interface only if the
policy engine allows it.
</description>
<enum name="app_role">
<entry name="popup" value="0"/>
<entry name="fullscreen" value="1"/>
<entry name="split_vertical" value="2"/>
<entry name="split_horizontal" value="3"/>
<entry name="remote" value="4"/>
</enum>
<enum name="app_state">
<entry name="activated" value="0"/>
<entry name="deactivated" value="1"/>
<entry name="destroyed" value="2"/>
</enum>
<event name="application">
<description summary="advertise application id">
The compositor may choose to advertise one or more application ids which
can be used to activate/switch to.
When this global is bound, the compositor will send all application ids
available for activation, but may send additional application id at any
time (when they've been mapped in the compositor).
</description>
<arg name="app_id" type="string"/>
</event>
<request name="activate_app">
<description summary="make client current window">
Ask the compositor to make a toplevel to become the current/focused
window for window management purposes.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="app_data" type="string" allow-null="true"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="set_app_property">
<description summary="set properties for a client identified by app_id">
Ask the compositor to make a top-level window obey the 'app_role' enum
and, depending on that role, to use some of the arguments as initial
values to take into account.
Note that x, y, bx, by, width and height would only make sense for the
pop-up role, with the output argument being applicable to all the roles.
The width and height values define the maximum area which the
top-level window should be placed into. Note this doesn't correspond to
top-level surface size, but to a bounding box which will be used to
clip the surface to, in case the surface area extends that of this
bounding box. Both of these values need to be larger than 0 (zero) to be
taken into account by the compositor. Any negative values for the width
and height will be discarded.
The x and y values will serve as the (initial) position values.
The bx and by values are the top-left x and y value of the bounding box.
Any clipping happening to the bounding box will not affect the surface
size or the position of the underlying surface backing the top-level
window. The bx and by values, like the positional values, could be
both set to zero, or even negative values. The compositor will pass
those on without any further validation.
The initial position values and the bounding rectangle will still be
in effect on a subsequent activation request of the 'app_id', assuming
it was previously de-activated at some point in time.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="role" type="uint" enum="app_role"/>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="bx" type="int"/>
<arg name="by" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="deactivate_app">
<description summary="de-activate/hide window identified by app_id">
Ask the compositor to hide the toplevel window for window
management purposes. Depending on the window role, this request
will either display the previously active window (or the background
in case there's no previously active surface) or temporarily (or
until a 'activate_app' is called upon) hide the surface. All
the surfaces are identifiable by using the app_id, and no actions are
taken in case the app_id is not/was not present.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
</request>
<event name="state_app">
<description summary="event sent when application has suffered state modification">
Notifies application(s) when other application have suffered state modifications.
</description>
<arg name="app_id" type="string"/>
<arg name="app_data" type="string" allow-null="true"/>
<arg name="state" type="uint" enum="app_state"/>
<arg name="role" type="uint" enum="app_role"/>
</event>
<!-- Version 2 addition -->
<request name="set_app_property_mode" since="2">
<description summary="Request to change the application properties lifetime">
Use this request to inform the compositor to maintain a pending state
for an app_id being set with set_app_property() request. Any
subsequent application matching that app_id would survive a potential
application destruction. Note that this request will take effect
globally on all applications.
To turn it on, or off, use the 'permanent' argument. Initially,
the compositor will have this option set to off. Note that it
doesn't matter the order of this request with respect to
set_app_property() request, as the changes will only take effect
when the application itself does the commit with an app_id set,
therefore the only requirement is to call this request before
the app_id client does its first commit.
</description>
<arg name="permanent" type="uint"/>
</request>
</interface>
</protocol>

482
proto/agl-shell.xml Normal file
View file

@ -0,0 +1,482 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="agl_shell">
<copyright>
Copyright © 2019, 2022 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="agl_shell" version="11">
<description summary="user interface for Automotive Grade Linux platform">
Starting with version 2 of the protocol, the client is required to wait
for the 'bound_ok' or 'bound_fail' events in order to proceed further.
In case the client gets a 'bound_fail' event then it should consider that
there's another client already bound to the agl_shell protocol.
A client that receives a 'bound_ok' event should consider that there's
no other client already bound to the interface and can proceed further.
If the client uses an older version of the protocol it will receive
automatically an error and the compositor will terminate the connection,
if there's another client already bound the interface.
If the client receives the 'bound_fail' event and attempts to use the
interface further it will receive an error and the compositor will
terminate the connection. After the 'bound_fail' event was received the
client should call the destructor, which has been added with version 2
of the protocol. The client is free to try at a later point in time to
see if it will receive the 'bound_ok' event, but there's no explicit way
of finding out when that event will be delivered.
It is assumed that it can infer that information through other
means/other channels.
</description>
<enum name="error">
<entry name="invalid_argument" value="0"/>
<entry name="background_exists" value="1"/>
<entry name="panel_exists" value="2"/>
</enum>
<enum name="edge">
<entry name="top" value="0"/>
<entry name="bottom" value="1"/>
<entry name="left" value="2"/>
<entry name="right" value="3"/>
</enum>
<enum name="app_state" since="3">
<entry name="started" value="0"/>
<entry name="terminated" value="1"/>
<entry name="activated" value="2"/>
<entry name="deactivated" value="3"/>
</enum>
<enum name="tile_orientation" since="11">
<entry name="none" value="0"/>
<entry name="left" value="1"/>
<entry name="right" value="2"/>
<entry name="top" value="3"/>
<entry name="bottom" value="4"/>
</enum>
<request name="ready">
<description summary="client is ready to be shown">
Tell the server that this client is ready to be shown. The server
will delay presentation during start-up until all shell clients are
ready to be shown, and will display a black screen instead.
This gives the client an opportunity to set up and configure several
surfaces into a coherent interface.
The client that binds to this interface must send this request, otherwise
they may stall the compositor unnecessarily.
If this request is called after the compositor has already finished
start-up, no operation is performed.
</description>
</request>
<request name="set_background">
<description summary="set surface as output's background">
Set the surface to act as the background of an output. After this
request, the server will immediately send a configure event with
the dimensions the client should use to cover the entire output.
The surface must have a "desktop" surface role, as supported by
libweston-desktop.
Only a single surface may be the background for any output. If a
background surface already exists, a protocol error is raised.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="set_panel">
<description summary="set surface as panel">
Set the surface to act as a panel of an output. The 'edge' argument
says what edge of the output the surface will be anchored to.
After this request, the server will send a configure event with the
corresponding width/height that the client should use, and 0 for the
other dimension. E.g. if the edge is 'top', the width will be the
output's width, and the height will be 0.
The surface must have a "desktop" surface role, as supported by
libweston-desktop.
The compositor will take the panel's window geometry into account when
positioning other windows, so the panels are not covered.
XXX: What happens if e.g. both top and left are used at the same time?
Who gets to have the corner?
Only a single surface may be the panel for an output's edge. If a
surface already exists on an edge, a protocol error is raised.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="output" type="object" interface="wl_output"/>
<arg name="edge" type="uint" enum="edge"/>
</request>
<request name="activate_app">
<description summary="make client current window">
Ask the compositor to make a toplevel to become the current/focused
window for window management purposes.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
If multiple toplevels have the same app_id, the result is unspecified.
XXX: Do we need feedback to say it didn't work? (e.g. client does
not exist)
</description>
<arg name="app_id" type="string"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<event name="bound_ok" since="2">
<description summary="event sent if binding was ok">
Informs the client that it was able to bind the agl_shell
interface succesfully. Clients are required to wait for this
event before continuing further.
</description>
</event>
<event name="bound_fail" since="2">
<description summary="event sent if binding was nok">
Informs the client that binding to the agl_shell interface was
unsuccesfull. Clients are required to wait for this event for
continuing further.
</description>
</event>
<request name="destroy" type="destructor" since="2">
<description summary="destroys the factory object">
</description>
</request>
<event name="app_state" since="3">
<description summary="event sent when an application suffered state modification">
Informs the client that an application has changed its state to another,
specified by the app_state enum. Client can use this event to track
current application state. For instance to know when the application has
started, or when terminated/stopped.
</description>
<arg name="app_id" type="string"/>
<arg name="state" type="uint" enum="app_state"/>
</event>
<request name="set_activate_region" since="4">
<description summary="sets a specific region to activate">
A hint for the compositor to use a custom area, rather than
inferring the activation area. If any panels are used
the compositor computes the activation area by subtracting the
panels geometry area. If no panels are used then the entire output
is being used. This request changes that as to hint the compositor
to use the supplied rectangle and ignore any potential panels
that might been set-up previously.
In order for this request to take effect it will need to happen
before the 'ready' request in order for the compositor to make use of it.
Note that any 'set_panel' request be will not be honored, if this request
has been called.
The x and y coordinates use the top-left corner as the origin. The
rectangle area shouldn't exceed the output area, while an area smaller
than the output, would basically result in showing up the background
surface.
</description>
<arg name="output" type="object" interface="wl_output"/>
<arg name="x" type="int" summary="x position of rectangle"/>
<arg name="y" type="int" summary="y position of rectangle"/>
<arg name="width" type="int" summary="width of rectangle"/>
<arg name="height" type="int" summary="height of rectangle"/>
</request>
<request name="deactivate_app" since="5">
<description summary="de-activate/hide window identified by app_id">
Ask the compositor to hide the toplevel window for window
management purposes. Depending on the window role, this request
will either display the previously active window (or the background
in case there's no previously active surface) or temporarily (or
until a 'activate_app' is called upon) hide the surface.
All the surfaces are identifiable by using the app_id, and no actions
are taken in case the app_id is not/was not present.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
</request>
<request name="set_app_float" since="6">
<description summary="set the window identified by app_id as float">
Makes the application identified by app_id as floating. If the
application's window is already mapped, in a maximized, normal state,
it would transition to the float state.
For applications that want to modify their own state, this request
must be done before the initial surface commit in order to take effect.
If the application is already in floating state, this request wouldn't
do anything.
There's no persistence of this request, once the application terminated
you'll to issue this request again for that particular app_id.
The x, and y values would be initial position of the window where the
window surface will be placed.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="x" type="int" summary="x position"/>
<arg name="y" type="int" summary="y position"/>
</request>
<request name="set_app_normal" since="6">
<description summary="set the window identified by app_id as normally started">
Returns the application identified by app_id as it was in the normal state.
This is useful to come back from other states to the maximized state, the
normal state applications are started.
</description>
<arg name="app_id" type="string"/>
</request>
<request name="set_app_fullscreen" since="7">
<description summary="">
Makes the application identified by app_id as fullscreen. If the
application's window is already mapped, in a maximized, normal state,
it would transition to the fullscreen state.
For applications that want to modify their own state, this request
must be done before the initial surface commit in order to take effect.
If the application is already in fullscreen state, this request wouldn't
do anything.
There's no persistence of this request, once the application terminated
you'll to issue this request again for that particular app_id.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
</request>
<request name="set_app_output" since="8">
<description summary="assign an application to a particular output">
this would allow the compositor to place an application on a particular
output, if that output is indeed available. this can happen before
application is started which would make the application start on that
particular output. if the application is already started it would
move the application to that output.
there's no persistence of this request, once the application terminated
you'll need to issue this request again for that particular app_id.
see xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<event name="app_on_output" since="8">
<description summary="Event sent as a reponse to set_app_output">
Clients can use this event to be notified when an application
wants to be displayed on a certain output. This event is sent in
response to the set_app_output request.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="output_name" type="string"/>
</event>
<request name="set_app_position" since="9">
<description summary="move window to a specific position">
Clients can inform the compositor to position a floating type of window
at the specific location, pointed by x and y value. If the window is
not a floating type, the request will be discarded. Note that
positioning doesn't take output into consideration nor does orientation
of the outpus. It is expected that the client knows already where the
position is localed in global coordonate space. If the window doesn't
exist the compositor will ignore the request. For this request to
function properly the window would first to be set as floating and then
it can be moved using this request.
see xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
</request>
<request name="set_app_scale" since="10">
<description summary="scale window to a specific rectangle">
Clients can inform the compositor to scale a floating type of window
to the values specified in width and height. If the window is
not a floating type, the request will be discarded. If the window
doesn't exist the compositor will ignore the request. For this request
to function properly the window would first to be set as floating
and then it can be moved using this request.
see xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</request>
<request name="set_app_split" since="11">
<description summary="set the application with a split orientation">
This requests asks the compositor to change the application from the
original mode (whatever that might be) to a split, tiled orientation
mode defined in the tile orientation enum.
Clients need to implement resizing (to handle xdg-shell configure
events) for this to work correctly.
This request only handles a single level of tiling for practical
reasons: to keep implementation simple and straight forward. The
compositor will ignore requests if there are already two windows
present. The client can verify this request succeed by checking the
xdg-shell configure event and with it, the states sent
by the compositor.
If there's no app_id with the supplied name, the compositor will add
the app to a pending list in order to be applied when an application
gets started, or if the application sets its application after the
initial wl_surface.commit request.
Applications can use this approach if they want to be started in a
tiled orientation position, before creating the xdg-shell toplevel role.
A none orientation type would make the window go back to the original
maximized mode. If two windows are side by side, returning one of them
back the original mode would mean the other one will be made hidden
and the one doing the request for the none orientation will become
the currently active window. A further activation, using activate_app
request for the other window would make that one active.
Closing the window in the tiled orientation state implies that either
the background surface will displayed, or in case there was another
applications being shown at that time, will make that application be
returned to the original, maximized state.
The tiled orientation could be applied independently of each other,
such that a client can transition from one tiled orientation to
another. Note that any other window already present would literally
take the opposite orientation with the one currently being changed. So
tiled orientation modification automatically implies a tile orientation
for any other application already present/active at that time.
In case there's already a client active at that time, it will be
attributed automatically the opposite tiled orientation, such that two
concurrent applications can be displayed at the same time.
The orientation tiles can not be combined, and only state at a time
can be active. Only horizontal and vertical tiling is possible. A
horizontal and vertical tile orientation simultaneously is not
possible.
Input focus is being delivered to the last started/activated window,
such that users can cycle between that one or the other, assumes there's
another window in the first place.
A width size can also be specified for the split window. Note that this
width can't exceed the output width value, or the compositor can choose
to ignore this value.
Making the split window sticky would inform the compositor that the
window should always be active when switching or when activating between
other windows. This would allow navigating, starting and activating other
windows while keeping the current window always in a split state.
See xdg_toplevel.set_app_id from the xdg-shell protocol for a
description of app_id.
</description>
<arg name="app_id" type="string"/>
<arg name="orientation" type="uint" enum="tile_orientation"/>
<arg name="width" type="int" summary="width of the window being split"/>
<arg name="sticky" type="int" summary="make the split window stiky"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
</interface>
<interface name="agl_shell_ext" version="1">
<description summary="extended user interface for Automotive Grade Linux platform">
This interface allows another client bind to the agl_shell interface,
while there's another shell client already present.
The client should first bind to this interface and then inform the
compositor with the 'doas_shell_client' request and it wants to bind to
the agl_shell interface. The client is still expected, if using a new
version of the agl_shell interface, to wait for the 'bound_ok' and
'bound_fail' events before issueing any other requests/events.
Note that this interface has its limitations, and the compositor would
still refuse the act for 'set_panel' or 'set_background' requests
of the agl_shell interface if there's already a client that used them.
Any other requests or events should be delievered and handled as it would
a client bound to the agl_shell interface.
</description>
<enum name="doas_shell_client_status">
<entry name="success" value="0"/>
<entry name="failed" value="1"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroys the factory object">
Call the destructor once you're ready with agl_shell_ext interface.
This would reset the state and would make any requests made
on the agl_shell interface be terminated. The client would need
to bind again the agl_shell_ext and issue a 'doas_shell_client'
request.
</description>
</request>
<request name="doas_shell_client">
<description summary="Informs the compositor it wants to bind to the
agl_shell interface">
Prior to binding to agl_shell interface, this request would inform
the compositor that it wants to gain access the agl_shell interface.
The client is expected to wait for 'doas_shell_client_done' event and
check for a successful status before going further with binding to
the agl_shell interface.
</description>
</request>
<event name="doas_done">
<description summary="event sent as a reply to doas_shell_client">
The client should check the status event to verify that the
compositor was able to handle the request.
</description>
<arg name="status" type="uint" enum="doas_shell_client_status"/>
</event>
</interface>
</protocol>

103
proto/alpha-modifier-v1.xml Normal file
View file

@ -0,0 +1,103 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="alpha_modifier_v1">
<copyright>
Copyright © 2024 Xaver Hugl
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_alpha_modifier_v1" version="1">
<description summary="surface alpha modifier manager">
This interface allows a client to set a factor for the alpha values on a
surface, which can be used to offload such operations to the compositor,
which can in turn for example offload them to KMS.
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>
<request name="destroy" type="destructor">
<description summary="destroy the alpha modifier manager object">
Destroy the alpha modifier manager. This doesn't destroy objects
created with the manager.
</description>
</request>
<enum name="error">
<entry name="already_constructed" value="0"
summary="wl_surface already has a alpha modifier object"/>
</enum>
<request name="get_surface">
<description summary="create a new alpha modifier surface object">
Create a new alpha modifier surface object associated with the
given wl_surface. If there is already such an object associated with
the wl_surface, the already_constructed error will be raised.
</description>
<arg name="id" type="new_id" interface="wp_alpha_modifier_surface_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
</interface>
<interface name="wp_alpha_modifier_surface_v1" version="1">
<description summary="alpha modifier object for a surface">
This interface allows the client to set a factor for the alpha values on
a surface, which can be used to offload such operations to the compositor.
The default factor is UINT32_MAX.
This object has to be destroyed before the associated wl_surface. Once the
wl_surface is destroyed, all request on this object will raise the
no_surface error.
</description>
<enum name="error">
<entry name="no_surface" value="0" summary="wl_surface was destroyed"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroy the alpha modifier object">
This destroys the object, and is equivalent to set_multiplier with
a value of UINT32_MAX, with the same double-buffered semantics as
set_multiplier.
</description>
</request>
<request name="set_multiplier">
<description summary="specify the alpha multiplier">
Sets the alpha multiplier for the surface. The alpha multiplier is
double-buffered state, see wl_surface.commit for details.
This factor is applied in the compositor's blending space, as an
additional step after the processing of per-pixel alpha values for the
wl_surface. The exact meaning of the factor is thus undefined, unless
the blending space is specified in a different extension.
This multiplier is applied even if the buffer attached to the
wl_surface doesn't have an alpha channel; in that case an alpha value
of one is used instead.
Zero means completely transparent, UINT32_MAX means completely opaque.
</description>
<arg name="factor" type="uint"/>
</request>
</interface>
</protocol>

40
proto/appmenu.xml Normal file
View file

@ -0,0 +1,40 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="appmenu">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2017 David Edmundson
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="org_kde_kwin_appmenu_manager" version="2">
<description summary="appmenu dbus address interface">
This interface allows a client to link a window (or wl_surface) to an com.canonical.dbusmenu
interface registered on DBus.
</description>
<request name="create">
<arg name="id" type="new_id" interface="org_kde_kwin_appmenu"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<!-- version 2 additions-->
<request name="release" type="destructor" since="2">
<description summary="destroy the org_kde_kwin_appmenu_manager object" />
</request>
</interface>
<interface name="org_kde_kwin_appmenu" version="2">
<description summary="appmenu dbus address interface">
The DBus service name and object path where the appmenu interface is present
The object should be registered on the session bus before sending this request.
If not applicable, clients should remove this object.
</description>
<request name="set_address">
<description summary="initialise or update the location of the AppMenu interface">
Set or update the service name and object path.
Strings should be formatted in Latin-1 matching the relevant DBus specifications.
</description>
<arg name="service_name" type="string" />
<arg name="object_path" type="string" />
</request>
<request name="release" type="destructor">
<description summary="release the appmenu object"/>
</request>
</interface>
</protocol>

228
proto/aura-output-management.xml Normal file
View file

@ -0,0 +1,228 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="aura_output_management">
<copyright>
Copyright 2024 The Chromium Authors
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="zaura_output_manager_v2" version="1">
<description summary="aura output manager singleton">
A global responsible for propagating atomic output configuration changes
to clients. An output configuration is a union of added / removed outputs
and updated output metrics.
Added outputs arrive at the client as wl_registry.global events, removed
outputs as wl_registry.global_remove events and updated output metrics as
a sequence of events defined on the zaura_output_manager_v2 interface.
This is followed by the manager's done event which signals the end of the
transaction.
The change should be processed by clients in a way that transitions from
one output configuration state to another without exposing the
intermediate output state to the rest of the application.
Participating servers should emit the zaura_output_manager_v2 global
before any wl_output globals in the sequence of wl_registry.global events.
Participating clients should bind the zaura_output_manager_v2 before any
wl_output globals. This ordering is required to ensure clients receive all
necessary output configuration information before receiving any further
server events that may reference bound wl_outputs.
Clients can expect that all events comprising a configuration change are
sent synchronously, one after the other, before any other server events
that leverage the output as an event param.
</description>
<event name="done" since="1">
<description
summary="sent all information about the output configuration change">
This event is sent after all added, changed and removed output events
for a given wl_output have been dispatched to the client.
</description>
</event>
<event name="display_id" since="1">
<description summary="advertise the output's display id">
This event describes the 64bit display id assigned to each display by
ChromeOS. The value is opaque and should not be interpreted.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<arg name="display_id_hi" type="uint" />
<arg name="display_id_lo" type="uint" />
</event>
<event name="logical_position" since="1">
<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 event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<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" since="1">
<description summary="size of the output in the global compositor space">
The logical_size event describes the logical size of the output in the
global compositor space.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<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="physical_size" since="1">
<description summary="size of the output in pixels">
The physical resolution of the display in pixels. The value should not
include any overscan insets or display rotation, except for any panel
orientation adjustment.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<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="work_area_insets" since="1">
<description summary="advertise the work area insets for the output">
This event describes the work area insets for the output in logical
screen coordinates, from which the work area can be calculated.
The event is sent when binding to the output object and subsequently as
output state changes.
</description>
<arg name="output_name" type="uint" />
<arg name="top" type="int" />
<arg name="left" type="int" />
<arg name="bottom" type="int" />
<arg name="right" type="int" />
</event>
<event name="device_scale_factor" since="1">
<description summary="advertise device scale factor for the output">
The scale factor of the output device. We reinterpret_cast the float
scale factor into a 32-bit uint and later cast back into a float. This
is because wayland does not support native transport of floats. As
different CPU architectures may use different endian representations for
IEEE 754 floats, this protocol implicitly assumes that the caller and
receiver are the same machine.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<arg name="device_scale_factor" type="uint"
summary="display scale factor, in float format" />
</event>
<event name="logical_transform" since="1">
<description summary="logical transform of the output">
This event describes the logical transform for the output. Whereas
panel transform corresponds to the display's panel rotation, the logical
transform corresponds to the display's logical rotation.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<arg name="transform" type="int" enum="wl_output.transform"
summary="transform that maps framebuffer to output" />
</event>
<event name="panel_transform" since="1">
<description summary="panel transform of the output">
This event describes the panel transform for the output, which is the
associated display's panel rotation.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<arg name="transform" type="int" enum="wl_output.transform"
summary="transform that maps framebuffer to output" />
</event>
<event name="name" since="1">
<description summary="human-readable name of this output">
The name is a UTF-8 string with no convention defined for its contents.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<arg name="name" type="string" summary="output name" />
</event>
<event name="description" since="1">
<description summary="human-readable description of this output">
The description is a UTF-8 string with no convention defined for its
contents.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<arg name="description" type="string" summary="output description" />
</event>
<event name="overscan_insets" since="1">
<description summary="advertise the overscan insets for the output">
This event describes the overscan insets for the output in physical
pixels.
The event is sent immediately after the wl_registry.global event for the
output and subsequently in latter display configuration changes.
</description>
<arg name="output_name" type="uint" />
<arg name="top" type="int" />
<arg name="left" type="int" />
<arg name="bottom" type="int" />
<arg name="right" type="int" />
</event>
<event name="activated" since="1">
<description summary="target display for new windows">
Notifies that this output is now active output. It is typically used as
a target when a new window is created without specific bounds.
</description>
<arg name="output_name" type="uint" />
</event>
</interface>
</protocol>

1672
proto/aura-shell.xml Normal file
View file

File diff suppressed because it is too large Load diff

28
proto/blur.xml Normal file
View file

@ -0,0 +1,28 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="blur">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2015 Martin Gräßlin
SPDX-FileCopyrightText: 2015 Marco Martin
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="org_kde_kwin_blur_manager" version="1">
<request name="create">
<arg name="id" type="new_id" interface="org_kde_kwin_blur"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="unset">
<arg name="surface" type="object" interface="wl_surface"/>
</request>
</interface>
<interface name="org_kde_kwin_blur" version="1">
<request name="commit">
</request>
<request name="set_region">
<arg name="region" type="object" interface="wl_region" allow-null="true"/>
</request>
<request name="release" type="destructor">
<description summary="release the blur object"/>
</request>
</interface>
</protocol>

800
proto/chrome-color-management.xml Normal file
View file

@ -0,0 +1,800 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="chrome_color_management">
<!--
NOTE: This protocol was forked from an upstream proposal. Once that proposal
is approved, we'll migrate to it. The proposal can be found at:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
-->
<copyright>
Copyright 2019 Sebastian Wick
Copyright 2019 Erwin Burema
Copyright 2020 AMD
Copyright 2020 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="color management protocol">
This protocol specifies a way for a client to set the color space and
HDR metadata of a surface and to get information about the color spaces
and HDR capabilities of outputs.
This protocol is based on a proposed upstream protocol, which we will migrate
to once it is approved. It may diverge from the proposed upstream protocol
over the course of our development.
</description>
<interface name="zcr_color_manager_v1" version="6">
<description summary="color manager singleton">
A global interface used for getting color management surface and color
management output objects as well as creating color space objects from
ICC profiles, parameters, or enumerated names.
</description>
<enum name="eotf_names">
<description summary="well-known EOTF names">
Names that describe a well-known EOTF.
A compositor must support all of these based on the protocol interface
version.
</description>
<!-- TODO EOTFs -->
<!-- <entry name="bt1886" value="" summary="BT.1886 transfer function"/> -->
<!-- <entry name="dci_p3" value="" summary="DCI-P3 transfer function"/> -->
<entry name="unknown" value="0" summary="unknown EOTF"/>
<entry name="linear" value="1" summary="Linear transfer function"/>
<entry name="srgb" value="2" summary="sRGB transfer function"/>
<entry name="bt2087" value="3" summary="BT.2087 transfer function"/>
<entry name="adobergb" value="4" summary="AdobeRGB transfer function"/>
<entry name="pq" value="5" summary="Perceptual quantizer / SMPTEST2084"/>
<entry name="hlg" value="6" summary="hybrid log gamma" since="2"/>
<entry name="bt709" value="7" summary="gamma for rec709 encoded videos" since="2"/>
<entry name="extendedsrgb10" value="8" summary="sRGB transfer function with headroom for HDR" since="2"/>
<entry name="smpte170m" value="9" summary="SMPTE240M transfer function" since="5"/>
<entry name="smpte240m" value="10" summary="SMPTE240M transfer function" since="5"/>
<entry name="smptest428_1" value="11" summary="SMPTEST428_1 transfer function" since="5"/>
<entry name="log" value="12" summary="LOG transfer function" since="5"/>
<entry name="log_sqrt" value="13" summary="LOG Sqrt transfer function" since="5"/>
<entry name="iec61966_2_4" value="14" summary="IEC61966_2_4 transfer function" since="5"/>
<entry name="bt1361_ecg" value="15" summary="BT1361_ECG transfer function" since="5"/>
<entry name="bt2020_10" value="16" summary="BT2020_10 transfer function" since="5"/>
<entry name="bt2020_12" value="17" summary="BT2020_12 transfer function" since="5"/>
<entry name="scrgb_linear_80_nits" value="18" summary="SCRGB Linear transfer function" since="5"/>
<entry name="gamma18" value="19" summary="GAMMA18 transfer function" since="5"/>
<entry name="gamma28" value="20" summary="GAMMA28 transfer function" since="5"/>
<entry name="srgb_hdr" value="21" summary="sRGB transfer function" since="6"/>
</enum>
<enum name="chromaticity_names">
<description summary="well-known chromaticity names">
Names that describe well-known chromaticities.
A compositor must support all of these based on the protocol interface
version.
</description>
<entry name="unknown" value="0" summary="unknown chromaticity"/>
<entry name="bt601_525_line" value="1"
summary="ITU-R BT.601 http://www.itu.int/rec/R-REC-BT.601/en"/>
<entry name="bt601_625_line" value="2"
summary="ITU-R BT.601 http://www.itu.int/rec/R-REC-BT.601/en"/>
<entry name="smpte170m" value="3"
summary="SMPTE 170M-1999 https://www.itu.int/rec/R-REC-BT.1700/en"/>
<entry name="bt709" value="4"
summary="ITU-R BT.709 https://www.itu.int/rec/R-REC-BT.709/en"/>
<entry name="bt2020" value="5"
summary="ITU-R BT.2020 http://www.itu.int/rec/R-REC-BT.2020/en"/>
<entry name="srgb" value="6"
summary="IEC/4WD 61966-2-1: sRGB https://webstore.iec.ch/publication/6169"/>
<entry name="displayp3" value="7"
summary="Display P3 https://developer.apple.com/reference/coregraphics/cgcolorspace/1408916-displayp3"/>
<entry name="adobergb" value="8"
summary="Adobe RGB https://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf"/>
<entry name="wide_gamut_color_spin" value="9"
summary="" since="5"/>
<entry name="bt470m" value="10"
summary="" since="5"/>
<entry name="smpte240m" value="11"
summary="" since="5"/>
<entry name="xyz_d50" value="12"
summary="" since="5"/>
<entry name="smptest428_1" value="13"
summary="" since="5"/>
<entry name="smptest431_2" value="14"
summary="" since="5"/>
<entry name="film" value="15"
summary="" since="5"/>
</enum>
<enum name="whitepoint_names">
<description summary="well-known whitepoint names">
Names that describe well-known whitepoints.
A compositor must support all of these based on the protocol interface
version.
</description>
<!-- TODO Whitepoints -->
<!-- <entry name="d55" value="" summary="D55 whitepoint"/> -->
<entry name="unknown" value="0" summary="unknown whitepoint"/>
<entry name="dci" value="1" summary="DCI whitepoint"/>
<entry name="d50" value="2" summary="D50 whitepoint"/>
<entry name="d65" value="3" summary="D65 whitepoint"/>
</enum>
<enum name="error">
<entry name="icc_fd" value="0" summary="given ICC fd has bad properties"/>
<entry name="bad_enum" value="1" summary="bad value given as a well-known name"/>
<entry name="bad_param" value="2" summary="bad parameter value"/>
</enum>
<request name="create_color_space_from_icc">
<description summary="create a color space object from ICC profiles">
Create a color space object from an ICC profile. This request returns
a zcr_color_space_creator_v1 object which either returns an error
or the successfully created zcr_color_space_v1 object.
The description of the color space to create is sent in the form of an
ICC profile as a file descriptor in the argument icc.
The fd must be seekable and the maximum size of the ICC profile is 4 MB.
Violating these requirements will raise an icc_fd protocol error. A
compositor must not modify the contents of the file, and the fd may be
sealed for writes and size changes.
The file contents must represent a valid ICC profile.
The ICC profile version must be 2 or 4, it must be a 3 channel profile
and the class must be 'input', 'output', 'abstract' or 'display'.
Violating these requirements will not result in a protocol error but
raise the zcr_color_space_creator_v1.error event.
See the zcr_color_space_v1 and zcr_color_space_creator_v1 interface for
more details about the created object.
See the specification from International Color Consortium for more
details about ICC profiles, also known as ISO 15076-1:2010.
</description>
<arg name="id" type="new_id" interface="zcr_color_space_creator_v1"/>
<arg name="icc" type="fd"/>
</request>
<request name="create_color_space_from_names">
<description summary="create a color space object from well-known names">
[Deprecated] Create a color space object from well-known names. This request returns
a zcr_color_space_creator_v1 object which either returns an error
or the successfully created zcr_color_space_v1 object.
EOTF, chromaticity and whitepoint must not be unknown. Otherwise, or
if a given value is not listed in the enumeration, the protocol error
bad_enum is raised.
See the zcr_color_space_v1 and zcr_color_space_creator_v1 interface for
more details about the created object. Use create_color_space_from_complete_names
instead.
</description>
<arg name="id" type="new_id" interface="zcr_color_space_creator_v1"/>
<arg name="eotf" type="uint" enum="eotf_names" summary="EOTF"/>
<arg name="chromaticity" type="uint" enum="chromaticity_names" summary="chromaticity"/>
<arg name="whitepoint" type="uint" enum="whitepoint_names" summary="whitepoint"/>
</request>
<request name="create_color_space_from_params">
<description summary="create a color space object from parameters">
[Deprecated] Create a color space object from parameters. This request returns
a zcr_color_space_creator_v1 object which either returns an error
or the successfully created zcr_color_space_v1 object.
EOTF must not be unknown. Otherwise, or if a given EOTF is not listed
in the enumeration, the protocol error bad_enum is raised.
The white point must be inside the triangle created by the red, green
and blue primaries. Otherwise the bad_param protocol error is raised.
All the chromaticity values are multiplied by 10000 to produce the
integers carried by the protocol.
See the zcr_color_space_v1 and zcr_color_space_creator_v1 interface for
more details about the created object. Use create_color_space_from_complete_params
instead.
</description>
<arg name="id" type="new_id" interface="zcr_color_space_creator_v1"/>
<arg name="eotf" type="uint" enum="eotf_names" summary="EOTF"/>
<arg name="primary_r_x" type="uint" summary="red primary X * 10000"/>
<arg name="primary_r_y" type="uint" summary="red primary Y * 10000"/>
<arg name="primary_g_x" type="uint" summary="green primary X * 10000"/>
<arg name="primary_g_y" type="uint" summary="green primary Y * 10000"/>
<arg name="primary_b_x" type="uint" summary="blue primary X * 10000"/>
<arg name="primary_b_y" type="uint" summary="blue primary Y * 10000"/>
<arg name="white_point_x" type="uint" summary="white point X * 10000"/>
<arg name="white_point_y" type="uint" summary="white point Y * 10000"/>
</request>
<request name="get_color_management_output">
<description summary="create a color management interface for a wl_output">
This creates a new zcr_color_management_output_v1 object for the
given wl_output.
See the zcr_color_management_output_v1 interface for more details.
</description>
<arg name="id" type="new_id" interface="zcr_color_management_output_v1"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="get_color_management_surface">
<description summary="create a color management interface for a wl_surface">
This creates a new color zcr_color_management_surface_v1 object for the
given wl_surface.
See the zcr_color_management_surface_v1 interface for more details.
</description>
<arg name="id" type="new_id" interface="zcr_color_management_surface_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the color manager">
Destroy the zcr_color_manager_v1 object. This does not affect any other
objects in any way.
</description>
</request>
<!-- Version 3 additions -->
<enum name="matrix_names">
<description summary="For specifying color matrices">
Names that describe typical ColorSpace Matrix IDs
</description>
<entry name="unknown" value="0" summary="Unknown range"/>
<entry name="rgb" value="1" summary="RGB matrix"/>
<entry name="bt709" value="2" summary="BT709 matrix"/>
<entry name="bt2020_ncl" value="3" summary="BT2020_NCL matrix"/>
<entry name="bt2020_cl" value="4" summary="BT2020_CL matrix"/>
<entry name="fcc" value="5" summary="FCC matrix"/>
<entry name="smpte170m" value="6" summary="SMPTE170M matrix"/>
<entry name="smpte240m" value="7" summary="SMPTE240M matrix"/>
<entry name="ydzdx" value="8" summary="YDZDX matrix" since="5"/>
<entry name="bt470bg" value="9" summary="BT470BG matrix" since="5"/>
<entry name="gbr" value="10" summary="GBR matrix" since="5"/>
<entry name="ycocg" value="11" summary="YCOCG matrix" since="5"/>
</enum>
<enum name="range_names">
<description summary="For specifying RGB ranges">
Names that describe typical RGB value ranges.
</description>
<entry name="unknown" value="0" summary="Unknown range"/>
<entry name="limited" value="1" summary="Limited RGB color range (values from 16-235 for 8-bit)"/>
<entry name="full" value="2" summary="Full RGB color range (values from 0 to 255 for 8-bit)"/>
<entry name="derived" value="3" summary="Range is defined by EOTF/MatrixID"/>
</enum>
<request name="create_color_space_from_complete_names" since="3">
<description summary="create a color space object from well-known names">
Create a color space object from well-known names. This request returns
a zcr_color_space_creator_v1 object which either returns an error
or the successfully created zcr_color_space_v1 object.
EOTF, chromaticity and whitepoint must not be unknown. Otherwise, or
if a given value is not listed in the enumeration, the protocol error
bad_enum is raised.
This request additionally includes matrix and range information.
See the zcr_color_space_v1 and zcr_color_space_creator_v1 interface for
more details about the created object.
</description>
<arg name="id" type="new_id" interface="zcr_color_space_creator_v1"/>
<arg name="eotf" type="uint" enum="eotf_names" summary="EOTF"/>
<arg name="chromaticity" type="uint" enum="chromaticity_names" summary="chromaticity"/>
<arg name="whitepoint" type="uint" enum="whitepoint_names" summary="whitepoint"/>
<arg name="matrix" type="uint" enum="matrix_names" summary="color matrix"/>
<arg name="range" type="uint" enum="range_names" summary="color range"/>
</request>
<request name="create_color_space_from_complete_params" since="3">
<description summary="create a color space object from parameters">
Create a color space object from parameters. This request returns
a zcr_color_space_creator_v1 object which either returns an error
or the successfully created zcr_color_space_v1 object.
EOTF must not be unknown. Otherwise, or if a given EOTF is not listed
in the enumeration, the protocol error bad_enum is raised.
The white point must be inside the triangle created by the red, green
and blue primaries. Otherwise the bad_param protocol error is raised.
All the chromaticity values are multiplied by 10000 to produce the
integers carried by the protocol.
This request additionally includes matrix and range information.
See the zcr_color_space_v1 and zcr_color_space_creator_v1 interface for
more details about the created object.
</description>
<arg name="id" type="new_id" interface="zcr_color_space_creator_v1"/>
<arg name="eotf" type="uint" enum="eotf_names" summary="EOTF"/>
<arg name="matrix" type="uint" enum="matrix_names" summary="Color matrix"/>
<arg name="range" type="uint" enum="range_names" summary="Color range"/>
<arg name="primary_r_x" type="uint" summary="red primary X * 10000"/>
<arg name="primary_r_y" type="uint" summary="red primary Y * 10000"/>
<arg name="primary_g_x" type="uint" summary="green primary X * 10000"/>
<arg name="primary_g_y" type="uint" summary="green primary Y * 10000"/>
<arg name="primary_b_x" type="uint" summary="blue primary X * 10000"/>
<arg name="primary_b_y" type="uint" summary="blue primary Y * 10000"/>
<arg name="white_point_x" type="uint" summary="white point X * 10000"/>
<arg name="white_point_y" type="uint" summary="white point Y * 10000"/>
</request>
</interface>
<interface name="zcr_color_management_output_v1" version="4">
<description summary="output color properties">
A zcr_color_management_output_v1 describes the color properties of an
output.
When zcr_color_management_output_v1 object is created, it will send
its initial events followed by a wl_output.done event. When creating
wl_output and its extension objects, use a final wl_display.sync to
guarantee that all output events have been received across all
extensions.
If the wl_output associated with the zcr_color_management_output_v1 is
destroyed, the zcr_color_management_output_v1 object becomes inert.
</description>
<event name="color_space_changed">
<description summary="color space changed">
The color_space_changed event is sent whenever the color space of the
output changed, followed by one wl_output.done event common to
output events across all extensions.
This is not an initial event.
</description>
</event>
<event name="extended_dynamic_range">
<description summary="output extended dynamic range">
This is both an initial event and sent whenever the value changed.
When the value changed, this event is followed by one wl_output.done
event common to output events across all extensions.
The extended dynamic range value describes how much dynamic range is
available relative to the SDR maximum white. EDR value is proportional
to luminance, and the luminance of black is used as the zero level.
A value of 1.0 means that the the display can not display
anything brighter than SDR maximum white. A value of 3.0 means that the
SDR maximum white is at one third of the highest luminance the display
can produce.
The absolute luminance of the SDR maximum white depends on the monitor
capabilities, the viewing conditions and the viewer personal
preferences. A such, it cannot be given a single value in cd/m².
Compositors using HDR video modes should allow users to control the the
SDR maximum white level which the output EDR value is calculated from.
The SDR maximum white is a relative reference luminance that allows
to tone-map content from different dynamic ranges into a single common
dynamic range for display.
The EDR value is multiplied by 1000 to produce the integer value
carried by the protocol.
</description>
<arg name="value" type="uint" summary="EDR value * 1000"/>
</event>
<request name="get_color_space">
<description summary="get the color space of the output">
This creates a new zcr_color_space_v1 object for the current color space
of the output. There always is exactly one color space active for an
output so the client should destroy the color space created by earlier
invocations of this request. This request is usually sent as a reaction
to the color_space_changed event or when creating a
zcr_color_management_output_v1 object.
The created zcr_color_space_v1 object preserves the color space
of the output from the time the object was created.
The resulting color space object allows get_information request.
See the zcr_color_space_v1 interface for more details.
</description>
<arg name="id" type="new_id" interface="zcr_color_space_v1"/>
</request>
<!-- TODO: HDR capabilities event -->
<request name="destroy" type="destructor">
<description summary="destroy the color management output">
Destroy the color zcr_color_management_output_v1 object. This does not
affect any remaining protocol objects.
</description>
</request>
</interface>
<interface name="zcr_color_management_surface_v1" version="4">
<description summary="color management extension to a surface">
A zcr_color_management_surface_v1 allows the client to set the color
space and HDR properties of a surface.
If the wl_surface associated with the zcr_color_management_surface_v1 is
destroyed, the zcr_color_management_surface_v1 object becomes inert.
</description>
<enum name="render_intent">
<description summary="render intent">
<!-- FIXME: rendering intent is not just a hint -->
Rendering intent allow the client to hint at how to perform color space
transformations.
See the ICC specification for more details about rendering intent.
</description>
<entry name="perceptual" value="0" summary="perceptual"/>
<entry name="relative" value="1" summary="media-relative colorimetric"/>
<entry name="saturation" value="2" summary="saturation"/>
<entry name="absolute" value="3" summary="ICC-absolute colorimetric"/>
<entry name="relative_bpc" value="4" summary="media-relative colorimetric + black point compensation"/>
</enum>
<enum name="alpha_mode">
<description summary="alpha mode">
Specifies whether alpha is pre-multiplied into color channels or not.
If pre-multiplied, the linear alpha value is already multiplied with the
(non-linear) color channel code values in the color channels.
</description>
<entry name="straight" value="0" summary="alpha is independent from color channels"/>
<entry name="premultiplied" value="1" summary="alpha is pre-multiplied into color channels"/>
</enum>
<request name="set_alpha_mode">
<description summary="set the surface alpha mode">
Assuming an alpha channel exists, it is always linear. The alpha mode
determines whether the color channels include alpha pre-multiplied or
not. Using straight alpha might have performance benefits.
Alpha mode is double buffered, and will be applied at the time
wl_surface.commit of the corresponding wl_surface is called.
By default, a surface is assumed to have pre-multiplied alpha.
</description>
<arg name="alpha_mode" type="uint" enum="alpha_mode" summary="alpha mode"/>
</request>
<request name="set_extended_dynamic_range">
<description summary="set the content extended dynamic range">
Set the extended dynamic range (EDR) value for the underlying surface.
The EDR value is double buffered, and will be applied at the time
wl_surface.commit of the corresponding wl_surface is called.
The EDR value describes how much dynamic range is encoded relative to
the SDR maximum white. EDR value is proportional to luminance, using
the luminance of black as the zero level. A value of 1.0 means that the
SDR maximum white is the highest possible luminance of the surface. A
value of 3.0 means that the SDR maximum white is one third of the
highest possible luminance of the surface.
The color space attached to the surface can make the code values in the
buffer non-linear in regards to the luminance. The code value to produce
a third of the luminance of the biggest code value therefore might not
be one third of the biggest code value.
For the definition of the SDR maximum white on an output, see
zcr_color_management_output_v1.extended_dynamic_range. Content
producers are free to choose their SDR maximum white level. How it
shall be displayed depends on the monitor capabilities and the output
EDR value.
By default the EDR value is 1.0. The compositor will tone map the image
to match the EDR of each output the surface is shown on. The aim for
the EDR-EDR mapping is to produce a relative luminance mapping that
looks equally good regardless of the viewing conditions and the monitor
capabilities, assuming the output EDR value was tuned to the output
capabilities and the viewing environment. There might be performance
and image quality benefits from providing content readily tone mapped to
the EDR value of the output the surface is shown on.
The EDR value is multiplied by 1000 to produce the integer value
carried by the protocol.
</description>
<arg name="value" type="uint" summary="EDR value * 1000"/>
</request>
<request name="set_color_space">
<description summary="set the surface color space">
Set the color space of the underlying surface. The color space and
render intent are double buffered, and will be applied
at the time wl_surface.commit of the corresponding wl_surface is called.
<!-- FIXME: same problem as in the render_intent enum -->
The render intent gives the compositor a hint what to optimize for in
color space transformations.
By default, a surface is assumed to have the sRGB color space and an
arbitrary render intent.
If the color space of the surface matches the color space of an output
it is shown on the performance and color accuracy might improve. To find
those color spaces the client can listen to the preferred_color_space or
the wl_surface.enter/leave events. This improvement may require using
the color space object created by
zcr_color_management_output_v1.get_color_space.
</description>
<arg name="color_space" type="object" interface="zcr_color_space_v1"/>
<arg name="render_intent" type="uint" enum="render_intent" summary="render intent"/>
</request>
<request name="set_default_color_space">
<description summary="set the surface color space to default">
This request sets the surface color space to the defaults, see
set_color_space. The setting will be applied at the time
wl_surface.commit of the corresponding wl_surface is called.
</description>
</request>
<!-- TODO: HDR metadata request -->
<event name="preferred_color_space">
<description summary="output for color optimization">
The preferred_color_space event is sent when the compositor determines
or switches the output that implies the preferred color space. The
preferred color space is the one which likely has the most performance
and quality benefits if used by a client for its surface contents.
The event does not carry a zcr_color_space_v1 but a wl_output object.
The concrete zcr_color_space_v1 can be created by calling
zcr_color_management_output_v1.get_color_space on the output and
listening to zcr_color_management_output_v1.color_space_changed
events.
As clients may bind to the same global wl_output multiple
times, this event is sent for each bound instance that matches
the preferred color space output. If a client has not bound to
the right wl_output global at all, this event is not sent.
This is only a hint and clients can set any valid color space with
set_color_space but there might be performance and color accuracy
improvements by providing the surface in the preferred color space.
</description>
<arg name="output" type="object" interface="wl_output"/>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the color management interface for a surface">
Destroy the zcr_color_management_surface_v1 object.
When the last zcr_color_management_surface_v1 object for a wl_surface
is destroyed, the destruction will pend unsetting the wl_surface's
color space, render intent and alpha mode similar to set_color_space
will pend a set.
</description>
</request>
</interface>
<interface name="zcr_color_space_creator_v1" version="4">
<description summary="color space creator">
A zcr_color_space_creator_v1 object returns a created color space
or the error which occured during creation.
Once a zcr_color_space_creator_v1 object has delivered a 'created'
or 'error' event it is automatically destroyed.
</description>
<enum name="creation_error" bitfield="true">
<description summary="color space creation error">
Bitmask of errors which occured while trying to create a color space
</description>
<entry name="malformed_icc" value="0x1" summary="malformed ICC profile"/>
<entry name="bad_icc" value="0x2" summary="ICC profile does not meet requirements"/>
<entry name="bad_primaries" value="0x4" summary="bad primaries"/>
<entry name="bad_whitepoint" value="0x8" summary="bad whitepoint"/>
</enum>
<event name="created">
<description summary="color space object created">
Delivers the successfully created color space.
The resulting color space object does not allow get_information request.
</description>
<arg name="id" type="new_id" interface="zcr_color_space_v1"/>
</event>
<event name="error">
<description summary="color space creation failed">
This event is sent if the color space creation failed.
</description>
<arg name="error" type="uint" enum="creation_error" summary="error bitmask"/>
</event>
</interface>
<interface name="zcr_color_space_v1" version="4">
<description summary="color space">
Refers to a color space which can be attached to a surface
(zcr_color_management_surface_v1.set_color_space). It may provide
information like the ICC profile and the well-known names to allow
clients to know the color space and do color transformations of their
own.
Once created and regardless of how it was created, a zcr_color_space_v1
object always refers to one fixed color space.
The client can create a zcr_color_space_v1 object with
zcr_color_manager_v1 requests or from an output by calling
zcr_color_management_output_v1.get_color_space.
Other extensions may define more zcr_color_space_v1 factory interfaces.
Those interfaces must explicitly specify the interface version for the
object created, otherwise versioning zcr_color_space_v1 correctly
becomes impossible. Using a 'new_id' argument without 'interface'
attribute defined in XML forces code generators to add two explicit
arguments: interface and version. Version is the explicit version
number needed, and interface should be required to be
"zcr_color_space_v1". The compositor supported zcr_color_space_v1
versions are defined by the advertised zcr_color_manager_v1 in
wl_registry.
</description>
<enum name="error">
<entry name="no_information" value="0" summary="get_information disallowed"/>
</enum>
<request name="get_information">
<description summary="get information about the color space">
As a reply to this request, the compositor will send all available
information events describing this color space object and finally
the 'done' event. Other extensions may define more events to be sent
before 'done'.
This request is allowed only on zcr_color_space_v1 objects where the
message that created the object specifies that get_information is
allowed. Otherwise protocol error no_information is raised.
Every get_information request on the same object will always return the
exact same data.
See zcr_color_management_output_v1.get_color_space and
zcr_color_space_creator_v1.created.
</description>
</request>
<event name="icc_file">
<description summary="ICC profile describing the color space">
This event may be sent only as a response to
zcr_color_space_v1.get_information.
The icc argument provides a file descriptor to the client which can be
memory-mapped to provide the ICC profile describing the color space.
The fd must be mapped with MAP_PRIVATE and read-only by the client.
Compositors should send this event always when information is requested.
ICC profiles provide the common foundation which all color managed
clients may rely on.
</description>
<arg name="icc" type="fd" summary="ICC profile file descriptor"/>
<arg name="icc_size" type="uint" summary="ICC profile size, in bytes"/>
</event>
<event name="names">
<description summary="well-known names of a color space">
[Deprecated] This event may be sent only as a response to
zcr_color_space_v1.get_information.
EOTF, chromaticity and whitepoint contain well-known names of those
properties if available and unknown otherwise.
Compositors should not assume that all clients can understand these
names. The names are provided for client convenience. If a client
understands the name triplet, it may ignore other information about
the color space, the ICC profile for example. Use complete_names instead.
</description>
<arg name="eotf" type="uint" enum="zcr_color_manager_v1.eotf_names" summary="EOTF"/>
<arg name="chromaticity" type="uint" enum="zcr_color_manager_v1.chromaticity_names" summary="chromaticity"/>
<arg name="whitepoint" type="uint" enum="zcr_color_manager_v1.whitepoint_names" summary="whitepoint"/>
</event>
<event name="params">
<description summary="RGB primaries along with whitepoint defining color space">
[Deprecated] This event may be sent only as a response to
zcr_color_space_v1.get_information.
The RGB primary value arguments along with the whitepoint value arguments
and eotf can be used to define an arbitrary or custom color space.
The eotf enum contains well known names of that property, but the compositor
should not assume that all clients will understand those names. Use
complete_params instead.
</description>
<arg name="eotf" type="uint" enum="zcr_color_manager_v1.eotf_names" summary="EOTF"/>
<arg name="primary_r_x" type="uint" summary="red primary X * 10000"/>
<arg name="primary_r_y" type="uint" summary="red primary Y * 10000"/>
<arg name="primary_g_x" type="uint" summary="green primary X * 10000"/>
<arg name="primary_g_y" type="uint" summary="green primary Y * 10000"/>
<arg name="primary_b_x" type="uint" summary="blue primary X * 10000"/>
<arg name="primary_b_y" type="uint" summary="blue primary Y * 10000"/>
<arg name="white_point_x" type="uint" summary="white point X * 10000"/>
<arg name="white_point_y" type="uint" summary="white point Y * 10000"/>
</event>
<event name="done">
<description summary="end of color space information">
This event may be sent only as a response to
zcr_color_space_v1.get_information.
This signifies that all color space information events have been
delivered for the object.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the color space">
Destroy the zcr_color_space_v1 object.
Destroying the zcr_color_space_v1 which is active on a surface or an
output does not change the color space of those objects.
</description>
</request>
<!-- Version 3 additions -->
<event name="complete_names" since="3">
<description summary="well-known names of a color space">
This event may be sent only as a response to
zcr_color_space_v1.get_information.
EOTF, chromaticity, matrix, range and whitepoint contain well-known names of those
properties if available and unknown otherwise.
Compositors should not assume that all clients can understand these
names. The names are provided for client convenience. If a client
understands the name triplet, it may ignore other information about
the color space, the ICC profile for example.
</description>
<arg name="eotf" type="uint" enum="zcr_color_manager_v1.eotf_names" summary="EOTF"/>
<arg name="chromaticity" type="uint" enum="zcr_color_manager_v1.chromaticity_names" summary="chromaticity"/>
<arg name="whitepoint" type="uint" enum="zcr_color_manager_v1.whitepoint_names" summary="whitepoint"/>
<arg name="matrix" type="uint" enum="zcr_color_manager_v1.matrix_names" summary="Color matrix"/>
<arg name="range" type="uint" enum="zcr_color_manager_v1.range_names" summary="Color range"/>
</event>
<event name="complete_params" since="3">
<description summary="RGB primaries along with whitepoint defining color space">
This event may be sent only as a response to
zcr_color_space_v1.get_information.
The RGB primary value arguments along with the whitepoint value arguments
and eotf can be used to define an arbitrary or custom color space.
The eotf enum contains well known names of that property, but the compositor
should not assume that all clients will understand those names.
</description>
<arg name="eotf" type="uint" enum="zcr_color_manager_v1.eotf_names" summary="EOTF"/>
<arg name="matrix" type="uint" enum="zcr_color_manager_v1.matrix_names" summary="Color matrix"/>
<arg name="range" type="uint" enum="zcr_color_manager_v1.range_names" summary="Color range"/>
<arg name="primary_r_x" type="uint" summary="red primary X * 10000"/>
<arg name="primary_r_y" type="uint" summary="red primary Y * 10000"/>
<arg name="primary_g_x" type="uint" summary="green primary X * 10000"/>
<arg name="primary_g_y" type="uint" summary="green primary Y * 10000"/>
<arg name="primary_b_x" type="uint" summary="blue primary X * 10000"/>
<arg name="primary_b_y" type="uint" summary="blue primary Y * 10000"/>
<arg name="white_point_x" type="uint" summary="white point X * 10000"/>
<arg name="white_point_y" type="uint" summary="white point Y * 10000"/>
</event>
</interface>
</protocol>

1631
proto/color-management-v1.xml Normal file
View file

File diff suppressed because it is too large Load diff

124
proto/commit-timing-v1.xml Normal file
View file

@ -0,0 +1,124 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="commit_timing_v1">
<copyright>
Copyright © 2023 Valve 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="wp_commit_timing_manager_v1" version="1">
<description summary="commit timing">
When a compositor latches on to new content updates it will check for
any number of requirements of the available content updates (such as
fences of all buffers being signalled) to consider the update ready.
This protocol provides a method for adding a time constraint to surface
content. This constraint indicates to the compositor that a content
update should be presented as closely as possible to, but not before,
a specified time.
This protocol does not change the Wayland property that content
updates are applied in the order they are received, even when some
content updates contain timestamps and others do not.
To provide timestamps, this global factory interface must be used to
acquire a wp_commit_timing_v1 object for a surface, which may then be
used to provide timestamp information for commits.
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>
<enum name="error">
<entry name="commit_timer_exists" value="0"
summary="commit timer already exists for surface"/>
</enum>
<request name="destroy" type="destructor">
<description summary="unbind from the commit timing 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="get_timer">
<description summary="request commit timer interface for surface">
Establish a timing controller for a surface.
Only one commit timer can be created for a surface, or a
commit_timer_exists protocol error will be generated.
</description>
<arg name="id" type="new_id" interface="wp_commit_timer_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
</interface>
<interface name="wp_commit_timer_v1" version="1">
<description summary="Surface commit timer">
An object to set a time constraint for a content update on a surface.
</description>
<enum name="error">
<entry name="invalid_timestamp" value="0"
summary="timestamp contains an invalid value"/>
<entry name="timestamp_exists" value="1"
summary="timestamp exists"/>
<entry name="surface_destroyed" value="2"
summary="the associated surface no longer exists"/>
</enum>
<request name="set_timestamp">
<description summary="Specify time the following commit takes effect">
Provide a timing constraint for a surface content update.
A set_timestamp request may be made before a wl_surface.commit to
tell the compositor that the content is intended to be presented
as closely as possible to, but not before, the specified time.
The time is in the domain of the compositor's presentation clock.
An invalid_timestamp error will be generated for invalid tv_nsec.
If a timestamp already exists on the surface, a timestamp_exists
error is generated.
Requesting set_timestamp after the commit_timer object's surface is
destroyed will generate a "surface_destroyed" error.
</description>
<arg name="tv_sec_hi" type="uint"
summary="high 32 bits of the seconds part of target time"/>
<arg name="tv_sec_lo" type="uint"
summary="low 32 bits of the seconds part of target time"/>
<arg name="tv_nsec" type="uint"
summary="nanoseconds part of target time"/>
</request>
<request name="destroy" type="destructor">
<description summary="Destroy the timer">
Informs the server that the client will no longer be using
this protocol object.
Existing timing constraints are not affected by the destruction.
</description>
</request>
</interface>
</protocol>

128
proto/content-type-v1.xml Normal file
View file

@ -0,0 +1,128 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="content_type_v1">
<copyright>
Copyright © 2021 Emmanuel Gil Peyrot
Copyright © 2022 Xaver Hugl
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_content_type_manager_v1" version="1">
<description summary="surface content type manager">
This interface allows a client to describe the kind of content a surface
will display, to allow the compositor to optimize its behavior for it.
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>
<request name="destroy" type="destructor">
<description summary="destroy the content type manager object">
Destroy the content type manager. This doesn't destroy objects created
with the manager.
</description>
</request>
<enum name="error">
<entry name="already_constructed" value="0"
summary="wl_surface already has a content type object"/>
</enum>
<request name="get_surface_content_type">
<description summary="create a new content type object">
Create a new content type object associated with the given surface.
Creating a wp_content_type_v1 from a wl_surface which already has one
attached is a client error: already_constructed.
</description>
<arg name="id" type="new_id" interface="wp_content_type_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
</interface>
<interface name="wp_content_type_v1" version="1">
<description summary="content type object for a surface">
The content type object allows the compositor to optimize for the kind
of content shown on the surface. A compositor may for example use it to
set relevant drm properties like "content type".
The client may request to switch to another content type at any time.
When the associated surface gets destroyed, this object becomes inert and
the client should destroy it.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the content type object">
Switch back to not specifying the content type of this surface. This is
equivalent to setting the content type to none, including double
buffering semantics. See set_content_type for details.
</description>
</request>
<enum name="type">
<description summary="possible content types">
These values describe the available content types for a surface.
</description>
<entry name="none" value="0">
<description summary="no content type applies">
The content type none means that either the application has no data
about the content type, or that the content doesn't fit into one of
the other categories.
</description>
</entry>
<entry name="photo" value="1">
<description summary="photo content type">
The content type photo describes content derived from digital still
pictures and may be presented with minimal processing.
</description>
</entry>
<entry name="video" value="2">
<description summary="video content type">
The content type video describes a video or animation and may be
presented with more accurate timing to avoid stutter. Where scaling
is needed, scaling methods more appropriate for video may be used.
</description>
</entry>
<entry name="game" value="3">
<description summary="game content type">
The content type game describes a running game. Its content may be
presented with reduced latency.
</description>
</entry>
</enum>
<request name="set_content_type">
<description summary="specify the content type">
Set the surface content type. This informs the compositor that the
client believes it is displaying buffers matching this content type.
This is purely a hint for the compositor, which can be used to adjust
its behavior or hardware settings to fit the presented content best.
The content type is double-buffered state, see wl_surface.commit for
details.
</description>
<arg name="content_type" type="uint" enum="type"
summary="the content type"/>
</request>
</interface>
</protocol>

58
proto/contrast.xml Normal file
View file

@ -0,0 +1,58 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="contrast">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2015 Martin Gräßlin
SPDX-FileCopyrightText: 2015 Marco Martin
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="org_kde_kwin_contrast_manager" version="2">
<request name="create">
<arg name="id" type="new_id" interface="org_kde_kwin_contrast"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="unset">
<arg name="surface" type="object" interface="wl_surface"/>
</request>
</interface>
<interface name="org_kde_kwin_contrast" version="2">
<request name="commit">
</request>
<request name="set_region">
<arg name="region" type="object" interface="wl_region" allow-null="true"/>
</request>
<request name="set_contrast">
<arg name="contrast" type="fixed"/>
</request>
<request name="set_intensity">
<arg name="intensity" type="fixed"/>
</request>
<request name="set_saturation">
<arg name="saturation" type="fixed"/>
</request>
<request name="release" type="destructor">
<description summary="release the contrast object"/>
</request>
<request name="set_frost" since="2">
<description summary="opt into frost effect w/ given colour">
enables 'frost' variant of contrast effect.
'frost' is an enhanced version of the contrast effect that
uses different colour arithmetic to get backgrounds simultaneously
higher in contrast and (apparent) transparency.
r, g, b, a are channels from 0-255, indicating a colour to use in contrast calculation.
should be based off of the "main" background colour of the surface.
</description>
<arg name="red" type="int" />
<arg name="green" type="int" />
<arg name="blue" type="int" />
<arg name="alpha" type="int" />
</request>
<request name="unset_frost" since="2">
<description summary="opts out of frost effect" />
</request>
</interface>
</protocol>

152
proto/cursor-shape-v1.xml Normal file
View file

@ -0,0 +1,152 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="cursor_shape_v1">
<copyright>
Copyright 2018 The Chromium Authors
Copyright 2023 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="wp_cursor_shape_manager_v1" version="1">
<description summary="cursor shape manager">
This global offers an alternative, optional way to set cursor images. This
new way uses enumerated cursors instead of a wl_surface like
wl_pointer.set_cursor does.
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>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
Destroy the cursor shape manager.
</description>
</request>
<request name="get_pointer">
<description summary="manage the cursor shape of a pointer device">
Obtain a wp_cursor_shape_device_v1 for a wl_pointer object.
When the pointer capability is removed from the wl_seat, the
wp_cursor_shape_device_v1 object becomes inert.
</description>
<arg name="cursor_shape_device" type="new_id" interface="wp_cursor_shape_device_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"/>
</request>
<request name="get_tablet_tool_v2">
<description summary="manage the cursor shape of a tablet tool device">
Obtain a wp_cursor_shape_device_v1 for a zwp_tablet_tool_v2 object.
When the zwp_tablet_tool_v2 is removed, the wp_cursor_shape_device_v1
object becomes inert.
</description>
<arg name="cursor_shape_device" type="new_id" interface="wp_cursor_shape_device_v1"/>
<arg name="tablet_tool" type="object" interface="zwp_tablet_tool_v2"/>
</request>
</interface>
<interface name="wp_cursor_shape_device_v1" version="1">
<description summary="cursor shape for a device">
This interface allows clients to set the cursor shape.
</description>
<enum name="shape">
<description summary="cursor shapes">
This enum describes cursor shapes.
The names are taken from the CSS W3C specification:
https://w3c.github.io/csswg-drafts/css-ui/#cursor
</description>
<entry name="default" value="1" summary="default cursor"/>
<entry name="context_menu" value="2" summary="a context menu is available for the object under the cursor"/>
<entry name="help" value="3" summary="help is available for the object under the cursor"/>
<entry name="pointer" value="4" summary="pointer that indicates a link or another interactive element"/>
<entry name="progress" value="5" summary="progress indicator"/>
<entry name="wait" value="6" summary="program is busy, user should wait"/>
<entry name="cell" value="7" summary="a cell or set of cells may be selected"/>
<entry name="crosshair" value="8" summary="simple crosshair"/>
<entry name="text" value="9" summary="text may be selected"/>
<entry name="vertical_text" value="10" summary="vertical text may be selected"/>
<entry name="alias" value="11" summary="drag-and-drop: alias of/shortcut to something is to be created"/>
<entry name="copy" value="12" summary="drag-and-drop: something is to be copied"/>
<entry name="move" value="13" summary="drag-and-drop: something is to be moved"/>
<entry name="no_drop" value="14" summary="drag-and-drop: the dragged item cannot be dropped at the current cursor location"/>
<entry name="not_allowed" value="15" summary="drag-and-drop: the requested action will not be carried out"/>
<entry name="grab" value="16" summary="drag-and-drop: something can be grabbed"/>
<entry name="grabbing" value="17" summary="drag-and-drop: something is being grabbed"/>
<entry name="e_resize" value="18" summary="resizing: the east border is to be moved"/>
<entry name="n_resize" value="19" summary="resizing: the north border is to be moved"/>
<entry name="ne_resize" value="20" summary="resizing: the north-east corner is to be moved"/>
<entry name="nw_resize" value="21" summary="resizing: the north-west corner is to be moved"/>
<entry name="s_resize" value="22" summary="resizing: the south border is to be moved"/>
<entry name="se_resize" value="23" summary="resizing: the south-east corner is to be moved"/>
<entry name="sw_resize" value="24" summary="resizing: the south-west corner is to be moved"/>
<entry name="w_resize" value="25" summary="resizing: the west border is to be moved"/>
<entry name="ew_resize" value="26" summary="resizing: the east and west borders are to be moved"/>
<entry name="ns_resize" value="27" summary="resizing: the north and south borders are to be moved"/>
<entry name="nesw_resize" value="28" summary="resizing: the north-east and south-west corners are to be moved"/>
<entry name="nwse_resize" value="29" summary="resizing: the north-west and south-east corners are to be moved"/>
<entry name="col_resize" value="30" summary="resizing: that the item/column can be resized horizontally"/>
<entry name="row_resize" value="31" summary="resizing: that the item/row can be resized vertically"/>
<entry name="all_scroll" value="32" summary="something can be scrolled in any direction"/>
<entry name="zoom_in" value="33" summary="something can be zoomed in"/>
<entry name="zoom_out" value="34" summary="something can be zoomed out"/>
</enum>
<enum name="error">
<entry name="invalid_shape" value="1"
summary="the specified shape value is invalid"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroy the cursor shape device">
Destroy the cursor shape device.
The device cursor shape remains unchanged.
</description>
</request>
<request name="set_shape">
<description summary="set device cursor to the shape">
Sets the device cursor to the specified shape. The compositor will
change the cursor image based on the specified shape.
The cursor actually changes only if the input device focus is one of
the requesting client's surfaces. If any, the previous cursor image
(surface or shape) is replaced.
The "shape" argument must be a valid enum entry, otherwise the
invalid_shape protocol error is raised.
This is similar to the wl_pointer.set_cursor and
zwp_tablet_tool_v2.set_cursor requests, but this request accepts a
shape instead of contents in the form of a surface. Clients can mix
set_cursor and set_shape requests.
The serial parameter must match the latest wl_pointer.enter or
zwp_tablet_tool_v2.proximity_in serial number sent to the client.
Otherwise the request will be ignored.
</description>
<arg name="serial" type="uint" summary="serial number of the enter event"/>
<arg name="shape" type="uint" enum="shape"/>
</request>
</interface>
</protocol>

87
proto/dpms.xml Normal file
View file

@ -0,0 +1,87 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="dpms">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2015 Martin Gräßlin
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="org_kde_kwin_dpms_manager" version="1">
<description summary="Output dpms manager">
The Dpms manager allows to get a org_kde_kwin_dpms for a given wl_output.
The org_kde_kwin_dpms provides the currently used VESA Display Power Management
Signaling state (see https://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling ).
In addition it allows to request a state change. A compositor is not obliged to honor it
and will normally automatically switch back to on state.
Warning! The protocol described in this file is a desktop environment
implementation detail. Regular clients must not use this protocol.
Backward incompatible changes may be added without bumping the major
version of the extension.
</description>
<request name="get">
<description summary="Get org_kde_kwin_dpms for wl_output">
Factory request to get the org_kde_kwin_dpms for a given wl_output.
</description>
<arg name="id" type="new_id" interface="org_kde_kwin_dpms"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
</interface>
<interface name="org_kde_kwin_dpms" version="1">
<description summary="Dpms for a wl_output">
This interface provides information about the VESA DPMS state for a wl_output.
It gets created through the request get on the org_kde_kwin_dpms_manager interface.
On creating the resource the server will push whether DPSM is supported for the output,
the currently used DPMS state and notifies the client through the done event once all
states are pushed. Whenever a state changes the set of changes is committed with the
done event.
</description>
<event name="supported">
<description summary="Event indicating whether DPMS is supported on the wl_output">
This event gets pushed on binding the resource and indicates whether the wl_output
supports DPMS. There are operation modes of a Wayland server where DPMS might not
make sense (e.g. nested compositors).
</description>
<arg name="supported" type="uint" summary="Boolean value whether DPMS is supported (1) for the wl_output or not (0)"/>
</event>
<enum name="mode">
<entry name="On" value="0"/>
<entry name="Standby" value="1"/>
<entry name="Suspend" value="2"/>
<entry name="Off" value="3"/>
</enum>
<event name="mode">
<description summary="Event indicating used DPMS mode">
This mode gets pushed on binding the resource and provides the currently used
DPMS mode. It also gets pushed if DPMS is not supported for the wl_output, in that
case the value will be On.
The event is also pushed whenever the state changes.
</description>
<arg name="mode" type="uint" summary="The new currently used mode"/>
</event>
<event name="done">
<description summary="All changes are pushed">
This event gets pushed on binding the resource once all other states are pushed.
In addition it gets pushed whenever a state changes to tell the client that all
state changes have been pushed.
</description>
</event>
<request name="set">
<description summary="Request DPMS state change for the wl_output">
Requests that the compositor puts the wl_output into the passed mode. The compositor
is not obliged to change the state. In addition the compositor might leave the mode
whenever it seems suitable. E.g. the compositor might return to On state on user input.
The client should not assume that the mode changed after requesting a new mode.
Instead the client should listen for the mode event.
</description>
<arg name="mode" type="uint" summary="Requested mode"/>
</request>
<request name="release" type="destructor">
<description summary="release the dpms object"/>
</request>
</interface>
</protocol>

317
proto/drm-lease-v1.xml Normal file
View file

@ -0,0 +1,317 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="drm_lease_v1">
<copyright>
Copyright © 2018 NXP
Copyright © 2019 Status Research &amp; Development GmbH.
Copyright © 2021 Xaver Hugl
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_drm_lease_device_v1" version="1">
<description summary="lease device">
This protocol is used by Wayland compositors which act as Direct
Rendering Manager (DRM) masters to lease DRM resources to Wayland
clients.
The compositor will advertise one wp_drm_lease_device_v1 global for each
DRM node. Some time after a client binds to the wp_drm_lease_device_v1
global, the compositor will send a drm_fd event followed by zero, one or
more connector events. After all currently available connectors have been
sent, the compositor will send a wp_drm_lease_device_v1.done event.
When the list of connectors available for lease changes the compositor
will send wp_drm_lease_device_v1.connector events for added connectors and
wp_drm_lease_connector_v1.withdrawn events for removed connectors,
followed by a wp_drm_lease_device_v1.done event.
The compositor will indicate when a device is gone by removing the global
via a wl_registry.global_remove event. Upon receiving this event, the
client should destroy any matching wp_drm_lease_device_v1 object.
To destroy a wp_drm_lease_device_v1 object, the client must first issue
a release request. Upon receiving this request, the compositor will
immediately send a released event and destroy the object. The client must
continue to process and discard drm_fd and connector events until it
receives the released event. Upon receiving the released event, the
client can safely cleanup any client-side resources.
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>
<request name="create_lease_request">
<description summary="create a lease request object">
Creates a lease request object.
See the documentation for wp_drm_lease_request_v1 for details.
</description>
<arg name="id" type="new_id" interface="wp_drm_lease_request_v1" />
</request>
<request name="release">
<description summary="release this object">
Indicates the client no longer wishes to use this object. In response
the compositor will immediately send the released event and destroy
this object. It can however not guarantee that the client won't receive
connector events before the released event. The client must not send any
requests after this one, doing so will raise a wl_display error.
Existing connectors, lease request and leases will not be affected.
</description>
</request>
<event name="drm_fd">
<description summary="open a non-master fd for this DRM node">
The compositor will send this event when the wp_drm_lease_device_v1
global is bound, although there are no guarantees as to how long this
takes - the compositor might need to wait until regaining DRM master.
The included fd is a non-master DRM file descriptor opened for this
device and the compositor must not authenticate it.
The purpose of this event is to give the client the ability to
query DRM and discover information which may help them pick the
appropriate DRM device or select the appropriate connectors therein.
</description>
<arg name="fd" type="fd" summary="DRM file descriptor" />
</event>
<event name="connector">
<description summary="advertise connectors available for leases">
The compositor will use this event to advertise connectors available for
lease by clients. This object may be passed into a lease request to
indicate the client would like to lease that connector, see
wp_drm_lease_request_v1.request_connector for details. While the
compositor will make a best effort to not send disconnected connectors,
no guarantees can be made.
The compositor must send the drm_fd event before sending connectors.
After the drm_fd event it will send all available connectors but may
send additional connectors at any time.
</description>
<arg name="id" type="new_id" interface="wp_drm_lease_connector_v1" />
</event>
<event name="done">
<description summary="signals grouping of connectors">
The compositor will send this event to indicate that it has sent all
currently available connectors after the client binds to the global or
when it updates the connector list, for example on hotplug, drm master
change or when a leased connector becomes available again. It will
similarly send this event to group wp_drm_lease_connector_v1.withdrawn
events of connectors of this device.
</description>
</event>
<event name="released" type="destructor">
<description summary="the compositor has finished using the device">
This event is sent in response to the release request and indicates
that the compositor is done sending connector events.
The compositor will destroy this object immediately after sending the
event and it will become invalid. The client should release any
resources associated with this device after receiving this event.
</description>
</event>
</interface>
<interface name="wp_drm_lease_connector_v1" version="1">
<description summary="a leasable DRM connector">
Represents a DRM connector which is available for lease. These objects are
created via wp_drm_lease_device_v1.connector events, and should be passed
to lease requests via wp_drm_lease_request_v1.request_connector.
Immediately after the wp_drm_lease_connector_v1 object is created the
compositor will send a name, a description, a connector_id and a done
event. When the description is updated the compositor will send a
description event followed by a done event.
</description>
<event name="name">
<description summary="name">
The compositor sends this event once the connector is created to
indicate the name of this connector. This will not change for the
duration of the Wayland session, but is not guaranteed to be consistent
between sessions.
If the compositor supports wl_output version 4 and this connector
corresponds to a wl_output, the compositor should use the same name as
for the wl_output.
</description>
<arg name="name" type="string" summary="connector name" />
</event>
<event name="description">
<description summary="description">
The compositor sends this event once the connector is created to provide
a human-readable description for this connector, which may be presented
to the user. The compositor may send this event multiple times over the
lifetime of this object to reflect changes in the description.
</description>
<arg name="description" type="string" summary="connector description" />
</event>
<event name="connector_id">
<description summary="connector_id">
The compositor sends this event once the connector is created to
indicate the DRM object ID which represents the underlying connector
that is being offered. Note that the final lease may include additional
object IDs, such as CRTCs and planes.
</description>
<arg name="connector_id" type="uint" summary="DRM connector ID" />
</event>
<event name="done">
<description summary="all properties have been sent">
This event is sent after all properties of a connector have been sent.
This allows changes to the properties to be seen as atomic even if they
happen via multiple events.
</description>
</event>
<event name="withdrawn">
<description summary="lease offer withdrawn">
Sent to indicate that the compositor will no longer honor requests for
DRM leases which include this connector. The client may still issue a
lease request including this connector, but the compositor will send
wp_drm_lease_v1.finished without issuing a lease fd. Compositors are
encouraged to send this event when they lose access to connector, for
example when the connector is hot-unplugged, when the connector gets
leased to a client or when the compositor loses DRM master.
If a client holds a lease for the connector, the status of the lease
remains the same. The client should destroy the object after receiving
this event.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy connector">
The client may send this request to indicate that it will not use this
connector. Clients are encouraged to send this after receiving the
"withdrawn" event so that the server can release the resources
associated with this connector offer. Neither existing lease requests
nor leases will be affected.
</description>
</request>
</interface>
<interface name="wp_drm_lease_request_v1" version="1">
<description summary="DRM lease request">
A client that wishes to lease DRM resources will attach the list of
connectors advertised with wp_drm_lease_device_v1.connector that they
wish to lease, then use wp_drm_lease_request_v1.submit to submit the
request.
</description>
<enum name="error">
<entry name="wrong_device" value="0"
summary="requested a connector from a different lease device"/>
<entry name="duplicate_connector" value="1"
summary="requested a connector twice"/>
<entry name="empty_lease" value="2"
summary="requested a lease without requesting a connector"/>
</enum>
<request name="request_connector">
<description summary="request a connector for this lease">
Indicates that the client would like to lease the given connector.
This is only used as a suggestion, the compositor may choose to
include any resources in the lease it issues, or change the set of
leased resources at any time. Compositors are however encouraged to
include the requested connector and other resources necessary
to drive the connected output in the lease.
Requesting a connector that was created from a different lease device
than this lease request raises the wrong_device error. Requesting a
connector twice will raise the duplicate_connector error.
</description>
<arg name="connector" type="object"
interface="wp_drm_lease_connector_v1" />
</request>
<request name="submit" type="destructor">
<description summary="submit the lease request">
Submits the lease request and creates a new wp_drm_lease_v1 object.
After calling submit the compositor will immediately destroy this
object, issuing any more requests will cause a wl_display error.
The compositor doesn't make any guarantees about the events of the
lease object, clients cannot expect an immediate response.
Not requesting any connectors before submitting the lease request
will raise the empty_lease error.
</description>
<arg name="id" type="new_id" interface="wp_drm_lease_v1" />
</request>
</interface>
<interface name="wp_drm_lease_v1" version="1">
<description summary="a DRM lease">
A DRM lease object is used to transfer the DRM file descriptor to the
client and manage the lifetime of the lease.
Some time after the wp_drm_lease_v1 object is created, the compositor
will reply with the lease request's result. If the lease request is
granted, the compositor will send a lease_fd event. If the lease request
is denied, the compositor will send a finished event without a lease_fd
event.
</description>
<event name="lease_fd">
<description summary="shares the DRM file descriptor">
This event returns a file descriptor suitable for use with DRM-related
ioctls. The client should use drmModeGetLease to enumerate the DRM
objects which have been leased to them. The compositor guarantees it
will not use the leased DRM objects itself until it sends the finished
event. If the compositor cannot or will not grant a lease for the
requested connectors, it will not send this event, instead sending the
finished event.
The compositor will send this event at most once during this objects
lifetime.
</description>
<arg name="leased_fd" type="fd" summary="leased DRM file descriptor" />
</event>
<event name="finished">
<description summary="sent when the lease has been revoked">
The compositor uses this event to either reject a lease request, or if
it previously sent a lease_fd, to notify the client that the lease has
been revoked. If the client requires a new lease, they should destroy
this object and submit a new lease request. The compositor will send
no further events for this object after sending the finish event.
Compositors should revoke the lease when any of the leased resources
become unavailable, namely when a hot-unplug occurs or when the
compositor loses DRM master. Compositors may advertise the connector
for leasing again, if the resource is available, by sending the
connector event through the wp_drm_lease_device_v1 interface.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroys the lease object">
The client should send this to indicate that it no longer wishes to use
this lease. The compositor should use drmModeRevokeLease on the
appropriate file descriptor, if necessary.
Upon destruction, the compositor should advertise the connector for
leasing again by sending the connector event through the
wp_drm_lease_device_v1 interface.
</description>
</request>
</interface>
</protocol>

276
proto/ext-data-control-v1.xml Normal file
View file

@ -0,0 +1,276 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_data_control_v1">
<copyright>
Copyright © 2018 Simon Ser
Copyright © 2019 Ivan Molodetskikh
Copyright © 2024 Neal Gompa
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 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="ext_data_control_manager_v1" version="1">
<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="ext_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="ext_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="ext_data_control_device_v1" version="1">
<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 triggers the used_source protocol error.
To unset the selection, set the source to NULL.
</description>
<arg name="source" type="object" interface="ext_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 ext_data_control_offer">
The data_offer event introduces a new ext_data_control_offer object,
which will subsequently be used in either the
ext_data_control_device.selection event (for the regular clipboard
selections) or the ext_data_control_device.primary_selection event (for
the primary clipboard selections). Immediately following the
ext_data_control_device.data_offer event, the new data_offer object
will send out ext_data_control_offer.offer events to describe the MIME
types it offers.
</description>
<arg name="id" type="new_id" interface="ext_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
ext_data_control_offer for the selection for this device. The
ext_data_control_device.data_offer and the ext_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 ext_data_control_offer is valid until a new
ext_data_control_offer or NULL is received. The client must destroy the
previous selection ext_data_control_offer, if any, upon receiving this
event. Regardless, the previous selection will be ignored once a new
selection ext_data_control_offer is received.
The first selection event is sent upon binding the
ext_data_control_device object.
</description>
<arg name="id" type="object" interface="ext_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>
<event name="primary_selection">
<description summary="advertise new primary selection">
The primary_selection event is sent out to notify the client of a new
ext_data_control_offer for the primary selection for this device. The
ext_data_control_device.data_offer and the ext_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 ext_data_control_offer is valid until
a new ext_data_control_offer or NULL is received. The client must
destroy the previous primary selection ext_data_control_offer, if any,
upon receiving this event. Regardless, the previous primary selection
will be ignored once a new primary selection ext_data_control_offer is
received.
If the compositor supports primary selection, the first
primary_selection event is sent upon binding the
ext_data_control_device object.
</description>
<arg name="id" type="object" interface="ext_data_control_offer_v1"
allow-null="true"/>
</event>
<request name="set_primary_selection">
<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 triggers the used_source 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="ext_data_control_source_v1"
allow-null="true"/>
</request>
<enum name="error">
<entry name="used_source" value="1"
summary="source given to set_selection or set_primary_selection was already used before"/>
</enum>
</interface>
<interface name="ext_data_control_source_v1" version="1">
<description summary="offer to transfer data">
The ext_data_control_source object is the source side of a
ext_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 ext_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 ext_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="ext_data_control_offer_v1" version="1">
<description summary="offer to transfer data">
A ext_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 ext_data_control_offer object.
One event per offered MIME type.
</description>
<arg name="mime_type" type="string" summary="offered MIME type"/>
</event>
</interface>
</protocol>

219
proto/ext-foreign-toplevel-list-v1.xml Normal file
View file

@ -0,0 +1,219 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_foreign_toplevel_list_v1">
<copyright>
Copyright © 2018 Ilia Bozhinov
Copyright © 2020 Isaac Freund
Copyright © 2022 wb9688
Copyright © 2023 i509VCB
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="list toplevels">
The purpose of this protocol is to provide protocol object handles for
toplevels, possibly originating from another client.
This protocol is intentionally minimalistic and expects additional
functionality (e.g. creating a screencopy source from a toplevel handle,
getting information about the state of the toplevel) to be implemented
in extension protocols.
The compositor may choose to restrict this protocol to a special client
launched by the compositor itself or expose it to all clients,
this is compositor policy.
The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document are to be interpreted as described in IETF RFC 2119.
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="ext_foreign_toplevel_list_v1" version="1">
<description summary="list toplevels">
A toplevel is defined as a surface with a role similar to xdg_toplevel.
XWayland surfaces may be treated like toplevels in this protocol.
After a client binds the ext_foreign_toplevel_list_v1, each mapped
toplevel window will be sent using the ext_foreign_toplevel_list_v1.toplevel
event.
Clients which only care about the current state can perform a roundtrip after
binding this global.
For each instance of ext_foreign_toplevel_list_v1, the compositor must
create a new ext_foreign_toplevel_handle_v1 object for each mapped toplevel.
If a compositor implementation sends the ext_foreign_toplevel_list_v1.finished
event after the global is bound, the compositor must not send any
ext_foreign_toplevel_list_v1.toplevel events.
</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 properties of the toplevel (identifier, title, app_id) will be sent
immediately after this event using the corresponding events for
ext_foreign_toplevel_handle_v1. The compositor will use the
ext_foreign_toplevel_handle_v1.done event to indicate when all data has
been sent.
</description>
<arg name="toplevel" type="new_id" interface="ext_foreign_toplevel_handle_v1"/>
</event>
<event name="finished">
<description summary="the compositor has finished with the toplevel manager">
This event indicates that the compositor is done sending events
to this object. The client should destroy the object.
See ext_foreign_toplevel_list_v1.destroy for more information.
The compositor must not send any more toplevel events after this event.
</description>
</event>
<request name="stop">
<description summary="stop sending events">
This request indicates that the client no longer wishes to receive
events for new toplevels.
The Wayland protocol is asynchronous, meaning the compositor may send
further toplevel events until the stop request is processed.
The client should wait for a ext_foreign_toplevel_list_v1.finished
event before destroying this object.
</description>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the ext_foreign_toplevel_list_v1 object">
This request should be called either when the client will no longer
use the ext_foreign_toplevel_list_v1 or after the finished event
has been received to allow destruction of the object.
If a client wishes to destroy this object it should send a
ext_foreign_toplevel_list_v1.stop request and wait for a ext_foreign_toplevel_list_v1.finished
event, then destroy the handles and then this object.
</description>
</request>
</interface>
<interface name="ext_foreign_toplevel_handle_v1" version="1">
<description summary="a mapped toplevel">
A ext_foreign_toplevel_handle_v1 object represents a mapped toplevel
window. A single app may have multiple mapped toplevels.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the ext_foreign_toplevel_handle_v1 object">
This request should be used when the client will no longer use the handle
or after the closed event has been received to allow destruction of the
object.
When a handle is destroyed, a new handle may not be created by the server
until the toplevel is unmapped and then remapped. Destroying a toplevel handle
is not recommended unless the client is cleaning up child objects
before destroying the ext_foreign_toplevel_list_v1 object, the toplevel
was closed or the toplevel handle will not be used in the future.
Other protocols which extend the ext_foreign_toplevel_handle_v1
interface should require destructors for extension interfaces be
called before allowing the toplevel handle to be destroyed.
</description>
</request>
<event name="closed">
<description summary="the toplevel has been closed">
The server will emit no further events on the ext_foreign_toplevel_handle_v1
after this event. Any requests received aside from the destroy request must
be ignored. Upon receiving this event, the client should destroy the handle.
Other protocols which extend the ext_foreign_toplevel_handle_v1
interface must also ignore requests other than destructors.
</description>
</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 ext_foreign_toplevel_handle_v1 properties
to be atomically applied. Other protocols which extend the
ext_foreign_toplevel_handle_v1 interface may use this event to also
atomically apply any pending state.
This event must not be sent after the ext_foreign_toplevel_handle_v1.closed
event.
</description>
</event>
<event name="title">
<description summary="title change">
The title of the toplevel has changed.
The configured state must not be applied immediately. See
ext_foreign_toplevel_handle_v1.done for details.
</description>
<arg name="title" type="string"/>
</event>
<event name="app_id">
<description summary="app_id change">
The app id of the toplevel has changed.
The configured state must not be applied immediately. See
ext_foreign_toplevel_handle_v1.done for details.
</description>
<arg name="app_id" type="string"/>
</event>
<event name="identifier">
<description summary="a stable identifier for a toplevel">
This identifier is used to check if two or more toplevel handles belong
to the same toplevel.
The identifier is useful for command line tools or privileged clients
which may need to reference an exact toplevel across processes or
instances of the ext_foreign_toplevel_list_v1 global.
The compositor must only send this event when the handle is created.
The identifier must be unique per toplevel and it's handles. Two different
toplevels must not have the same identifier. The identifier is only valid
as long as the toplevel is mapped. If the toplevel is unmapped the identifier
must not be reused. An identifier must not be reused by the compositor to
ensure there are no races when sharing identifiers between processes.
An identifier is a string that contains up to 32 printable ASCII bytes.
An identifier must not be an empty string. It is recommended that a
compositor includes an opaque generation value in identifiers. How the
generation value is used when generating the identifier is implementation
dependent.
</description>
<arg name="identifier" type="string"/>
</event>
</interface>
</protocol>

131
proto/ext-idle-notify-v1.xml Normal file
View file

@ -0,0 +1,131 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_idle_notify_v1">
<copyright>
Copyright © 2015 Martin Gräßlin
Copyright © 2022 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="ext_idle_notifier_v1" version="2">
<description summary="idle notification manager">
This interface allows clients to monitor user idle status.
After binding to this global, clients can create ext_idle_notification_v1
objects to get notified when the user is idle for a given amount of time.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
Destroy the manager object. All objects created via this interface
remain valid.
</description>
</request>
<request name="get_idle_notification">
<description summary="create a notification object">
Create a new idle notification object.
The notification object has a minimum timeout duration and is tied to a
seat. The client will be notified if the seat is inactive for at least
the provided timeout. See ext_idle_notification_v1 for more details.
A zero timeout is valid and means the client wants to be notified as
soon as possible when the seat is inactive.
</description>
<arg name="id" type="new_id" interface="ext_idle_notification_v1"/>
<arg name="timeout" type="uint" summary="minimum idle timeout in msec"/>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
<!-- Version 2 additions -->
<request name="get_input_idle_notification" since="2">
<description summary="create a notification object">
Create a new idle notification object to track input from the
user, such as keyboard and mouse movement. Because this object is
meant to track user input alone, it ignores idle inhibitors.
The notification object has a minimum timeout duration and is tied to a
seat. The client will be notified if the seat is inactive for at least
the provided timeout. See ext_idle_notification_v1 for more details.
A zero timeout is valid and means the client wants to be notified as
soon as possible when the seat is inactive.
</description>
<arg name="id" type="new_id" interface="ext_idle_notification_v1"/>
<arg name="timeout" type="uint" summary="minimum idle timeout in msec"/>
<arg name="seat" type="object" interface="wl_seat"/>
</request>
</interface>
<interface name="ext_idle_notification_v1" version="2">
<description summary="idle notification">
This interface is used by the compositor to send idle notification events
to clients.
Initially the notification object is not idle. The notification object
becomes idle when no user activity has happened for at least the timeout
duration, starting from the creation of the notification object. User
activity may include input events or a presence sensor, but is
compositor-specific.
How this notification responds to idle inhibitors depends on how
it was constructed. If constructed from the
get_idle_notification request, then if an idle inhibitor is
active (e.g. another client has created a zwp_idle_inhibitor_v1
on a visible surface), the compositor must not make the
notification object idle. However, if constructed from the
get_input_idle_notification request, then idle inhibitors are
ignored, and only input from the user, e.g. from a keyboard or
mouse, counts as activity.
When the notification object becomes idle, an idled event is sent. When
user activity starts again, the notification object stops being idle,
a resumed event is sent and the timeout is restarted.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the notification object">
Destroy the notification object.
</description>
</request>
<event name="idled">
<description summary="notification object is idle">
This event is sent when the notification object becomes idle.
It's a compositor protocol error to send this event twice without a
resumed event in-between.
</description>
</event>
<event name="resumed">
<description summary="notification object is no longer idle">
This event is sent when the notification object stops being idle.
It's a compositor protocol error to send this event twice without an
idled event in-between. It's a compositor protocol error to send this
event prior to any idled event.
</description>
</event>
</interface>
</protocol>

109
proto/ext-image-capture-source-v1.xml Normal file
View file

@ -0,0 +1,109 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_image_capture_source_v1">
<copyright>
Copyright © 2022 Andri Yngvason
Copyright © 2024 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>
<description summary="opaque image capture source objects">
This protocol serves as an intermediary between capturing protocols and
potential image capture sources such as outputs and toplevels.
This protocol may be extended to support more image capture sources in the
future, thereby adding those image capture sources to other protocols that
use the image capture source object without having to modify those
protocols.
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="ext_image_capture_source_v1" version="1">
<description summary="opaque image capture source object">
The image capture source object is an opaque descriptor for a capturable
resource. This resource may be any sort of entity from which an image
may be derived.
Note, because ext_image_capture_source_v1 objects are created from multiple
independent factory interfaces, the ext_image_capture_source_v1 interface is
frozen at version 1.
</description>
<request name="destroy" type="destructor">
<description summary="delete this object">
Destroys the image capture source. This request may be sent at any time
by the client.
</description>
</request>
</interface>
<interface name="ext_output_image_capture_source_manager_v1" version="1">
<description summary="image capture source manager for outputs">
A manager for creating image capture source objects for wl_output objects.
</description>
<request name="create_source">
<description summary="create source object for output">
Creates a source object for an output. Images captured from this source
will show the same content as the output. Some elements may be omitted,
such as cursors and overlays that have been marked as transparent to
capturing.
</description>
<arg name="source" type="new_id" interface="ext_image_capture_source_v1"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="destroy" type="destructor">
<description summary="delete this object">
Destroys the manager. This request may be sent at any time by the client
and objects created by the manager will remain valid after its
destruction.
</description>
</request>
</interface>
<interface name="ext_foreign_toplevel_image_capture_source_manager_v1" version="1">
<description summary="image capture source manager for foreign toplevels">
A manager for creating image capture source objects for
ext_foreign_toplevel_handle_v1 objects.
</description>
<request name="create_source">
<description summary="create source object for foreign toplevel">
Creates a source object for a foreign toplevel handle. Images captured
from this source will show the same content as the toplevel.
</description>
<arg name="source" type="new_id" interface="ext_image_capture_source_v1"/>
<arg name="toplevel_handle" type="object" interface="ext_foreign_toplevel_handle_v1"/>
</request>
<request name="destroy" type="destructor">
<description summary="delete this object">
Destroys the manager. This request may be sent at any time by the client
and objects created by the manager will remain valid after its
destruction.
</description>
</request>
</interface>
</protocol>

456
proto/ext-image-copy-capture-v1.xml Normal file
View file

@ -0,0 +1,456 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_image_copy_capture_v1">
<copyright>
Copyright © 2021-2023 Andri Yngvason
Copyright © 2024 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>
<description summary="image capturing into client buffers">
This protocol allows clients to ask the compositor to capture image sources
such as outputs and toplevels into user submitted buffers.
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="ext_image_copy_capture_manager_v1" version="1">
<description summary="manager to inform clients and begin capturing">
This object is a manager which offers requests to start capturing from a
source.
</description>
<enum name="error">
<entry name="invalid_option" value="1" summary="invalid option flag"/>
</enum>
<enum name="options" bitfield="true">
<entry name="paint_cursors" value="1" summary="paint cursors onto captured frames"/>
</enum>
<request name="create_session">
<description summary="capture an image capture source">
Create a capturing session for an image capture source.
If the paint_cursors option is set, cursors shall be composited onto
the captured frame. The cursor must not be composited onto the frame
if this flag is not set.
If the options bitfield is invalid, the invalid_option protocol error
is sent.
</description>
<arg name="session" type="new_id" interface="ext_image_copy_capture_session_v1"/>
<arg name="source" type="object" interface="ext_image_capture_source_v1"/>
<arg name="options" type="uint" enum="options"/>
</request>
<request name="create_pointer_cursor_session">
<description summary="capture the pointer cursor of an image capture source">
Create a cursor capturing session for the pointer of an image capture
source.
</description>
<arg name="session" type="new_id" interface="ext_image_copy_capture_cursor_session_v1"/>
<arg name="source" type="object" interface="ext_image_capture_source_v1"/>
<arg name="pointer" type="object" interface="wl_pointer"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
Destroy the manager object.
Other objects created via this interface are unaffected.
</description>
</request>
</interface>
<interface name="ext_image_copy_capture_session_v1" version="1">
<description summary="image copy capture session">
This object represents an active image copy capture session.
After a capture session is created, buffer constraint events will be
emitted from the compositor to tell the client which buffer types and
formats are supported for reading from the session. The compositor may
re-send buffer constraint events whenever they change.
To advertise buffer constraints, the compositor must send in no
particular order: zero or more shm_format and dmabuf_format events, zero
or one dmabuf_device event, and exactly one buffer_size event. Then the
compositor must send a done event.
When the client has received all the buffer constraints, it can create a
buffer accordingly, attach it to the capture session using the
attach_buffer request, set the buffer damage using the damage_buffer
request and then send the capture request.
</description>
<enum name="error">
<entry name="duplicate_frame" value="1"
summary="create_frame sent before destroying previous frame"/>
</enum>
<event name="buffer_size">
<description summary="image capture source dimensions">
Provides the dimensions of the source image in buffer pixel coordinates.
The client must attach buffers that match this size.
</description>
<arg name="width" type="uint" summary="buffer width"/>
<arg name="height" type="uint" summary="buffer height"/>
</event>
<event name="shm_format">
<description summary="shm buffer format">
Provides the format that must be used for shared-memory buffers.
This event may be emitted multiple times, in which case the client may
choose any given format.
</description>
<arg name="format" type="uint" enum="wl_shm.format" summary="shm format"/>
</event>
<event name="dmabuf_device">
<description summary="dma-buf device">
This event advertises the device buffers must be allocated on for
dma-buf buffers.
In general the device is a DRM node. The DRM node type (primary vs.
render) is unspecified. Clients must not rely on the compositor sending
a particular node type. Clients cannot check two devices for equality
by comparing the dev_t value.
</description>
<arg name="device" type="array" summary="device dev_t value"/>
</event>
<event name="dmabuf_format">
<description summary="dma-buf format">
Provides the format that must be used for dma-buf buffers.
The client may choose any of the modifiers advertised in the array of
64-bit unsigned integers.
This event may be emitted multiple times, in which case the client may
choose any given format.
</description>
<arg name="format" type="uint" summary="drm format code"/>
<arg name="modifiers" type="array" summary="drm format modifiers"/>
</event>
<event name="done">
<description summary="all constraints have been sent">
This event is sent once when all buffer constraint events have been
sent.
The compositor must always end a batch of buffer constraint events with
this event, regardless of whether it sends the initial constraints or
an update.
</description>
</event>
<event name="stopped">
<description summary="session is no longer available">
This event indicates that the capture session has stopped and is no
longer available. This can happen in a number of cases, e.g. when the
underlying source is destroyed, if the user decides to end the image
capture, or if an unrecoverable runtime error has occurred.
The client should destroy the session after receiving this event.
</description>
</event>
<request name="create_frame">
<description summary="create a frame">
Create a capture frame for this session.
At most one frame object can exist for a given session at any time. If
a client sends a create_frame request before a previous frame object
has been destroyed, the duplicate_frame protocol error is raised.
</description>
<arg name="frame" type="new_id" interface="ext_image_copy_capture_frame_v1"/>
</request>
<request name="destroy" type="destructor">
<description summary="delete this object">
Destroys the session. This request can be sent at any time by the
client.
This request doesn't affect ext_image_copy_capture_frame_v1 objects created by
this object.
</description>
</request>
</interface>
<interface name="ext_image_copy_capture_frame_v1" version="1">
<description summary="image capture frame">
This object represents an image capture frame.
The client should attach a buffer, damage the buffer, and then send a
capture request.
If the capture is successful, the compositor must send the frame metadata
(transform, damage, presentation_time in any order) followed by the ready
event.
If the capture fails, the compositor must send the failed event.
</description>
<enum name="error">
<entry name="no_buffer" value="1" summary="capture sent without attach_buffer"/>
<entry name="invalid_buffer_damage" value="2" summary="invalid buffer damage"/>
<entry name="already_captured" value="3" summary="capture request has been sent"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroy this object">
Destroys the frame. This request can be sent at any time by the
client.
</description>
</request>
<request name="attach_buffer">
<description summary="attach buffer to session">
Attach a buffer to the session.
The wl_buffer.release request is unused.
The new buffer replaces any previously attached buffer.
This request must not be sent after capture, or else the
already_captured protocol error is raised.
</description>
<arg name="buffer" type="object" interface="wl_buffer"/>
</request>
<request name="damage_buffer">
<description summary="damage buffer">
Apply damage to the buffer which is to be captured next. This request
may be sent multiple times to describe a region.
The client indicates the accumulated damage since this wl_buffer was
last captured. During capture, the compositor will update the buffer
with at least the union of the region passed by the client and the
region advertised by ext_image_copy_capture_frame_v1.damage.
When a wl_buffer is captured for the first time, or when the client
doesn't track damage, the client must damage the whole buffer.
This is for optimisation purposes. The compositor may use this
information to reduce copying.
These coordinates originate from the upper left corner of the buffer.
If x or y are strictly negative, or if width or height are negative or
zero, the invalid_buffer_damage protocol error is raised.
This request must not be sent after capture, or else the
already_captured protocol error is raised.
</description>
<arg name="x" type="int" summary="region x coordinate"/>
<arg name="y" type="int" summary="region y coordinate"/>
<arg name="width" type="int" summary="region width"/>
<arg name="height" type="int" summary="region height"/>
</request>
<request name="capture">
<description summary="capture a frame">
Capture a frame.
Unless this is the first successful captured frame performed in this
session, the compositor may wait an indefinite amount of time for the
source content to change before performing the copy.
This request may only be sent once, or else the already_captured
protocol error is raised. A buffer must be attached before this request
is sent, or else the no_buffer protocol error is raised.
</description>
</request>
<event name="transform">
<description summary="buffer transform">
This event is sent before the ready event and holds the transform that
the compositor has applied to the buffer contents.
</description>
<arg name="transform" type="uint" enum="wl_output.transform"/>
</event>
<event name="damage">
<description summary="buffer damaged region">
This event is sent before the ready event. It may be generated multiple
times to describe a region.
The first captured frame in a session will always carry full damage.
Subsequent frames' damaged regions describe which parts of the buffer
have changed since the last ready event.
These coordinates originate in the upper left corner of the buffer.
</description>
<arg name="x" type="int" summary="damage x coordinate"/>
<arg name="y" type="int" summary="damage y coordinate"/>
<arg name="width" type="int" summary="damage width"/>
<arg name="height" type="int" summary="damage height"/>
</event>
<event name="presentation_time">
<description summary="presentation time of the frame">
This event indicates the time at which the frame is presented to the
output in system monotonic time. This event is sent before the ready
event.
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>
<event name="ready">
<description summary="frame is available for reading">
Called as soon as the frame is copied, indicating it is available
for reading.
The buffer may be re-used by the client after this event.
After receiving this event, the client must destroy the object.
</description>
</event>
<enum name="failure_reason">
<entry name="unknown" value="0">
<description summary="unknown runtime error">
An unspecified runtime error has occurred. The client may retry.
</description>
</entry>
<entry name="buffer_constraints" value="1">
<description summary="buffer constraints mismatch">
The buffer submitted by the client doesn't match the latest session
constraints. The client should re-allocate its buffers and retry.
</description>
</entry>
<entry name="stopped" value="2">
<description summary="session is no longer available">
The session has stopped. See ext_image_copy_capture_session_v1.stopped.
</description>
</entry>
</enum>
<event name="failed">
<description summary="capture failed">
This event indicates that the attempted frame copy has failed.
After receiving this event, the client must destroy the object.
</description>
<arg name="reason" type="uint" enum="failure_reason"/>
</event>
</interface>
<interface name="ext_image_copy_capture_cursor_session_v1" version="1">
<description summary="cursor capture session">
This object represents a cursor capture session. It extends the base
capture session with cursor-specific metadata.
</description>
<enum name="error">
<entry name="duplicate_session" value="1" summary="get_capture_session sent twice"/>
</enum>
<request name="destroy" type="destructor">
<description summary="delete this object">
Destroys the session. This request can be sent at any time by the
client.
This request doesn't affect ext_image_copy_capture_frame_v1 objects created by
this object.
</description>
</request>
<request name="get_capture_session">
<description summary="get image copy capturer session">
Gets the image copy capture session for this cursor session.
The session will produce frames of the cursor image. The compositor may
pause the session when the cursor leaves the captured area.
This request must not be sent more than once, or else the
duplicate_session protocol error is raised.
</description>
<arg name="session" type="new_id" interface="ext_image_copy_capture_session_v1"/>
</request>
<event name="enter">
<description summary="cursor entered captured area">
Sent when a cursor enters the captured area. It shall be generated
before the "position" and "hotspot" events when and only when a cursor
enters the area.
The cursor enters the captured area when the cursor image intersects
with the captured area. Note, this is different from e.g.
wl_pointer.enter.
</description>
</event>
<event name="leave">
<description summary="cursor left captured area">
Sent when a cursor leaves the captured area. No "position" or "hotspot"
event is generated for the cursor until the cursor enters the captured
area again.
</description>
</event>
<event name="position">
<description summary="position changed">
Cursors outside the image capture source do not get captured and no
event will be generated for them.
The given position is the position of the cursor's hotspot and it is
relative to the main buffer's top left corner in transformed buffer
pixel coordinates. The coordinates may be negative or greater than the
main buffer size.
</description>
<arg name="x" type="int" summary="position x coordinates"/>
<arg name="y" type="int" summary="position y coordinates"/>
</event>
<event name="hotspot">
<description summary="hotspot changed">
The hotspot describes the offset between the cursor image and the
position of the input device.
The given coordinates are the hotspot's offset from the origin in
buffer coordinates.
Clients should not apply the hotspot immediately: the hotspot becomes
effective when the next ext_image_copy_capture_frame_v1.ready event is received.
Compositors may delay this event until the client captures a new frame.
</description>
<arg name="x" type="int" summary="hotspot x coordinates"/>
<arg name="y" type="int" summary="hotspot y coordinates"/>
</event>
</interface>
</protocol>

328
proto/ext-session-lock-v1.xml Normal file
View file

@ -0,0 +1,328 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_session_lock_v1">
<copyright>
Copyright 2021 Isaac Freund
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.
</copyright>
<description summary="secure session locking with arbitrary graphics">
This protocol allows for a privileged Wayland client to lock the session
and display arbitrary graphics while the session is locked.
The compositor may choose to restrict this protocol to a special client
launched by the compositor itself or expose it to all privileged clients,
this is compositor policy.
The client is responsible for performing authentication and informing the
compositor when the session should be unlocked. If the client dies while
the session is locked the session remains locked, possibly permanently
depending on compositor policy.
The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document are to be interpreted as described in IETF RFC 2119.
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="ext_session_lock_manager_v1" version="1">
<description summary="used to lock the session">
This interface is used to request that the session be locked.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the session lock manager object">
This informs the compositor that the session lock manager object will
no longer be used. Existing objects created through this interface
remain valid.
</description>
</request>
<request name="lock">
<description summary="attempt to lock the session">
This request creates a session lock and asks the compositor to lock the
session. The compositor will send either the ext_session_lock_v1.locked
or ext_session_lock_v1.finished event on the created object in
response to this request.
</description>
<arg name="id" type="new_id" interface="ext_session_lock_v1"/>
</request>
</interface>
<interface name="ext_session_lock_v1" version="1">
<description summary="manage lock state and create lock surfaces">
In response to the creation of this object the compositor must send
either the locked or finished event.
The locked event indicates that the session is locked. This means
that the compositor must stop rendering and providing input to normal
clients. Instead the compositor must blank all outputs with an opaque
color such that their normal content is fully hidden.
The only surfaces that should be rendered while the session is locked
are the lock surfaces created through this interface and optionally,
at the compositor's discretion, special privileged surfaces such as
input methods or portions of desktop shell UIs.
The locked event must not be sent until a new "locked" frame (either
from a session lock surface or the compositor blanking the output) has
been presented on all outputs and no security sensitive normal/unlocked
content is possibly visible.
The finished event should be sent immediately on creation of this
object if the compositor decides that the locked event will not be sent.
The compositor may wait for the client to create and render session lock
surfaces before sending the locked event to avoid displaying intermediate
blank frames. However, it must impose a reasonable time limit if
waiting and send the locked event as soon as the hard requirements
described above can be met if the time limit expires. Clients should
immediately create lock surfaces for all outputs on creation of this
object to make this possible.
This behavior of the locked event is required in order to prevent
possible race conditions with clients that wish to suspend the system
or similar after locking the session. Without these semantics, clients
triggering a suspend after receiving the locked event would race with
the first "locked" frame being presented and normal/unlocked frames
might be briefly visible as the system is resumed if the suspend
operation wins the race.
If the client dies while the session is locked, the compositor must not
unlock the session in response. It is acceptable for the session to be
permanently locked if this happens. The compositor may choose to continue
to display the lock surfaces the client had mapped before it died or
alternatively fall back to a solid color, this is compositor policy.
Compositors may also allow a secure way to recover the session, the
details of this are compositor policy. Compositors may allow a new
client to create a ext_session_lock_v1 object and take responsibility
for unlocking the session, they may even start a new lock client
instance automatically.
</description>
<enum name="error">
<entry name="invalid_destroy" value="0"
summary="attempted to destroy session lock while locked"/>
<entry name="invalid_unlock" value="1"
summary="unlock requested but locked event was never sent"/>
<entry name="role" value="2"
summary="given wl_surface already has a role"/>
<entry name="duplicate_output" value="3"
summary="given output already has a lock surface"/>
<entry name="already_constructed" value="4"
summary="given wl_surface has a buffer attached or committed"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroy the session lock">
This informs the compositor that the lock object will no longer be
used. Existing objects created through this interface remain valid.
After this request is made, lock surfaces created through this object
should be destroyed by the client as they will no longer be used by
the compositor.
It is a protocol error to make this request if the locked event was
sent, the unlock_and_destroy request must be used instead.
</description>
</request>
<event name="locked">
<description summary="session successfully locked">
This client is now responsible for displaying graphics while the
session is locked and deciding when to unlock the session.
The locked event must not be sent until a new "locked" frame has been
presented on all outputs and no security sensitive normal/unlocked
content is possibly visible.
If this event is sent, making the destroy request is a protocol error,
the lock object must be destroyed using the unlock_and_destroy request.
</description>
</event>
<event name="finished">
<description summary="the session lock object should be destroyed">
The compositor has decided that the session lock should be destroyed
as it will no longer be used by the compositor. Exactly when this
event is sent is compositor policy, but it must never be sent more
than once for a given session lock object.
This might be sent because there is already another ext_session_lock_v1
object held by a client, or the compositor has decided to deny the
request to lock the session for some other reason. This might also
be sent because the compositor implements some alternative, secure
way to authenticate and unlock the session.
The finished event should be sent immediately on creation of this
object if the compositor decides that the locked event will not
be sent.
If the locked event is sent on creation of this object the finished
event may still be sent at some later time in this object's
lifetime. This is compositor policy.
Upon receiving this event, the client should make either the destroy
request or the unlock_and_destroy request, depending on whether or
not the locked event was received on this object.
</description>
</event>
<request name="get_lock_surface">
<description summary="create a lock surface for a given output">
The client is expected to create lock surfaces for all outputs
currently present and any new outputs as they are advertised. These
won't be displayed by the compositor unless the lock is successful
and the locked event is sent.
Providing a wl_surface which already has a role or already has a buffer
attached or committed is a protocol error, as is attaching/committing
a buffer before the first ext_session_lock_surface_v1.configure event.
Attempting to create more than one lock surface for a given output
is a duplicate_output protocol error.
</description>
<arg name="id" type="new_id" interface="ext_session_lock_surface_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="output" type="object" interface="wl_output"/>
</request>
<request name="unlock_and_destroy" type="destructor">
<description summary="unlock the session, destroying the object">
This request indicates that the session should be unlocked, for
example because the user has entered their password and it has been
verified by the client.
This request also informs the compositor that the lock object will
no longer be used and should be destroyed. Existing objects created
through this interface remain valid.
After this request is made, lock surfaces created through this object
should be destroyed by the client as they will no longer be used by
the compositor.
It is a protocol error to make this request if the locked event has
not been sent. In that case, the lock object must be destroyed using
the destroy request.
Note that a correct client that wishes to exit directly after unlocking
the session must use the wl_display.sync request to ensure the server
receives and processes the unlock_and_destroy request. Otherwise
there is no guarantee that the server has unlocked the session due
to the asynchronous nature of the Wayland protocol. For example,
the server might terminate the client with a protocol error before
it processes the unlock_and_destroy request.
</description>
</request>
</interface>
<interface name="ext_session_lock_surface_v1" version="1">
<description summary="a surface displayed while the session is locked">
The client may use lock surfaces to display a screensaver, render a
dialog to enter a password and unlock the session, or however else it
sees fit.
On binding this interface the compositor will immediately send the
first configure event. After making the ack_configure request in
response to this event the client should attach and commit the first
buffer. Committing the surface before acking the first configure is a
protocol error. Committing the surface with a null buffer at any time
is a protocol error.
The compositor is free to handle keyboard/pointer focus for lock
surfaces however it chooses. A reasonable way to do this would be to
give the first lock surface created keyboard focus and change keyboard
focus if the user clicks on other surfaces.
</description>
<enum name="error">
<entry name="commit_before_first_ack" value="0"
summary="surface committed before first ack_configure request"/>
<entry name="null_buffer" value="1"
summary="surface committed with a null buffer"/>
<entry name="dimensions_mismatch" value="2"
summary="failed to match ack'd width/height"/>
<entry name="invalid_serial" value="3"
summary="serial provided in ack_configure is invalid"/>
</enum>
<request name="destroy" type="destructor">
<description summary="destroy the lock surface object">
This informs the compositor that the lock surface object will no
longer be used.
It is recommended for a lock client to destroy lock surfaces if
their corresponding wl_output global is removed.
If a lock surface on an active output is destroyed before the
ext_session_lock_v1.unlock_and_destroy event is sent, the compositor
must fall back to rendering a solid color.
</description>
</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.
Sending an ack_configure request consumes the configure event
referenced by the given serial, as well as all older configure events
sent on this object.
It is a protocol error to issue multiple ack_configure requests
referencing the same configure event or to issue an ack_configure
request referencing a configure event older than the last configure
event acked for a given lock surface.
</description>
<arg name="serial" type="uint" summary="serial from the configure event"/>
</request>
<event name="configure">
<description summary="the client should resize its surface">
This event is sent once on binding the interface and may be sent again
at the compositor's discretion, for example if output geometry changes.
The width and height are in surface-local coordinates and are exact
requirements. Failing to match these surface dimensions in the next
commit after acking a configure is a protocol error.
</description>
<arg name="serial" type="uint" summary="serial for use in ack_configure"/>
<arg name="width" type="uint"/>
<arg name="height" type="uint"/>
</event>
</interface>
</protocol>

110
proto/ext-transient-seat-v1.xml Normal file
View file

@ -0,0 +1,110 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_transient_seat_v1">
<copyright>
Copyright © 2020 - 2023 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="protocol for creating temporary seats">
The transient seat protocol can be used by privileged clients to create
independent seats that will be removed from the compositor when the client
destroys its transient seat.
This protocol is intended for use with virtual input protocols such as
"virtual_keyboard_unstable_v1" or "wlr_virtual_pointer_unstable_v1", both
of which allow the user to select a seat.
The "wl_seat" global created by this protocol does not generate input events
on its own, or have any capabilities except those assigned to it by other
protocol extensions, such as the ones mentioned above.
For example, a remote desktop server can create a seat with virtual inputs
for each remote user by following these steps for each new connection:
* Create a transient seat
* Wait for the transient seat to be created
* Locate a "wl_seat" global with a matching name
* Create virtual inputs using the resulting "wl_seat" global
</description>
<interface name="ext_transient_seat_manager_v1" version="1">
<description summary="transient seat manager">
The transient seat manager creates short-lived seats.
</description>
<request name="create">
<description summary="create a transient seat">
Create a new seat that is removed when the client side transient seat
object is destroyed.
The actual seat may be removed sooner, in which case the transient seat
object shall become inert.
</description>
<arg name="seat" type="new_id" interface="ext_transient_seat_v1"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
Destroy the manager.
All objects created by the manager will remain valid until they are
destroyed themselves.
</description>
</request>
</interface>
<interface name="ext_transient_seat_v1" version="1">
<description summary="transient seat handle">
When the transient seat handle is destroyed, the seat itself will also be
destroyed.
</description>
<event name="ready">
<description summary="transient seat is ready">
This event advertises the global name for the wl_seat to be used with
wl_registry_bind.
It is sent exactly once, immediately after the transient seat is created
and the new "wl_seat" global is advertised, if and only if the creation
of the transient seat was allowed.
</description>
<arg name="global_name" type="uint"/>
</event>
<event name="denied">
<description summary="transient seat creation denied">
The event informs the client that the compositor denied its request to
create a transient seat.
It is sent exactly once, immediately after the transient seat object is
created, if and only if the creation of the transient seat was denied.
After receiving this event, the client should destroy the object.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy transient seat">
When the transient seat object is destroyed by the client, the
associated seat created by the compositor is also destroyed.
</description>
</request>
</interface>
</protocol>

422
proto/ext-workspace-v1.xml Normal file
View file

@ -0,0 +1,422 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ext_workspace_v1">
<copyright>
Copyright © 2019 Christopher Billington
Copyright © 2020 Ilia Bozhinov
Copyright © 2022 Victoria Brekenfeld
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="ext_workspace_manager_v1" version="1">
<description summary="list and control workspaces">
Workspaces, also called virtual desktops, are groups of surfaces. A
compositor with a concept of workspaces may only show some such groups of
surfaces (those of 'active' workspaces) at a time. 'Activating' a
workspace is a request for the compositor to display that workspace's
surfaces as normal, whereas the compositor may hide or otherwise
de-emphasise surfaces that are associated only with 'inactive' workspaces.
Workspaces are grouped by which sets of outputs they correspond to, and
may contain surfaces only from those outputs. In this way, it is possible
for each output to have its own set of workspaces, or for all outputs (or
any other arbitrary grouping) to share workspaces. Compositors may
optionally conceptually arrange each group of workspaces in an
N-dimensional grid.
The purpose of this protocol is to enable the creation of taskbars and
docks by providing them with a list of workspaces and their properties,
and allowing them to activate and deactivate workspaces.
After a client binds the ext_workspace_manager_v1, each workspace will be
sent via the workspace event.
</description>
<event name="workspace_group">
<description summary="a workspace group has been created">
This event is emitted whenever a new workspace group has been created.
All initial details of the workspace group (outputs) will be
sent immediately after this event via the corresponding events in
ext_workspace_group_handle_v1 and ext_workspace_handle_v1.
</description>
<arg name="workspace_group" type="new_id" interface="ext_workspace_group_handle_v1"/>
</event>
<event name="workspace">
<description summary="workspace has been created">
This event is emitted whenever a new workspace has been created.
All initial details of the workspace (name, coordinates, state) will
be sent immediately after this event via the corresponding events in
ext_workspace_handle_v1.
Workspaces start off unassigned to any workspace group.
</description>
<arg name="workspace" type="new_id" interface="ext_workspace_handle_v1"/>
</event>
<request name="commit">
<description summary="all requests about the workspaces have been sent">
The client must send this request after it has finished sending other
requests. The compositor must process a series of requests preceding a
commit request atomically.
This allows changes to the workspace properties to be seen as atomic,
even if they happen via multiple events, and even if they involve
multiple ext_workspace_handle_v1 objects, for example, deactivating one
workspace and activating another.
</description>
</request>
<event name="done">
<description summary="all information about the workspaces and workspace groups has been sent">
This event is sent after all changes in all workspaces and workspace groups have been
sent.
This allows changes to one or more ext_workspace_group_handle_v1
properties and ext_workspace_handle_v1 properties
to be seen as atomic, even if they happen via multiple events.
In particular, an output moving from one workspace group to
another sends an output_enter event and an output_leave event to the two
ext_workspace_group_handle_v1 objects in question. The compositor sends
the done event only after updating the output information in both
workspace groups.
</description>
</event>
<event name="finished" type="destructor">
<description summary="the compositor has finished with the workspace_manager">
This event indicates that the compositor is done sending events to the
ext_workspace_manager_v1. The server will destroy the object
immediately after sending this request.
</description>
</event>
<request name="stop">
<description summary="stop sending events">
Indicates the client no longer wishes to receive events for new
workspace groups. However the compositor may emit further workspace
events, until the finished event is emitted. The compositor is expected
to send the finished event eventually once the stop request has been processed.
The client must not send any requests after this one, doing so will raise a wl_display
invalid_object error.
</description>
</request>
</interface>
<interface name="ext_workspace_group_handle_v1" version="1">
<description summary="a workspace group assigned to a set of outputs">
A ext_workspace_group_handle_v1 object represents a workspace group
that is assigned a set of outputs and contains a number of workspaces.
The set of outputs assigned to the workspace group is conveyed to the client via
output_enter and output_leave events, and its workspaces are conveyed with
workspace events.
For example, a compositor which has a set of workspaces for each output may
advertise a workspace group (and its workspaces) per output, whereas a compositor
where a workspace spans all outputs may advertise a single workspace group for all
outputs.
</description>
<enum name="group_capabilities" bitfield="true">
<entry name="create_workspace" value="1" summary="create_workspace request is available"/>
</enum>
<event name="capabilities">
<description summary="compositor capabilities">
This event advertises the capabilities supported by the compositor. If
a capability isn't supported, clients should hide or disable the UI
elements that expose this functionality. For instance, if the
compositor doesn't advertise support for creating workspaces, a button
triggering the create_workspace request should not be displayed.
The compositor will ignore requests it doesn't support. For instance,
a compositor which doesn't advertise support for creating workspaces will ignore
create_workspace requests.
Compositors must send this event once after creation of an
ext_workspace_group_handle_v1. When the capabilities change, compositors
must send this event again.
</description>
<arg name="capabilities" type="uint" summary="capabilities" enum="group_capabilities"/>
</event>
<event name="output_enter">
<description summary="output assigned to workspace group">
This event is emitted whenever an output is assigned to the workspace
group or a new `wl_output` object is bound by the client, which was already
assigned to this workspace_group.
</description>
<arg name="output" type="object" interface="wl_output"/>
</event>
<event name="output_leave">
<description summary="output removed from workspace group">
This event is emitted whenever an output is removed from the workspace
group.
</description>
<arg name="output" type="object" interface="wl_output"/>
</event>
<event name="workspace_enter">
<description summary="workspace added to workspace group">
This event is emitted whenever a workspace is assigned to this group.
A workspace may only ever be assigned to a single group at a single point
in time, but can be re-assigned during it's lifetime.
</description>
<arg name="workspace" type="object" interface="ext_workspace_handle_v1"/>
</event>
<event name="workspace_leave">
<description summary="workspace removed from workspace group">
This event is emitted whenever a workspace is removed from this group.
</description>
<arg name="workspace" type="object" interface="ext_workspace_handle_v1"/>
</event>
<event name="removed">
<description summary="this workspace group has been removed">
This event is send when the group associated with the ext_workspace_group_handle_v1
has been removed. After sending this request the compositor will immediately consider
the object inert. Any requests will be ignored except the destroy request.
It is guaranteed there won't be any more events referencing this
ext_workspace_group_handle_v1.
The compositor must remove all workspaces belonging to a workspace group
via a workspace_leave event before removing the workspace group.
</description>
</event>
<request name="create_workspace">
<description summary="create a new workspace">
Request that the compositor create a new workspace with the given name
and assign it to this group.
There is no guarantee that the compositor will create a new workspace,
or that the created workspace will have the provided name.
</description>
<arg name="workspace" type="string"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the ext_workspace_group_handle_v1 object">
Destroys the ext_workspace_group_handle_v1 object.
This request should be send either when the client does not want to
use the workspace group object any more or after the removed event to finalize
the destruction of the object.
</description>
</request>
</interface>
<interface name="ext_workspace_handle_v1" version="1">
<description summary="a workspace handing a group of surfaces">
A ext_workspace_handle_v1 object represents a workspace that handles a
group of surfaces.
Each workspace has:
- a name, conveyed to the client with the name event
- potentially an id conveyed with the id event
- a list of states, conveyed to the client with the state event
- and optionally a set of coordinates, conveyed to the client with the
coordinates event
The client may request that the compositor activate or deactivate the workspace.
Each workspace can belong to only a single workspace group.
Depepending on the compositor policy, there might be workspaces with
the same name in different workspace groups, but these workspaces are still
separate (e.g. one of them might be active while the other is not).
</description>
<event name="id">
<description summary="workspace id">
If this event is emitted, it will be send immediately after the
ext_workspace_handle_v1 is created or when an id is assigned to
a workspace (at most once during it's lifetime).
An id will never change during the lifetime of the `ext_workspace_handle_v1`
and is guaranteed to be unique during it's lifetime.
Ids are not human-readable and shouldn't be displayed, use `name` for that purpose.
Compositors are expected to only send ids for workspaces likely stable across multiple
sessions and can be used by clients to store preferences for workspaces. Workspaces without
ids should be considered temporary and any data associated with them should be deleted once
the respective object is lost.
</description>
<arg name="id" type="string"/>
</event>
<event name="name">
<description summary="workspace name changed">
This event is emitted immediately after the ext_workspace_handle_v1 is
created and whenever the name of the workspace changes.
A name is meant to be human-readable and can be displayed to a user.
Unlike the id it is neither stable nor unique.
</description>
<arg name="name" type="string"/>
</event>
<event name="coordinates">
<description summary="workspace coordinates changed">
This event is used to organize workspaces into an N-dimensional grid
within a workspace group, and if supported, is emitted immediately after
the ext_workspace_handle_v1 is created and whenever the coordinates of
the workspace change. Compositors may not send this event if they do not
conceptually arrange workspaces in this way. If compositors simply
number workspaces, without any geometric interpretation, they may send
1D coordinates, which clients should not interpret as implying any
geometry. Sending an empty array means that the compositor no longer
orders the workspace geometrically.
Coordinates have an arbitrary number of dimensions N with an uint32
position along each dimension. By convention if N > 1, the first
dimension is X, the second Y, the third Z, and so on. The compositor may
chose to utilize these events for a more novel workspace layout
convention, however. No guarantee is made about the grid being filled or
bounded; there may be a workspace at coordinate 1 and another at
coordinate 1000 and none in between. Within a workspace group, however,
workspaces must have unique coordinates of equal dimensionality.
</description>
<arg name="coordinates" type="array"/>
</event>
<enum name="state" bitfield="true">
<description summary="types of states on the workspace">
The different states that a workspace can have.
</description>
<entry name="active" value="1" summary="the workspace is active"/>
<entry name="urgent" value="2" summary="the workspace requests attention"/>
<entry name="hidden" value="4">
<description summary="the workspace is not visible">
The workspace is not visible in its workspace group, and clients
attempting to visualize the compositor workspace state should not
display such workspaces.
</description>
</entry>
</enum>
<event name="state">
<description summary="the state of the workspace changed">
This event is emitted immediately after the ext_workspace_handle_v1 is
created and each time the workspace state changes, either because of a
compositor action or because of a request in this protocol.
Missing states convey the opposite meaning, e.g. an unset active bit
means the workspace is currently inactive.
</description>
<arg name="state" type="uint" enum="state"/>
</event>
<enum name="workspace_capabilities" bitfield="true">
<entry name="activate" value="1" summary="activate request is available"/>
<entry name="deactivate" value="2" summary="deactivate request is available"/>
<entry name="remove" value="4" summary="remove request is available"/>
<entry name="assign" value="8" summary="assign request is available"/>
</enum>
<event name="capabilities">
<description summary="compositor capabilities">
This event advertises the capabilities supported by the compositor. If
a capability isn't supported, clients should hide or disable the UI
elements that expose this functionality. For instance, if the
compositor doesn't advertise support for removing workspaces, a button
triggering the remove request should not be displayed.
The compositor will ignore requests it doesn't support. For instance,
a compositor which doesn't advertise support for remove will ignore
remove requests.
Compositors must send this event once after creation of an
ext_workspace_handle_v1 . When the capabilities change, compositors
must send this event again.
</description>
<arg name="capabilities" type="uint" summary="capabilities" enum="workspace_capabilities"/>
</event>
<event name="removed">
<description summary="this workspace has been removed">
This event is send when the workspace associated with the ext_workspace_handle_v1
has been removed. After sending this request, the compositor will immediately consider
the object inert. Any requests will be ignored except the destroy request.
It is guaranteed there won't be any more events referencing this
ext_workspace_handle_v1.
The compositor must only remove a workspaces not currently belonging to any
workspace_group.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="destroy the ext_workspace_handle_v1 object">
Destroys the ext_workspace_handle_v1 object.
This request should be made either when the client does not want to
use the workspace object any more or after the remove event to finalize
the destruction of the object.
</description>
</request>
<request name="activate">
<description summary="activate the workspace">
Request that this workspace be activated.
There is no guarantee the workspace will be actually activated, and
behaviour may be compositor-dependent. For example, activating a
workspace may or may not deactivate all other workspaces in the same
group.
</description>
</request>
<request name="deactivate">
<description summary="deactivate the workspace">
Request that this workspace be deactivated.
There is no guarantee the workspace will be actually deactivated.
</description>
</request>
<request name="assign">
<description summary="assign workspace to group">
Requests that this workspace is assigned to the given workspace group.
There is no guarantee the workspace will be assigned.
</description>
<arg name="workspace_group" type="object" interface="ext_workspace_group_handle_v1"/>
</request>
<request name="remove">
<description summary="remove the workspace">
Request that this workspace be removed.
There is no guarantee the workspace will be actually removed.
</description>
</request>
</interface>
</protocol>

95
proto/fake-input.xml Normal file
View file

@ -0,0 +1,95 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="fake_input">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2015 Martin Gräßlin
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="org_kde_kwin_fake_input" version="5">
<description summary="Fake input manager">
This interface allows other processes to provide fake input events.
Purpose is on the one hand side to provide testing facilities like XTest on X11.
But also to support use case like kdeconnect's mouse pad interface.
A compositor should not trust the input received from this interface.
Clients should not expect that the compositor honors the requests from this
interface.
Warning! The protocol described in this file is a desktop environment
implementation detail. Regular clients must not use this protocol.
Backward incompatible changes may be added without bumping the major
version of the extension.
</description>
<request name="authenticate">
<description summary="Information why the client wants to use the interface">
A client should use this request to tell the compositor why it wants to
use this interface. The compositor might use the information to decide
whether it wants to grant the request. The data might also be passed to
the user to decide whether the application should get granted access to
this very privileged interface.
</description>
<arg name="application" type="string" summary="user visible name of the application"/>
<arg name="reason" type="string" summary="reason why the application wants to use this interface"/>
</request>
<request name="pointer_motion">
<arg name="delta_x" type="fixed"/>
<arg name="delta_y" type="fixed"/>
</request>
<request name="button">
<arg name="button" type="uint"/>
<arg name="state" type="uint"/>
</request>
<request name="axis">
<arg name="axis" type="uint"/>
<arg name="value" type="fixed"/>
</request>
<request name="touch_down" since="2">
<description summary="touch down event">
A client should use this request to send touch down event at specific
coordinates.
</description>
<arg name="id" type="uint" summary="unique id for touch down event"/>
<arg name="x" type="fixed" summary="x coordinate for touch down event"/>
<arg name="y" type="fixed" summary="y coordinate for touch down event"/>
</request>
<request name="touch_motion" since="2">
<description summary="touch motion event">
A client should use this request to send touch motion to specific position.
</description>
<arg name="id" type="uint" summary="unique id for touch motion event"/>
<arg name="x" type="fixed" summary="x coordinate for touch motion event"/>
<arg name="y" type="fixed" summary="y coordinate for touch motion event"/>
</request>
<request name="touch_up" since="2">
<description summary="touch up event">
A client should use this request to send touch up event.
</description>
<arg name="id" type="uint" summary="unique id for touch up event"/>
</request>
<request name="touch_cancel" since="2">
<description summary="touch cancel event">
A client should use this request to cancel the current
touch event.
</description>
</request>
<request name="touch_frame" since="2">
<description summary="touch frame event">
A client should use this request to send touch frame event.
</description>
</request>
<request name="pointer_motion_absolute" since="3">
<arg name="x" type="fixed"/>
<arg name="y" type="fixed"/>
</request>
<request name="keyboard_key" since="4">
<arg name="button" type="uint"/>
<arg name="state" type="uint"/>
</request>
<!-- Version 5 additions -->
<request name="destroy" type="destructor" since="5">
<description summary="Destroy the fake input device"/>
</request>
</interface>
</protocol>

143
proto/fifo-v1.xml Normal file
View file

@ -0,0 +1,143 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="fifo_v1">
<copyright>
Copyright © 2023 Valve 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="wp_fifo_manager_v1" version="1">
<description summary="protocol for fifo constraints">
When a Wayland compositor considers applying a content update,
it must ensure all the update's readiness constraints (fences, etc)
are met.
This protocol provides a way to use the completion of a display refresh
cycle as an additional readiness constraint.
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>
<enum name="error">
<description summary="fatal presentation error">
These fatal protocol errors may be emitted in response to
illegal requests.
</description>
<entry name="already_exists" value="0"
summary="fifo manager already exists for surface"/>
</enum>
<request name="destroy" type="destructor">
<description summary="unbind from the manager 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="get_fifo">
<description summary="request fifo interface for surface">
Establish a fifo object for a surface that may be used to add
display refresh constraints to content updates.
Only one such object may exist for a surface and attempting
to create more than one will result in an already_exists
protocol error. If a surface is acted on by multiple software
components, general best practice is that only the component
performing wl_surface.attach operations should use this protocol.
</description>
<arg name="id" type="new_id" interface="wp_fifo_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
</interface>
<interface name="wp_fifo_v1" version="1">
<description summary="fifo interface">
A fifo object for a surface that may be used to add
display refresh constraints to content updates.
</description>
<enum name="error">
<description summary="fatal error">
These fatal protocol errors may be emitted in response to
illegal requests.
</description>
<entry name="surface_destroyed" value="0"
summary="the associated surface no longer exists"/>
</enum>
<request name="set_barrier">
<description summary="sets the start point for a fifo constraint">
When the content update containing the "set_barrier" is applied,
it sets a "fifo_barrier" condition on the surface associated with
the fifo object. The condition is cleared immediately after the
following latching deadline for non-tearing presentation.
The compositor may clear the condition early if it must do so to
ensure client forward progress assumptions.
To wait for this condition to clear, use the "wait_barrier" request.
"set_barrier" is double-buffered state, see wl_surface.commit.
Requesting set_barrier after the fifo object's surface is
destroyed will generate a "surface_destroyed" error.
</description>
</request>
<request name="wait_barrier">
<description summary="adds a fifo constraint to a content update">
Indicate that this content update is not ready while a
"fifo_barrier" condition is present on the surface.
This means that when the content update containing "set_barrier"
was made active at a latching deadline, it will be active for
at least one refresh cycle. A content update which is allowed to
tear might become active after a latching deadline if no content
update became active at the deadline.
The constraint must be ignored if the surface is a subsurface in
synchronized mode. If the surface is not being updated by the
compositor (off-screen, occluded) the compositor may ignore the
constraint. Clients must use an additional mechanism such as
frame callbacks or timestamps to ensure throttling occurs under
all conditions.
"wait_barrier" is double-buffered state, see wl_surface.commit.
Requesting "wait_barrier" after the fifo object's surface is
destroyed will generate a "surface_destroyed" error.
</description>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the fifo interface">
Informs the server that the client will no longer be using
this protocol object.
Surface state changes previously made by this protocol are
unaffected by this object's destruction.
</description>
</request>
</interface>
</protocol>

102
proto/fractional-scale-v1.xml Normal file
View file

@ -0,0 +1,102 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="fractional_scale_v1">
<copyright>
Copyright © 2022 Kenny Levinsen
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 fractional surface scales">
This protocol allows a compositor to suggest for surfaces to render at
fractional scales.
A client can submit scaled content by utilizing wp_viewport. This is done by
creating a wp_viewport object for the surface and setting the destination
rectangle to the surface size before the scale factor is applied.
The buffer size is calculated by multiplying the surface size by the
intended scale.
The wl_surface buffer scale should remain set to 1.
If a surface has a surface-local size of 100 px by 50 px and wishes to
submit buffers with a scale of 1.5, then a buffer of 150px by 75 px should
be used and the wp_viewport destination rectangle should be 100 px by 50 px.
For toplevel surfaces, the size is rounded halfway away from zero. The
rounding algorithm for subsurface position and size is not defined.
</description>
<interface name="wp_fractional_scale_manager_v1" version="1">
<description summary="fractional surface scale information">
A global interface for requesting surfaces to use fractional scales.
</description>
<request name="destroy" type="destructor">
<description summary="unbind the fractional surface scale interface">
Informs the server that the client will not be using this protocol
object anymore. This does not affect any other objects,
wp_fractional_scale_v1 objects included.
</description>
</request>
<enum name="error">
<entry name="fractional_scale_exists" value="0"
summary="the surface already has a fractional_scale object associated"/>
</enum>
<request name="get_fractional_scale">
<description summary="extend surface interface for scale information">
Create an add-on object for the the wl_surface to let the compositor
request fractional scales. If the given wl_surface already has a
wp_fractional_scale_v1 object associated, the fractional_scale_exists
protocol error is raised.
</description>
<arg name="id" type="new_id" interface="wp_fractional_scale_v1"
summary="the new surface scale info interface id"/>
<arg name="surface" type="object" interface="wl_surface"
summary="the surface"/>
</request>
</interface>
<interface name="wp_fractional_scale_v1" version="1">
<description summary="fractional scale interface to a wl_surface">
An additional interface to a wl_surface object which allows the compositor
to inform the client of the preferred scale.
</description>
<request name="destroy" type="destructor">
<description summary="remove surface scale information for surface">
Destroy the fractional scale object. When this object is destroyed,
preferred_scale events will no longer be sent.
</description>
</request>
<event name="preferred_scale">
<description summary="notify of new preferred scale">
Notification of a new preferred scale for this surface that the
compositor suggests that the client should use.
The sent scale is the numerator of a fraction with a denominator of 120.
</description>
<arg name="scale" type="uint" summary="the new preferred scale"/>
</event>
</interface>
</protocol>

254
proto/fullscreen-shell-unstable-v1.xml 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" type="destructor">
<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" type="destructor">
<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" type="destructor">
<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>

107
proto/gtk-shell.xml Normal file
View file

@ -0,0 +1,107 @@
<protocol name="gtk">
<interface name="gtk_shell1" version="5">
<description summary="gtk specific extensions">
gtk_shell is a protocol extension providing additional features for
clients implementing it.
</description>
<enum name="capability">
<entry name="global_app_menu" value="1"/>
<entry name="global_menu_bar" value="2"/>
<entry name="desktop_icons" value="3"/>
</enum>
<event name="capabilities">
<arg name="capabilities" type="uint"/>
</event>
<request name="get_gtk_surface">
<arg name="gtk_surface" type="new_id" interface="gtk_surface1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="set_startup_id">
<arg name="startup_id" type="string" allow-null="true"/>
</request>
<request name="system_bell">
<arg name="surface" type="object" interface="gtk_surface1" allow-null="true"/>
</request>
<!-- Version 3 additions -->
<request name="notify_launch" since="3">
<arg name="startup_id" type="string"/>
</request>
</interface>
<interface name="gtk_surface1" version="5">
<request name="set_dbus_properties">
<arg name="application_id" type="string" allow-null="true"/>
<arg name="app_menu_path" type="string" allow-null="true"/>
<arg name="menubar_path" type="string" allow-null="true"/>
<arg name="window_object_path" type="string" allow-null="true"/>
<arg name="application_object_path" type="string" allow-null="true"/>
<arg name="unique_bus_name" type="string" allow-null="true"/>
</request>
<request name="set_modal"/>
<request name="unset_modal"/>
<request name="present">
<arg name="time" type="uint"/>
</request>
<!-- Version 2 additions -->
<enum name="state">
<entry name="tiled" value="1"/>
<entry name="tiled_top" value="2" since="2" />
<entry name="tiled_right" value="3" since="2" />
<entry name="tiled_bottom" value="4" since="2" />
<entry name="tiled_left" value="5" since="2" />
</enum>
<enum name="edge_constraint" since="2">
<entry name="resizable_top" value="1"/>
<entry name="resizable_right" value="2"/>
<entry name="resizable_bottom" value="3"/>
<entry name="resizable_left" value="4"/>
</enum>
<event name="configure">
<arg name="states" type="array"/>
</event>
<event name="configure_edges" since="2">
<arg name="constraints" type="array"/>
</event>
<!-- Version 3 additions -->
<request name="request_focus" since="3">
<arg name="startup_id" type="string" allow-null="true"/>
</request>
<!-- Version 4 additions -->
<request name="release" type="destructor" since="4"/>
<!-- Version 5 additions -->
<enum name="gesture" since="5">
<entry name="double_click" value="1"/>
<entry name="right_click" value="2"/>
<entry name="middle_click" value="3"/>
</enum>
<enum name="error" since="5">
<entry name="invalid_gesture" value="0"/>
</enum>
<request name="titlebar_gesture" since="5">
<arg name="serial" type="uint"/>
<arg name="seat" type="object" interface="wl_seat"/>
<arg name="gesture" type="uint" enum="gesture"/>
</request>
</interface>
</protocol>

95
proto/hyprland-ctm-control-v1.xml Normal file
View file

@ -0,0 +1,95 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="hyprland_ctm_control_v1">
<copyright>
Copyright © 2024 Vaxry
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</copyright>
<description summary="controlling outputs' color transform matrix">
This protocol allows a client to control outputs' color transform matrix (CTM).
This protocol is privileged and should not be exposed to unprivileged clients.
</description>
<interface name="hyprland_ctm_control_manager_v1" version="1">
<description summary="manager to control CTMs">
This object is a manager which offers requests to control CTMs.
If any changes are done, once this object is destroyed, CTMs are reset back to
an identity matrix.
</description>
<request name="set_ctm_for_output">
<description summary="set the CTM of an output">
Set a CTM for a wl_output.
This state is not applied immediately; clients must call .commit to
apply any pending changes.
The provided values describe a 3x3 Row-Major CTM with values in the range of [0, ∞)
Passing values outside of the range will raise an invalid_matrix error.
The default value of the CTM is an identity matrix.
If an output doesn't get a CTM set with set_ctm_for_output and commit is called,
that output will get its CTM reset to an identity matrix.
</description>
<arg name="output" type="object" interface="wl_output"/>
<arg name="mat0" type="fixed"/>
<arg name="mat1" type="fixed"/>
<arg name="mat2" type="fixed"/>
<arg name="mat3" type="fixed"/>
<arg name="mat4" type="fixed"/>
<arg name="mat5" type="fixed"/>
<arg name="mat6" type="fixed"/>
<arg name="mat7" type="fixed"/>
<arg name="mat8" type="fixed"/>
</request>
<request name="commit">
<description summary="commit the pending state">
Commits the pending state(s) set by set_ctm_for_output.
</description>
</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.
The CTMs of all outputs will be reset to an identity matrix.
</description>
</request>
<enum name="error">
<entry name="invalid_matrix" value="0"
summary="the matrix values are invalid."/>
</enum>
</interface>
</protocol>

128
proto/hyprland-focus-grab-v1.xml Normal file
View file

@ -0,0 +1,128 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="hyprland_focus_grab_v1">
<copyright>
Copyright © 2024 outfoxxed
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</copyright>
<description summary="limit input focus to a set of surfaces">
This protocol allows clients to limit input focus to a specific set
of surfaces and receive a notification when the limiter is removed as
detailed below.
</description>
<interface name="hyprland_focus_grab_manager_v1" version="1">
<description summary="manager for focus grab objects">
This interface allows a client to create surface grab objects.
</description>
<request name="create_grab">
<description summary="create a focus grab object">
Create a surface grab object.
</description>
<arg name="grab" type="new_id" interface="hyprland_focus_grab_v1"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the focus grab manager">
Destroy the focus grab manager.
This doesn't destroy existing focus grab objects.
</description>
</request>
</interface>
<interface name="hyprland_focus_grab_v1" version="1">
<description summary="input focus limiter">
This interface restricts input focus to a specified whitelist of
surfaces as long as the focus grab object exists and has at least
one comitted surface.
Mouse and touch events inside a whitelisted surface will be passed
to the surface normally, while events outside of a whitelisted surface
will clear the grab object. Keyboard events will be passed to the client
and a compositor-picked surface in the whitelist will receive a
wl_keyboard::enter event if a whitelisted surface is not already entered.
Upon meeting implementation-defined criteria usually meaning a mouse or
touch input outside of any whitelisted surfaces, the compositor will
clear the whitelist, rendering the grab inert and sending the cleared
event. The same will happen if another focus grab or similar action
is started at the compositor's discretion.
</description>
<request name="add_surface">
<description summary="add a surface to the focus whitelist">
Add a surface to the whitelist. Destroying the surface is treated the
same as an explicit call to remove_surface and duplicate additions are
ignored.
Does not take effect until commit is called.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="remove_surface">
<description summary="remove a surface from the focus whitelist">
Remove a surface from the whitelist. Destroying the surface is treated
the same as an explicit call to this function.
If the grab was active and the removed surface was entered by the
keyboard, another surface will be entered on commit.
Does not take effect until commit is called.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="commit">
<description summary="commit the focus whitelist">
Commit pending changes to the surface whitelist.
If the list previously had no entries and now has at least one, the grab
will start. If it previously had entries and now has none, the grab will
become inert.
</description>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the focus grab">
Destroy the grab object and remove the grab if active.
</description>
</request>
<event name="cleared">
<description summary="the focus grab was cleared">
Sent when an active grab is cancelled by the compositor,
regardless of cause.
</description>
</event>
</interface>
</protocol>

112
proto/hyprland-global-shortcuts-v1.xml Normal file
View file

@ -0,0 +1,112 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="hyprland_global_shortcuts_v1">
<copyright>
Copyright © 2022 Vaxry
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</copyright>
<description summary="registering global shortcuts">
This protocol allows a client to register triggerable actions,
meant to be global shortcuts.
</description>
<interface name="hyprland_global_shortcuts_manager_v1" version="1">
<description summary="manager to register global shortcuts">
This object is a manager which offers requests to create global shortcuts.
</description>
<request name="register_shortcut">
<description summary="register a shortcut">
Register a new global shortcut.
A global shortcut is anonymous, meaning the app does not know what key(s) trigger it.
The shortcut's keybinding shall be dealt with by the compositor.
In the case of a duplicate app_id + id combination, the already_taken protocol error is raised.
</description>
<arg name="shortcut" type="new_id" interface="hyprland_global_shortcut_v1"/>
<arg name="id" type="string" summary="a unique id for the shortcut"/>
<arg name="app_id" type="string" summary="the app_id of the application requesting the shortcut"/>
<arg name="description" type="string" summary="user-readable text describing what the shortcut does."/>
<arg name="trigger_description" type="string" summary="user-readable text describing how to trigger the shortcut for the client to render."/>
</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>
<enum name="error">
<entry name="already_taken" value="0"
summary="the app_id + id combination has already been registered."/>
</enum>
</interface>
<interface name="hyprland_global_shortcut_v1" version="1">
<description summary="a shortcut">
This object represents a single shortcut.
</description>
<event name="pressed">
<description summary="keystroke pressed">
The keystroke was pressed.
tv_ values hold the timestamp of the occurrence.
</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="released">
<description summary="keystroke released">
The keystroke was released.
tv_ values hold the timestamp of the occurrence.
</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>
<request name="destroy" type="destructor">
<description summary="delete this object, used or not">
Destroys the shortcut. Can be sent at any time by the client.
</description>
</request>
</interface>
</protocol>

99
proto/hyprland-lock-notify-v1.xml Normal file
View file

@ -0,0 +1,99 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="hyprland_lock_notify_v1">
<copyright>
Copyright © 2025 Maximilian Seidler
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</copyright>
<interface name="hyprland_lock_notifier_v1" version="1">
<description summary="lock notification manager">
This interface allows clients to monitor whether the wayland session is
locked or unlocked.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the manager">
Destroy the manager object. All objects created via this interface
remain valid.
</description>
</request>
<request name="get_lock_notification">
<description summary="create a notification object">
Create a new lock notification object.
If the session is already locked when calling this method,
the locked event shall be sent immediately.
</description>
<arg name="id" type="new_id" interface="hyprland_lock_notification_v1"/>
</request>
</interface>
<interface name="hyprland_lock_notification_v1" version="1">
<description summary="lock notification">
This interface is used by the compositor to send lock notification events
to clients.
Typically the "locked" and "unlocked" events are emitted when a client
locks/unlocks the session via ext-session-lock, but the compositor may
choose to send notifications for any other locking mechanisms.
The compositor must notfiy after possible transition periods
between locked and unlocked states of the session.
In the context of ext-session-lock, that means the "locked" event is
expected to be sent after the session-lock client has presented
a lock screen frame on every output, which corresponds to the "locked"
event of ext-session-lock.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the notification object">
Destroy the notification object.
</description>
</request>
<event name="locked">
<description summary="session is locked">
This event is sent when the wayland session is locked.
It's a compositor protocol error to send this event twice without an
unlock event in-between.
</description>
</event>
<event name="unlocked">
<description summary="session is no longer locked">
This event is sent when the wayland session is unlocked.
It's a compositor protocol error to send this event twice without an
locked event in-between. It's a compositor protocol error to send this
event prior to any locked event.
</description>
</event>
</interface>
</protocol>

126
proto/hyprland-surface-v1.xml Normal file
View file

@ -0,0 +1,126 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="hyprland_surface_v1">
<copyright>
Copyright © 2025 outfoxxed
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</copyright>
<description summary="hyprland-specific wl_surface extensions">
This protocol exposes hyprland-specific wl_surface properties.
</description>
<interface name="hyprland_surface_manager_v1" version="2">
<description summary="manager for hyprland surface objects">
This interface allows a client to create hyprland surface objects.
</description>
<request name="get_hyprland_surface">
<description summary="create a hyprland surface object">
Create a hyprland surface object for the given wayland surface.
If the wl_surface already has an associated hyprland_surface_v1 object,
even from a different manager, creation is a protocol error.
</description>
<arg name="id" type="new_id" interface="hyprland_surface_v1"/>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the hyprland surface manager">
Destroy the surface manager.
This does not destroy existing surface objects.
</description>
</request>
<enum name="error">
<entry name="already_constructed" value="0" summary="wl_surface already has a hyprland surface object"/>
</enum>
</interface>
<interface name="hyprland_surface_v1" version="2">
<description summary="hyprland-specific wl_surface properties">
This interface allows access to hyprland-specific properties of a wl_surface.
Once the wl_surface has been destroyed, the hyprland surface object must be
destroyed as well. All other operations are a protocol error.
</description>
<request name="set_opacity">
<description summary="set the overall opacity of the surface">
Sets a multiplier for the overall opacity of the surface.
This multiplier applies to visual effects such as blur behind the surface
in addition to the surface's content.
The default value is 1.0.
Setting a value outside of the range 0.0 - 1.0 (inclusive) is a protocol error.
Does not take effect until wl_surface.commit is called.
</description>
<arg name="opacity" type="fixed"/>
</request>
<request name="destroy" type="destructor">
<description summary="destroy the hyprland surface interface">
Destroy the hyprland surface object, resetting properties provided
by this interface to their default values on the next wl_surface.commit.
</description>
</request>
<enum name="error">
<entry name="no_surface" value="0" summary="wl_surface was destroyed"/>
<entry name="out_of_range" value="1" summary="given opacity was not in the range 0.0 - 1.0 (inclusive)"/>
</enum>
<request name="set_visible_region" since="2">
<description summary="set the visible region of the surface">
This request sets the region of the surface that contains visible content.
Visible content refers to content that has an alpha value greater than zero.
The visible region is an optimization hint for the compositor that lets it
avoid drawing parts of the surface that are not visible. Setting a visible region
that does not contain all content in the surface may result in missing content
not being drawn.
The visible region is specified in buffer-local coordinates.
The compositor ignores the parts of the visible region that fall outside of the surface.
When all parts of the region fall outside of the buffer geometry, the compositor may
avoid rendering the surface entirely.
The initial value for the visible region is empty. Setting the
visible region has copy semantics, and the wl_region object can be destroyed immediately.
A NULL wl_region causes the visible region to be set to empty.
Does not take effect until wl_surface.commit is called.
</description>
<arg name="region" type="object" interface="wl_region" allow-null="true"/>
</request>
</interface>
</protocol>

228
proto/hyprland-toplevel-export-v1.xml Normal file
View file

@ -0,0 +1,228 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="hyprland_toplevel_export_v1">
<copyright>
Copyright © 2022 Vaxry
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</copyright>
<description summary="capturing the contents of toplevel windows">
This protocol allows clients to ask for exporting another toplevel's
surface(s) to a buffer.
Particularly useful for sharing a single window.
</description>
<interface name="hyprland_toplevel_export_manager_v1" version="2">
<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_toplevel">
<description summary="capture a toplevel">
Capture the next frame of a toplevel. (window)
The captured frame will not contain any server-side decorations and will
ignore the compositor-set geometry, like e.g. rounded corners.
It will contain all the subsurfaces and popups, however the latter will be clipped
to the geometry of the base surface.
The handle parameter refers to the address of the window as seen in `hyprctl clients`.
For example, for d161e7b0 it would be 3512854448.
</description>
<arg name="frame" type="new_id" interface="hyprland_toplevel_export_frame_v1"/>
<arg name="overlay_cursor" type="int"
summary="composite cursor onto the frame"/>
<arg name="handle" type="uint" summary="the handle of the toplevel (window) to be captured"/>
</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>
<!-- Version 2 -->
<request name="capture_toplevel_with_wlr_toplevel_handle" since="2">
<description summary="capture a toplevel">
Same as capture_toplevel, but with a zwlr_foreign_toplevel_handle_v1 handle.
</description>
<arg name="frame" type="new_id" interface="hyprland_toplevel_export_frame_v1"/>
<arg name="overlay_cursor" type="int"
summary="composite cursor onto the frame"/>
<arg name="handle" type="object" interface="zwlr_foreign_toplevel_handle_v1" allow-null="false" summary="the zwlr_foreign_toplevel_handle_v1 handle of the toplevel to be captured"/>
</request>
<!-- End Version 2 -->
</interface>
<interface name="hyprland_toplevel_export_frame_v1" version="2">
<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.
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 the
correct size, see hyprland_toplevel_export_frame_v1.buffer and
hyprland_toplevel_export_frame_v1.linux_dmabuf. The buffer needs to have a
supported format.
If the frame is successfully copied, a "flags" and a "ready" event is
sent. Otherwise, a "failed" event is sent.
This event will wait for appropriate damage to be copied, unless the ignore_damage
arg is set to a non-zero value.
</description>
<arg name="buffer" type="object" interface="wl_buffer"/>
<arg name="ignore_damage" type="int"/>
</request>
<event name="damage">
<description summary="carries the coordinates of the damaged region">
This event is sent right before the ready event when ignore_damage was
not set. It may be generated multiple times for each copy
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
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>
<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>
<event name="linux_dmabuf">
<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">
<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>

83
proto/idle-inhibit-unstable-v1.xml 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>

38
proto/idle.xml Normal file
View file

@ -0,0 +1,38 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="idle">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2015 Martin Gräßlin
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="org_kde_kwin_idle" version="1">
<description summary="User idle time manager">
This interface allows to monitor user idle time on a given seat. The interface
allows to register timers which trigger after no user activity was registered
on the seat for a given interval. It notifies when user activity resumes.
This is useful for applications wanting to perform actions when the user is not
interacting with the system, e.g. chat applications setting the user as away, power
management features to dim screen, etc..
</description>
<request name="get_idle_timeout">
<arg name="id" type="new_id" interface="org_kde_kwin_idle_timeout"/>
<arg name="seat" type="object" interface="wl_seat"/>
<arg name="timeout" type="uint" summary="The idle timeout in msec"/>
</request>
</interface>
<interface name="org_kde_kwin_idle_timeout" version="1">
<request name="release" type="destructor">
<description summary="release the timeout object"/>
</request>
<request name="simulate_user_activity">
<description summary="Simulates user activity for this timeout, behaves just like real user activity on the seat"/>
</request>
<event name="idle">
<description summary="Triggered when there has not been any user activity in the requested idle time interval"/>
</event>
<event name="resumed">
<description summary="Triggered on the first user activity after an idle event"/>
</event>
</interface>
</protocol>

305
proto/input-method-unstable-v1.xml 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>

494
proto/input-method-unstable-v2.xml Normal file
View file

@ -0,0 +1,494 @@
<?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>
<enum name="error">
<entry name="role" value="0" summary="wl_surface has another role"/>
</enum>
<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
usable, 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>

145
proto/input-timestamps-unstable-v1.xml 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>

100
proto/ivi-application.xml Normal file
View file

@ -0,0 +1,100 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ivi_application">
<copyright>
Copyright (C) 2013 DENSO CORPORATION
Copyright (c) 2013 BMW Car IT GmbH
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="ivi_surface" version="1">
<description summary="application interface to surface in ivi compositor"/>
<request name="destroy" type="destructor">
<description summary="destroy ivi_surface">
This removes the link from ivi_id to wl_surface and destroys ivi_surface.
The ID, ivi_id, is free and can be used for surface_create again.
</description>
</request>
<event name="configure">
<description summary="suggest resize">
The configure event asks the client to resize its surface.
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).
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.
</description>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
</event>
</interface>
<interface name="ivi_application" version="1">
<description summary="create ivi-style surfaces">
This interface is exposed as a global singleton.
This interface is implemented by servers that provide IVI-style user interfaces.
It allows clients to associate an ivi_surface with wl_surface.
</description>
<enum name="error">
<entry name="role" value="0" summary="given wl_surface has another role"/>
<entry name="ivi_id" value="1" summary="given ivi_id is assigned to another wl_surface"/>
</enum>
<request name="surface_create">
<description summary="create ivi_surface with numeric ID in ivi compositor">
This request gives the wl_surface the role of an IVI Surface. Creating more than
one ivi_surface for a wl_surface is not allowed. Note, that this still allows the
following example:
1. create a wl_surface
2. create ivi_surface for the wl_surface
3. destroy the ivi_surface
4. create ivi_surface for the wl_surface (with the same or another ivi_id as before)
surface_create will create an interface:ivi_surface with numeric ID; ivi_id in
ivi compositor. These ivi_ids are defined as unique in the system to identify
it inside of ivi compositor. The ivi compositor implements business logic how to
set properties of the surface with ivi_id according to the status of the system.
E.g. a unique ID for Car Navigation application is used for implementing special
logic of the application about where it shall be located.
The server regards the following cases as protocol errors and disconnects the client.
- wl_surface already has another role.
- ivi_id is already assigned to another wl_surface.
If client destroys ivi_surface or wl_surface which is assigned to the ivi_surface,
ivi_id which is assigned to the ivi_surface is free for reuse.
</description>
<arg name="ivi_id" type="uint"/>
<arg name="surface" type="object" interface="wl_surface"/>
<arg name="id" type="new_id" interface="ivi_surface"/>
</request>
</interface>
</protocol>

98
proto/ivi-hmi-controller.xml Normal file
View file

@ -0,0 +1,98 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ivi_hmi_controller">
<copyright>
Copyright (C) 2013 DENSO CORPORATION
Copyright (c) 2013 BMW Car IT GmbH
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="ivi_hmi_controller" version="1">
<description summary="set up and control IVI style UI"/>
<request name="UI_ready">
<description summary="inform the ready for drawing desktop." />
</request>
<request name="workspace_control">
<description summary="start controlling a surface by server">
Reference protocol to control a surface by server.
To control a surface by server, it gives seat to the server
to e.g. control Home screen. Home screen has several workspaces
to group launchers of wayland application. These workspaces
are drawn on a horizontally long surface to be controlled
by motion of input device. E.g. A motion from right to left
happens, the viewport of surface is controlled in the ivi-shell
by using ivi-layout. client can recognizes the end of controlling
by event "workspace_end_control".
</description>
<arg name="seat" type="object" interface="wl_seat"/>
<arg name="serial" type="uint"/>
</request>
<enum name="layout_mode">
<entry name="tiling" value="0"/>
<entry name="side_by_side" value="1"/>
<entry name="full_screen" value="2"/>
<entry name="random" value="3" />
</enum>
<request name="switch_mode">
<description summary="request mode switch of application layout">
hmi-controller loaded to ivi-shall implements 4 types of layout
as a reference; tiling, side by side, full_screen, and random.
</description>
<arg name="layout_mode" type="uint"/>
</request>
<enum name="home">
<entry name="off" value="0"/>
<entry name="on" value="1"/>
</enum>
<request name="home">
<description summary="request displaying/undisplaying home screen">
home screen is a reference implementation of launcher to launch
wayland applications. The home screen has several workspaces to
group wayland applications. By defining the following keys in
weston.ini, user can add launcher icon to launch a wayland application
to a workspace.
[ivi-launcher]
workspace-id=0
: id of workspace to add a launcher
icon-id=4001
: ivi id of ivi_surface to draw an icon
icon=/home/user/review/build-ivi-shell/data/icon_ivi_flower.png
: path to icon image
path=/home/user/review/build-ivi-shell/weston-dnd
: path to wayland application
</description>
<arg name="home" type="uint"/>
</request>
<event name="workspace_end_control">
<description summary="notify controlling workspace end"/>
<arg name="is_controlled" type="int"/>
</event>
</interface>
</protocol>

78
proto/kde-external-brightness-v1.xml Normal file
View file

@ -0,0 +1,78 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="kde_external_brightness_v1">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2024 Xaver Hugl <xaver.hugl@gmail.com>
SPDX-License-Identifier: MIT-CMU
]]></copyright>
<interface name="kde_external_brightness_v1" version="2">
<description summary="external brightness control">
Some brightness control mechanisms are somewhat unstable, or require root
privileges, so putting them inside of the compositor is not desired.
This protocol is for outsourcing the actual brightness-setting to a
process outside of the compositor.
</description>
<request name="destroy" type="destructor">
<description summary="Destroy the object."/>
</request>
<request name="create_brightness_control">
<description summary="registers a brightness device with the compositor"/>
<arg name="id" type="new_id" interface="kde_external_brightness_device_v1"/>
</request>
</interface>
<interface name="kde_external_brightness_device_v1" version="2">
<description summary="brightness control device">
After creating this object, the client should issue all relevant setup requests
(set_internal, set_edid, set_max_brightness, optionally set_observed_brightness)
and finish the sequence with commit.
Afterwards, for each change in values, the client must call commit again.
</description>
<request name="destroy" type="destructor">
<description summary="destroy the object and unregister the brightness control device"/>
</request>
<request name="set_internal">
<description summary="sets whether or not the brightness device belongs to an internal display"/>
<arg name="internal" type="uint" summary="1 if it's an internal panel, 0 if not"/>
</request>
<request name="set_edid">
<description summary="set the EDID data for identification of the display"/>
<arg name="string" type="string" summary="base-64 encoded string of the first 128 bytes of the EDID"/>
</request>
<request name="set_max_brightness">
<description summary="notifies the compositor of the maximum brightness that can be set on this device"/>
<arg name="value" type="uint" summary="the maximum value that can be set"/>
</request>
<request name="commit">
<description summary="notifies the compositor that all relevant identifiers and values have been sent"/>
</request>
<event name="requested_brightness">
<description summary="requests the client to change the brightness to this value">
The client must ensure that if the brightness level changes due to external factors,
that it either overwrites those changes with what the compositor last requested,
or commit again with set_observed_brightness specifying the changed brightness.
</description>
<arg name="value" type="uint" summary="the value to set the device to"/>
</event>
<request name="set_observed_brightness" since="2">
<description summary="notifies the compositor of the brightness that was read from this device">
The client can set this to notify the compositor of the device's initial brightness.
It can also set this again after the initial commit to notify the compositor that
the brightness level has changed due to external factors.
The compositor is free to use or ignore this value as it sees fit.
</description>
<arg name="value" type="uint" summary="the observed value that was read"/>
</request>
</interface>
</protocol>

38
proto/kde-lockscreen-overlay-v1.xml Normal file
View file

@ -0,0 +1,38 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="kde_lockscreen_overlay_v1">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2022 Aleix Pol Gonzalez <aleixpol@kde.org>
SPDX-License-Identifier: LGPL-2.1-or-later
]]></copyright>
<interface name="kde_lockscreen_overlay_v1" version="1">
<description summary="Allow surfaces over the lockscreen">
Allows a client to request a surface to be visible when the system is locked.
This is meant to be used for specific high urgency cases like phone calls or alarms.
Warning! The protocol described in this file is a desktop environment
implementation detail. Regular clients must not use this protocol.
Backward incompatible changes may be added without bumping the major
version of the extension.
</description>
<enum name="error">
<entry name="invalid_surface_state" value="0" summary="the client provided an invalid surface state"/>
</enum>
<request name="allow">
<description summary="Tell about which surface could be raised above the lockscreen">
Informs the compositor that the surface could be shown when the screen is locked. This request should be called while the surface is unmapped.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
</request>
<request name="destroy" type="destructor">
<description summary="Destroy the kde_lockscreen_overlay_v1">
This won't affect the surface previously marked with the allow request.
</description>
</request>
</interface>
</protocol>

453
proto/kde-output-device-v2.xml Normal file
View file

@ -0,0 +1,453 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="kde_output_device_v2">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2008-2011 Kristian Høgsberg
SPDX-FileCopyrightText: 2010-2011 Intel Corporation
SPDX-FileCopyrightText: 2012-2013 Collabora, Ltd.
SPDX-FileCopyrightText: 2015 Sebastian Kügler <sebas@kde.org>
SPDX-FileCopyrightText: 2021 Méven Car <meven.car@enioka.com>
SPDX-License-Identifier: MIT-CMU
]]></copyright>
<interface name="kde_output_device_v2" version="11">
<description summary="output configuration representation">
An output device describes a display device available to the compositor.
output_device is similar to wl_output, but focuses on output
configuration management.
A client can query all global output_device objects to enlist all
available display devices, even those that may currently not be
represented by the compositor as a wl_output.
The client sends configuration changes to the server through the
outputconfiguration interface, and the server applies the configuration
changes to the hardware and signals changes to the output devices
accordingly.
This object is published as global during start up for every available
display devices, or when one later becomes available, for example by
being hotplugged via a physical connector.
Warning! The protocol described in this file is a desktop environment
implementation detail. Regular clients must not use this protocol.
Backward incompatible changes may be added without bumping the major
version of the extension.
</description>
<enum name="subpixel">
<description summary="subpixel geometry information">
This enumeration describes how the physical pixels on an output are
laid out.
</description>
<entry name="unknown" value="0"/>
<entry name="none" value="1"/>
<entry name="horizontal_rgb" value="2"/>
<entry name="horizontal_bgr" value="3"/>
<entry name="vertical_rgb" value="4"/>
<entry name="vertical_bgr" value="5"/>
</enum>
<enum name="transform">
<description summary="transform from framebuffer to output">
This describes the transform, that a compositor will apply to a
surface to compensate for the rotation or mirroring of an
output device.
The flipped values correspond to an initial flip around a
vertical axis followed by rotation.
The purpose is mainly to allow clients to render accordingly and
tell the compositor, so that for fullscreen surfaces, the
compositor is still able to scan out directly client surfaces.
</description>
<entry name="normal" value="0"/>
<entry name="90" value="1"/>
<entry name="180" value="2"/>
<entry name="270" value="3"/>
<entry name="flipped" value="4"/>
<entry name="flipped_90" value="5"/>
<entry name="flipped_180" value="6"/>
<entry name="flipped_270" value="7"/>
</enum>
<event name="geometry">
<description summary="geometric properties of the output">
The geometry event describes geometric properties of the output.
The event is sent when binding to the output object and whenever
any of the properties change.
</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"/>
<arg name="physical_width" type="int"
summary="width in millimeters of the output"/>
<arg name="physical_height" type="int"
summary="height in millimeters of the output"/>
<arg name="subpixel" type="int"
summary="subpixel orientation of the output"/>
<arg name="make" type="string"
summary="textual description of the manufacturer"/>
<arg name="model" type="string"
summary="textual description of the model"/>
<arg name="transform" type="int"
summary="transform that maps framebuffer to output"/>
</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="kde_output_device_mode_v2"/>
</event>
<event name="mode">
<description summary="advertise available output modes and current one">
The mode event describes an available mode for the output.
When the client binds to the output_device object, the server sends this
event once for every available mode the output_device can be operated by.
There will always be at least one event sent out on initial binding,
which represents the current mode.
Later if an output changes, its mode event is sent again for the
eventual added modes and lastly the current mode. In other words, the
current mode is always represented by the latest event sent with the current
flag set.
The size of a mode 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, as described in
kde_output_device_v2.scale, or transformed, as described in
kde_output_device_v2.transform.
</description>
<arg name="mode" type="new_id" interface="kde_output_device_mode_v2"/>
</event>
<event name="done">
<description summary="sent all information about output">
This event is sent after all other properties have been
sent on binding to the output object as well as after any
other output property change have been applied later on.
This allows to see changes to the output properties as atomic,
even if multiple events successively announce them.
</description>
</event>
<event name="scale">
<description summary="output scaling properties">
This event contains scaling geometry information
that is not in the geometry event. It may be sent after
binding the output object or if the output scale changes
later. If it is not sent, the client should assume a
scale of 1.
A scale larger than 1 means that the compositor will
automatically scale surface buffers by this amount
when rendering. This is used for high resolution
displays where applications rendering at the native
resolution would be too small to be legible.
It is intended that scaling aware clients track the
current output of a surface, and if it is on a scaled
output it should use wl_surface.set_buffer_scale with
the scale of the output. That way the compositor can
avoid scaling the surface, and the client can supply
a higher detail image.
</description>
<arg name="factor" type="fixed" summary="scaling factor of output"/>
</event>
<event name="edid">
<description summary="advertise EDID data for the output">
The edid event encapsulates the EDID data for the outputdevice.
The event is sent when binding to the output object. The EDID
data may be empty, in which case this event is sent anyway.
If the EDID information is empty, you can fall back to the name
et al. properties of the outputdevice.
</description>
<arg name="raw" type="string" summary="base64-encoded EDID string"/>
</event>
<event name="enabled">
<description summary="output is enabled or disabled">
The enabled event notifies whether this output is currently
enabled and used for displaying content by the server.
The event is sent when binding to the output object and
whenever later on an output changes its state by becoming
enabled or disabled.
</description>
<arg name="enabled" type="int" summary="output enabled state"/>
</event>
<event name="uuid">
<description summary="A unique id for this outputdevice">
The uuid can be used to identify the output. It's controlled by
the server entirely. The server should make sure the uuid is
persistent across restarts. An empty uuid is considered invalid.
</description>
<arg name="uuid" type="string" summary="output devices ID"/>
</event>
<event name="serial_number">
<description summary="Serial Number">
Serial ID of the monitor, sent on startup before the first done event.
</description>
<arg name="serialNumber" type="string"
summary="textual representation of serial number"/>
</event>
<event name="eisa_id">
<description summary="EISA ID">
EISA ID of the monitor, sent on startup before the first done event.
</description>
<arg name="eisaId" type="string"
summary="textual representation of EISA identifier"/>
</event>
<enum name="capability" bitfield="true">
<description summary="describes capabilities of the outputdevice">
Describes what capabilities this device has.
</description>
<entry name="overscan" value="0x1"
summary="if this output_device can use overscan"/>
<entry name="vrr" value="0x2"
summary="if this outputdevice supports variable refresh rate"/>
<entry name="rgb_range" value="0x4"
summary="if setting the rgb range is possible"/>
<entry name="high_dynamic_range" value="0x8" since="3"
summary="if this outputdevice supports high dynamic range"/>
<entry name="wide_color_gamut" value="0x10" since="3"
summary="if this outputdevice supports a wide color gamut"/>
<entry name="auto_rotate" value="0x20" since="4"
summary="if this outputdevice supports autorotation"/>
<entry name="icc_profile" value="0x40" since="5"
summary="if this outputdevice supports icc profiles"/>
<entry name="brightness" value="0x80" since="9"
summary="if this outputdevice supports the brightness setting"/>
</enum>
<event name="capabilities">
<description summary="capability flags">
What capabilities this device has, sent on startup before the first
done event.
</description>
<arg name="flags" type="uint" enum="capability"/>
</event>
<event name="overscan">
<description summary="overscan">
Overscan value of the monitor in percent, sent on startup before the
first done event.
</description>
<arg name="overscan" type="uint"
summary="amount of overscan of the monitor"/>
</event>
<enum name="vrr_policy">
<description summary="describes vrr policy">
Describes when the compositor may employ variable refresh rate
</description>
<entry name="never" value="0"/>
<entry name="always" value="1"/>
<entry name="automatic" value="2"/>
</enum>
<event name="vrr_policy">
<description summary="Variable Refresh Rate Policy">
What policy the compositor will employ regarding its use of variable
refresh rate.
</description>
<arg name="vrr_policy" type="uint" enum="vrr_policy"/>
</event>
<enum name="rgb_range">
<description summary="describes RGB range policy">
Whether full or limited color range should be used
</description>
<entry name="automatic" value="0"/>
<entry name="full" value="1"/>
<entry name="limited" value="2"/>
</enum>
<event name="rgb_range">
<description summary="RGB range">
What rgb range the compositor is using for this output
</description>
<arg name="rgb_range" type="uint" enum="rgb_range"/>
</event>
<event name="name" since="2">
<description summary="Output's name">
Name of the output, it's useful to cross-reference to an zxdg_output_v1 and ultimately QScreen
</description>
<arg name="name" type="string"/>
</event>
<event name="high_dynamic_range" since="3">
<description summary="if HDR is enabled">
Whether or not high dynamic range is enabled for this output
</description>
<arg name="hdr_enabled" type="uint" summary="1 if enabled, 0 if disabled"/>
</event>
<event name="sdr_brightness" since="3">
<description summary="the brightness of sdr if hdr is enabled">
If high dynamic range is used, this value defines the brightness in nits for content
that's in standard dynamic range format. Note that while the value is in nits, that
doesn't necessarily translate to the same brightness on the screen.
</description>
<arg name="sdr_brightness" type="uint"/>
</event>
<event name="wide_color_gamut" since="3">
<description summary="if WCG is enabled">
Whether or not the use of a wide color gamut is enabled for this output
</description>
<arg name="wcg_enabled" type="uint" summary="1 if enabled, 0 if disabled"/>
</event>
<enum name="auto_rotate_policy">
<description summary="describes when auto rotate should be used"/>
<entry name="never" value="0"/>
<entry name="in_tablet_mode" value="1"/>
<entry name="always" value="2"/>
</enum>
<event name="auto_rotate_policy" since="4">
<description summary="describes when auto rotate is used"/>
<arg name="policy" type="uint" enum="auto_rotate_policy"/>
</event>
<event name="icc_profile_path" since="5">
<description summary="describes when auto rotate is used"/>
<arg name="profile_path" type="string"/>
</event>
<event name="brightness_metadata" since="6">
<description summary="metadata about the screen's brightness limits"/>
<arg name="max_peak_brightness" type="uint" summary="in nits"/>
<arg name="max_frame_average_brightness" type="uint" summary="in nits"/>
<arg name="min_brightness" type="uint" summary="in 0.0001 nits"/>
</event>
<event name="brightness_overrides" since="6">
<description summary="overrides for the screen's brightness limits"/>
<arg name="max_peak_brightness" type="int" summary="-1 for no override, positive values are the brightness in nits"/>
<arg name="max_average_brightness" type="int" summary="-1 for no override, positive values are the brightness in nits"/>
<arg name="min_brightness" type="int" summary="-1 for no override, positive values are the brightness in 0.0001 nits"/>
</event>
<event name="sdr_gamut_wideness" since="6">
<description summary="describes which gamut is assumed for sRGB applications">
This can be used to provide the colors users assume sRGB applications should have based on the
default experience on many modern sRGB screens.
</description>
<arg name="gamut_wideness" type="uint" summary="0 means rec.709 primaries, 10000 means native primaries"/>
</event>
<enum name="color_profile_source" since="7">
<description summary="which source the compositor should use for the color profile on an output"/>
<entry name="sRGB" value="0"/>
<entry name="ICC" value="1"/>
<entry name="EDID" value="2"/>
</enum>
<event name="color_profile_source" since="7">
<description summary="describes which source the compositor uses for the color profile on an output"/>
<arg name="source" type="uint" enum="color_profile_source"/>
</event>
<event name="brightness" since="8">
<description summary="brightness multiplier">
This is the brightness modifier of the output. It doesn't specify
any absolute values, but is merely a multiplier on top of other
brightness values, like sdr_brightness and brightness_metadata.
0 is the minimum brightness (not completely dark) and 10000 is
the maximum brightness.
This is currently only supported / meaningful while HDR is active.
</description>
<arg name="brightness" type="uint" summary="brightness in 0-10000"/>
</event>
<enum name="color_power_tradeoff">
<description summary="tradeoff between power and accuracy">
The compositor can do a lot of things that trade between
performance, power and color accuracy. This setting describes
a high level preference from the user about in which direction
that tradeoff should be made.
</description>
<entry name="efficiency" value="0" summary="prefer efficiency and performance"/>
<entry name="accuracy" value="1" summary="prefer accuracy"/>
</enum>
<event name="color_power_tradeoff" since="10">
<description summary="the preferred color/power tradeoff"/>
<arg name="preference" type="uint" enum="color_power_tradeoff"/>
</event>
<event name="dimming" since="11">
<description summary="dimming multiplier">
This is the dimming multiplier of the output. This is similar to
the brightness setting, except it's meant to be a temporary setting
only, not persistent and may be implemented differently depending
on the display.
0 is the minimum dimming factor (not completely dark) and 10000
means the output is not dimmed.
</description>
<arg name="multiplier" type="uint" summary="multiplier in 0-10000"/>
</event>
</interface>
<interface name="kde_output_device_mode_v2" version="1">
<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
kde_output_device.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="removed">
<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>
</protocol>

355
proto/kde-output-management-v2.xml Normal file
View file

@ -0,0 +1,355 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="kde_output_management_v2">
<copyright><![CDATA[
SPDX-FileCopyrightText: 2008-2011 Kristian Høgsberg
SPDX-FileCopyrightText: 2010-2011 Intel Corporation
SPDX-FileCopyrightText: 2012-2013 Collabora, Ltd.
SPDX-FileCopyrightText: 2015 Sebastian Kügler <sebas@kde.org>
SPDX-FileCopyrightText: 2021 Méven Car <meven.car@enioka.com>
SPDX-FileCopyrightText: 2023 Xaver Hugl <xaver.hugl@kde.org>
SPDX-License-Identifier: MIT-CMU
]]></copyright>
<interface name="kde_output_management_v2" version="12">
<description summary="configuration of server outputs through clients">
This interface enables clients to set properties of output devices for screen
configuration purposes via the server. To this end output devices are referenced
by global kde_output_device_v2 objects.
outputmanagement (wl_global)
--------------------------
request:
* create_configuration -> outputconfiguration (wl_resource)
outputconfiguration (wl_resource)
--------------------------
requests:
* enable(outputdevice, bool)
* mode(outputdevice, mode)
* transformation(outputdevice, flag)
* position(outputdevice, x, y)
* apply
events:
* applied
* failed
The server registers one outputmanagement object as a global object. In order
to configure outputs a client requests create_configuration, which provides a
resource referencing an outputconfiguration for one-time configuration. That
way the server knows which requests belong together and can group them by that.
On the outputconfiguration object the client calls for each output whether the
output should be enabled, which mode should be set (by referencing the mode from
the list of announced modes) and the output's global position. Once all outputs
are configured that way, the client calls apply.
At that point and not earlier the server should try to apply the configuration.
If this succeeds the server emits the applied signal, otherwise the failed
signal, such that the configuring client is noticed about the success of its
configuration request.
Through this design the interface enables atomic output configuration changes if
internally supported by the server.
Warning! The protocol described in this file is a desktop environment implementation
detail. Regular clients must not use this protocol. Backward incompatible
changes may be added without bumping the major version of the extension.
</description>
<request name="create_configuration">
<description summary="provide outputconfiguration object for configuring outputs">
Request an outputconfiguration object through which the client can configure
output devices.
</description>
<arg name="id" type="new_id" interface="kde_output_configuration_v2"/>
</request>
</interface>
<interface name="kde_output_configuration_v2" version="12">
<description summary="configure single output devices">
outputconfiguration is a client-specific resource that can be used to ask
the server to apply changes to available output devices.
The client receives a list of output devices from the registry. When it wants
to apply new settings, it creates a configuration object from the
outputmanagement global, writes changes through this object's enable, scale,
transform and mode calls. It then asks the server to apply these settings in
an atomic fashion, for example through Linux' DRM interface.
The server signals back whether the new settings have applied successfully
or failed to apply. outputdevice objects are updated after the changes have been
applied to the hardware and before the server side sends the applied event.
</description>
<enum name="error">
<description summary="kde_output_configuration_v2 error values">
These error can be emitted in response to kde_output_configuration_v2 requests.
</description>
<entry name="already_applied" value="0" summary="the config is already applied"/>
</enum>
<request name="enable">
<description summary="enable or disable an output">
Mark the output as enabled or disabled.
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice to be en- or disabled"/>
<arg name="enable" type="int" summary="1 to enable or 0 to disable this output"/>
</request>
<request name="mode">
<description summary="switch output-device to mode">
Sets the mode for a given output.
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice this mode change applies to"/>
<arg name="mode" type="object" interface="kde_output_device_mode_v2" summary="the mode to apply"/>
</request>
<request name="transform">
<description summary="transform output-device">
Sets the transformation for a given output.
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice this transformation change applies to"/>
<arg name="transform" type="int" summary="transform enum"/>
</request>
<request name="position">
<description summary="position output in global space">
Sets the position for this output device. (x,y) describe the top-left corner
of the output in global space, whereby the origin (0,0) of the global space
has to be aligned with the top-left corner of the most left and in case this
does not define a single one the top output.
There may be no gaps or overlaps between outputs, i.e. the outputs are
stacked horizontally, vertically, or both on each other.
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice this position applies to"/>
<arg name="x" type="int" summary="position on the x-axis"/>
<arg name="y" type="int" summary="position on the y-axis"/>
</request>
<request name="scale">
<description summary="set scaling factor of this output">
Sets the scaling factor for this output device.
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice this scale change applies to"/>
<arg name="scale" type="fixed" summary="scaling factor"/>
</request>
<request name="apply">
<description summary="apply configuration changes to all output devices">
Asks the server to apply property changes requested through this outputconfiguration
object to all outputs on the server side.
The output configuration can be applied only once. The already_applied protocol error
will be posted if the apply request is called the second time.
</description>
</request>
<event name="applied">
<description summary="configuration changes have been applied">
Sent after the server has successfully applied the changes.
.
</description>
</event>
<event name="failed">
<description summary="configuration changes failed to apply">
Sent if the server rejects the changes or failed to apply them.
</description>
</event>
<request name="destroy" type="destructor">
<description summary="release the outputconfiguration object"/>
</request>
<request name="overscan">
<description summary="set overscan value">
Set the overscan value of this output device with a value in percent.
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice overscan applies to"/>
<arg name="overscan" type="uint" summary="overscan value"/>
</request>
<enum name="vrr_policy">
<description summary="describes vrr policy">
Describes when the compositor may employ variable refresh rate
</description>
<entry name="never" value="0"/>
<entry name="always" value="1"/>
<entry name="automatic" value="2"/>
</enum>
<request name="set_vrr_policy">
<description summary="set the VRR policy">
Set what policy the compositor should employ regarding its use of
variable refresh rate.
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice this VRR policy applies to"/>
<arg name="policy" type="uint" enum="vrr_policy" summary="the vrr policy to apply"/>
</request>
<enum name="rgb_range">
<description summary="describes RGB range policy">
Whether this output should use full or limited rgb.
</description>
<entry name="automatic" value="0"/>
<entry name="full" value="1"/>
<entry name="limited" value="2"/>
</enum>
<request name="set_rgb_range">
<description summary="RGB range">
Whether full or limited color range should be used
</description>
<arg name="outputdevice" type="object" interface="kde_output_device_v2" summary="outputdevice the rgb range applies to"/>
<arg name="rgb_range" type="uint" enum="rgb_range"/>
</request>
<request name="set_primary_output" since="2">
<description summary="Select which primary output to use" />
<arg name="output" type="object" interface="kde_output_device_v2" allow-null="false"/>
</request>
<request name="set_priority" since="3">