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>
We found that when we are using a remote desktop, the monitor DPI
reported by GetDpiForMonitor() may not make sense. For example, on
Chrome Remote Desktop we always get 25 DPI, while the standard DPI is
96. Because of that, the calculated guest DPI is also too low, and all
the UI elements in the guest appear very small.
This might be a flaw in Windows Remote Desktop Protocol. As a
workaround, we would just assume the monitor DPI is the standard value
if we find that KiwiVM is running in a remote session.
Bug: 273810154
Test: Ran B* in CRD and checked the Overlay UI size
Change-Id: Ie335fe8df394b19733bbee8f70931c29b836f3d3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804796
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
The downstream also relies on the keycode_converter module to translate
the input events.
Change-Id: I840226246dbf5112837b76ea7ad5677f75a4a5ca
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804692
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
This is used if the start game button is pressed when a game is already
running. The user may hit that button if they have trouble in finding
the game window since it may be behind other windows or minimized. The
BSS will send an empty ShowWindowRequest and we will bring the window to
the foreground. If the window has been minimized, we will need to
restore it first.
Bug: 260061297
Test: Ran GPG and tested this feature
Change-Id: Id7c7253b2d82cddc9670804486d3bfed92379a12
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804691
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Bug: 262705211
Test: ran emulator & verified scroll position is sent to the guest &
that the bug no longer repros.
Change-Id: Iaa8e748aeaa8faea361e7d6deb94fe152824c850
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804795
Reviewed-by: Vikram Auradkar <auradkar@google.com>
`update_virtual_display_projection()` calls into gfxstream, which may
take a long time to finish if we have a hard time acquiring a certain
lock in gfxstream (b/244201551). We will log the elapsed time and create
a B2T2 rule to catch hanging events.
Bug: 244201551
Test: Ran GPG and checked the log
Change-Id: I4055abc77bcbeeea465e6a79353d0e57fbb63acc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4802517
Reviewed-by: Vikram Auradkar <auradkar@google.com>
virtio-input devices can receive events from the guest. Primarily this
is used controlling the numlock, capslock, and scroll lock lights. For
KiwiMouse, we'll be using LED 0 (the numlock LED) to allow the guest to
signal whether the mouse should be captured.
We need the capture information to be communicated from the virtio-input
device to SurfaceInput, but some of the plumbing is missing. Currently
we only support host -> guest data, and not the other way around (at
least in gpu_display_win). This CL adds a route for data to flow from
virtio-input to the gpu_display_win Surface via the
the GPU device worker & GpuDisplay::handle_event_device.
Bug: 239991275
Test: ran emulator & verified events were arriving in
on_handle_event_device as expected.
Change-Id: I7ab8e5ec51f7aa655b2cb44fe38483103388b53d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719210
Reviewed-by: Vikram Auradkar <auradkar@google.com>
After go/playcl/83699, the WndProc thread is the only thread that
accesses this tube, so we could change its type from Arc<Mutex<Tube>> to
Rc<Tube>, so that we no longer need to worry about deadlocking.
This tube was a field of struct DisplayParameters. That struct is used
for CLI arg parsing, however, we don't get this tube from CLI so the
code looks awkward. Besides, DisplayParameters specifies params for each
individual window, but we will likely only have one tube and share it
among multiple windows when we support multi-windowing. So, we can
remove it from DisplayParameters, and WindowProcedureThread will
distribute the clones of the tube to surfaces.
Bug: 257486521
Test: Ran GPG
Change-Id: Ic7adeb4a41c89d79e40820ad4d50e8d85c4e385c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4804685
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
We used to spawn a separate thread to poll gpu_main_display_tube for
messages from the external supervisor, and then wrap those messages in
thread messages (WM_USER_HANDLE_SERVICE_MESSAGE_INTERNAL) that are
posted to the WndProc thread. Now that we have replaced GetMessageW() with
MsgWaitForMultipleObjects(), we can poll that tube and the message queue
at the same time in the WndProc thread, and then route service messages
to WindowMessageDispatcher::process_service_message().
The newly added MsgWaitContext looks similar to EventContext but it is
much simpler, since we don't need to worry about removing handles,
setting timeout, etc. It may get more complex when we start to add more
handles to it (for event devices, etc.), and we might look for ways to
unify the logic with EventContext, but this simple struct should suffice
for now.
Bug: 244489783
Bug: 244491590
Test: flat run emulator
Test: flat run battlestar
Change-Id: I5722523ad1424a1860f2883d33728a1baf9550cc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719209
Reviewed-by: Pujun Lun <lunpujun@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Currently we have two display event loops, one in the GPU worker thread
(mainly used by other platforms; we just poll event devices and the
display closed event there) and one in the WndProc thread (for handling
Windows specific window messages). We are exploring the possibilities of
merging those loops.
MsgWaitForMultipleObjects() allows us to wait for window messages and
other events at the same time. As the first step of our experiments,
we will use it to replace GetMessageW() while keeping everything else
unchanged. Simple performance tests show that there is no regression in
the average latency between we posting a message to the message queue
and we finishing retrieving it from the queue.
Bug: 244489783
Test: Ran GPG
Change-Id: I2ccea348459fa7af0a2ee0ac55e7c817f222a2f6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719208
Reviewed-by: Pujun Lun <lunpujun@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
If PeekMessageW() does retrieve a message, we are responsibe for
dropping it.
Bug: 244489783
Test: Ran GPG
Change-Id: I69250387cc93698513a47d38de52d161a0026692
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4719207
Reviewed-by: Pujun Lun <lunpujun@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
syslog() is used on the error path for wayland display management. On
32-bit arm, the glibc implementation of syslog() uses send(), which
causes a seccomp violation. This was regressed a long time ago and never
found until now.
Fixing syslog() on 32-bit arm requires changes to gpu_device.policy on
32-bit arm (to add send() and socket()), but we'd prefer to call
crosvm's configured logger and drop syslog() anyways, so let's just do
that.
TEST=Run crosvm + glxgears/vkcube
BUG=b:281165392
Change-Id: I69bcf8cf3617d117360c4a255b1cc1234493eccc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4517955
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The code should not depend on xlib::Window being u64 internally (it
could differ on 32-bit platforms), so allow the clippy warning rather
than removing the casts.
BUG=b:276487055
TEST=tools/clippy # with rust 1.68
Change-Id: Iba59c2d4fb940837783679fce81c2b35ed64142b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4390738
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
We are down to only 30 `unsafe impl DataInit` across our repo now!
TEST=CQ
BUG=b:204409584
Change-Id: I1b6cf95b2a15eac194f3b464330009fd898a0bfa
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4356907
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Previously this function will consume 24 bytes from event socket
and try to convert the bytes into virtio_input_event (8 bytes)
using DataInit::from_slice(). from_slice() guards size mismatched
conversion and will always return None and fall into Err branch.
Seems related to crrev/c/2034046
TEST=CQ, input still work running a debian desktop vm
Change-Id: Ib82095fed6ec4591ba170a6a52fe47a61d33e013
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4357923
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.com>
This allows us to print a more useful error message if the
wayland-scanner tool is not present.
BUG=None
TEST=cargo build # with and without wayland-scanner present
Change-Id: I8909e064621cb4d71bc8ec96d76df8a2b4c4fc88
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4294676
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This CL removed many uses of DataInit in devices. Some paddings
are manually added/fixed to allow AsBytes to derive without ABI
changes.
TESTED=CQ
BUG=b:204409584
Change-Id: I1f8c2d5304fc8e685cc3e5166c73481f6a3f78f7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4235224
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Zihan Chen <zihanchen@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
- Rust toolchain is updated to 1.65.0
- Catapult dashboard upload tool is added to dev_container
- Bindgen is updated to latest version to support custom derive
- Derive Eq when PartialEq is derived as required by new Clippy
TEST=CQ, bindgen-all-the-things
FIXED=b:260784028
BUG=b:257303497
Change-Id: I2034cd09e0aed84d4e9b30f2e85d84d94a442ea4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4228427
Auto-Submit: Zihan Chen <zihanchen@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Zihan Chen <zihanchen@google.com>
Instead of configuring which crates to --exclude in
test_config.py, we can use conditional compilation to
exclude code that is not supported on windows.
This allows more fine-grained control and also allows
us to use plain cargo for building without complicated
configuration and exclusions.
BUG=b:265829867
TEST=cargo test --lib --bins --workspace
--target=x86_64-pc-windows-gnu
--features=all-mingw64
Change-Id: I8422c3f08053bc27d9896b220876a56bd25543d6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4165868
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
These should be written as ChromeOS and ChromiumOS (without the space)
to match the updated branding. The copyright headers were already
migrated to the new style (https://crrev.com/c/3894243), but there were
some more instances left over.
BUG=None
TEST=tools/cargo-doc
Change-Id: I8c76aea2eb33b2e370ab71ee9b5cc0a4cfd00585
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4129934
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The simple_open example doesn't work without --features=x, so mark it as
a required feature.
BUG=None
TEST=cargo build -p gpu_display --example simple_open # fails
TEST=cargo build -p gpu_display --features x --example simple_open
Change-Id: Id780d6e56bb8aebd4abfc42f58ab0b49fb524f02
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4068551
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
