From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754196AbbCYPTR (ORCPT ); Wed, 25 Mar 2015 11:19:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34206 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753662AbbCYPTP (ORCPT ); Wed, 25 Mar 2015 11:19:15 -0400 Message-ID: <1427296740.23304.21.camel@nilsson.home.kraxel.org> Subject: Re: [PATCH] Add virtio gpu driver. From: Gerd Hoffmann To: Daniel Stone Cc: virtio-dev@lists.oasis-open.org, "Michael S. Tsirkin" , "open list:ABI/API" , Rusty Russell , open list , "open list:DRM DRIVERS" , "open list:VIRTIO CORE, NET..." , Dave Airlie Date: Wed, 25 Mar 2015 16:19:00 +0100 In-Reply-To: References: <1427213239-8775-1-git-send-email-kraxel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Di, 2015-03-24 at 22:50 +0000, Daniel Stone wrote: > Hi, > > On 24 March 2015 at 16:07, Gerd Hoffmann 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