Commits on Source (11)
-
Alexandros Frantzis authored
Add opaque EGL buffers to the supported buffer types for use with the explicit synchronization protocol. Opaque EGL buffers rely on the same EGL implementation in both the compositor and clients, which makes it straightforward to manage client expectations about fence support for such buffers. Also make it clearer that implementations are free to support other buffer types beyond the required ones. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
Alexandros Frantzis authored
Graphics APIs are expected to use this protocol under the hood, and since there can only be one user of explicit synchronization per surface, warn about using the protocol directly in such cases. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
Alexandros Frantzis authored
Clarify that after zwp_buffer_release_v1 events, otherwise unused buffers can be reused without any additional implicit synchronization. This is in contrast to wl_buffer.release, which doesn't guarantee that implicit synchronization is not required to safely use a buffer after the event is received. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
Sebastian Krzyszkowiak authored
Signed-off-by:
Sebastian Krzyszkowiak <dos@dosowisko.net> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
Chia-I Wu authored
DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf. It provides legacy support and makes it easier to replace wl_drm. v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which requires a version bump) v4: no version bump, but a note for now Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Daniel Stone <daniels@collabora.com>
-
Jonas Ådahl authored
As requested by Mike, update the E-mail address listed in the README. Signed-off-by:
Jonas Ådahl <jadahl@gmail.com>
-
Simon Ser authored
This commit makes it so a wl_output.done event is guaranteed to be sent with a xdg_output.done event. This protocol change has been discussed in a recent xorg-devel discussions [1]. First let's recap why a change is needed: Xwayland listens to both wl_output and xdg_output changes. When an output's properties change, Xwayland expects to receive both a wl_output.done event and an xdg_output.done event. If that's not the case, Xwayland doesn't update its state (so old state is still exposed to X11 clients). Most of the time, both objects will be updated at the same time (e.g. the current mode is changed, so both wl_output.mode and xdg_output.logical_size are sent) so this won't be an issue. However in some situations only one of wl_output or xdg_output changes. For instance: - The mode is changed at the same time as the scale, resulting in the same logical_size. - The compositor doesn't expose the outputs' position via wl_output, so whenever the position changes only xdg_output is updated. Both KDE [2] and wlroots [3] have experienced this issue. For this reason, I'd like to update the xdg-output protocol to make it mandatory to always send a wl_output.done event after xdg_output changes. This effectively makes wl_output.done atomically apply all output state (including the state of add-on objects like xdg_output). This approach is pretty similar to wl_surface.commit: this request will atomically apply surface state including the state of e.g. the xdg_surface object tied to the wl_surface. To update the protocol to reflect this new requirement we can either: - **Bump xdg_output version**. The current protocol doesn't specify that wl_output.done must be sent, adding this new requirement would be a breaking change. We need to fix Xwayland for the current xdg_output version (maybe make it non-atomic for the current version, atomic for the new one?). Should we deprecate xdg_output.done in the new version? - **Don't bump xdg_output version**. This clarifies what is expected in practice by Xwayland, a major xdg_output consumer, and what is currently implemented by all compositors. There's one issue with the "don't bump" approach: indeed in practice compositors always send wl_output.done and xdg_output.done in pairs, however the ordering between those two events is not guaranteed. This means some compositors might send this sequence: wl_output.geometry(…) wl_output.done() xdg_output.logical_position(…) xdg_output.done() In this case the wl_output.done event fails to atomically apply the xdg_output state. For this reason, I think bumping the version is a better approach. This commit also deprecates xdg_output.done, which doesn't have any purpose anymore. [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html [2]: https://phabricator.kde.org/D19253 [3]: https://github.com/swaywm/sway/issues/4064 Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Jonas Ådahl <jadahl@gmail.com>
-
Simon Ser authored
This allows clients to destroy a gesture object before they disconnect. The request isn't named "destroy", as this would conflict with wayland-scanner's auto-generated destructor (which just destroys the client-side object without sending any request). Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Jonas Ådahl <jadahl@gmail.com>
-
Jan-Marek Glogowski authored
LibreOffice is one big binary with explicit brandings for different application modules. This is represented in X11 by a different WM_CLASS setting for a window. The WM_CLASS is changed based on the loaded document at runtime. As a result LibreOffice already offers multiple desktop files with different icons, StartupWMClass entries and application names. This amendment of the set_app_id request just explicitly specifies the use case to change a surfaces' app ID at runtime, so a compositor implementor is made aware of it. Just as the WM_CLASS, a change of the app ID should result in an update of the propertes of a surface depending on the app ID, like the window icon specified in the desktop file or a re-grouping of the surfaces in a task manager. Signed-off-by:
Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by:
Jonas Ådahl <jadahl@gmail.com> Reviewed-by:
Simon Ser <contact@emersion.fr>
-
Simon Ser authored
The output description is a human-readable text describing the output. Unlike the name which uniquely identifies the output, it's intended to be displayed to the user. It might be desirable for a compositor to update an output's description. For instance, when only one output is plugged in, it's not necessary to dump make, model, serial and connector to the description, something like "Dell U2717D" is enough. However when two identical outputs are plugged in it's necessary to add e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1] for a discussion about this. This commit bumps xdg_output's version to allow compositors to update the property. [1]: https://github.com/swaywm/wlroots/issues/1623 Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Jonas Ådahl <jadahl@gmail.com> Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
-
Jonas Ådahl authored
Signed-off-by:
Jonas Ådahl <jadahl@gmail.com>