This allows setting a customizable trigger which may be used to ungrab
the display. Currently, the default is ctrl+alt+g and the only thing that
will be released is the shortcut inhibition.
This will allow us to receive input like Super for the activities overview
while the widget is active.
We still need a way to release the grab, but that will come soon.
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).
It's really annoying when a touchpad doesn't work at all in a MKS session.
So instead of doing nothing, at least try to send a wheel event so that
some amount of scroll may occur.
Eventually, we need a real touchpad D-Bus interface to deliver events.
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.
We may need to tweak this for relative mouse positions if we find we dont
get reliable information from the peer. But this is a start, which I see
we get back from Qemu at least when we're in -enable-kvm mode.
Now that we are doing our own paintable management, we can more easily
transition to doing our own event management with the Legacy event
controller (which, despite the name, really just allows us to get more
direct GdkEvent for processing).
Additionally, this adds support for scroll events to the guest.
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.
We want a bit more control over things than we can get with GtkPicture so
do the snapshot/measure internally. This allows us to know where the
picture is to be allocated so that we can translate pointer events to the
location within the console.
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 need to handle a mouse that is not absolute positioned (the default it
seems) and this does that (crudely for the moment until we have some sort
of grab management).
Additionally, click events are propagated to the Qemu instance as well.
We don't want to go through get_bytestring() as this is a bit cleaner as
to ensure we're holding onto references for the rest of the function
lifetime. Otherwise, completing the operation could cause our parameters
to be released (at least theoretically).
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.
Because the other side is doing AUTHENTICATION_SERVER, which really it
has no business doing any flags, we have to connect asynchronously or we'd
block because it doesn't yet have our FD to communicate with.
So connect asynchronously, return our FD, and then process from there.
This is somewhat annoying because it means you can't connect your
object until the otherside already sees our connection. We delay message
processing to help with that though.
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.
