On Di, 2015-03-24 at 22:50 +0000, Daniel Stone wrote:
> Hi,
>
> On 24 March 2015 at 16:07, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
> > +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> > + struct drm_framebuffer *fb,
> > + struct drm_pending_vblank_event *event,
> > + uint32_t flags)
> > +{
> > + return -EINVAL;
> > +}
>
> I'm not going to lie, I was really hoping the 5th (?) GPU option for
> Qemu would support pageflipping.
As Dave already pointed out there is a WIP patch for that, it'll be
there.
While being at it:
- bochsdrm (qemu -vga std driver) supports pageflip since 3.19.
- cirrus is more or less a lost case, we mimic existing hardware
from the 90ies here and it simply isn't up to todays needs for
many reasons. Just stop using it.
- qxl -- hmm, not sure, there is this "primary surface" concept in
the virtual hardware design, which doesn't mix very well with
pageflip I suspect.
> Daniel's comment about conversion to
> atomic is relevant, but: do you have a mechanism which allows you to
> post updates (e.g. 'start displaying this buffer now please') that
> allows you to get events back when they have actually been displayed?
It's possible to fence the framebuffer update requests, so you'll be
notified when the update has reached the qemu ui code. Typically the ui
code has queued the update at that point. So with a local display (sdl,
gtk) showing up on the screen should be just a pageflip (on the host)
away. With a remote display (vnc) it will take a little longer until
the user will actually see the update.
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
