This is an object which is meant to be acquired/released in response to
user input. Currently, it will inhibit the shortcuts in the display server
if possible.
Some additional things may be added eventually like relative pointers or
similar (by grabbing pointer input).
This is a child widget to the MksDisplay which contains just the paintable
region of the remote screen. Doing so allows us to avoid having to handle
crossing events carefully for things like cursors.
Instead, now the MksDisplay calculates the area for the picture and
allocates it there. The MksDisplayPicture will always snapshot the
paintable using the full area it has been allocated.
Event processing can also largely move into the Picture widget which
simplifies bounds checking.
This has limited functionality because what we really need is support for
wayland!183 as it would only work unsandboxed.
But it provides a convenient abstraction point for implementing that as
well once we have it.
This just starts on the DMA-BUF code and abstracts MksPaintable so it can
encapsulate both MksDmabufPaintable and MksCairoFramebuffer.
Currently, the dmabuf just tailes everything (fully) but we can fix that
with snapshot work stil. Either way, want to get the abstraction landed
first before we dive deeper into that.
We don't need to do this manually now that we have GtkPicture working
correctly with content-fit. We still want to maintain our own widget to
manage things like grabs and all that though.
This adds MksCairoFramebuffer which does tessellation to get damage regions
for the framebuffer. Still some bugs involved, but good enough to get some
bits on the screen which is what I'm looking for right now.
The goal here is to keep the MksPaintableListener inside of MksPaintable
so that we don't have to create API between the two. Additionally, the
MksPaintable can own it's own G-DBus connection as we don't want to share
them for updates with anything else (as they can have large data chunks
coming across).
This is intended to be the software fallback path where we have to take
Update() and Scanout() method invocations from the Qemu instance. It
implements paintable and tries to reuse a backing texture until a threshold
has been met at which point it does a full redraw.
The backing texture is reused between snapshots to increase the chance that
we may skip a followup VRAM upload to the GPU. The damage rectangles will
be re-uploaded each frame. There is some opportunity to optimize that
last part by keeping them around and adding a secondary damage region.
Of course, we would still want things to go the MksDmabufTexture path
when possible.
This is an org.qemu.Listener using the gdbus-codegen generated skeleton as
the parent type.
What will probably happen here, is that we create a MksPaintable which is
given to the listener to call internal API upon.
The paintable code will be a bit more complex than originally anticipated
in that we are going to need to do our own tessellation so that we get
damage regions which are not the whole widget. Very similar to what I did
in the GdkMacosTile for gdk/macos/.
MksScreenAttributes is an opaque type with setters so that we can
potentially extend it in the future without ABI issues.
Furthermore, this adds a configure API for both sync and async to
MksScreen.
Currently, I get NOT_SUPPORTED back from Qemu, but I think that's because
I'm not even past the bootloader/EFI stage for tests.
This changes things to use the object manager to discover the VM instance.
We'll have to add support for other wrappers to use object managers so that
they can be added to the devices list as they are seen.
Adds MksKeyboard and MksMouse types. Setup a MksScreenKind for the
MksScreen based on MksQemuConsole:type property. Currently the keyboard
and mouse are not wired up, but here for scoping out the properties.
This library doesn't do much yet. It contains the scaffolding and the
rough shape of what I think the API should be in mks-types.h. Some of the
types have some skeleton implementation as well to hid the D-Bus API
behind those types.
The next steps are to fill out the other wrapper objects and see what
properties we should expose from the underlying D-Bus proxies.
Along with that, will be a GtkWidget which can have a number of properties
set on it to specify the MksScreen, MksKeyboard, and MksMouse devices. It
may make sense to attach the session + screen to the widget, so that it can
adapt to keyboard and mouse changes though.
