From nobody Sat Jan 07 22:32:29 2023 X-Original-To: dev-commits-ports-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NqFML0g16z2pJYx; Sat, 7 Jan 2023 22:32:30 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NqFML0Q1Kz3yfd; Sat, 7 Jan 2023 22:32:30 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673130750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=abJnNxNZ0dDWJlg59F6IHp3QBXe8WAZPZWDTwsx9j9Q=; b=tcihp5oaGKVSpM746SDoYFyUOI2US/zmhGj1AwqoKg9tn/0TzC3kgH4ZVL88ws9XGxljoj MEAnuLKhYv/vi1A+6AkBZ9QDG6TsyUjzigexOos23d560o9qUgu5CEjYcpuqb24J8b+CkP 5Mc/G9D5J4jT5vxTpz0Lp9oYBTMmFUSFML1LbjZxzz4R0Ji5lauhOPkoniyBKI7wmA68kw MMAJmvQhbzIgn2bOAWW4jqxt0nc/0X5oMjuEKM0B531e/g4lhYi4c4MivrEa6V7VdE9kOL edJDPQigD16njJ0K+p42+McJlLr2XGajPAhkMKQQLkiFB+EkA+JYPDdW2Lh1Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673130750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=abJnNxNZ0dDWJlg59F6IHp3QBXe8WAZPZWDTwsx9j9Q=; b=ubp71nACKvGC6JcL1Yju6y88Fbn97nHzXA9VXWgRnEs+tUGLJduzY+MVm/GNa5V/Pvnz15 CxrJYYKlNFoEGrVjJaxpb58EGqkdKQr4K1VKRrU606Ul5P2zNoJhJAgG3NsCsgRQDtGr13 /i0cKhSXr5WrVgsU54oZSlSUk63D6vjCLYInjtk8ZcjgKlVwodjmyrvzZXKXY57HU7ArpQ JcZHwymJujkWtIG/SG8YyspDi/YIS0HYKUjtn2uthmXMZurPTeukLF3Ibjsk1GLXxPeNWz NjnNLjyzggXUV9JQJEjIXM5l1KLa3AlyBoC4L2ia+m61O0MdLqcAZvsDbVF1HQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673130750; a=rsa-sha256; cv=none; b=ZEw48/F6NqGE2CjfEwd4E0/ansoD5GbiS7W2/I4i9YzYahORFkQDC5hA3gZxXioahhqc60 fNy2R3gsCbrBcK8YNGc4uY5QzybcoChIirFTu6Hu8gzxeN7cUMF0di3o8gZkyHt9G6hMwM hAfreWxV+U8VRyHqs5KqrJRb+NF4vFOMYcMzeAR6NXJ43TdIe1rDMfimJerL3UwyF7kIaD OHvUHc/bzyqkVoJhrbLDyC18ADBjTCRRgns22Oy+tujdiVEJ5wh5Mw3QCVlHmDQDJ6YD7m eXJ4Re5ArerSmvcGGR6MbMl9/pSRFp+Afj549YAM3QH/6eHC7mNQwKix6CQrmg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4NqFMK6c8KzR7N; Sat, 7 Jan 2023 22:32:29 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 307MWTob055061; Sat, 7 Jan 2023 22:32:29 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 307MWTAS055060; Sat, 7 Jan 2023 22:32:29 GMT (envelope-from git) Date: Sat, 7 Jan 2023 22:32:29 GMT Message-Id: <202301072232.307MWTAS055060@gitrepo.freebsd.org> To: ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org, dev-commits-ports-main@FreeBSD.org From: Jan Beich Subject: git: 854f8bb5cc7c - main - games/veloren: unbreak Wayland support List-Id: Commit messages for all branches of the ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-all@freebsd.org X-BeenThere: dev-commits-ports-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: jbeich X-Git-Repository: ports X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 854f8bb5cc7c3a80d6a7c2c9e2e77cd5019b3feb Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by jbeich: URL: https://cgit.FreeBSD.org/ports/commit/?id=854f8bb5cc7c3a80d6a7c2c9e2e77cd5019b3feb commit 854f8bb5cc7c3a80d6a7c2c9e2e77cd5019b3feb Author: Jan Beich AuthorDate: 2023-01-07 17:00:01 +0000 Commit: Jan Beich 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. + + +- ++ + + Notify the client when the related request is done. + +@@ -187,7 +187,7 @@ + + + +- ++ + + 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. + + ++ run the automated script that keeps it in sync with drm_fourcc.h. --> + + + +@@ -399,6 +402,14 @@ + + + ++ ++ ++ ++ ++ ++ ++ ++ + + + +@@ -427,10 +438,15 @@ + + + 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. + + + +@@ -594,9 +610,9 @@ + will be raised otherwise. + + ++ enum="wl_data_device_manager.dnd_action"/> + ++ enum="wl_data_device_manager.dnd_action"/> + + + +@@ -606,7 +622,7 @@ + side changes its offered actions through wl_data_source.set_actions. + + ++ enum="wl_data_device_manager.dnd_action"/> + + + +@@ -648,7 +664,7 @@ + must happen before the call to wl_data_offer.finish. + + ++ enum="wl_data_device_manager.dnd_action"/> + + + +@@ -746,7 +762,7 @@ + for drag-and-drop will raise a protocol error. + + ++ enum="wl_data_device_manager.dnd_action"/> + + + +@@ -803,7 +819,7 @@ + they reflect the current action. + + ++ enum="wl_data_device_manager.dnd_action"/> + + + +@@ -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. + + +@@ -1327,7 +1345,7 @@ + + + +- ++ + + 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 @@ + + + ++ ++ + + + +@@ -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. + + + +@@ -1721,6 +1758,27 @@ + + + ++ ++ ++ ++ ++ ++ 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. ++ ++ ++ ++ + + + +@@ -1741,6 +1799,14 @@ + + + ++ ++ ++ These errors can be emitted in response to wl_seat requests. ++ ++ ++ ++ + + + 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. + + + +@@ -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. + + + +@@ -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. + + + +@@ -1814,9 +1883,22 @@ + + + +- 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. + + + +@@ -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. + + + + + 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 @@ + + Notification that this seat's keyboard focus is on a certain + surface. ++ ++ The compositor must send the wl_keyboard.modifiers event after this ++ event. + + + +@@ -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. + + + +@@ -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. + + + +@@ -2413,7 +2512,7 @@ + + + +- ++ + + 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. + + +@@ -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. + + + +@@ -2584,6 +2695,62 @@ + use the output object anymore. + + ++ ++ ++ ++ ++ ++ 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. ++ ++ ++ ++ ++ ++ ++ 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. ++ ++ ++ + + + +@@ -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