This is useful for e.g. unit tests.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: Ica409926c9da6c788a60134fa3f609db97f4aaa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983092
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We are using similar structures for describing the planes of a frame in
the decoder and encoder. Consolidate them into a single structure
accessible from the shared format module.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I289c896e022cbb0952a1f2be626b3f8a6caaf13e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983091
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The interface to return the event pipe for a backend currently requires
a &File to be returned, which is not very appropriate since the file
only serves as a proxy to the pipe's file descriptor.
Although libvda uses this structure to return its event pipe, this won't
be the case for all backends, so change the interface to return a
non-owned Descriptor, which is more generic and suitable to the task.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I73dc66ba59e023a77d7b8e0efe533ec7805cf441
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983090
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
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>
The new cras_backend to be implemented will use these functions
BUG=b:179757101
TEST=cargo test
Change-Id: Ie1777d79a16303e562740b2e02f6b509fab4ef92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2993704
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Woody Chow <woodychow@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Updates virtio-gpu frontend to track multiple
scanouts and the resources set for those scanouts.
Adds a --gpu-display command line arg to avoid having
to create a very complicated --gpu string.
BUG=b:173523402
TEST=launch Cuttlefish w/ multiple displays
TEST=(see change series at aosp/1652814)
Change-Id: I73174c11f35f865b8b67ae77d8169d6812f85535
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2836265
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
use_output_buffer() can fail, in which case we won't have processed any
buffer. Increase our ID counter only if we are confident a buffer with
the assigned ID will eventually be delivered.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I37ad68059854182795ff631b3816614058444900
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983088
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
It allows Rutabaga library users to set a fence callback on the
component builder or while creating a context. The handler is
called when a fence is signaled as completed and could
be executed from another thread.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Change-Id: Ia9176bf2f0822a0076bed6a7a09e709b426aa620
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845982
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
The vhost user block device can be started as follows:
```
cargo run --features=block --bin vhost-user-block-device -- \
--file vhost_test.img --socket /tmp/vhost_user_blk.socket
```
Or a read only disk:
```
cargo run --features=block --bin vhost-user-block-device -- \
--file vhost_test.img:read-only --socket /tmp/vhost_user_blk.socket
```
And tested with a crosvm instance as follows:
```
cargo run -- run --disable-sandbox --rwroot debian.ext4 \
-p "console=hvc0 root=/dev/vda rw" \
--vhost-user-blk /tmp/vhost_user_blk.socket bzImage
```
The vhost-user-block device will appear as /dev/vdb.
BUG=b:179755342
Change-Id: Ie8c10dad8978e0f4a381e06576239df1e8174db5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948103
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
These functions will be used from the `vhost_user_devices` code to run
vhost-user block.
Change-Id: I8351a9b0ced1e36a0543096c59560bbd14dba06a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948102
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
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>
Although the current crosvm won't change call fd once it's set, the
vhost-user allows it and QEMU does so.
So, we wrap CallEvent with `Arc<Mutex<...>>` so that we can replace the
fd later.
BUG=b:190450677
TEST=run with QEMU using vhost-user net device
Change-Id: I16cbcd843e370aeaf6b28c8a520b3bfa4a35286b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2950027
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The features bit manipulation was already duplicated and will be needed
again in the vhost_user implementation.
Change-Id: I8a75341053feac8c222c2d959370aa9f32a82258
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948101
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
There is a desire for Wayland and possibly other display backends to
reasonably handle input. Move the event device logic inside the X11
backend up to the common layer to prevent duplication.
The common layer also keeps track of surfaces and external memory
objects to make this easier. The GpuDisplaySurface/GpuDisplayMemory
traits are introduced in case the common layer needs to perform
compositor specific operation.
BUG=b:173630595
TEST=compile and run with X11
Change-Id: Ied060a7cc216ac6c084030aad1fc839c022a3395
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2852523
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
It is inherently racy to wait on a Condvar without first checking if the
condition is already satisfied. Additionally, Condvar::wait can
spuriously return early even when the condition is not satisfied so it
is necessary to check it in a loop.
BUG=b:190444698
TEST=cargo test
Change-Id: If7703c6e8b9015df3c463147f3ad2a1c10c3a7ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2944323
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The resource bridge is only used by 2 methods of Device, so it makes
little sense to have worker maintain it and pass it around. Make it a
member of Device instead.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I5d305177b5fa6d86ee49d404a0fd65ba573578a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932301
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This removes the need to pass the descriptor map as an argument of all
Worker's methods.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: Ide8d1a858bb09f1098a38c49643fdf365ae7aec1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932300
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The command and event queues are not replaced throughout the Worker's
life, and their ownership is given to it when run() is invoked. Make
them members of Worker so we don't need to pass them around with each
method call.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I92441a8be5e9dbc2fdaddc1546632ea404de0aaa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932299
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
A given net device should expose the minimum MTU of all its
tap interfaces. This ensures that the guest won't inadvertently
produce frames that the host will have to drop, if a lower MTU
is in use on the host (common with cellular links).
BUG=b:171098377
TEST=create tap with MTU < 1500 and start crosvm
Change-Id: I6add14b532e4c2d070d2fe4410272421afc1303f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2917620
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
All the members of Worker are currently public to allow users to
build them inline. Use a constructor instead so all members can be made
private.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I093d7e9b9183b46c7ffe6717199e0ed654b6236e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932298
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Support running the wl device as an out-of-tree process. Unlike other
vhost-user devices, this one uses a second socket for additional
wayland-specific messages between the device and VMM. Since
virtio-wayland is not a standardized device and it's likely it will be
merged into the gpu device, it's not worth the effort to try to
incorporate the wayland-specific extensions into the regular vhost-user
protocol.
BUG=b:179755841
TEST=start a crostini vm with a vhost-user-wl device and play
gnome-mahjongg
Change-Id: I455d32393426aff2acd392092ff82f6cc970d903
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2919156
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
BUG=b:179755841
TEST=start a crostini vm with a vhost-user-wl device and play
gnome-mahjongg
Change-Id: I4bbb084eed972e783908b23b37443ebb2f4847ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2919155
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We can directly call pop() in write_event() and return an error if no
item is available. pop() actually does exactly what we were doing, but
makes the code a bit shorter.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I893666de0132f573164687e78fe0ac4e8996da71
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932297
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This will make it easier to run the virtqueues from a vhost-user
process.
BUG=b:179755841
TEST=Start crostini and play gnome-mahjongg.
Change-Id: Ic4132a66ef7718fe85307f5d743110645288967a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2910215
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Currently, the encoder returns an error if no buffer was available to
signal the end of stream after a flush had completed. Fix this
non-compliant behavior by just waiting until the next output buffer is
queued by the client, and returning that buffer immediately to signal
the end of stream.
Since this behavior is also needed for the decoder, and is a workaround
for libvda's inability to signal the last buffer of a stream, make that
functionality available through a new EosBufferManager struct that can
easily be reused and removed.
BUG=b:168750131
BUG=b:186374269
BUG=b:161774071
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch-arc-r.
TEST=android.mediav2.cts.EncoderProfileLevelTest passes 100 times on
eve-arc-r.
Change-Id: Iebac5f3342393cc6763dbeedda041cf0c3983085
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2914232
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
For cross platform purposes, we need to be able to switch out the
implementation of rust-vmm/vhost. To make this easier, this CL moves all
VMM side calls into that crate into VhostUesrHandler. (The device side
calls are already in DeviceRequestHandler, so no further change is
needed there.)
Note that vmm_vhost::vhost_user::message::* are fine to use directly for cross
platform purposes.
BUG=None
TEST=builds
Change-Id: I5252e8522efa61dc773a74889915ec9a7ef58ec5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2913139
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Move all the block related code to a module under virtio.
This is deemed better than manual namespacing with block_....rs
Change-Id: I8543ef0345011679e02d3762ff94729b0a4eb1f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2915763
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
It has taken a while to get the non-async code removed so make the
shared parts explicitly shared instead of duplicated.
Change-Id: I58d092eefad37bc23da80f0ecac394bb6155efc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2910993
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The seq_socket_send() function only requires a non-mutable reference;
drop the mut.
Fixes clippy warning "the function `seq_socket_send` doesn't need a
mutable reference".
BUG=None
TEST=bin/clippy
Change-Id: I517a8d782601f33653db33c201666707beddd5ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2885787
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Make the act of dequeueing the EOS buffer a method of its own, so it can
be invoked from different points of the code.
BUG=b:168750131
BUG=b:186374269
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch-arc-r.
Change-Id: Ic8c2cc118df234093ae15aada0737063c8ad80c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2914231
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Add a default-enabled "usb" feature to allow compiling out the emulated
USB controller and host device provider when not needed (e.g. for
crosvm-direct).
This reduces the crosvm-direct binary size by about 400 KiB.
BUG=b:173824333
TEST=cargo build --no-default-features
TEST=cargo build # ensure xhci controller is added
Change-Id: I1fc0eeb09c647854e5df57cd2fe7e92140256853
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2913136
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace an else block that just returns None with the equivalent use of
the question mark operator, and rewrite the comment that used to be in
the else block to match.
Fixes the clippy warning "this if-let-else may be rewritten with the `?`
operator".
https://rust-lang.github.io/rust-clippy/master/index.html#question_mark
BUG=None
TEST=bin/clippy
TEST=cargo test -p devices
Change-Id: Ifda6d55c16e12fc7939343757d7f2843b4df9b27
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2885784
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Fixes clippy warnings like:
using `clone` on type `...` which implements the `Copy` trait
and
redundant clone
note: this value is dropped without further use
BUG=None
TEST=bin/clippy
TEST=cargo test -p devices
Change-Id: I8c13b79b54265e5527cadcb8a2e9f54419044bcf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2885781
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a constructor for building a VDA-backed encoder instead of requiring
the user to build one.
BUG=b:169295147
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on hatch-arc-r.
Change-Id: I712499904845b3cccb52a3e9e07c87cc1a3c92c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891144
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current generic Worker code is being instanciated once per kind of
video decoder and encoder. This results in quite a bit of duplication to
avoid one virtual call per device event, and also prevents us from
selecting the codec backend dynamically.
Convert that code to use a Device trait object instead for both
simplicity and flexibility.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: I9aacd0286022d9eaa44bd57656d1959de78322a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891143
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Move the backend code into a module of the same name, to mirror the
structure used by the decoder.
BUG=b:169295147
TEST=cargo build --features="video-decoder,video-encoder"
Change-Id: I9175b054811d294c338f8b58961e4b45b10c99ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891142
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
