| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
|
|
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 <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
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 <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Closes: https://gitlab.freedesktop.org/wayland/wayland/issues/59
|
|
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 <contact@emersion.fr>
|
|
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 <contact@emersion.fr>
|
|
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 <pekka.paalanen@collabora.com>
|
|
Signed-off-by: onox <denkpadje@gmail.com>
|
|
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>
|
|
Unfortunately this hunk fell out during a rebase. Sorry!
Signed-off-by: Daniel Stone <daniels@collabora.com>
|
|
advertise the supported fourcc format modifiers along with supported
formats to the client. the 'modifier' event introduced here is
intended to replace the 'format' event from zwp_linux_dmabuf_v1
version 1.
bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
versions to 3.
v2: specify request name in event description for clarity (Yong Bakos)
v3: grammar fixup (Yong Bakos)
v4: add deprecation warning against 'format' event usage (pq)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
provide a mechanism that allows clients to import the added dmabufs
and immediately use the newly created wl_buffers without waiting on
an event. this is useful to clients that are sure of their import
request succeeding, and wish to avoid the wl_buffer communication
roundtrip.
bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
versions.
v2: specify using incorrectly imported dmabufs as undefined behavior
instead of sending success/failure events. (pq, daniels)
v3: preserve the optional protocol error added in v2 and explicitly
state the outcome of import success or failure (pq)
v4: clarify create_immed failure cases and error codes (pq)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
clearly state the request name in format event to avoid abmiguous
interpretation between 'zwp_linux_buffer_params_v1::create' and
'zwp_linux_dmabuf_v1::create_params' requests.
v2: grammar fixup (Yong Bakos)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Suggested-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Enum entries and message arguments are sometimes preceded by a blank line, but
often aren't.
Standardize the format of the protocol specification by removing blank lines
preceding a list of message arguments and enum entries.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Remove line breaks preceding closing interface tags, to match conventions
in this, and other, protocol xml docs.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Version postfix added to interface names.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
