diff --git a/protocols/linux-dmabuf-unstable-v1.xml b/protocols/linux-dmabuf-unstable-v1.xml
deleted file mode 100644
index feb037d..0000000
--- a/protocols/linux-dmabuf-unstable-v1.xml
+++ /dev/null
@@ -1,362 +0,0 @@
-
-
-
-
- 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.
-
-
-
-
- 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.
-
-
-
-
- Objects created through this interface, especially wl_buffers, will
- remain valid.
-
-
-
-
-
- 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.
-
-
-
-
-
-
- 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.
-
-
-
-
-
-
- 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.
-
-
-
-
-
-
-
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Cleans up the temporary data sent to the server for dmabuf-based
- wl_buffer creation.
-
-
-
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 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.
-
-
-
-
-
-
-
-
-
- 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.
-
-
-
-
-
-
- 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.
-
-
-
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
diff --git a/protocols/meson.build b/protocols/meson.build
index bb854b5..ee4aed1 100644
--- a/protocols/meson.build
+++ b/protocols/meson.build
@@ -1,3 +1,5 @@
+wl_protocol_dir = wayland_protos.get_variable('pkgdatadir')
+
wayland_scanner_dep = dependency('wayland-scanner', required: false, native: true)
if wayland_scanner_dep.found()
wayland_scanner = find_program(
@@ -9,9 +11,9 @@ else
endif
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',
- 'xdg-output-unstable-v1.xml',
]
wl_proto_files = []
diff --git a/protocols/xdg-output-unstable-v1.xml b/protocols/xdg-output-unstable-v1.xml
deleted file mode 100644
index 8cfb714..0000000
--- a/protocols/xdg-output-unstable-v1.xml
+++ /dev/null
@@ -1,220 +0,0 @@
-
-
-
-
- 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.
-
-
-
- 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.
-
-
-
-
- A global factory interface for xdg_output objects.
-
-
-
-
- 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.
-
-
-
-
-
- This creates a new xdg_output object for the given wl_output.
-
-
-
-
-
-
-
-
- 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.
-
-
-
-
- Using this request a client can tell the server that it is not
- going to use the xdg_output object anymore.
-
-
-
-
-
- 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.
-
-
-
-
-
-
-
- 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).
-
-
-
-
-
-
-
- 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.
-
-
-
-
-
-
-
- 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.
-
-
-
-
-
-
- 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.
-
-
-
-
-
-