Michel Dänzer <mic...@daenzer.net> writes: > With variable refresh rate, it could certainly be useful for the kernel > to have this information as early as possible. It shouldn't make any > difference with fixed refresh though, since the kernel should always be > able to hit the next refresh in that case as long as the fences for the > flip signal in time for vertical blank.
Although, if the application is mixing present_period and display_timing operations, things can still get mixed up -- a frame with present_period followed by a frame with display_timing can invalidate the computed next frame time. Applications doing that may not get the best possible result... Ok, it sounds like I should at least go clean up the implementation and make it into something not quite so embarrassing to me. Going forward, how can we provide this to application developers for experimentation? Would we consider including it in a release once reviewed within the Mesa community? -- -keith
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
