The current approach makes use of
- A tiled rendering to work around gdk_texture_diff only doing pointer
comparaison
- Assumes that we would only recieve a scanout cmd followed by multiple
flush ones
In reality, with virtio-gpu at least, the scanout cmd is always
submitted followed by a flush one containing the damaged region.
With the assumption currently made, we end up creating a new paintable
for every scanout cmd causing a full redraw instead
of only redrawing the damaged areas.
Isntead we create the paintable once and call import whenever
we receive a flush cmd (UpdateDMABUF) so we can properly
pass the damage area when creating a GdkGLTexture making
the tiled rendering no longer needed.
Otherwise the VM would have no idea about the size of the target widget.
To do so, we introduce a ScreenResizer object that remembers the previous
screen attributes as well the next attributes to configure.
Taking care of scheduling resize operations and avoids submitting
the same attributes twice.
Honestly, Qemu *probably* should be calling into us with the cursor after
we connect to get this right, but it doesn't which leaves the user with a
bit of an issue if there is no active cursor.
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.
