mirror of
https://github.com/hyprwm/xdg-desktop-portal-hyprland.git
synced 2024-11-22 22:35:59 +01:00
protocols: Use protocols from the wayland-protocols dependency
We can generate protocol code for wayland-protocols directly from the dependency instead of shipping our own copy.
This commit is contained in:
columbarius
parent
14852efb05
commit
4516d8b79e
3 changed files with 4 additions and 584 deletions
|
|
@ -1,362 +0,0 @@
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
|
||||||
<protocol name="linux_dmabuf_unstable_v1">
|
|
||||||
|
|
||||||
<copyright>
|
|
||||||
Copyright © 2014, 2015 Collabora, Ltd.
|
|
||||||
|
|
||||||
Permission is hereby granted, free of charge, to any person obtaining a
|
|
||||||
copy of this software and associated documentation files (the "Software"),
|
|
||||||
to deal in the Software without restriction, including without limitation
|
|
||||||
the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
||||||
and/or sell copies of the Software, and to permit persons to whom the
|
|
||||||
Software is furnished to do so, subject to the following conditions:
|
|
||||||
|
|
||||||
The above copyright notice and this permission notice (including the next
|
|
||||||
paragraph) shall be included in all copies or substantial portions of the
|
|
||||||
Software.
|
|
||||||
|
|
||||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
||||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
||||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
||||||
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
||||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
||||||
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
||||||
DEALINGS IN THE SOFTWARE.
|
|
||||||
</copyright>
|
|
||||||
|
|
||||||
<interface name="zwp_linux_dmabuf_v1" version="3">
|
|
||||||
<description summary="factory for creating dmabuf-based wl_buffers">
|
|
||||||
Following the interfaces from:
|
|
||||||
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
|
|
||||||
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
|
|
||||||
and the Linux DRM sub-system's AddFb2 ioctl.
|
|
||||||
|
|
||||||
This interface offers ways to create generic dmabuf-based
|
|
||||||
wl_buffers. Immediately after a client binds to this interface,
|
|
||||||
the set of supported formats and format modifiers is sent with
|
|
||||||
'format' and 'modifier' events.
|
|
||||||
|
|
||||||
The following are required from clients:
|
|
||||||
|
|
||||||
- Clients must ensure that either all data in the dma-buf is
|
|
||||||
coherent for all subsequent read access or that coherency is
|
|
||||||
correctly handled by the underlying kernel-side dma-buf
|
|
||||||
implementation.
|
|
||||||
|
|
||||||
- Don't make any more attachments after sending the buffer to the
|
|
||||||
compositor. Making more attachments later increases the risk of
|
|
||||||
the compositor not being able to use (re-import) an existing
|
|
||||||
dmabuf-based wl_buffer.
|
|
||||||
|
|
||||||
The underlying graphics stack must ensure the following:
|
|
||||||
|
|
||||||
- The dmabuf file descriptors relayed to the server will stay valid
|
|
||||||
for the whole lifetime of the wl_buffer. This means the server may
|
|
||||||
at any time use those fds to import the dmabuf into any kernel
|
|
||||||
sub-system that might accept it.
|
|
||||||
|
|
||||||
To create a wl_buffer from one or more dmabufs, a client creates a
|
|
||||||
zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params
|
|
||||||
request. All planes required by the intended format are added with
|
|
||||||
the 'add' request. Finally, a 'create' or 'create_immed' request is
|
|
||||||
issued, which has the following outcome depending on the import success.
|
|
||||||
|
|
||||||
The 'create' request,
|
|
||||||
- on success, triggers a 'created' event which provides the final
|
|
||||||
wl_buffer to the client.
|
|
||||||
- on failure, triggers a 'failed' event to convey that the server
|
|
||||||
cannot use the dmabufs received from the client.
|
|
||||||
|
|
||||||
For the 'create_immed' request,
|
|
||||||
- on success, the server immediately imports the added dmabufs to
|
|
||||||
create a wl_buffer. No event is sent from the server in this case.
|
|
||||||
- on failure, the server can choose to either:
|
|
||||||
- terminate the client by raising a fatal error.
|
|
||||||
- mark the wl_buffer as failed, and send a 'failed' event to the
|
|
||||||
client. If the client uses a failed wl_buffer as an argument to any
|
|
||||||
request, the behaviour is compositor implementation-defined.
|
|
||||||
|
|
||||||
Warning! The protocol described in this file is experimental and
|
|
||||||
backward incompatible changes may be made. Backward compatible changes
|
|
||||||
may be added together with the corresponding interface version bump.
|
|
||||||
Backward incompatible changes are done by bumping the version number in
|
|
||||||
the protocol and interface names and resetting the interface version.
|
|
||||||
Once the protocol is to be declared stable, the 'z' prefix and the
|
|
||||||
version number in the protocol and interface names are removed and the
|
|
||||||
interface version number is reset.
|
|
||||||
</description>
|
|
||||||
|
|
||||||
<request name="destroy" type="destructor">
|
|
||||||
<description summary="unbind the factory">
|
|
||||||
Objects created through this interface, especially wl_buffers, will
|
|
||||||
remain valid.
|
|
||||||
</description>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
<request name="create_params">
|
|
||||||
<description summary="create a temporary object for buffer parameters">
|
|
||||||
This temporary object is used to collect multiple dmabuf handles into
|
|
||||||
a single batch to create a wl_buffer. It can only be used once and
|
|
||||||
should be destroyed after a 'created' or 'failed' event has been
|
|
||||||
received.
|
|
||||||
</description>
|
|
||||||
<arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1"
|
|
||||||
summary="the new temporary"/>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
<event name="format">
|
|
||||||
<description summary="supported buffer format">
|
|
||||||
This event advertises one buffer format that the server supports.
|
|
||||||
All the supported formats are advertised once when the client
|
|
||||||
binds to this interface. A roundtrip after binding guarantees
|
|
||||||
that the client has received all supported formats.
|
|
||||||
|
|
||||||
For the definition of the format codes, see the
|
|
||||||
zwp_linux_buffer_params_v1::create request.
|
|
||||||
|
|
||||||
Warning: the 'format' event is likely to be deprecated and replaced
|
|
||||||
with the 'modifier' event introduced in zwp_linux_dmabuf_v1
|
|
||||||
version 3, described below. Please refrain from using the information
|
|
||||||
received from this event.
|
|
||||||
</description>
|
|
||||||
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
<event name="modifier" since="3">
|
|
||||||
<description summary="supported buffer format modifier">
|
|
||||||
This event advertises the formats that the server supports, along with
|
|
||||||
the modifiers supported for each format. All the supported modifiers
|
|
||||||
for all the supported formats are advertised once when the client
|
|
||||||
binds to this interface. A roundtrip after binding guarantees that
|
|
||||||
the client has received all supported format-modifier pairs.
|
|
||||||
|
|
||||||
For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
|
|
||||||
0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
|
|
||||||
It indicates that the server can support the format with an implicit
|
|
||||||
modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
|
|
||||||
is as if no explicit modifier is specified. The effective modifier
|
|
||||||
will be derived from the dmabuf.
|
|
||||||
|
|
||||||
For the definition of the format and modifier codes, see the
|
|
||||||
zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add
|
|
||||||
requests.
|
|
||||||
</description>
|
|
||||||
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
|
|
||||||
<arg name="modifier_hi" type="uint"
|
|
||||||
summary="high 32 bits of layout modifier"/>
|
|
||||||
<arg name="modifier_lo" type="uint"
|
|
||||||
summary="low 32 bits of layout modifier"/>
|
|
||||||
</event>
|
|
||||||
</interface>
|
|
||||||
|
|
||||||
<interface name="zwp_linux_buffer_params_v1" version="3">
|
|
||||||
<description summary="parameters for creating a dmabuf-based wl_buffer">
|
|
||||||
This temporary object is a collection of dmabufs and other
|
|
||||||
parameters that together form a single logical buffer. The temporary
|
|
||||||
object may eventually create one wl_buffer unless cancelled by
|
|
||||||
destroying it before requesting 'create'.
|
|
||||||
|
|
||||||
Single-planar formats only require one dmabuf, however
|
|
||||||
multi-planar formats may require more than one dmabuf. For all
|
|
||||||
formats, an 'add' request must be called once per plane (even if the
|
|
||||||
underlying dmabuf fd is identical).
|
|
||||||
|
|
||||||
You must use consecutive plane indices ('plane_idx' argument for 'add')
|
|
||||||
from zero to the number of planes used by the drm_fourcc format code.
|
|
||||||
All planes required by the format must be given exactly once, but can
|
|
||||||
be given in any order. Each plane index can be set only once.
|
|
||||||
</description>
|
|
||||||
|
|
||||||
<enum name="error">
|
|
||||||
<entry name="already_used" value="0"
|
|
||||||
summary="the dmabuf_batch object has already been used to create a wl_buffer"/>
|
|
||||||
<entry name="plane_idx" value="1"
|
|
||||||
summary="plane index out of bounds"/>
|
|
||||||
<entry name="plane_set" value="2"
|
|
||||||
summary="the plane index was already set"/>
|
|
||||||
<entry name="incomplete" value="3"
|
|
||||||
summary="missing or too many planes to create a buffer"/>
|
|
||||||
<entry name="invalid_format" value="4"
|
|
||||||
summary="format not supported"/>
|
|
||||||
<entry name="invalid_dimensions" value="5"
|
|
||||||
summary="invalid width or height"/>
|
|
||||||
<entry name="out_of_bounds" value="6"
|
|
||||||
summary="offset + stride * height goes out of dmabuf bounds"/>
|
|
||||||
<entry name="invalid_wl_buffer" value="7"
|
|
||||||
summary="invalid wl_buffer resulted from importing dmabufs via
|
|
||||||
the create_immed request on given buffer_params"/>
|
|
||||||
</enum>
|
|
||||||
|
|
||||||
<request name="destroy" type="destructor">
|
|
||||||
<description summary="delete this object, used or not">
|
|
||||||
Cleans up the temporary data sent to the server for dmabuf-based
|
|
||||||
wl_buffer creation.
|
|
||||||
</description>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
<request name="add">
|
|
||||||
<description summary="add a dmabuf to the temporary set">
|
|
||||||
This request adds one dmabuf to the set in this
|
|
||||||
zwp_linux_buffer_params_v1.
|
|
||||||
|
|
||||||
The 64-bit unsigned value combined from modifier_hi and modifier_lo
|
|
||||||
is the dmabuf layout modifier. DRM AddFB2 ioctl calls this the
|
|
||||||
fb modifier, which is defined in drm_mode.h of Linux UAPI.
|
|
||||||
This is an opaque token. Drivers use this token to express tiling,
|
|
||||||
compression, etc. driver-specific modifications to the base format
|
|
||||||
defined by the DRM fourcc code.
|
|
||||||
|
|
||||||
Warning: It should be an error if the format/modifier pair was not
|
|
||||||
advertised with the modifier event. This is not enforced yet because
|
|
||||||
some implementations always accept DRM_FORMAT_MOD_INVALID. Also
|
|
||||||
version 2 of this protocol does not have the modifier event.
|
|
||||||
|
|
||||||
This request raises the PLANE_IDX error if plane_idx is too large.
|
|
||||||
The error PLANE_SET is raised if attempting to set a plane that
|
|
||||||
was already set.
|
|
||||||
</description>
|
|
||||||
<arg name="fd" type="fd" summary="dmabuf fd"/>
|
|
||||||
<arg name="plane_idx" type="uint" summary="plane index"/>
|
|
||||||
<arg name="offset" type="uint" summary="offset in bytes"/>
|
|
||||||
<arg name="stride" type="uint" summary="stride in bytes"/>
|
|
||||||
<arg name="modifier_hi" type="uint"
|
|
||||||
summary="high 32 bits of layout modifier"/>
|
|
||||||
<arg name="modifier_lo" type="uint"
|
|
||||||
summary="low 32 bits of layout modifier"/>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
<enum name="flags">
|
|
||||||
<entry name="y_invert" value="1" summary="contents are y-inverted"/>
|
|
||||||
<entry name="interlaced" value="2" summary="content is interlaced"/>
|
|
||||||
<entry name="bottom_first" value="4" summary="bottom field first"/>
|
|
||||||
</enum>
|
|
||||||
|
|
||||||
<request name="create">
|
|
||||||
<description summary="create a wl_buffer from the given dmabufs">
|
|
||||||
This asks for creation of a wl_buffer from the added dmabuf
|
|
||||||
buffers. The wl_buffer is not created immediately but returned via
|
|
||||||
the 'created' event if the dmabuf sharing succeeds. The sharing
|
|
||||||
may fail at runtime for reasons a client cannot predict, in
|
|
||||||
which case the 'failed' event is triggered.
|
|
||||||
|
|
||||||
The 'format' argument is a DRM_FORMAT code, as defined by the
|
|
||||||
libdrm's drm_fourcc.h. The Linux kernel's DRM sub-system is the
|
|
||||||
authoritative source on how the format codes should work.
|
|
||||||
|
|
||||||
The 'flags' is a bitfield of the flags defined in enum "flags".
|
|
||||||
'y_invert' means the that the image needs to be y-flipped.
|
|
||||||
|
|
||||||
Flag 'interlaced' means that the frame in the buffer is not
|
|
||||||
progressive as usual, but interlaced. An interlaced buffer as
|
|
||||||
supported here must always contain both top and bottom fields.
|
|
||||||
The top field always begins on the first pixel row. The temporal
|
|
||||||
ordering between the two fields is top field first, unless
|
|
||||||
'bottom_first' is specified. It is undefined whether 'bottom_first'
|
|
||||||
is ignored if 'interlaced' is not set.
|
|
||||||
|
|
||||||
This protocol does not convey any information about field rate,
|
|
||||||
duration, or timing, other than the relative ordering between the
|
|
||||||
two fields in one buffer. A compositor may have to estimate the
|
|
||||||
intended field rate from the incoming buffer rate. It is undefined
|
|
||||||
whether the time of receiving wl_surface.commit with a new buffer
|
|
||||||
attached, applying the wl_surface state, wl_surface.frame callback
|
|
||||||
trigger, presentation, or any other point in the compositor cycle
|
|
||||||
is used to measure the frame or field times. There is no support
|
|
||||||
for detecting missed or late frames/fields/buffers either, and
|
|
||||||
there is no support whatsoever for cooperating with interlaced
|
|
||||||
compositor output.
|
|
||||||
|
|
||||||
The composited image quality resulting from the use of interlaced
|
|
||||||
buffers is explicitly undefined. A compositor may use elaborate
|
|
||||||
hardware features or software to deinterlace and create progressive
|
|
||||||
output frames from a sequence of interlaced input buffers, or it
|
|
||||||
may produce substandard image quality. However, compositors that
|
|
||||||
cannot guarantee reasonable image quality in all cases are recommended
|
|
||||||
to just reject all interlaced buffers.
|
|
||||||
|
|
||||||
Any argument errors, including non-positive width or height,
|
|
||||||
mismatch between the number of planes and the format, bad
|
|
||||||
format, bad offset or stride, may be indicated by fatal protocol
|
|
||||||
errors: INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS,
|
|
||||||
OUT_OF_BOUNDS.
|
|
||||||
|
|
||||||
Dmabuf import errors in the server that are not obvious client
|
|
||||||
bugs are returned via the 'failed' event as non-fatal. This
|
|
||||||
allows attempting dmabuf sharing and falling back in the client
|
|
||||||
if it fails.
|
|
||||||
|
|
||||||
This request can be sent only once in the object's lifetime, after
|
|
||||||
which the only legal request is destroy. This object should be
|
|
||||||
destroyed after issuing a 'create' request. Attempting to use this
|
|
||||||
object after issuing 'create' raises ALREADY_USED protocol error.
|
|
||||||
|
|
||||||
It is not mandatory to issue 'create'. If a client wants to
|
|
||||||
cancel the buffer creation, it can just destroy this object.
|
|
||||||
</description>
|
|
||||||
<arg name="width" type="int" summary="base plane width in pixels"/>
|
|
||||||
<arg name="height" type="int" summary="base plane height in pixels"/>
|
|
||||||
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
|
|
||||||
<arg name="flags" type="uint" summary="see enum flags"/>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
<event name="created">
|
|
||||||
<description summary="buffer creation succeeded">
|
|
||||||
This event indicates that the attempted buffer creation was
|
|
||||||
successful. It provides the new wl_buffer referencing the dmabuf(s).
|
|
||||||
|
|
||||||
Upon receiving this event, the client should destroy the
|
|
||||||
zlinux_dmabuf_params object.
|
|
||||||
</description>
|
|
||||||
<arg name="buffer" type="new_id" interface="wl_buffer"
|
|
||||||
summary="the newly created wl_buffer"/>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
<event name="failed">
|
|
||||||
<description summary="buffer creation failed">
|
|
||||||
This event indicates that the attempted buffer creation has
|
|
||||||
failed. It usually means that one of the dmabuf constraints
|
|
||||||
has not been fulfilled.
|
|
||||||
|
|
||||||
Upon receiving this event, the client should destroy the
|
|
||||||
zlinux_buffer_params object.
|
|
||||||
</description>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
<request name="create_immed" since="2">
|
|
||||||
<description summary="immediately create a wl_buffer from the given
|
|
||||||
dmabufs">
|
|
||||||
This asks for immediate creation of a wl_buffer by importing the
|
|
||||||
added dmabufs.
|
|
||||||
|
|
||||||
In case of import success, no event is sent from the server, and the
|
|
||||||
wl_buffer is ready to be used by the client.
|
|
||||||
|
|
||||||
Upon import failure, either of the following may happen, as seen fit
|
|
||||||
by the implementation:
|
|
||||||
- the client is terminated with one of the following fatal protocol
|
|
||||||
errors:
|
|
||||||
- INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS,
|
|
||||||
in case of argument errors such as mismatch between the number
|
|
||||||
of planes and the format, bad format, non-positive width or
|
|
||||||
height, or bad offset or stride.
|
|
||||||
- INVALID_WL_BUFFER, in case the cause for failure is unknown or
|
|
||||||
plaform specific.
|
|
||||||
- the server creates an invalid wl_buffer, marks it as failed and
|
|
||||||
sends a 'failed' event to the client. The result of using this
|
|
||||||
invalid wl_buffer as an argument in any request by the client is
|
|
||||||
defined by the compositor implementation.
|
|
||||||
|
|
||||||
This takes the same arguments as a 'create' request, and obeys the
|
|
||||||
same restrictions.
|
|
||||||
</description>
|
|
||||||
<arg name="buffer_id" type="new_id" interface="wl_buffer"
|
|
||||||
summary="id for the newly created wl_buffer"/>
|
|
||||||
<arg name="width" type="int" summary="base plane width in pixels"/>
|
|
||||||
<arg name="height" type="int" summary="base plane height in pixels"/>
|
|
||||||
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
|
|
||||||
<arg name="flags" type="uint" summary="see enum flags"/>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
</interface>
|
|
||||||
|
|
||||||
</protocol>
|
|
||||||
|
|
@ -1,3 +1,5 @@
|
||||||
|
wl_protocol_dir = wayland_protos.get_variable('pkgdatadir')
|
||||||
|
|
||||||
wayland_scanner_dep = dependency('wayland-scanner', required: false, native: true)
|
wayland_scanner_dep = dependency('wayland-scanner', required: false, native: true)
|
||||||
if wayland_scanner_dep.found()
|
if wayland_scanner_dep.found()
|
||||||
wayland_scanner = find_program(
|
wayland_scanner = find_program(
|
||||||
|
|
@ -9,9 +11,9 @@ else
|
||||||
endif
|
endif
|
||||||
|
|
||||||
client_protocols = [
|
client_protocols = [
|
||||||
'linux-dmabuf-unstable-v1.xml',
|
wl_protocol_dir / 'unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml',
|
||||||
|
wl_protocol_dir / 'unstable/xdg-output/xdg-output-unstable-v1.xml',
|
||||||
'wlr-screencopy-unstable-v1.xml',
|
'wlr-screencopy-unstable-v1.xml',
|
||||||
'xdg-output-unstable-v1.xml',
|
|
||||||
]
|
]
|
||||||
|
|
||||||
wl_proto_files = []
|
wl_proto_files = []
|
||||||
|
|
|
||||||
|
|
@ -1,220 +0,0 @@
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
|
||||||
<protocol name="xdg_output_unstable_v1">
|
|
||||||
|
|
||||||
<copyright>
|
|
||||||
Copyright © 2017 Red Hat Inc.
|
|
||||||
|
|
||||||
Permission is hereby granted, free of charge, to any person obtaining a
|
|
||||||
copy of this software and associated documentation files (the "Software"),
|
|
||||||
to deal in the Software without restriction, including without limitation
|
|
||||||
the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
||||||
and/or sell copies of the Software, and to permit persons to whom the
|
|
||||||
Software is furnished to do so, subject to the following conditions:
|
|
||||||
|
|
||||||
The above copyright notice and this permission notice (including the next
|
|
||||||
paragraph) shall be included in all copies or substantial portions of the
|
|
||||||
Software.
|
|
||||||
|
|
||||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
||||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
||||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
||||||
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
||||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
||||||
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
||||||
DEALINGS IN THE SOFTWARE.
|
|
||||||
</copyright>
|
|
||||||
|
|
||||||
<description summary="Protocol to describe output regions">
|
|
||||||
This protocol aims at describing outputs in a way which is more in line
|
|
||||||
with the concept of an output on desktop oriented systems.
|
|
||||||
|
|
||||||
Some information are more specific to the concept of an output for
|
|
||||||
a desktop oriented system and may not make sense in other applications,
|
|
||||||
such as IVI systems for example.
|
|
||||||
|
|
||||||
Typically, the global compositor space on a desktop system is made of
|
|
||||||
a contiguous or overlapping set of rectangular regions.
|
|
||||||
|
|
||||||
Some of the information provided in this protocol might be identical
|
|
||||||
to their counterparts already available from wl_output, in which case
|
|
||||||
the information provided by this protocol should be preferred to their
|
|
||||||
equivalent in wl_output. The goal is to move the desktop specific
|
|
||||||
concepts (such as output location within the global compositor space,
|
|
||||||
the connector name and types, etc.) out of the core wl_output protocol.
|
|
||||||
|
|
||||||
Warning! The protocol described in this file is experimental and
|
|
||||||
backward incompatible changes may be made. Backward compatible
|
|
||||||
changes may be added together with the corresponding interface
|
|
||||||
version bump.
|
|
||||||
Backward incompatible changes are done by bumping the version
|
|
||||||
number in the protocol and interface names and resetting the
|
|
||||||
interface version. Once the protocol is to be declared stable,
|
|
||||||
the 'z' prefix and the version number in the protocol and
|
|
||||||
interface names are removed and the interface version number is
|
|
||||||
reset.
|
|
||||||
</description>
|
|
||||||
|
|
||||||
<interface name="zxdg_output_manager_v1" version="3">
|
|
||||||
<description summary="manage xdg_output objects">
|
|
||||||
A global factory interface for xdg_output objects.
|
|
||||||
</description>
|
|
||||||
|
|
||||||
<request name="destroy" type="destructor">
|
|
||||||
<description summary="destroy the xdg_output_manager object">
|
|
||||||
Using this request a client can tell the server that it is not
|
|
||||||
going to use the xdg_output_manager object anymore.
|
|
||||||
|
|
||||||
Any objects already created through this instance are not affected.
|
|
||||||
</description>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
<request name="get_xdg_output">
|
|
||||||
<description summary="create an xdg output from a wl_output">
|
|
||||||
This creates a new xdg_output object for the given wl_output.
|
|
||||||
</description>
|
|
||||||
<arg name="id" type="new_id" interface="zxdg_output_v1"/>
|
|
||||||
<arg name="output" type="object" interface="wl_output"/>
|
|
||||||
</request>
|
|
||||||
</interface>
|
|
||||||
|
|
||||||
<interface name="zxdg_output_v1" version="3">
|
|
||||||
<description summary="compositor logical output region">
|
|
||||||
An xdg_output describes part of the compositor geometry.
|
|
||||||
|
|
||||||
This typically corresponds to a monitor that displays part of the
|
|
||||||
compositor space.
|
|
||||||
|
|
||||||
For objects version 3 onwards, after all xdg_output properties have been
|
|
||||||
sent (when the object is created and when properties are updated), a
|
|
||||||
wl_output.done event is sent. This allows changes to the output
|
|
||||||
properties to be seen as atomic, even if they happen via multiple events.
|
|
||||||
</description>
|
|
||||||
|
|
||||||
<request name="destroy" type="destructor">
|
|
||||||
<description summary="destroy the xdg_output object">
|
|
||||||
Using this request a client can tell the server that it is not
|
|
||||||
going to use the xdg_output object anymore.
|
|
||||||
</description>
|
|
||||||
</request>
|
|
||||||
|
|
||||||
<event name="logical_position">
|
|
||||||
<description summary="position of the output within the global compositor space">
|
|
||||||
The position event describes the location of the wl_output within
|
|
||||||
the global compositor space.
|
|
||||||
|
|
||||||
The logical_position event is sent after creating an xdg_output
|
|
||||||
(see xdg_output_manager.get_xdg_output) and whenever the location
|
|
||||||
of the output changes within the global compositor space.
|
|
||||||
</description>
|
|
||||||
<arg name="x" type="int"
|
|
||||||
summary="x position within the global compositor space"/>
|
|
||||||
<arg name="y" type="int"
|
|
||||||
summary="y position within the global compositor space"/>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
<event name="logical_size">
|
|
||||||
<description summary="size of the output in the global compositor space">
|
|
||||||
The logical_size event describes the size of the output in the
|
|
||||||
global compositor space.
|
|
||||||
|
|
||||||
For example, a surface without any buffer scale, transformation
|
|
||||||
nor rotation set, with the size matching the logical_size will
|
|
||||||
have the same size as the corresponding output when displayed.
|
|
||||||
|
|
||||||
Most regular Wayland clients should not pay attention to the
|
|
||||||
logical size and would rather rely on xdg_shell interfaces.
|
|
||||||
|
|
||||||
Some clients such as Xwayland, however, need this to configure
|
|
||||||
their surfaces in the global compositor space as the compositor
|
|
||||||
may apply a different scale from what is advertised by the output
|
|
||||||
scaling property (to achieve fractional scaling, for example).
|
|
||||||
|
|
||||||
For example, for a wl_output mode 3840×2160 and a scale factor 2:
|
|
||||||
|
|
||||||
- A compositor not scaling the surface buffers will advertise a
|
|
||||||
logical size of 3840×2160,
|
|
||||||
|
|
||||||
- A compositor automatically scaling the surface buffers will
|
|
||||||
advertise a logical size of 1920×1080,
|
|
||||||
|
|
||||||
- A compositor using a fractional scale of 1.5 will advertise a
|
|
||||||
logical size to 2560×1620.
|
|
||||||
|
|
||||||
For example, for a wl_output mode 1920×1080 and a 90 degree rotation,
|
|
||||||
the compositor will advertise a logical size of 1080x1920.
|
|
||||||
|
|
||||||
The logical_size event is sent after creating an xdg_output
|
|
||||||
(see xdg_output_manager.get_xdg_output) and whenever the logical
|
|
||||||
size of the output changes, either as a result of a change in the
|
|
||||||
applied scale or because of a change in the corresponding output
|
|
||||||
mode(see wl_output.mode) or transform (see wl_output.transform).
|
|
||||||
</description>
|
|
||||||
<arg name="width" type="int"
|
|
||||||
summary="width in global compositor space"/>
|
|
||||||
<arg name="height" type="int"
|
|
||||||
summary="height in global compositor space"/>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
<event name="done">
|
|
||||||
<description summary="all information about the output have been sent">
|
|
||||||
This event is sent after all other properties of an xdg_output
|
|
||||||
have been sent.
|
|
||||||
|
|
||||||
This allows changes to the xdg_output properties to be seen as
|
|
||||||
atomic, even if they happen via multiple events.
|
|
||||||
|
|
||||||
For objects version 3 onwards, this event is deprecated. Compositors
|
|
||||||
are not required to send it anymore and must send wl_output.done
|
|
||||||
instead.
|
|
||||||
</description>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
<!-- Version 2 additions -->
|
|
||||||
|
|
||||||
<event name="name" since="2">
|
|
||||||
<description summary="name of this output">
|
|
||||||
Many compositors will assign names to their outputs, show them to the
|
|
||||||
user, allow them to be configured by name, etc. The client may wish to
|
|
||||||
know this name as well to offer the user similar behaviors.
|
|
||||||
|
|
||||||
The naming convention is compositor defined, but limited to
|
|
||||||
alphanumeric characters and dashes (-). Each name is unique among all
|
|
||||||
wl_output globals, but if a wl_output global is destroyed the same name
|
|
||||||
may be reused later. The names will also remain consistent across
|
|
||||||
sessions with the same hardware and software configuration.
|
|
||||||
|
|
||||||
Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do
|
|
||||||
not assume that the name is a reflection of an underlying DRM
|
|
||||||
connector, X11 connection, etc.
|
|
||||||
|
|
||||||
The name event is sent after creating an xdg_output (see
|
|
||||||
xdg_output_manager.get_xdg_output). This event is only sent once per
|
|
||||||
xdg_output, and the name does not change over the lifetime of the
|
|
||||||
wl_output global.
|
|
||||||
</description>
|
|
||||||
<arg name="name" type="string" summary="output name"/>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
<event name="description" since="2">
|
|
||||||
<description summary="human-readable description of this output">
|
|
||||||
Many compositors can produce human-readable descriptions of their
|
|
||||||
outputs. The client may wish to know this description as well, to
|
|
||||||
communicate the user for various purposes.
|
|
||||||
|
|
||||||
The description is a UTF-8 string with no convention defined for its
|
|
||||||
contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11
|
|
||||||
output via :1'.
|
|
||||||
|
|
||||||
The description event is sent after creating an xdg_output (see
|
|
||||||
xdg_output_manager.get_xdg_output) and whenever the description
|
|
||||||
changes. The description is optional, and may not be sent at all.
|
|
||||||
|
|
||||||
For objects of version 2 and lower, this event is only sent once per
|
|
||||||
xdg_output, and the description does not change over the lifetime of
|
|
||||||
the wl_output global.
|
|
||||||
</description>
|
|
||||||
<arg name="description" type="string" summary="output description"/>
|
|
||||||
</event>
|
|
||||||
|
|
||||||
</interface>
|
|
||||||
</protocol>
|
|
||||||
Loading…
Reference in a new issue