[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Rainer Hochecker]

Daniel,

Peter posted me some snippets about your discussion around vblank that
confused me. Our use case is as follows:
We synchronise our video player clock to the pace of the display. Assume we
play some 23.976 content and the actual refresh rate is 24hz. We increment
the clock every vblank, that makes the clock run faster. Audio is resampled
to the faster running clock.
For this we just need an event fired for vblank.

Another requirement not directly related to 1)
We would like to know when a frame in actually presented on screen. Now
this is only guessing.

Rainer

On Wed, Jun 15, 2016 at 10:57 AM, Daniel Vetter <daniel.vetter at ffwll.ch>
wrote:

> On Wed, Jun 15, 2016 at 9:29 AM, Michel Dänzer <michel at daenzer.net> wrote:
> > On 14.06.2016 18:35, Daniel Vetter wrote:
> >> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer <michel at daenzer.net>
> wrote:
> >>> On 14.06.2016 18:03, Daniel Vetter wrote:
> >>>> Somehow this escaped us, this is a KMS ioctl which should only be used
> >>>> by the master (which is the thing that's also in control of kms
> >>>> resources). Everything else is bound to result in fail.
> >>>>
> >>>> Clients shouldn't have a trouble coping with this, since a pile of
> >>>> drivers don't support vblank waits (or just randomly fall over when
> >>>> using them). Note that the big motivation for abusing this like mad
> >>>> seems to be that EGL doesn't have OML_sync, but somehow it didn't
> >>>> cross anyone's mind that adding OML_sync to EGL would be useful.
> >>>
> >>> That may be one motivation, but it's certainly not the only one.
> >>> DRM_IOCTL_WAIT_VBLANK is used by apps which don't use EGL or any
> similar
> >>> API at all.
> >>
> >> Hm, what else?
> >
> > Off the top of my head, I know specifically about compton and xfwm4.
> > There's certainly more.
>
> But do they anything more fancy than what could be achieved with
> OML_sync too? Or is the issue that they don't want to use EGL/GLX? In
> that case I think it's reasonable to ask them to use bare-metal
> Present, since that's not any less portable than using the vblank
> ioctl.
>
> > Note that as I mentioned before in the other thread, I absolutely agree
> > that DRM_IOCTL_WAIT_VBLANK isn't supposed to be used directly. But the
> > fact of the matter is that it is being used like that (possibly has been
> > since before the DRM master concept even existed), and presumably it
> > actually works with simple setups (which might be the majority). So
> > there might be some backlash if it suddenly stops working.
>
> Fully agreed. Hence just RFC, and yes we need to get the EGL extension
> in place first, and at least kick most of the popular apps to have
> their code ready, and wait a bit, and wait some more, before we can
> nuke the ioctl from the kernel for non-master. It'll probably take 5
> years if we're fast :( I do think that we should be ok with breaking
> the last few hold-outs, but we definitely need to have an alternate
> solution for EGL ready. Hence why I want to know whether there's
> anyone who's using this outside of EGL.
>
> Really this was just drive-by that I spotted while looking around at
> stuff for our other discussion around vblanks.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/85b087df/attachment.html>