- 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>
Let's remove the tubes:
1) gpu_device_service_tube - We diverge downstream nearly everywhere due
to other tubes passed just like it. Reducing merge conflicts should
happen maybe via structs, but we are already paying the cost anyway
when code changes next to this tube (due to the other differing args)
2) gpu_main_display_tube - We will be moving this to the wndproc thread
when upstreaming further work on it, so there is no need to keep the
old version around.
BUG=b:243061269
TEST=presubmit, cargo build
Change-Id: I241922952d34a212dcb412bc1f0391f8473d8a61
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4033254
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Pujun Lun <lunpujun@google.com>
Commit-Queue: Idan Raiter <idanr@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We do receive WM_ENTERSIZEMOVE when the window is about to be resized or
moved, but it doesn't tell us whether resizing or moving should be
expected. We won't know that until later we receive WM_SIZING or
WM_MOVING. There are also corner cases where we don't receive either
WM_SIZING or WM_MOVING in the modal loop, or receive both of them.
This CL adds an enum SizeMoveLoopState to track this state, so that we
can know whether the window is resizing or moving.
One alternative is to use WM_NCHITTEST to test whether the cursor is on
the window title bar (which implies moving the window) or window
borders/corners (which implies resizing) when WM_ENTERSIZEMOVE is
received. However, the user may also trigger resizing/moving from the
system menu (e.g. by right-clicking on the title bar and selecting it
from the drop down list), so this is not always reliable.
BUG=b:254702853
TEST=Tested in the Windows downstream
Change-Id: I8c8d97a7542b291c57dbddb75d785b324ff2776e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3975933
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The Windows official doc suggests that, "New Windows applications
should use Unicode to avoid the inconsistencies of varied code
pages and for ease of localization".
BUG=b:254702853
TEST=Tested in the Windows downstream
Change-Id: I159263d21ff5e9900c4bb79fe17bd0aa3aedae0d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3971022
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Trying to reconcile the difference between the linux and windows
implementations.
Code relying on the eventfd count must now use the linux specific
`EventExt` interface.
BUG=b:231344063
TEST=presubmits
Change-Id: I14eb50f7a02d766a00f27aca388823309633e193
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3864030
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
This replaces the handwritten arg parser with the serde_keyvalue
based parser. Eventually we will unify the arg parsing with Unix.
BUG=b:233676779
TEST=cargo b --features all-msvc64,gpu --no-default-features
TEST=cargo t -p vm_control --features all-msvc64,gpu
--no-default-features
TEST=cargo t -p crosvm sys::windows::config::
--features all-msvc64,gpu --no-default-features
Change-Id: I36a563be9767c7e5cbd3ab44f6a9ba23cd64cdb6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3939033
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
1. gpu_control_tube is not used on Windows yet. We will make use of
it and test it in the downstream first before removing the Unix
feature flag.
2. In Gpu::keep_rds(), skip appending descriptors of stdout and
stderr since it is hard to find such descriptors on Windows, and
this function won't be called on Windows anyways.
3. Some functions in gpu_display should be guarded with gfxstream
feature flag, since we don't need to link against gfxstream
binary when we are building/tesing without gfxstream.
BUG=b:213149288
TEST=presubmit
Change-Id: I28c3d16d82916e6d4a542aa008dd09015141716c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3947825
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Fix a few stray references to "CrosVM" and "CrosVm" so that we refer to
the crosvm project with consistent capitalization.
BUG=None
TEST=None
Change-Id: If5c3c131774d6e5da1d27466810642aec3cb42ac
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3938640
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This function has no call site so we might remove it to simplify
the code.
BUG=b:213150276
TEST=presubmit
Change-Id: I7c74c91de224cbccecd307c7774a15145d12433e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3930937
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
We were busy-waiting on atomic variables for the message loop
state of the WndProc thread. That is to make sure other threads
don't start posting messages to the WndProc thread until the
latter has created the message queue and is about to enter the
message loop. We can use mpsc channels instead. The WndProc
thread notifies other threads that it is ready by sending out its
thread ID.
BUG=b:243184256
TEST=tested in downstream
Change-Id: Ia2a675c083bb6aa9046dd9eab932a95fa06b8709
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928133
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
We were busy-waiting on atomic variables for surface creation
results. We can use mpsc channels to avoid that, which also
eliminates the need for enum CreateSurfaceResult since we just need
to send booleans.
BUG=b:243184256
TEST=tested in downstream
Change-Id: If4c39c797f9ca9edf3695e44689904066546759f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928131
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Notable changes:
1. Use "W" methods during window creation and message dispatching
to ensure unicode characters are sent to the window.
2. In DisplayEventDispatcher::dispatch(), filter() and map() will
be ignored if we don't call collect(). We replace map() with a
for loop to make this clearer.
Other changes are due to linter/formatter warnings, etc.
Bug=b:213150276
TEST=cargo b -p gpu_display --features win64 --no-default-features
Change-Id: I767aec208d8afd7d7cb86039d08ba8ec8369da81
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3913991
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
On Windows, we have to create a GUI thread that creates the window and
retrieves window messages from the thread-specific message queue created
by the system. All host events, such as window resizing and mouse and
keyboard events, are sent in the form of window messages. Hence, we
created these structs/traits to model it:
- `Window`: Owns the handle of one window, and provides helper functions
for operating on this window.
- `HandleWindowMessage`: A trait implemented by the struct that
processes host events. In our case, that is the surface.
- `WindowMessageProcessor`: Holds one `Window` object and one
`HandleWindowMessage` trait object. We only support one window for
now. Once we support multi-windowing, there will be multiple
processors.
- `WindowMessageDispatcher`: A singleton, responsible for dispatching
messages retrieved from the message queue to the targeted processor.
- `WindowProcedureThread`: Wraps the GUI thread, retrieves messages from
the message queue and forwards them to the dispatcher. It also
provides helper functions for other threads to talk to the GUI thread.
- `MessageRelayThread`: Relays service messages to the GUI thread.
Main difference from other platforms: event devices are imported to the
GUI thread, since all host events are processed there.
BUG=b:213150276
TEST=presubmit
Change-Id: I0aabf6adf8a9ff4b24375e9c7df7625b6f761c7a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3834009
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
