crosvm/gpu_display/protocol/virtio-gpu-metadata-v1.xml
Jason Macnak 114d7d7ccd gpu_display: Add opt wayland ext for sending scanout id
Cuttlefish's streaming server, which acts as a Wayland compositor
in order to receive display framebuffers from Crosvm, needs some
mechanism to tell which Wayland surface corresponds to which display
(a "display" is a "scanout" in virtio-gpu terminology).

Wayland object ids can not be directly used for this as all Wayland
objects share a single global id space (so the first created Wayland
wl_surface surface object may have id = 15).

Previously, the case of unchanging displays was handled by enforcing
the creation order of surfaces within Crosvm so that Cuttlefish's
streaming server (which is a Wayland compositor) could assume the
creation order corresponded to the display order. However, this still
experienced issues (b:186580833) when surfaces were destroyed and
later recreated when handling `set_scanout(..., resource_id = 0)`
commands.

There is also an ongoing effort to support adding and removing
displays at runtime in (see aosp/1671968) which experiences the
same issue. When surfaces are arbitrarily created and destroyed,
Cuttlefish's streaming server has no way to determine which Wayland
surface corresponds to which display.

To solve all of this, this change introduces an extension to allow
Wayland clients (Crosvm) to attach additional metadata (scanout_id)
to Wayland objects (surfaces) so that Wayland compositors (Cuttlefish's
streaming server) can exactly determine which surfaces correspond
to which displays. I will attempt to upstream this protocol (tracked
in b:191901112).

BUG=b:188904670
BUG=b:187351899
BUG=b:191901112
TEST=launch Cuttlefish with single display
TEST=launch Cuttlefish with multiple displays
TEST=launch Cuttlefish and hotplug some displays

Change-Id: I2aa4b714a49e4d85b6a3c705ba0d5bc1720b838e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2909903
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
2021-06-30 02:22:14 +00:00

75 lines
No EOL
3.4 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<protocol name="wp_virtio_gpu_metadata_v1">
<copyright>
Copyright 2021 The Chromium Authors.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
</copyright>
<interface name="wp_virtio_gpu_metadata_v1" version="1">
<description summary="attach virtio gpu metadata">
The global interface which allows attaching virtio-gpu metadata
to wl_surface objects.
</description>
<enum name="error">
<entry name="surface_metadata_exists" value="0"
summary="the surface already has a metadata object associated"/>
</enum>
<request name="get_surface_metadata">
<description summary="extend surface interface for attaching metadata">
Instantiate an virtio_gpu_surface_metadata_v1 extension for the given
wl_surface to attach virtio gpu metadata. If the given wl_surface
already has a surface metadata object associated, the
surface_metadata_exists protocol error is raised.
</description>
<arg name="id" type="new_id" interface="wp_virtio_gpu_surface_metadata_v1"
summary="the new metadata interface id"/>
<arg name="surface" type="object" interface="wl_surface"
summary="the surface"/>
</request>
</interface>
<interface name="wp_virtio_gpu_surface_metadata_v1" version="1">
<description summary="interface to attach virtio gpu metadata to a wl_surface">
An additional interface to a wl_surface object, which allows the
client to attach additional metadata to the surface.
If the wl_surface associated with the virtio_gpu_surface_metadata_v1 is
destroyed, all virtio_gpu_surface_metadata_v1 requests except 'destroy'
raise the protocol error no_surface.
If the virtio_gpu_surface_metadata_v1 object is destroyed, the metadata
state is removed from the wl_surface. The change will be applied
on the next wl_surface.commit.
</description>
<enum name="error">
<entry name="no_surface" value="0"
summary="the wl_surface was destroyed"/>
</enum>
<request name="set_scanout_id">
<description summary="set the virtio gpu scanout id of the surface">
Set the virtio gpu scanout id of the associated wl_surface.
</description>
<arg name="scanout_id" type="uint" summary="virtio gpu scanout id"/>
</request>
</interface>
</protocol>