[RFC] wl_surface video protocol extension

[Axel Davy]

On Mon, 28 Oct 2013, Pekka Paalanen wrote:

>
> The only immediate effect I could see for the protocol proposal is
> to replace the frequency field in a "monitor refresh rate changed"
> event with a min and max duration, or whatever that could actually
> describe how GSYNC affects timings.

I don't understand in which situations you would need to know this 
refresh rate. Again, I advocate to do the same thing than the X present 
extension: the ability to ask the frame to hit the screen at a specific 
ust 'if possible' and get the feedback at which ust it did actually hit 
the screen. If a client wants to estimate the refresh rate, it can.


> I also expect video player timing algorithms to need to actually
> take GSYNC into account, or they might become unstable as there is
> no constant refresh rate. At least they would need to know about
> GSYNC to take advantage of it.
>

The best for video players is the ability to ask the frame to be shown 
at a specific ust and get the feedback at which ust it did hit the 
screen. Then they don't have to care much about refresh rate.

> IOW, I'm not sure it's worth to design support for GSYNC at the
> moment. I am tempted to say that let's leave it for another
> extension (should not be too hard or invasive to add later, as the
> only thing changing is the concept of output refresh rate, right?),
> and wait for the hardware to be widely adopted. Oh, and also driver
> support?

I see no real issue to support GSYNC.


Axel