linux-kernel - Re: [PATCH 2/2] drm/virtio: send vblank event on plane atomic update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPj87rO5M3u-X6O6kOqcaXXM_gndAqE22Hr_oJ8Xj20idXaJtQ@mail.gmail.com>
Date:	Tue, 22 Mar 2016 13:17:24 +0000
From:	Daniel Stone <daniel@...ishbar.org>
To:	Gustavo Padovan <gustavo@...ovan.org>
Cc:	Gerd Hoffmann <kraxel@...hat.com>, David Airlie <airlied@...ux.ie>,
	"open list:VIRTIO GPU DRIVER" <dri-devel@...ts.freedesktop.org>,
	"open list:VIRTIO GPU DRIVER" 
	<virtualization@...ts.linux-foundation.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] drm/virtio: send vblank event on plane atomic update

Hi,

On 21 March 2016 at 19:23, Gustavo Padovan <gustavo@...ovan.org> wrote:
> @@ -96,6 +98,11 @@ static void virtio_gpu_plane_atomic_update(struct drm_plane *plane,
>                                       plane->state->crtc_y,
>                                       plane->state->crtc_w,
>                                       plane->state->crtc_h);
> +
> +       spin_lock_irqsave(&crtc->dev->event_lock, flags);
> +       if (crtc->state->event)
> +               drm_crtc_send_vblank_event(crtc, crtc->state->event);
> +       spin_unlock_irqrestore(&crtc->dev->event_lock, flags);

This seems like the wrong place to do it, in that it will generate one
flip event per plane, rather than one per CRTC. So this should
probably be done in the overall atomic_commit hook I think.

Also, without some kind of delay, this means that we'll generate
flip-complete events immediately, which will cause compositors like
Weston to render infinitely fast. It's probably worth looking at what
happened when this came up with Bochs - I'm not sure if we fake a 16ms
delay, or refuse to do async modesets, or what.

Cheers,
Daniel