Local Display Direct Flip Feature Discussion

Gerd Hoffmann kraxel at redhat.com
Wed Dec 19 11:26:16 UTC 2018


  Hi,

> > Isn't a framebuffer just a gem object with metadata (fourcc, width,
> > height, stride, ...) attached?  So I'm wondering how that works in
> > detail.  What happens on page-flip?  Do you make the framebuffer
> > reference another gem object then?  Or do you blit the guest display
> > to the framebuffer?
> The special DRM framebuffer is transparent to the guest display driver.
> We just want to use this object to save the guest framebuffer info in
> host-side.

Hmm, so this object isn't a normal drm framebuffer.  You are just
masquerading it as drm framebuffer, so you can assign it to a
drm crtc or drm plane.

I'm not convinced this is a good idea.

It makes sense to allow mapping guest outputs to host outputs.  I think
it is more useful to handle that at crtc level not plane level, so it'll
work for both primary and cursor plane.  I think it would be cleaner
to introduce new drm (generic or i915) APIs for that instead of creating
special framebuffer objects which behave in non-standard ways.

Alternatively try to tackle the problem in a completely different way.
Right now qemu will check for display changes using a timer.  We could
add some page flip notification mechanism (using an eventfd for example)
so qemu can update the host plane (or notify spice client) instantly
instead of waiting for the next display refresh timer tick.

cheers,
  Gerd

PS: will be offline until jan 7th starting dec 21st.


More information about the intel-gvt-dev mailing list