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

[Daniel Vetter]

On Thu, Jun 16, 2016 at 3:02 PM, Rainer Hochecker <fernetmenta at kodi.tv> wrote:
> 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.


If you do vblank support right (which means GLX_OML_sync_control, it
should work on mesa/glx but not anywhere else unfortunately) you get
both. That's what I mean with calling the vblank ioctl directly is a
hack: It's only really one half of correctly done a/v sync, you get
the clock source but still have no idea when the frames actually show
up. GLX_OML_sync_control (and a port to EGL/wayland, if someone
bothers with that) gives you that control, plus ofc still a clock
source which is as accurate as the current one (since it's the same).

Note that DRI2/DRI3 and wayland all support this already, it's just a
matter of wiring it up as an EGL extension. And of course it won't
work on nvidia blobs because they just suck at this and don't want to
let apps control all the double/triple buffering and whatever else
they have in their driver.

Note that the only reason this works on mesa is because Mario Kleiner
really cares about it, and fixed up all the bugs across the entire
stack (meas, X, kernel drivers). Mario might be interested in an EGL
version of all this, not sure. Adding him.

Oh and: Please feel free to add other video players and folks
interested in this, I don't know them really at all.

Cheers, Daniel

>
> 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
>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch