v2: improved swap/MSC-wait scheduling in DPMS-off state

[Michel Dänzer]

On Mit, 2013-05-08 at 22:39 -0400, Ilija Hadzic wrote:
> The following patch series is a version 2 of the patches
> sent about two weeks ago [1] with the objective to add full
> emulation of a running CRTC while the display is in DPMS-off
> state. This series addresses the following issues:
> 
> 1) Fixed an incorrect comment as pointed by Richard Wilbur.
> 2) Added conditional #define of DRM_CAP_TIMESTAMP_MONOTONIC
>    as requested by Michel Dnzer.
> 3) Fixed two failures of glx-oml-sync-control-waitformsc piglit
>    test (last patch, which is new, and patch #7, which existed before
>    but is now amended) address the issue (see the commit messages
>    for details).
> 4) Changed the way the last known vblank rate is stored (see commit
>    message in patch #5 for details).
> 5) Simplified a few things (see patch #9 for details)
> 6) Amended other patches as needed to reconcile them with
>    the above changes.
> 
> There was a third kind of failure in piglit where test  
> glx-oml-sync-control-swapbuffersmsc-return was failing with incorrect
> SBC [2]. That problem is outside the scope of this patch series, it existed
> before and cannot be fixed with DDX patches. I tracked it all the way
> up to DRI2SwapEvent function in DIX and just before DIX calls
> WriteEventsToClient (i.e., end of hardware-DDX-DIX path) the SBC is
> still correct. Then I tracked it from the top down and got to
> dri2XcbSwapBuffers in Mesa (everything below that is generic message
> processing code from the server) and SBC is incorrect there. So I think
> we are dealing with some ugly corruption of messages between the X server
> and the application, which I, admittedly, don't fully understand. However,
> what I did proves that it's unrelated to DDX, so it's a topic for a different
> thread on a different mailing list.
> 
> Hopefully, this patch series addresses all concerns and problems
> raised so far.

I removed the incorrect (and irrelevant) statement that the refresh rate
is always an integer from the log of patch 5 and pushed the series.
Thanks!


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer