RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

[Jerome Glisse]

On Thu, Jun 14, 2012 at 1:19 PM, Joakim Plate <elupus at ecce.se> wrote:
>
>> >
>> > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000.
> Only
>> > issue is that changing it will break any app relying on it being REALTIME
> clock.
>> >
>>
>> App that rely on it being anything special are badly broken and i
>> don't think there is any such app. The specification strongly stress
>> that app should make no assumption about it.
>>
>
> While that may be true... Since there is no other API for getting this UST
> clock, it's somewhat limited in use. Even if i know vsync happened at time X, if
> don't know what time it is "now" how can i make use of it?
>
> Spec says: "The Unadjusted System Time (or UST)
>    is a 64-bit monotonically increasing counter that is available
>    throughout the system."
>
> If across the system, the only API to get to this value is through GLX api, it's
> rather hard to make use of.
>
> For example syncing audio to vsync. One need to sync audio output written to
> audio renderer now, with this clock.
>
> Also regarding relying on current behavior... Even if this change is made now,
> there will be a lot of system with the old behaviour. So knowning if the change
> has been made in a system is crucial for supporting both / not enabling when
> feature is unreliable.
>
> /Joakim
>

This extension is not for predicting when is the next vblank and it's
wrong to try to use it for that. My understanding is that you should
use this extension for instance to show N video frame per second,
based on the number of frame you play per second you can synchronize
sounds output.

Cheers,
Jerome