Introduce a display subsystem for GPU output #319
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mtjhrc
force-pushed
the
gtk-display
branch
4 times, most recently
from
d7deac6 to
056b470
Compare
This is similar concept to the mpsc::channel but uses an EventFd to notify the reader when data is availible. This seems like it could be generally useful, when we need to use Epoll to also wait for other file descriptor events. This is just a simple implementation using EventFd and could maybe be optimized. (maybe even using a unix pipe directly) Signed-off-by: Matej Hrica <[email protected]>
We wrongly expected an extra virtio_gpu_ctrl_hdr for VIRTIO_GPU_CMD_GET_DISPLAY_INFO The command doesn't have any body and we have already read the ctrl_header. Signed-off-by: Matej Hrica <[email protected]>
mtjhrc
force-pushed
the
gtk-display
branch
4 times, most recently
from
dbb85d3 to
ee15200
Compare
Introduce a DisplayBackend trait and a DisplayBackendNoop implementation. Hook up the gpu device to use the display backend. For now this only hooks up the simplest and slowest option of display output - the output is copied to the CPU using the transfer_read operation and passed to the display backend. The DisplayBackendNoop doesn't provide any displays, so this doesn't display anything yet. Introduce a new public API function krun_set_display() for configuring VM displays. The virtio-gpu code is based on rust-vmm/vhost-device-gpu. Signed-off-by: Matej Hrica <[email protected]>
Add a DisplayBackend implementation using GTK. This also introduces a new public API function krun_set_display_backend_gtk() for enabling the gtk display backend. Signed-off-by: Matej Hrica <[email protected]>
The --display option can be provided multiple times. Specyfing at least one display automatically enables the GTK display backend. Signed-off-by: Matej Hrica <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds initial support for the more traditional display output from the VM by basically having virtual displays (until now we only had cross-domain/wayland).
This implementes 2 display backends:
DisplayBackendNoop- used by default, pretty much returns an error for every operationDisplayBackendGtk- implementation using GTK (works on Linux, to be tested on macOS)This introduces 2 new public API function:
int32_t krun_set_display_backend_gtk(uint32_t ctx_id)int32_t krun_set_display(uint32_t ctx_id, uint32_t display_id, uint32_t width, uint32_t height)Current limitations to be addressed by future PRs:
You can test this using the newly added
--displayoption inchroot_vmand running something graphical in the guest - the simplest option is probablykmscube:$ ./chroot_vm --display=0:1920:1080 rootfs_fedora kmscube