1. Handle cursor scanout as well
2. Add set_android_surface_position to handle cursor move event
Bug: 327559087
Test: check cursor in vm
Change-Id: I5429cb88a0f7983df015e05745070bf71f7c15ad
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5569432
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Jiyong Park <jiyong@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Ensure that every Cargo.toml dependency on a third-party crates.io crate
specifies at least a major version, or a minor version for 0.x crates,
to ensure that if a new major version is published, it cannot cause API
breaks.
The versions are selected to match the ones already in Cargo.lock, so
this should have no functional change, but it will help prevent new "*"
versions from being introduced via copy-and-paste.
For rationale, see the Cargo FAQ:
<https://doc.rust-lang.org/cargo/faq.html#can-libraries-use--as-a-version-for-their-dependencies>
`minijail`, `audio_streams`, and `cras` are left as "*" for now, since
they have unusual situations (imported from a submodule and/or replaced
at build time with ebuild magic).
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=verify Cargo.lock is unchanged
Change-Id: Ifa18199f812f01d2d10bfb4146b3353c1a76527c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5555656
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
GFX work often requires review from domain expers, but until now we have
not formally enumerated this list.
BUG=b:328338772
TEST=n/a
Change-Id: If71c03270df675d43049c95491f91a5229ca05b5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5437463
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
This parameter specifies the max number of concurrent crosvm
displays we support. By default, it will be VIRTIO_GPU_MAX_SCANOUTS
(i.e. 16). Different products may choose different upper bounds,
but it should never exceed VIRTIO_GPU_MAX_SCANOUTS. For Windows,
this defines the max number of concurrent windows.
BUG=b:332910955
Change-Id: I9127133e444063f791bc01715ef9a383fc8b9ee6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5426762
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
This change refactors the C interface between crosvm and the android
display backend which is designed to be implemented outside of crosvm.
The below is a few important changes:
* The new interface allows crosvm to draw directly on Android surface.
Previously, we allocated a framebuffer in crosvm, let crosvm draw on
it, and passed it to the Android-side backend where the framebuffer
is copied to Android surface using CPU.
* Respect stride set by Android. When a buffer is created on the Android
side, the stride is usually set to a multiple of 16 for maximum
performance. This change reports that stride back to crosvm so that it
can respect the stride. Previously, we used a stride value that is equal
to the screen width which may not be multiple of 16.
* The error callback function pointer is passed to the Android side only
when the context is created. The Android side is expected to keep the
pointer along with the context and use it when something goes wrong.
Bug: 331900473
TEST=./tools/presubmit
Change-Id: I3e5b05407c41413ea55bba37cb7f34f504799734
(cherry picked from commit 4e5494276d9736fa697bcd3e62207f8708b1c0a4)
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5446565
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
"width" and "height" are removed from the interface since they can
be derived from DisplayParameters.
Windows implementation was assuming only one display, so
DisplayParameters was passed in with GpuDisplay::open_winapi() and
assumed not to change. To support multi-display, it needs to be
passed in every time we create a new surface. This should make no
functional change to other platforms.
BUG=b:332910955
Change-Id: I32767a37c8a1f50716190e13aa94c9c159db3d04
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5041413
Reviewed-by: Jason Macnak <natsu@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Previously, the X display window did not have a title. Set it to
"crosvm" to match the Wayland display and make it easier to find when
switching windows.
BUG=None
TEST=tools/examples/example_desktop
Change-Id: I4fc2b2bfdb6e4dd008b3a1f274a6c0b4eb6d020d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5402949
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
This change introduces two features:
* android_display and
* android_display_stub
The android_display feature adds a new GPU display backend for Android
which emits the display output to an Android surface. The surface is not
created by the backend itself, but by an external entity (ex: Android
app) by creating a SurfaceView. This allows us to display a VM anywhere
the app is shown.
The owner of the surface (the app) is expected to share the surface with
the new backend by calling an AIDL method that the backend will
implement. The AIDL service implementing the method will be registered
to the service manager using the name set via the cmdline option
--android-display-service NAME.
This CL however doesn't include the implementation of the AIDL service
because upstream crosvm doesn't support building an AIDL service and
Android-specific libraries like libnativewindow. Instead, the
android_display_stub feature provides a no-op stub for the AIDL service,
so that we can at least build the rest of the new display backend.
TEST=cargo build
TEST=cargo build -F android_display,android_display_stub
TEST=./tools/run_tests
TEST=./tools/run_tests -F android_display,android_display_stub
TEST=./tools/presubmit
Bug: 325929966
Change-Id: I24f672beaa4a28253f150306a64df34f4962361e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5390926
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jiyong Park <jiyong@google.com>
Use zerocopy functions directly instead. This is a step toward replacing
our data_model crate with standard crates.io functionality where
possible.
BUG=b:312312646
TEST=tools/dev_container tools/presubmit
Change-Id: I9717edce6fe2b4ca53ad9043db61de2e9bc55b78
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5046345
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Add a new vulkan interface to GpuDisplay and GpuDisplaySurface, and
implement the new interface for GpuDisplayWin using VulkanDisplay.
Test: ran emulatorNexusHwcTest
Change-Id: I241af4edaae7c5d5d99f6b27fb2a7448b9a1b321
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5214575
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
The event device type was missing, which makes it a hassle to determine
the type (it can be done from the index). Our path for reading events
also threw away the underlying error, which makes debugging pretty
tricky. This CL fixes both issues.
BUG=b:324486429
TEST=builds
Change-Id: Ie42c065fc6b35c9195db136b94e8831d82c8a23e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5351358
Reviewed-by: Pujun Lun <lunpujun@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The lazy_static crate should not be used in crosvm (it has been replaced
with once_cell in https://crrev.com/c/3707624), and sync::Mutex can be
statically initialized now (https://crrev.com/c/5318701), so the lazy
initialization is not even necessary.
Additionally, the once_cell dependency was unnecessarily reintroduced;
it is unused, so it can be removed from Cargo.toml (again).
Change-Id: I263d856e72dbf531ab25595c60f9e88aba9e321f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5342656
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Implementation of PostResource and the vulkan calls that blit the image
to the swapchain image.
Test: build
Change-Id: Ib76043ee30e1ef4ff5f1da77bbb2d2548e7af681
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5214573
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Mateusz Przybylski <mprzybyl@google.com>
The post worker is responsible for actually posting images to the
display when `post` is called. The image supplied to `post` is copied to
the swapchain image (via a blit operation) and then the swapchain image
is queued for presentation to the display.
Test: build
Change-Id: Ief7bb4aed9b33d3fab48696193d6a3bb438dbf24
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5214572
Reviewed-by: Mateusz Przybylski <mprzybyl@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Implement the top level types of vulkan display, including
VulkanDisplay and VulkanState and VulkanStateBuilder.
Test: build
Change-Id: I8bf7113d14219500f7a1388bc8ebb73f89bc8d09
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5214570
Reviewed-by: Mateusz Przybylski <mprzybyl@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
This is a new display path for creating vulkan-based surfaces.
Test: build
Change-Id: I28e3b455ed265b615c4f8fe7c6ac28e2da81ec2e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5214569
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Example command:
crosvm gpu set-mouse-mode <control_socket_path> \
--display-id=0 \
--mouse-mode=relative
This enables the Windows implementation to toggle mouse capture
mode (touchscreen <-> relative). It will have no effect if the
specified "display-id" doesn't point to an existing guest display
associated with an in-use host display.
BUG=b:324087519
TEST=presubmit
Change-Id: I9e513eb692d4b9cba66eb1e629ab8f7018645059
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5319794
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
MouseInputManager supports touchscreen mode and relative mode (i.e.
captured mouse cursor). The relative mode uses Windows raw input
events. Since only one window in an application can receive those
events, we register the raw input device with the MessageOnlyWindow
and reroute the raw input events to the current foreground GUI
window.
BUG=b:254702853
TEST=presubmit
Change-Id: I18e4d62777bdf0e7d39267426d1301fa6211af31
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5318692
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
We will create per-scanout touchscreen devices to support multi-window.
DisplayEventDispatcher is updated to manage multiple device ids for one
kind of event devices, and GuiWindow needs to be passed around in
KeyboardInputManager and MouseInputManager to provide the scanout id
when we need to dispatch events to the guest.
BUG=b:254702853
TEST=presubmit
Change-Id: Ie40d2e67bab3a564b17c41555f4ba235993b0e19
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5318691
Reviewed-by: Richard Zhang <rizhang@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Missed these since they used the fully qualified sync::Mutex instead of
just Mutex.
Change-Id: I20748fa4a1271ce3b89e576e9c0925ab894104bc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5321445
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Frederick Mayle <fmayle@google.com>
1. Introduced two structs for window management:
a. WindowResources: a host window that isn't currently used (no
Surface associated).
b. WindowMessageProcessor: a host window associated with a guest
display/Surface.
2. Enabled WindowMessageDispatcher to manage multiple
WindowResources and WindowMessageProcessors.
3. Enabled adding/removing multiple Surfaces. See the CreateSurface
and ReleaseSurface commands in DisplaySendToWndProc.
BUG=b:254702853
TEST=presubmit
Change-Id: I5940a597e00f58dfb99b43149d72a7e36f196f7e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5286460
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
There don't appear to be any new clippy warnings, and this is the
version of Rust that Android is now using: b/303252546. Work for the
next version is tracked in b/310977762.
This doesn't have any particular features I'm looking for (async traits
only come in 1.75.0). I'm not particularly attached to this change. If
it's easy to upgrade the container though, we could ensure no new clippy
warnings appear.
Android rust versions appear here:
https://cs.android.com/android/platform/superproject/main/+/main:prebuilts/rust/linux-x86/
Also not sure what the ChromeOS release schedule is.
Release docs: https://releases.rs/docs/1.73.0/
Test: tools/dev_container --clean bash -c "rustc --version && tools/presubmit clippy"
Change-Id: I2d3010c3032053709f0c0beb7dcbe2b80d782415
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5201659
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
GpuDisplay::create_surface() and GpuDisplay::set_scanout_id() were
called back-to-back. To support multi-display on Windows (where
host windows are associated with scanouts), it makes more sense to
pass in the scanout id when creating the surface so that we can
immediately use it for routing input events. This shouldn't affect
other platforms.
BUG=b:254702853
TEST=presubmit
Change-Id: I0c4081107706420492465e755f9440f3c4363b78
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5273974
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
This is where we process host display events, such as window size
change and mouse input events. MouseInputManager etc are currently
no-op. Their implementation will be added later.
BUG=b:306024335
Change-Id: Ib67fd64894bd8c9f47cf2ee3cdf2a20901defe3b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5053935
Reviewed-by: Richard Zhang <rizhang@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
IoBuf is defined in a platform-specific way (it is either iovec on unix
or WSABUF for windows), so it fits into the mission statement of the
base crate, which is meant to be *the* platform abstraction layer in
crosvm.
IoBufMut and VolatileMemory/VolatileSlice are defined in terms of IoBuf,
so they are also moved into base for consistency. Every crate that uses
these types already depended on base, so no extra dependencies are
added, and a few can be removed.
BUG=b:312312646
TEST=tools/dev_container tools/presubmit
Change-Id: I4dddc55d46906dfc55b88e8e6a967d7e1c1922dd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5046605
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
It will be used in the upcoming Windows implementation. The
behavior should remain unchanged for other platforms.
BUG=b:306407787
Change-Id: I7f925055e2d3d9e03f64096cbf590c7ac897a00c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5028148
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
The WindowMessage enum covers general window messages that multiple
modules may want to process, such as window manager, input manager,
etc.
After this change, it isn't necessary to have the HandleWindowMessage
trait anymore. It will be nuked in the follow-up CL.
BUG=b:244492422
Change-Id: Ib4d8dfd29ff7d7f55aa2d1f759b091aee32c2cdf
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5002765
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Refactor the build.rs platform detection to explicitly select the
Wayland support code when building for Linux (instead of skipping it
only for Windows).
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=cargo build -p gpu_display --target=aarch64-apple-darwin
Change-Id: I9437acdc2e2439d0da094887a5a8f520f3279399
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5005295
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Cody Schuffelen <schuffelen@google.com>
Move the initialization of input event config to a separate function
to prepare removing the input event config from the GPU config.
Test: flat run emulator and see input functioning
Bug: 291656763
Change-Id: Ic733949a122b0e51fad2794e154511a5f3fb1085
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804702
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
The features we request in gpu_display weren't complete with respect to
the code we were using from dependent crates. This has been fine because
we usually build crosvm as a monolith, but when testing we need the
individual crates to be complete.
Bug: 295082178
Test: nextest -p gpu_display --features=kiwi -E \
'test(can_create_2_window_proc_threads)'
Change-Id: Ib1f6a23149f08124eab3cad56cf9350a570d1c9a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4805406
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
We weren't able to create multiple GuiWindow's and MessageOnlyWindow's
because they will try to register the window class with the same name
every time a window is created.
Move the logic to register window class to window_procedure_thread, and
also register different window classes for different message handlers
because they don't share the same WNDPROC.
Test: cargo nextest run --workspace --features all-msvc64_product_debug gpu_display
Test: flat run emulator
Change-Id: Icaf3596731c7bcdedccfa6d9929bee0d0f63cfb5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804700
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Updates are made to source and documentation.
This more accurately represents the currently supported platforms of
Android/Linux and Windows, without unexpectedly including other
unix-like operating systems.
Command to reproduce:
$ find . -type f -not -path '*/\.git/*' | xargs -I {} sed -i 's/cfg(unix)/cfg(any(target_os = "android", target_os = "linux"))/g' {}
$ cargo fmt
md files manually updated to fix line lengths.
Renaming `unix` modules to `linux` will be done in a later CL.
Test: ./tools/dev_container ./tools/presubmit
Bug: b/298269162
Change-Id: I42c1bf0abf80b9a0df25551613910293217c7295
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4909059
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
zerocopy 0.7.x has finally released as a stable version, uprev it
to allow some remaining structs to be derivable.
TEST=CQ
BUG=b:300969352
FIXED=b:300969352
Change-Id: I90f0dfb09494f875fef1cd11bfcbd48030846092
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4878761
Auto-Submit: Zihan Chen <zihanchen@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.com>
This is to differentiate it from another struct, MessageOnlyWindow.
The only change besides renaming is that the function
get_current_module_handle() is moved out of the impl block of GuiWindow
since it is used by both types of windows.
Bug: 279810202
Test: Ran GPG
Change-Id: Ica607d8e2e8f2e0f0525dd86765c345252042963
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804698
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Thread messages will be dropped when the modal loop is running, meaning
if the user is resizing/moving the window or invoking the window menu,
we will lose input device events or the command to destroy the window.
This CL uses a message-only window as a message router, whose HWND will
be exposed to other threads. Instead of being posted to the WndProc
thread itself, all those thread messages are now posted to this message
router window, so that they will still be dispatched to our wnd_proc
function while the modal loop is running. Other alternatives have been
discussed in b/279810202.
The lifetime of this new window is slightly shorter than that of the
WndProc thread. When we are about to terminate KiwiVM, we will destroy
the GUI window first, and then the message router window. The WndProc
thread will exit after those are done.
Now we have two types of windows in window.rs: MessageOnlyWindow and
Window. The latter one will be renamed to GuiWindow in the follow-up CL.
They implement the common trait, BasicWindow, to provide the basic
functionalities such as exposing the HWND, destorying the window, etc.
Bug: 279810202
Test: Ran GPG and tested basic windowing functionality
Change-Id: I7bff35a9f435d2a4250dcf3aa93b39e0ca64faff
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804802
Reviewed-by: Noah Gold <nkgold@google.com>
Previously all of the zerocopy imports just used "*", but there are
API changes in zerocopy 0.7, so ensure we get a compatible version by
depending on 0.6 everywhere.
This is a no-op since Cargo.lock already specifies a 0.6.x version, but
it will prevent accidentally upgrading to 0.7.x without updating to the
new API.
BUG=b:301283548
TEST=cargo build
Change-Id: Ifd702d982a09b5083dddd666dc6f3052cba22214
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4878502
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This will record the thread/window messages flowing through our message
pump. It could help debug window not responding issues like b/264846691.
TODO(b/252870196):
Add freeze detection and trigger simulated crash reports.
Bug: 264846691
Test: Triggered crash reports and checked the generated traces
Change-Id: If7a9fc4da40ed5b56cb7eff40e2680eccf0c6150
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804800
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Auto-Submit: Kaiyi Li <kaiyili@google.com>
General strategy:
* We only snapshot the state relevant to the virtio-gpu 2d mode
protocol (i.e. scanouts, resources, fences).
* The GpuDisplay is recreated from scratch, we don't want to snapshot
the state of a Wayland socket (for example).
* No state about pending virtio requests needs to be snapshotted
because the 2d backend completes them synchronously.
BUG=b:266514608
Change-Id: I9cfec93b1e4c9bcbb55dca09a19f6fc146db2b54
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4777342
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We need to pass back the `EventDevice`s, otherwise virtio-input devices
will break on suspend.
I've moved the `import_event_device` calls up the stack to reduce the
amount of plumbing required.
BUG=b:266514608
Change-Id: I3decbb472bf66709cb2d3fe766d4bc3701a6a080
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4802512
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
