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.
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 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 ultimately going to give us back a paintable, but it's only in
partial state right now. We need to figure out the right semantics for
ownership between the listener/paintable/screen/etc.
We may want the widget to be the owner of everything (and keep the
painable/listener internal API) which is likely the most convenient from
an object ownership standpoint.
