git: 634d84874d48 - 2023Q1 - games/veloren: unbreak Wayland support
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 07 Jan 2023 22:32:49 UTC
The branch 2023Q1 has been updated by jbeich:
URL: https://cgit.FreeBSD.org/ports/commit/?id=634d84874d4800a073f732230e26d55c1ad57d86
commit 634d84874d4800a073f732230e26d55c1ad57d86
Author: Jan Beich <jbeich@FreeBSD.org>
AuthorDate: 2023-01-07 17:00:01 +0000
Commit: Jan Beich <jbeich@FreeBSD.org>
CommitDate: 2023-01-07 22:32:42 +0000
games/veloren: unbreak Wayland support
PR: 268810
(cherry picked from commit 854f8bb5cc7c3a80d6a7c2c9e2e77cd5019b3feb)
---
games/veloren/Makefile | 3 +-
games/veloren/files/patch-wayland | 503 ++++++++++++++++++++++++++++++++++++++
2 files changed, 505 insertions(+), 1 deletion(-)
diff --git a/games/veloren/Makefile b/games/veloren/Makefile
index 618e7e2b8591..5b0bb776c00b 100644
--- a/games/veloren/Makefile
+++ b/games/veloren/Makefile
@@ -1,7 +1,8 @@
PORTNAME= veloren
DISTVERSIONPREFIX= v
DISTVERSION= 0.14.0
-CATEGORIES= games # wayland: depends on https://gitlab.com/veloren/veloren/-/issues/1567
+PORTREVISION= 1
+CATEGORIES= games wayland
.if !make(makesum)
MASTER_SITES= LOCAL/jbeich
.endif
diff --git a/games/veloren/files/patch-wayland b/games/veloren/files/patch-wayland
new file mode 100644
index 000000000000..793f230fb853
--- /dev/null
+++ b/games/veloren/files/patch-wayland
@@ -0,0 +1,503 @@
+https://gitlab.com/veloren/veloren/-/issues/1567
+
+Backport https://github.com/smithay/wayland-rs/commit/7045d5b01859
+to support wl_shm::Format::Abgr16161616 and wl_shm::Format::Xbgr16161616 after
+https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/7ad67e0f1db4 (wlroots >= 0.16)
+https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/9f938f7f2a2a (wlroots >= 0.17)
+
+--- cargo-crates/wayland-client-0.28.6/wayland.xml.orig 1970-01-01 00:00:00 UTC
++++ cargo-crates/wayland-client-0.28.6/wayland.xml
+@@ -179,7 +179,7 @@
+ the related request is done.
+ </description>
+
+- <event name="done">
++ <event name="done" type="destructor">
+ <description summary="done event">
+ Notify the client when the related request is done.
+ </description>
+@@ -187,7 +187,7 @@
+ </event>
+ </interface>
+
+- <interface name="wl_compositor" version="4">
++ <interface name="wl_compositor" version="5">
+ <description summary="the compositor singleton">
+ A compositor. This object is a singleton global. The
+ compositor is in charge of combining the contents of multiple
+@@ -296,9 +296,12 @@
+ The drm format codes match the macros defined in drm_fourcc.h, except
+ argb8888 and xrgb8888. The formats actually supported by the compositor
+ will be reported by the format event.
++
++ For all wl_shm formats and unless specified in another protocol
++ extension, pre-multiplied alpha is used for pixel values.
+ </description>
+ <!-- Note to protocol writers: don't update this list manually, instead
+- run the automated script that keeps it in sync with drm_fourcc.h. -->
++ run the automated script that keeps it in sync with drm_fourcc.h. -->
+ <entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>
+ <entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>
+ <entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>
+@@ -399,6 +402,14 @@
+ <entry name="p010" value="0x30313050" summary="2x2 subsampled Cr:Cb plane 10 bits per channel"/>
+ <entry name="p012" value="0x32313050" summary="2x2 subsampled Cr:Cb plane 12 bits per channel"/>
+ <entry name="p016" value="0x36313050" summary="2x2 subsampled Cr:Cb plane 16 bits per channel"/>
++ <entry name="axbxgxrx106106106106" value="0x30314241" summary="[63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian"/>
++ <entry name="nv15" value="0x3531564e" summary="2x2 subsampled Cr:Cb plane"/>
++ <entry name="q410" value="0x30313451"/>
++ <entry name="q401" value="0x31303451"/>
++ <entry name="xrgb16161616" value="0x38345258" summary="[63:0] x:R:G:B 16:16:16:16 little endian"/>
++ <entry name="xbgr16161616" value="0x38344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>
++ <entry name="argb16161616" value="0x38345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>
++ <entry name="abgr16161616" value="0x38344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>
+ </enum>
+
+ <request name="create_pool">
+@@ -427,10 +438,15 @@
+ <interface name="wl_buffer" version="1">
+ <description summary="content for a wl_surface">
+ A buffer provides the content for a wl_surface. Buffers are
+- created through factory interfaces such as wl_drm, wl_shm or
+- similar. It has a width and a height and can be attached to a
+- wl_surface, but the mechanism by which a client provides and
+- updates the contents is defined by the buffer factory interface.
++ created through factory interfaces such as wl_shm, wp_linux_buffer_params
++ (from the linux-dmabuf protocol extension) or similar. It has a width and
++ a height and can be attached to a wl_surface, but the mechanism by which a
++ client provides and updates the contents is defined by the buffer factory
++ interface.
++
++ If the buffer uses a format that has an alpha channel, the alpha channel
++ is assumed to be premultiplied in the color channels unless otherwise
++ specified.
+ </description>
+
+ <request name="destroy" type="destructor">
+@@ -594,9 +610,9 @@
+ will be raised otherwise.
+ </description>
+ <arg name="dnd_actions" type="uint" summary="actions supported by the destination client"
+- enum="wl_data_device_manager.dnd_action"/>
++ enum="wl_data_device_manager.dnd_action"/>
+ <arg name="preferred_action" type="uint" summary="action preferred by the destination client"
+- enum="wl_data_device_manager.dnd_action"/>
++ enum="wl_data_device_manager.dnd_action"/>
+ </request>
+
+ <event name="source_actions" since="3">
+@@ -606,7 +622,7 @@
+ side changes its offered actions through wl_data_source.set_actions.
+ </description>
+ <arg name="source_actions" type="uint" summary="actions offered by the data source"
+- enum="wl_data_device_manager.dnd_action"/>
++ enum="wl_data_device_manager.dnd_action"/>
+ </event>
+
+ <event name="action" since="3">
+@@ -648,7 +664,7 @@
+ must happen before the call to wl_data_offer.finish.
+ </description>
+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"
+- enum="wl_data_device_manager.dnd_action"/>
++ enum="wl_data_device_manager.dnd_action"/>
+ </event>
+ </interface>
+
+@@ -746,7 +762,7 @@
+ for drag-and-drop will raise a protocol error.
+ </description>
+ <arg name="dnd_actions" type="uint" summary="actions supported by the data source"
+- enum="wl_data_device_manager.dnd_action"/>
++ enum="wl_data_device_manager.dnd_action"/>
+ </request>
+
+ <event name="dnd_drop_performed" since="3">
+@@ -803,7 +819,7 @@
+ they reflect the current action.
+ </description>
+ <arg name="dnd_action" type="uint" summary="action selected by the compositor"
+- enum="wl_data_device_manager.dnd_action"/>
++ enum="wl_data_device_manager.dnd_action"/>
+ </event>
+ </interface>
+
+@@ -829,7 +845,8 @@
+ for the eventual data transfer. If source is NULL, enter, leave
+ and motion events are sent only to the client that initiated the
+ drag and the client is expected to handle the data passing
+- internally.
++ internally. If source is destroyed, the drag-and-drop session will be
++ cancelled.
+
+ The origin surface is the surface where the drag originates and
+ the client must have an active implicit grab that matches the
+@@ -943,9 +960,10 @@
+ immediately before receiving keyboard focus and when a new
+ selection is set while the client has keyboard focus. The
+ data_offer is valid until a new data_offer or NULL is received
+- or until the client loses keyboard focus. The client must
+- destroy the previous selection data_offer, if any, upon receiving
+- this event.
++ or until the client loses keyboard focus. Switching surface with
++ keyboard focus within the same client doesn't mean a new selection
++ will be sent. The client must destroy the previous selection
++ data_offer, if any, upon receiving this event.
+ </description>
+ <arg name="id" type="object" interface="wl_data_offer" allow-null="true"
+ summary="selection data_offer object"/>
+@@ -1327,7 +1345,7 @@
+ </event>
+ </interface>
+
+- <interface name="wl_surface" version="4">
++ <interface name="wl_surface" version="5">
+ <description summary="an onscreen surface">
+ A surface is a rectangular area that may be displayed on zero
+ or more outputs, and shown any number of times at the compositor's
+@@ -1378,6 +1396,8 @@
+ </description>
+ <entry name="invalid_scale" value="0" summary="buffer scale value is invalid"/>
+ <entry name="invalid_transform" value="1" summary="buffer transform value is invalid"/>
++ <entry name="invalid_size" value="2" summary="buffer size is invalid"/>
++ <entry name="invalid_offset" value="3" summary="buffer offset is invalid"/>
+ </enum>
+
+ <request name="destroy" type="destructor">
+@@ -1392,15 +1412,23 @@
+
+ The new size of the surface is calculated based on the buffer
+ size transformed by the inverse buffer_transform and the
+- inverse buffer_scale. This means that the supplied buffer
+- must be an integer multiple of the buffer_scale.
++ inverse buffer_scale. This means that at commit time the supplied
++ buffer size must be an integer multiple of the buffer_scale. If
++ that's not the case, an invalid_size error is sent.
+
+ The x and y arguments specify the location of the new pending
+ buffer's upper left corner, relative to the current buffer's upper
+ left corner, in surface-local coordinates. In other words, the
+ x and y, combined with the new surface size define in which
+- directions the surface's size changes.
++ directions the surface's size changes. Setting anything other than 0
++ as x and y arguments is discouraged, and should instead be replaced
++ with using the separate wl_surface.offset request.
+
++ When the bound wl_surface version is 5 or higher, passing any
++ non-zero x or y is a protocol violation, and will result in an
++ 'invalid_offset' error being raised. To achieve equivalent semantics,
++ use wl_surface.offset.
++
+ Surface contents are double-buffered state, see wl_surface.commit.
+
+ The initial surface contents are void; there is no content.
+@@ -1427,9 +1455,12 @@
+ from the same backing storage or use wp_linux_buffer_release.
+
+ Destroying the wl_buffer after wl_buffer.release does not change
+- the surface contents. However, if the client destroys the
+- wl_buffer before receiving the wl_buffer.release event, the surface
+- contents become undefined immediately.
++ the surface contents. Destroying the wl_buffer before wl_buffer.release
++ is allowed as long as the underlying buffer storage isn't re-used (this
++ can happen e.g. on client process termination). However, if the client
++ destroys the wl_buffer before receiving the wl_buffer.release event and
++ mutates the underlying buffer storage, the surface contents become
++ undefined immediately.
+
+ If wl_surface.attach is sent with a NULL wl_buffer, the
+ following wl_surface.commit will remove the surface content.
+@@ -1606,6 +1637,12 @@
+ This is emitted whenever a surface's creation, movement, or resizing
+ results in it no longer having any part of it within the scanout region
+ of an output.
++
++ Clients should not use the number of outputs the surface is on for frame
++ throttling purposes. The surface might be hidden even if no leave event
++ has been sent, and the compositor might expect new surface content
++ updates even if no enter event has been sent. The frame event should be
++ used instead.
+ </description>
+ <arg name="output" type="object" interface="wl_output" summary="output left by the surface"/>
+ </event>
+@@ -1721,6 +1758,27 @@
+ <arg name="width" type="int" summary="width of damage rectangle"/>
+ <arg name="height" type="int" summary="height of damage rectangle"/>
+ </request>
++
++ <!-- Version 5 additions -->
++
++ <request name="offset" since="5">
++ <description summary="set the surface contents offset">
++ The x and y arguments specify the location of the new pending
++ buffer's upper left corner, relative to the current buffer's upper
++ left corner, in surface-local coordinates. In other words, the
++ x and y, combined with the new surface size define in which
++ directions the surface's size changes.
++
++ Surface location offset is double-buffered state, see
++ wl_surface.commit.
++
++ This request is semantically equivalent to and the replaces the x and y
++ arguments in the wl_surface.attach request in wl_surface versions prior
++ to 5. See wl_surface.attach for details.
++ </description>
++ <arg name="x" type="int" summary="surface-local x coordinate"/>
++ <arg name="y" type="int" summary="surface-local y coordinate"/>
++ </request>
+ </interface>
+
+ <interface name="wl_seat" version="7">
+@@ -1741,6 +1799,14 @@
+ <entry name="touch" value="4" summary="the seat has touch devices"/>
+ </enum>
+
++ <enum name="error">
++ <description summary="wl_seat error values">
++ These errors can be emitted in response to wl_seat requests.
++ </description>
++ <entry name="missing_capability" value="0"
++ summary="get_pointer, get_keyboard or get_touch called on seat without the matching capability"/>
++ </enum>
++
+ <event name="capabilities">
+ <description summary="seat capabilities changed">
+ This is emitted whenever a seat gains or loses the pointer,
+@@ -1779,7 +1845,8 @@
+ This request only takes effect if the seat has the pointer
+ capability, or has had the pointer capability in the past.
+ It is a protocol violation to issue this request on a seat that has
+- never had the pointer capability.
++ never had the pointer capability. The missing_capability error will
++ be sent in this case.
+ </description>
+ <arg name="id" type="new_id" interface="wl_pointer" summary="seat pointer"/>
+ </request>
+@@ -1792,7 +1859,8 @@
+ This request only takes effect if the seat has the keyboard
+ capability, or has had the keyboard capability in the past.
+ It is a protocol violation to issue this request on a seat that has
+- never had the keyboard capability.
++ never had the keyboard capability. The missing_capability error will
++ be sent in this case.
+ </description>
+ <arg name="id" type="new_id" interface="wl_keyboard" summary="seat keyboard"/>
+ </request>
+@@ -1805,7 +1873,8 @@
+ This request only takes effect if the seat has the touch
+ capability, or has had the touch capability in the past.
+ It is a protocol violation to issue this request on a seat that has
+- never had the touch capability.
++ never had the touch capability. The missing_capability error will
++ be sent in this case.
+ </description>
+ <arg name="id" type="new_id" interface="wl_touch" summary="seat touch interface"/>
+ </request>
+@@ -1814,9 +1883,22 @@
+
+ <event name="name" since="2">
+ <description summary="unique identifier for this seat">
+- In a multiseat configuration this can be used by the client to help
+- identify which physical devices the seat represents. Based on
+- the seat configuration used by the compositor.
++ In a multi-seat configuration the seat name can be used by clients to
++ help identify which physical devices the seat represents.
++
++ The seat name is a UTF-8 string with no convention defined for its
++ contents. Each name is unique among all wl_seat globals. The name is
++ only guaranteed to be unique for the current compositor instance.
++
++ The same seat names are used for all clients. Thus, the name can be
++ shared across processes to refer to a specific wl_seat global.
++
++ The name event is sent after binding to the seat global. This event is
++ only sent once per seat object, and the name does not change over the
++ lifetime of the wl_seat global.
++
++ Compositors may re-use the same seat name if the wl_seat global is
++ destroyed and re-created later.
+ </description>
+ <arg name="name" type="string" summary="seat identifier"/>
+ </event>
+@@ -1881,6 +1963,10 @@
+ wl_surface is no longer used as the cursor. When the use as a
+ cursor ends, the current and pending input regions become
+ undefined, and the wl_surface is unmapped.
++
++ The serial parameter must match the latest wl_pointer.enter
++ 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="surface" type="object" interface="wl_surface" allow-null="true"
+@@ -2175,7 +2261,8 @@
+ <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.
++ memory-mapped in read-only mode to provide a keyboard mapping
++ description.
+
+ From version 7 onwards, the fd must be mapped with MAP_PRIVATE by
+ the recipient, as MAP_SHARED may fail.
+@@ -2189,6 +2276,9 @@
+ <description summary="enter event">
+ Notification that this seat's keyboard focus is on a certain
+ surface.
++
++ The compositor must send the wl_keyboard.modifiers event after this
++ event.
+ </description>
+ <arg name="serial" type="uint" summary="serial number of the enter event"/>
+ <arg name="surface" type="object" interface="wl_surface" summary="surface gaining keyboard focus"/>
+@@ -2202,6 +2292,9 @@
+
+ The leave notification is sent before the enter notification
+ for the new focus.
++
++ After this event client must assume that all keys, including modifiers,
++ are lifted and also it must stop key repeating if there's some going on.
+ </description>
+ <arg name="serial" type="uint" summary="serial number of the leave event"/>
+ <arg name="surface" type="object" interface="wl_surface" summary="surface that lost keyboard focus"/>
+@@ -2220,6 +2313,12 @@
+ A key was pressed or released.
+ The time argument is a timestamp with millisecond
+ granularity, with an undefined base.
++
++ The key is a platform-specific key code that can be interpreted
++ by feeding it to the keyboard mapping (see the keymap event).
++
++ If this event produces a change in modifiers, then the resulting
++ wl_keyboard.modifiers event must be sent after this event.
+ </description>
+ <arg name="serial" type="uint" summary="serial number of the key event"/>
+ <arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
+@@ -2413,7 +2512,7 @@
+ </event>
+ </interface>
+
+- <interface name="wl_output" version="3">
++ <interface name="wl_output" version="4">
+ <description summary="compositor output region">
+ An output describes part of the compositor geometry. The
+ compositor works in the 'compositor coordinate system' and an
+@@ -2469,12 +2568,15 @@
+ The physical size can be set to zero if it doesn't make sense for this
+ output (e.g. for projectors or virtual outputs).
+
++ The geometry event will be followed by a done event (starting from
++ version 2).
++
+ Note: wl_output only advertises partial information about the output
+ position and identification. Some compositors, for instance those not
+ implementing a desktop-style output layout or those exposing virtual
+ outputs, might fake this information. Instead of using x and y, clients
+ should use xdg_output.logical_position. Instead of using make and model,
+- clients should use xdg_output.name and xdg_output.description.
++ clients should use name and description.
+ </description>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+@@ -2515,6 +2617,10 @@
+ current. In other words, the current mode is always the last
+ mode that was received with the current flag set.
+
++ Non-current modes are deprecated. A compositor can decide to only
++ advertise the current mode and never send other modes. Clients
++ should not rely on non-current modes.
++
+ 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,
+@@ -2526,6 +2632,9 @@
+ The vertical refresh rate can be set to zero if it doesn't make
+ sense for this output (e.g. for virtual outputs).
+
++ The mode event will be followed by a done event (starting from
++ version 2).
++
+ Clients should not use the refresh rate to schedule frames. Instead,
+ they should use the wl_surface.frame event or the presentation-time
+ protocol.
+@@ -2572,6 +2681,8 @@
+ the scale of the output. That way the compositor can
+ avoid scaling the surface, and the client can supply
+ a higher detail image.
++
++ The scale event will be followed by a done event.
+ </description>
+ <arg name="factor" type="int" summary="scaling factor of output"/>
+ </event>
+@@ -2584,6 +2695,62 @@
+ use the output object anymore.
+ </description>
+ </request>
++
++ <!-- Version 4 additions -->
++
++ <event name="name" since="4">
++ <description summary="name of this output">
++ Many compositors will assign user-friendly names to their outputs, show
++ them to the user, allow the user to refer to an output, etc. The client
++ may wish to know this name as well to offer the user similar behaviors.
++
++ The name is a UTF-8 string with no convention defined for its contents.
++ Each name is unique among all wl_output globals. The name is only
++ guaranteed to be unique for the compositor instance.
++
++ The same output name is used for all clients for a given wl_output
++ global. Thus, the name can be shared across processes to refer to a
++ specific wl_output global.
++
++ The name is not guaranteed to be persistent across sessions, thus cannot
++ be used to reliably identify an output in e.g. configuration files.
++
++ 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 binding the output object. This event is
++ only sent once per output object, and the name does not change over the
++ lifetime of the wl_output global.
++
++ Compositors may re-use the same output name if the wl_output global is
++ destroyed and re-created later. Compositors should avoid re-using the
++ same name if possible.
++
++ The name event will be followed by a done event.
++ </description>
++ <arg name="name" type="string" summary="output name"/>
++ </event>
++
++ <event name="description" since="4">
++ <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, e.g. for
++ output selection purposes.
++
++ The description is a UTF-8 string with no convention defined for its
++ contents. The description is not guaranteed to be unique among all
++ wl_output globals. Examples might include 'Foocorp 11" Display' or
++ 'Virtual X11 output via :1'.
++
++ The description event is sent after binding the output object and
++ whenever the description changes. The description is optional, and may
++ not be sent at all.
++
++ The description event will be followed by a done event.
++ </description>
++ <arg name="description" type="string" summary="output description"/>
++ </event>
+ </interface>
+
+ <interface name="wl_region" version="1">
+@@ -2707,7 +2874,7 @@
+ wl_surface state directly. A sub-surface is initially in the
+ synchronized mode.
+
+- Sub-surfaces have also other kind of state, which is managed by
++ Sub-surfaces also have another kind of state, which is managed by
+ wl_subsurface requests, as opposed to wl_surface requests. This
+ state includes the sub-surface position relative to the parent
+ surface (wl_subsurface.set_position), and the stacking order of