[RFC] wl_surface video protocol extension
davy at clipper.ens.fr
Mon Oct 28 13:18:45 CET 2013
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
I see no real issue to support GSYNC.
More information about the wayland-devel