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@xxxxxxxx> wrote:
On Wed, Jun 15, 2016 at 9:29 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote:
> On 14.06.2016 18:35, Daniel Vetter wrote:
>> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer <michel@xxxxxxxxxxx> 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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
