Date: Sat, 7 Jan 2023 22:32:29 GMT From: Jan Beich <jbeich@FreeBSD.org> To: ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org, dev-commits-ports-main@FreeBSD.org Subject: git: 854f8bb5cc7c - main - games/veloren: unbreak Wayland support Message-ID: <202301072232.307MWTAS055060@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by jbeich: URL: https://cgit.FreeBSD.org/ports/commit/?id=854f8bb5cc7c3a80d6a7c2c9e2e77cd5019b3feb commit 854f8bb5cc7c3a80d6a7c2c9e2e77cd5019b3feb 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:08 +0000 games/veloren: unbreak Wayland support PR: 268810 --- 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 c3c155197932..89b679a781af 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202301072232.307MWTAS055060>