Set cursor to none (i.e., hide it) on init.
Otherwise, in cases where the define_cursor
signal is not received (e.g., atomic kms),
there are two cursors painted on the Widget
display.
Signed-off-by: Albert Esteve <aesteve@redhat.com>
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.
