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