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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
