crosvm/gpu_display/src/dwl.rs

175 lines
5.6 KiB
Rust
Raw Normal View History

// Copyright 2019 The Chromium OS Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
/* automatically generated by rust-bindgen */
/// @page page_xdg_shell_unstable_v6 The xdg_shell_unstable_v6 protocol
/// @section page_ifaces_xdg_shell_unstable_v6 Interfaces
/// - @subpage page_iface_zxdg_shell_v6 - create desktop-style surfaces
/// - @subpage page_iface_zxdg_positioner_v6 - child surface positioner
/// - @subpage page_iface_zxdg_surface_v6 - desktop user interface surface base interface
/// - @subpage page_iface_zxdg_toplevel_v6 - toplevel surface
/// - @subpage page_iface_zxdg_popup_v6 - short-lived, popup surfaces for menus
/// @section page_copyright_xdg_shell_unstable_v6 Copyright
/// <pre>
///
/// Copyright © 2008-2013 Kristian Høgsberg
/// Copyright © 2013 Rafael Antognolli
/// Copyright © 2013 Jasper St. Pierre
/// Copyright © 2010-2013 Intel Corporation
///
/// 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.
/// </pre>
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct wl_output {
_unused: [u8; 0],
}
#[repr(C)]
pub struct dwl_context {
pub _bindgen_opaque_blob: [u64; 52usize],
}
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct dwl_dmabuf {
pub _bindgen_opaque_blob: [u64; 3usize],
}
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct dwl_surface {
pub _bindgen_opaque_blob: [u64; 12usize],
}
gpu_display/wayland: Added keyboard and pointing devices Added preliminary version of keyboard and pointing device routine for wayland implementation. The pointing input is wired as a multi touch device. Due to the fact that wayland client is callback based, all the necessary incoming events are serialized and stashed in the temp circular buffer and then processed afterwards from the main event loop. Known issues: 1. Mouse input can't be properly wired inside the guest as a mouse device without pointer locking, but this is not what we want. The approach emulates it as a multitouch device, but, of course, it implies limitations in functionality. Limitations include cursor in the VM that doesn't move in unison with the host cursor. 2. I kept the mouse cursor surface since it's not decided yet which approach for handling pointing input device will be used (see #1). Removing the mouse surface in the guest would remove the lagging guest cursor. The alternatives to the multi-touch device are: "- Relative mice (e.g. a typical PC mouse). These are relative devices, meaning they send deltas from the current cursor position. Some apps like games rely on these events. - Touchscreens (multitouch, single touch). These are absolute devices, and are much easier to implement seamless guest/host input for. - Touchpads (these are absolute devices). I'm not sure these are really compelling for any use case." -nkgold@ 3. This code is for POC purpose only, so there are still lot of minor issues and negligence in it. Looking forward for your comments and proposals. BUG=b:177939148 TEST=crosvm $ARGS \ --display-window-keyboard \ --display-window-mouse \ --gpu=3d,glx=false,egl=true \ --wayland-sock=/run/user/1000/wayland-0 \ $OTHER_ARGS Change-Id: If4a9b73b8da4e0cc52fa619bbd6e5588ccdb7874 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2688439 Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Zach Reizner <zachr@chromium.org>
2021-02-02 06:14:16 +00:00
#[allow(dead_code)]
pub const DWL_KEYBOARD_KEY_STATE_RELEASED: i32 = 0;
pub const DWL_KEYBOARD_KEY_STATE_PRESSED: i32 = 1;
#[allow(dead_code)]
pub const DWL_EVENT_TYPE_KEYBOARD_ENTER: u32 = 0x00;
#[allow(dead_code)]
pub const DWL_EVENT_TYPE_KEYBOARD_LEAVE: u32 = 0x01;
pub const DWL_EVENT_TYPE_KEYBOARD_KEY: u32 = 0x02;
#[allow(dead_code)]
pub const DWL_EVENT_TYPE_POINTER_ENTER: u32 = 0x10;
#[allow(dead_code)]
pub const DWL_EVENT_TYPE_POINTER_LEAVE: u32 = 0x11;
#[allow(dead_code)]
pub const DWL_EVENT_TYPE_POINTER_MOVE: u32 = 0x12;
#[allow(dead_code)]
pub const DWL_EVENT_TYPE_POINTER_BUTTON: u32 = 0x13;
pub const DWL_EVENT_TYPE_TOUCH_DOWN: u32 = 0x20;
pub const DWL_EVENT_TYPE_TOUCH_UP: u32 = 0x21;
pub const DWL_EVENT_TYPE_TOUCH_MOTION: u32 = 0x22;
pub const DWL_SURFACE_FLAG_RECEIVE_INPUT: u32 = 1 << 0;
pub const DWL_SURFACE_FLAG_HAS_ALPHA: u32 = 1 << 1;
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct dwl_event {
pub surface_descriptor: *const ::std::ffi::c_void,
pub event_type: u32,
pub params: [i32; 3usize],
}
extern "C" {
pub fn dwl_context_new() -> *mut dwl_context;
}
extern "C" {
pub fn dwl_context_destroy(self_: *mut *mut dwl_context);
}
extern "C" {
pub fn dwl_context_setup(
self_: *mut dwl_context,
socket_path: *const ::std::os::raw::c_char,
) -> bool;
}
extern "C" {
pub fn dwl_context_fd(self_: *mut dwl_context) -> ::std::os::raw::c_int;
}
extern "C" {
pub fn dwl_context_dispatch(self_: *mut dwl_context);
}
extern "C" {
pub fn dwl_context_dmabuf_new(
self_: *mut dwl_context,
import_id: u32,
fd: ::std::os::raw::c_int,
offset: u32,
stride: u32,
modifiers: u64,
width: u32,
height: u32,
fourcc: u32,
) -> *mut dwl_dmabuf;
}
extern "C" {
pub fn dwl_dmabuf_destroy(self_: *mut *mut dwl_dmabuf);
}
extern "C" {
pub fn dwl_context_surface_new(
self_: *mut dwl_context,
parent_id: u32,
surface_id: u32,
shm_fd: ::std::os::raw::c_int,
shm_size: usize,
buffer_size: usize,
width: u32,
height: u32,
stride: u32,
gpu_display/wayland: Added keyboard and pointing devices Added preliminary version of keyboard and pointing device routine for wayland implementation. The pointing input is wired as a multi touch device. Due to the fact that wayland client is callback based, all the necessary incoming events are serialized and stashed in the temp circular buffer and then processed afterwards from the main event loop. Known issues: 1. Mouse input can't be properly wired inside the guest as a mouse device without pointer locking, but this is not what we want. The approach emulates it as a multitouch device, but, of course, it implies limitations in functionality. Limitations include cursor in the VM that doesn't move in unison with the host cursor. 2. I kept the mouse cursor surface since it's not decided yet which approach for handling pointing input device will be used (see #1). Removing the mouse surface in the guest would remove the lagging guest cursor. The alternatives to the multi-touch device are: "- Relative mice (e.g. a typical PC mouse). These are relative devices, meaning they send deltas from the current cursor position. Some apps like games rely on these events. - Touchscreens (multitouch, single touch). These are absolute devices, and are much easier to implement seamless guest/host input for. - Touchpads (these are absolute devices). I'm not sure these are really compelling for any use case." -nkgold@ 3. This code is for POC purpose only, so there are still lot of minor issues and negligence in it. Looking forward for your comments and proposals. BUG=b:177939148 TEST=crosvm $ARGS \ --display-window-keyboard \ --display-window-mouse \ --gpu=3d,glx=false,egl=true \ --wayland-sock=/run/user/1000/wayland-0 \ $OTHER_ARGS Change-Id: If4a9b73b8da4e0cc52fa619bbd6e5588ccdb7874 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2688439 Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Zach Reizner <zachr@chromium.org>
2021-02-02 06:14:16 +00:00
flags: u32,
) -> *mut dwl_surface;
}
gpu_display/wayland: Added keyboard and pointing devices Added preliminary version of keyboard and pointing device routine for wayland implementation. The pointing input is wired as a multi touch device. Due to the fact that wayland client is callback based, all the necessary incoming events are serialized and stashed in the temp circular buffer and then processed afterwards from the main event loop. Known issues: 1. Mouse input can't be properly wired inside the guest as a mouse device without pointer locking, but this is not what we want. The approach emulates it as a multitouch device, but, of course, it implies limitations in functionality. Limitations include cursor in the VM that doesn't move in unison with the host cursor. 2. I kept the mouse cursor surface since it's not decided yet which approach for handling pointing input device will be used (see #1). Removing the mouse surface in the guest would remove the lagging guest cursor. The alternatives to the multi-touch device are: "- Relative mice (e.g. a typical PC mouse). These are relative devices, meaning they send deltas from the current cursor position. Some apps like games rely on these events. - Touchscreens (multitouch, single touch). These are absolute devices, and are much easier to implement seamless guest/host input for. - Touchpads (these are absolute devices). I'm not sure these are really compelling for any use case." -nkgold@ 3. This code is for POC purpose only, so there are still lot of minor issues and negligence in it. Looking forward for your comments and proposals. BUG=b:177939148 TEST=crosvm $ARGS \ --display-window-keyboard \ --display-window-mouse \ --gpu=3d,glx=false,egl=true \ --wayland-sock=/run/user/1000/wayland-0 \ $OTHER_ARGS Change-Id: If4a9b73b8da4e0cc52fa619bbd6e5588ccdb7874 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2688439 Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Zach Reizner <zachr@chromium.org>
2021-02-02 06:14:16 +00:00
extern "C" {
pub fn dwl_surface_destroy(self_: *mut *mut dwl_surface);
}
extern "C" {
pub fn dwl_surface_commit(self_: *mut dwl_surface);
}
extern "C" {
pub fn dwl_surface_buffer_in_use(self_: *mut dwl_surface, buffer_index: usize) -> bool;
}
extern "C" {
pub fn dwl_surface_flip(self_: *mut dwl_surface, buffer_index: usize);
}
extern "C" {
pub fn dwl_surface_flip_to(self_: *mut dwl_surface, import_id: u32);
}
extern "C" {
pub fn dwl_surface_close_requested(self_: *const dwl_surface) -> bool;
}
extern "C" {
pub fn dwl_surface_set_position(self_: *mut dwl_surface, x: u32, y: u32);
}
extern "C" {
pub fn dwl_surface_descriptor(self_: *const dwl_surface) -> *const ::std::ffi::c_void;
}
gpu_display/wayland: Added keyboard and pointing devices Added preliminary version of keyboard and pointing device routine for wayland implementation. The pointing input is wired as a multi touch device. Due to the fact that wayland client is callback based, all the necessary incoming events are serialized and stashed in the temp circular buffer and then processed afterwards from the main event loop. Known issues: 1. Mouse input can't be properly wired inside the guest as a mouse device without pointer locking, but this is not what we want. The approach emulates it as a multitouch device, but, of course, it implies limitations in functionality. Limitations include cursor in the VM that doesn't move in unison with the host cursor. 2. I kept the mouse cursor surface since it's not decided yet which approach for handling pointing input device will be used (see #1). Removing the mouse surface in the guest would remove the lagging guest cursor. The alternatives to the multi-touch device are: "- Relative mice (e.g. a typical PC mouse). These are relative devices, meaning they send deltas from the current cursor position. Some apps like games rely on these events. - Touchscreens (multitouch, single touch). These are absolute devices, and are much easier to implement seamless guest/host input for. - Touchpads (these are absolute devices). I'm not sure these are really compelling for any use case." -nkgold@ 3. This code is for POC purpose only, so there are still lot of minor issues and negligence in it. Looking forward for your comments and proposals. BUG=b:177939148 TEST=crosvm $ARGS \ --display-window-keyboard \ --display-window-mouse \ --gpu=3d,glx=false,egl=true \ --wayland-sock=/run/user/1000/wayland-0 \ $OTHER_ARGS Change-Id: If4a9b73b8da4e0cc52fa619bbd6e5588ccdb7874 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2688439 Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Zach Reizner <zachr@chromium.org>
2021-02-02 06:14:16 +00:00
extern "C" {
pub fn dwl_context_pending_events(self_: *const dwl_context) -> bool;
}
extern "C" {
pub fn dwl_context_next_event(self_: *mut dwl_context, event: *mut dwl_event);
}
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
extern "C" {
pub fn dwl_surface_set_scanout_id(self_: *mut dwl_surface, scanout_id: u32);
}