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.
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.
