crosvm/gpu_display/protocol/virtio-gpu-metadata-v1.xml

75 lines
3.4 KiB
XML
Raw Normal View History

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-05-21 16:33:27 +00:00
<?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>