wayland-protocols.git/unstable/linux-dmabuf, branch master

linux-dmabuf: Fix a couple of typos

2023-04-18T12:06:04+00:00

There are no interfaces such as zlinux_dmabuf_params and zlinux_buffer_params. Signed-off-by: Vlad Zahorodnii

linux-dmabuf: fix references to tranche_formats

2022-11-14T11:08:21+00:00

Signed-off-by: Manuel Stoeckl

linux-dmabuf: fix typo in dev_t example code

2022-01-17T14:54:49+00:00

dev_t is not a struct, it's a typedef. Signed-off-by: Simon Ser

linux-dmabuf: send protocol error on invalid format/modifier

2021-11-23T08:52:53+00:00

Now that compositors must send INVALID to advertise support for implicit modifiers, we can make it a protocol error to add a DMA-BUF plane with an unsupported format + modifier pair. Signed-off-by: Simon Ser Reviewed-by: Daniel Stone

unstable/linux-dmabuf: add wp_linux_dmabuf_feedback

2021-11-23T08:47:24+00:00

On multi-GPU setups, multiple devices can be used for rendering. Clients need feedback about the device in use by the compositor. For instance, if they render on another GPU, then they need to make sure the memory is accessible between devices and that their buffers are not placed in hidden memory. This commit introduces a new wp_linux_dmabuf_feedback object. This object advertises a preferred main device, a set of preferred formats/modifiers and target devices. Each object is bound to a wl_surface and can dynamically update its feedback parameters. This enables fine-grained per-surface optimizations. For instance, when a surface is scanned out on a GPU the compositor isn't compositing with, the target device can be set to this GPU to avoid unnecessary roundtrips. A feedback object can also be standalone for clients that don't support per-surface feedback. Signed-off-by: Simon Ser Signed-off-by: Leandro Ribeiro Reviewed-by: Daniel Stone Closes: https://gitlab.freedesktop.org/wayland/wayland/issues/59

linux-dmabuf: add note about pre-multiplied alpha

2021-11-10T15:01:34+00:00

Add a note about pre-multiplied alpha for all DRM formats. Include an escape hatch in the spec to allow other protocol extensions to override this. Essentially the same as [1]. [1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/187 Signed-off-by: Simon Ser

linux-dmabuf: clarify what mixed valid/INVALID modifiers mean

2021-03-31T07:24:53+00:00

This commit makes it clear that compositors can send valid modifiers and DRM_FORMAT_MOD_INVALID for a given format. This means that the compositor supports both implicit and explicit modifiers. See the warning further down: > 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. Xwayland already requires compositors to send DRM_FORMAT_MOD_INVALID for importing buffers with an implicit modifier [1]. In a future protocol version, it would be nice to make it a protocol error (or at least a soft failure) to use any format/modifier pair that wasn't advertised. A use-case for this is Vulkan compositors: the Vulkan DMA-BUF extensions require an explicit modifier and cannot import buffers which have an implicit modifier. [1]: https://gitlab.freedesktop.org/xorg/xserver/-/blob/6c51818a0f55282cbe5a870f58ca82ca45ee472d/hw/xwayland/xwayland-glamor-gbm.c#L328 Signed-off-by: Simon Ser

linux-dmabuf: no buffer errors on device disappearance

2021-02-16T09:32:58+00:00

This was prompted by the discussion from https://lists.freedesktop.org/archives/dri-devel/2020-May/266611.html which is not the final wording. When a DRM device is hot-unplugged, particularly if it is the Wayland compositor's compositing GPU, EGL may start returning errors from trying to use the client's dmabuf. Or, if the client is rendering on another GPU which gets hot-unplugged, the dmabuf the compositor already has may start failing. Hot-unplug is an abrupt global action, and there is no way a client or a compositor could ensure they clean up before things start failing. It is not the client's fault, so the client should not get disconnected if already existing wl_buffer objects start failing. This patch add the wording to the protocol to this effect. The intention is that the compositor replaces the failed buffers with some placeholder content. There is no way this could be glitch-free. In its own pace the client should discover the DRM device is gone, clean up, and perhaps use something else. How exactly that should happen depends on the rendering API the client is using. This is a tiny step towards making DRM device hot-unplug not crash applications that wish to handle the unplug gracefully. Signed-off-by: Pekka Paalanen

linux-dmabuf: Add enum attribute to 'flags'

2021-01-05T18:36:32+00:00

Signed-off-by: onox

linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID

2019-05-02T11:30:32+00:00

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 Reviewed-by: Pekka Paalanen Reviewed-by: Simon Ser Reviewed-by: Daniel Stone